Shipping fast with AI but don't fully trust the code? I help developers 1:1 turn AI-built apps into something they understand and own. How it works →
A Reddit thread caught my eye this week. A developer spent three days with AI building out an authentication system, then realized the entire user flow was wrong. Not because the code was bad. Because nobody had mapped out what the system was actually supposed to do before line one.
That's what happens when speed gets decoupled from direction.
Faster, but facing a wall #
Someone nailed it in a comment on one of my LinkedIn posts:
"AI is an amazing accelerator. It can take us faster in the direction we are already facing. However, if we are facing a wall and start driving a fast car at full speed ahead, the result is easy to guess."
That's the trap with AI tools right now. They're incredible at making you faster, but they don't tell you whether you're facing the right direction. Three days of clean, working, AI-generated auth code is still three days lost if the user flow underneath it is wrong.
The Reddit poster didn't have a code problem. He had a design problem. Nobody sat down before line one and asked: what is this thing supposed to do?
Dan Hockenmaier put it in a quadrant: give powerful AI to someone without judgment and you get slop cannons; give it to someone with judgment and you get turbo brains. Same tool, opposite outcome.
Tokenmaxxing, the new LOC fallacy #
There's a name circulating for the current trend: tokenmaxxing. Pumping out as much AI-generated code as possible and treating volume as productivity. There's even a term for what gets shipped: dark code. Code in production that no human fully understands, owns, or documents. It echoes the 90s, when lines of code were treated as a productivity metric.
And now there's talk of loop engineering. Addy Osmani describes it as "replacing yourself as the person who prompts the agent. You design the system that does it instead." A loop is "a recursive goal where you define a purpose and the AI iterates until complete." He thinks it may be the future of working with coding agents, yet even he stresses that verification stays your job and warns of the "comprehension debt" that piles up when code ships without anyone understanding it. Which is the point: AI has no notion of what it's supposed to be building unless we keep telling it and course correcting. The moment we stop, it happily keeps generating code that isn't in the best interest of the system.
The job of a software developer was never just to write code. It's to build systems that are easy to extend and maintain. Writing code is one means to that goal. AI moved the cost of that one means close to zero. That's a real shift, but it doesn't change what the goal was in the first place.
A useful analogy I've seen making the rounds: when machines were invented to carry bricks, house builders didn't become obsolete. They started shipping faster. The role evolved from carrying material to planning and controlling the build. The same shift is happening to us now. The "coder" role compresses. The engineering role expands.
The foundations don't move #
Lance Gutteridge has a useful reminder in Avoiding IT Disasters. He describes how high-level languages came about: assembly required a near one-to-one mapping between code and machine instructions. Engineers wanted to express formulas, not bookkeeping. So FORTRAN was invented.
"Computer scientists started building what were called high-level languages. They were called high level because they were more removed from the machine. Assembly languages had an almost one-to-one correspondence between lines in the program and machine instructions. So that meant a lot of lines to get even simple things done."
When I read that, I see LLMs as the next layer of abstraction. They are. But every previous abstraction came with the same lesson: the new layer makes you faster at certain parts, but it does not relieve you of the responsibility to design the system underneath.
FORTRAN didn't make engineers obsolete. It made the ones who understood the problem more productive, and made the ones who didn't more dangerous. LLMs are doing the same thing, just at a higher level and at a faster pace, which is both exciting and dangerous.
Where speed actually pays off #
So speed only compounds when you know where you're going. You rarely nail that in one shot. You converge on it through tight feedback loops, shipping a slice, learning from it, and correcting. As Jason Gorman put it on LinkedIn:
"In software development, it's the feedback loops doing the heavy lifting. Not the plan. Not the execution. It's the
learningthat uncovers the real value, and teams should be optimising forthat."
That's what the Reddit developer was missing, not a perfect plan but a loop. Three days of AI-generated auth without validating the user flow isn't iteration. It's acceleration without feedback. AI didn't cause that. It just accelerated the gap.
The developers I see thriving with AI aren't the ones with the cleverest prompts or proficient tool use. They're the ones who do the design work first, break it into manageable chunks, manage context, and build proper test and evaluation harnesses. All of this requires fundamentals, taste, and judgment.
Keep reading #
Shipping fast with AI is the easy part. Knowing what to keep, rewrite, and trust is the hard part. I work with developers 1:1 to audit AI-built codebases, trace the real control flow, and make them something you can explain and own, without leaning on a chatbot. How 1:1 coaching works →