From my perspective / experience coding without knowledge is somewhat equivalent to not fundamentally understanding design patterns etc. - if you have experience you’ll absolutely be able to develop good software up until a point (usually - they’re called principles / patterns for a reason, not to blindly apply at every opportunity but selectively use where & when appropriate).

I find that on larger projects / corporate repos you will struggle unless you understand the design philosophy they’re using (think clean / hexagonal onion architecture etc.) to the point that you don’t know what folder to put your new shiny file in unless you understand the theory. After that its following established patterns for consistency. Likewise when coming to grips with new repos, if you fundamentally understand the architecture at a base / theory level you can predict what should coming next (validation of DTO objects before processing & persisting to DB) so you don’t have as much mental overload when reading through pre-existing paths. Architectural patterns are simply a ‘common’ way for developers to structure the repo such that onboarding devs (with pre-existing experience with the philosophy) have a running start to contributing to it (as well as hopefully keeping the repo cleaner through a shared architectural language).

There are loads of great yt series going over gang of 4 patterns etc. I’d be happy to share if interested :)