The trap I fell into
In my last post I admitted I'd fallen into a trap. When I started coding with all the new tools, I got hooked on the prompt-feedback loop — the thrill of watching working apps appear in minutes. What I didn't see at first was the quicksand underneath it. I lost a lot of good hours begging Claude or Cursor to do what I actually wanted.
I'm not the only one
Then I watched a talk by Matt Pocock on exactly this subject.
He walks through the mistakes engineers and architects keep making as they adopt these tools, and he clearly speaks from experience — he's been there, has the scars, learned the lessons, and lived to tell the tale. What follows are a few of his points that stuck with me, plus my own take on them.
The illusion of cheap code
Pocock's central argument is that today's tools make code feel cheap. Type a paragraph and an agent hands you 3,000 lines that might do what you asked. For a throwaway script you'll run twice, fine. For production software — enterprise software especially — that illusion turns into real problems fast. As he puts it, bad code is now the most expensive it has ever been.
Back to basics
Throughout the talk he quotes the classic software texts I read years ago. Those lessons are woven into how I work, but I'll be honest — I'd forgotten a lot of the specifics. So I ordered physical copies to keep on my desk again. The two he leans on are A Philosophy of Software Design by John Ousterhout and The Pragmatic Programmer by David Thomas and Andrew Hunt.
Every programmer I came up with had read both. It was good to hear him reach back to them, because the lessons in each shaped my early career, and it's strange and satisfying to see how directly they apply now.
Complexity is the enemy
A big chunk of the talk is about complexity. Ousterhout's view, roughly, is that anything making code harder to understand is a source of complexity, and complexity is what erodes good design. I'd push it one step further: any complexity you don't need is technical debt you'll pay off sooner or later. The catch is that agents are very good at producing it.
I used to think complicated code was fine as long as the agent understood it. I just had to be clear about what I wanted. A lot of us learned the hard way that this isn't true.
A shared language
Pocock also points to the gap in shared language between the developer and the AI. This isn't new. It's the same gap that shows up when developers build software with subject-matter experts — most of the trouble isn't technical, it's that the customer and the developer are speaking past each other. I've watched it happen. A developer builds exactly what was asked, the customer requests what they think is a tiny change, and suddenly it's a week of rework.
Testing is hard
One of my earliest mistakes was trusting too much. I'd find a bug, ask the agent to fix it, and it would tell me with total confidence that it had. I'd run the whole build-and-deploy cycle only to find the original bug still there — or the next obvious one waiting right behind it.
A lot of that was on me. I know that even a few lines of code need tests that pass cleanly before anything ships. The good news is there are skills now that automate solid test generation, and once I started using them I made far better progress.
Deep vs. shallow design
One principle that stuck with me early on is building deep modules: a lot of functionality behind a simple interface, with the complexity hidden from whoever's using it. Shallow design is the opposite, and it's easy to recognize once you've been burned by it. You spend a day working with a module, then need something simple from it, only to find that the simple thing lives in a sister module that behaves slightly differently — and that this new module is missing something you'd been relying on. That's shallow design.
Agents will happily generate large, shallow designs. They look fine on day one and turn brittle by day thirty.
A resource worth knowing
After the talk I poked around Matt's site. Alongside the paid courses there's a lot of free material, including the skills he mentions. I installed his skills pack and tried a few. The grill-me skill is especially thorough — I wish I'd run it against a few of my past apps.
Wrapping up
Mostly I was relieved to learn I wasn't the only one hitting these walls. My one piece of advice: before you go build your own framework, go find experienced people like Pocock and see how they solved the problem first. More often than not, someone has already shipped a battle-tested skill or module — and given it away for free.