When I started programming, I wanted to learn everything about design patterns. After all, architecture and design seems to follow the ethos of "work smart, not hard" at a glance - think of what you want to build, then use clever and proven techniques to ensure everything goes smoothly at a fraction of the time. Sure, there will be some upfront cost, but that time will easily be saved because you did it the "right way" from the start, you didn’t cut any corners and are going to reap the rewards when you scoff at the clumsy engineers that have to rewrite their application because they didn’t know what an observer was!
So you go about your code - meticulously "decoupling" every element, using observer, mvc and event buses, along with TDD to ensure you aren’t making any mistakes alo…
When I started programming, I wanted to learn everything about design patterns. After all, architecture and design seems to follow the ethos of "work smart, not hard" at a glance - think of what you want to build, then use clever and proven techniques to ensure everything goes smoothly at a fraction of the time. Sure, there will be some upfront cost, but that time will easily be saved because you did it the "right way" from the start, you didn’t cut any corners and are going to reap the rewards when you scoff at the clumsy engineers that have to rewrite their application because they didn’t know what an observer was!
So you go about your code - meticulously "decoupling" every element, using observer, mvc and event buses, along with TDD to ensure you aren’t making any mistakes along the way that could ripple through your system. You feel proud of what you did. That is until you notice that TDD does not help you pass the most important test - building something that users want. And let’s face it, unlike what your professor tried to make you believe: design patterns don’t make code easier to read, they make it harder. Breaking up your classes into multiple different views, models, controllers etc. is not going to make it easier to understand than just having a single, well confined class that does everything you need.
Noticing this pattern, over time my preference shifted from doing things "the right way" to doing things in the way that gets stuff done, for my side projects at least where the code was not put up to the scrutiny of a co-worker’s code review. This meant imperative, straight to the point code, with logic that fit together simply bundled into a class (often a singleton) and using ECS to have some basic structure and order for sequencing game logic (the pattern, next to dependency injection, I found to be indispensable when developing games). I found this way only has one major downside - certain parts of the application become harder to test as a unit. This is fine if you have a good integration test framework (which I do), since those catch most of the tricky bugs anyway at the downside of taking longer to run. However, as my tests are running in headless mode, testing ui was something I simply couldn’t do. My ui code was basically just the view, bundled together with state and glue code, called directly from other classes via dependency injection (yes, I injected views and ui components into ECS systems - deal with it).
However, when I started vibe coding, I started to notice something - writing code was no longer the bottleneck, validation and testing was. I could easily extend my code with features at a breakneck pace and writing tests all the same, but making sure all that code was actually working became increasingly more tricky. I noticed the trade offs of design patterns had fallen on their head. Who cares if refactoring was going to take a lot of time? AI will do it while I sleep. Who cares that using a pattern like MVC meant my code was split into different classes? AI can fit them all into one context window. Used to think TDD was a waste of time because you always found that after starting on the implementation you had to rewrite all your the tests? Me too, but now that AI is writing them and is doing so in a matter of seconds, that is no longer showstopper.
Case study: In the last few days, AI has been viciously rewriting my spaghetti views into neatly split MVC components, letting me test the controllers separately. In the future, I’ll be able to tell AI to test the UI logic of my game as well, allowing me to focus more on debugging the graphics and UX by hand. I’d never see the day, but vibe coding is making me become a design pattern advocate once again...
Files
King’s Path
Synergy-focused Tower Defense
| Status | Prototype |
| Author | thefakeborzi |
| Genre | Action |
| Tags | Tower Defense, Turn-Based Combat |
| Languages | English |
| Accessibility | Configurable controls, Interactive tutorial |
More posts
3 days ago
4 days ago
9 days ago
20 days ago
38 days ago
48 days ago
52 days ago
59 days ago
80 days ago