We have four senior developers at 3S Coding. The youngest is in his late thirties. A few months ago he opened a Zoom meeting with a clean argument: we are old school, we are slow on AI adoption, and we are going to lose to developers who are not. He said it calmly. He genuinely believed it.
I did not argue. I needed to verify it for myself โ and yes, I know you have seen this movie before. So had I. That is exactly why I had to run it.
The setup
The deal was simple. One team: the youngest of us, using any AI coding agent he wanted, any subscription, no restrictions. The other team: three senior developers and our in-house designer, building the same thing the old school way. We were allowed to use AI for troubleshooting โ the way we used to use Stack Overflow, not the way a ghostwriter uses a client brief.
The project was a medium-complexity internal tool. Front end, back end, database. Real logic and calculations in it โ not just CRUD operations. No mobile application because none of us had the patience for that discussion. Deadline: three weeks.
We agreed on three rules before anyone opened a code editor:
- Whatever code you deliver is your code. You own it, you understand it, you are responsible for it.
- Test coverage minimum 80%. Real tests โ not cosmetic ones written to hit a number.
- The code gets reviewed. Not just run.
Three weeks
The AI team started with prompts. The old school team started with a war room.
We worked with the designer to go through every screen, every edge case, every state. We defined the architecture, agreed on the stack, set milestones, divided the work. The database schema alone took two days of conversation before anyone touched a keyboard. By the end of week one, the designer had delivered the first screen designs and the back end had shape.
The AI team member was done with the tool in two days.
I will let that land for a moment.
He spent the remaining three weeks reading the code, refactoring, and holding it to the standards we hold all our work to. By the end of week three, he had not finished reading all of it. AI does not write sparse code. It writes thorough, sometimes exhaustive code โ more than you asked for, organized in ways that make local sense and accumulate into something large.
The results
We met in person at the end of week three. Each team presented the work.
My team โ three senior developers working more than eight hours a day, plus a designer who put in around twenty hours on the interface โ delivered 85% unit test coverage, 100% end-to-end and integration test coverage, production-ready software. Poorly documented because time did not allow for that. Could use some refactoring in places. Solid.
The AI team โ one senior developer and roughly $300 in tokens โ delivered 90% coverage across all test types, well documented, production ready. Technically finished in three days. The three weeks were spent on quality control.
From a business perspective, the math is uncomfortable. Three senior salaries plus a designer versus one senior salary plus $300. That gap is real and pretending otherwise would be dishonest.
What I will say about the AI output is this: it produced a lot of code. More than necessary. The kind that looks intentional on every line โ and some of it is not. That is a different category of technical debt than the kind we know how to manage. Our code had rough edges we could name. The AI code had rough edges that required archaeology to find.
Then we brought in the marketing manager
This was the honest part of the experiment. We wanted to isolate the variable: was it the AI that delivered, or was it the senior developer who guided the AI?
We brought in our marketing manager. Smart, runs the business side of things fluently, not a developer. We explained what we were doing, gave her the requirements, guided her briefly at the beginning, then stepped back. She sat in front of a terminal โ she called it "hacker mode," which was appropriate โ gave one prompt, and let the AI run on autopilot. A few hours later, the screen said the job was done.
We ran it. It worked. Then we started checking.
Some requirements were missing. Some parts broke on edge cases that were not exotic โ just real inputs any business user would eventually enter. Database security was thin. Some fundamentals were wrong in ways that would not show up until something broke in production. Nothing catastrophic. Nothing deliverable either.
What this actually means
AI is not bad. That would be the embarrassing conclusion and the wrong one.
What my youngest colleague demonstrated is that one experienced developer with the right AI tools can produce what three experienced developers produce without them. That is a real shift. I accept it fully. The economics have changed and anyone who tells you otherwise is protecting something other than their clients' interests.
What the marketing manager demonstrated is that "AI can write code" and "anyone can build software" are two different sentences. Only one of them is true.
The same knowledge in different hands makes all the difference. That was Goethe's point in 1797. It is still the point.
Goethe wrote the Sorcerer's Apprentice as a poem. The apprentice knew enough magic to start the brooms. He did not know enough to stop them. The sorcerer returns, reads the situation in seconds, and corrects it โ not because he has a better tool, but because he has spent a lifetime with the craft.
My AI subscription could stop tomorrow. That would not stop me. I know the craft. I have walked the path โ broken things in production, debugged at 2am, carried the weight of decisions that could not be undone. That is not nostalgia. That is what makes the tool useful instead of dangerous.
Not everyone agrees with this approach. That is fine. My reasoning is straightforward: if the AI stops, I pick up and continue. The code is mine. It always was.
