Yesterday, an Engineering Lead friend of mine called me in a panic. He took a deep breath and said:
"I am thinking of firing all 5 of my freshers. I am completely clueless."
He was frustrated, exhausted, and staring down the barrel of a massive deadline. He had been given exactly 7 months to take his startup’s core product from the boardroom whiteboard to a live production environment.
To achieve this, management gave him 5 junior developers (freshers with up to 2 years of experience), maximum-tier Claude subscriptions, and unlimited coffee.
For the first few weeks, he told me, it felt like magic. They went from PRD to code, from code to unit tests, and from unit tests to completely green sprints. They were moving at lightspeed.
But then, the honeymoon ended.
As the project gained significant progress and the codebase grew into a massive monolith, the illusion of speed shattered. If there was a minor bug in the code, the developers would try to fix it, and in the process, they would break 10 existing, perfectly stable flows.
Demos were failing back-to-back. The developers had stopped using their minds. They had completely surrendered to mindless prompting.
To see what was going wrong, my friend sat behind one of his developers to watch him code.
He was stunned. The developer didn't open the files. He didn't read the logs. He just opened the terminal and typed a command directly to the Agentic AI:
“Find me the Home page and check where this state propagation is happening.”
My friend was triggered. How will this ever go live? How will they handle real traffic if nobody actually knows how the application works?
When he told me this, I realized exactly what was happening. We are confusing "Generating Code" with "Engineering Systems".
Here is the solution and framework I explained to him to save his team and his launch.
The Diagnosis: The Shift to "Vibe Coding"
I told him that his team was suffering from the exact trap of the new Agentic AI era.
Earlier, with chat-based AI usage, there was still a layer of inherent friction. A developer had to copy code, paste it, read it, and integrate it. There was some basic awareness of what, where, when, and why.
But with Agentic AI running directly in the terminal, the AI generates, modifies, and deletes 30 files across the codebase in a single prompt. If there is a bug, the junior developer has absolutely no clue that a file called HomepageService even exists, let alone how it interacts with the database.
We have officially entered the era of "Vibe Coding".
This is when engineers prompt features into existence at light speed, trusting the LLM more than the application logs, and hoping the code just works.
But here is the hard truth about software engineering: Code is not an asset. Code is a liability.
AI has driven the cost of writing syntax to absolute zero, but it has skyrocketed the cost of reading and maintaining it. Every line of code your AI agent generates must eventually be read, tested, debugged, and secured by a human.
The Solution: 4 Steps to Rebuild Engineering Judgment
I told my friend he didn't need to fire his team. He just needed to change their environment and redefine what "coding" meant in his startup.
1. Kill the Agent, Keep the Co-Pilot (Temporarily) You need to reintroduce friction. Disable the terminal agents that can autonomously edit 30 files at once. Force the junior developers back to standard chat-based AI where they have to manually move the code and integrate it. They need to feel the pain of the architecture they are building, otherwise, they will never understand it.
2. Shift from "Generating" to "Code Archeology" In this era, the premium skill is no longer generating code—it is Code Archeology. You must train your freshers to look at a block of AI-generated spaghetti and figure out why it did what it did. Make it a rule: No PR is approved unless the developer can verbally explain the execution path of the code the AI generated.
3. Design First, Prompt Second AI is a pattern-matching machine, and your codebase is its training data. If you feed it hasty, unorganized patterns, it will create chaos at scale. Force the developers to write a brief, plain-English architectural plan before they prompt the AI. They must define the components, the state propagation, and the data flow themselves. Simplicity is the only thing AI can't hallucinate.
4. Change the Definition of "Done" Right now, your developers think "Done" means the AI outputted a script without a syntax error. You must change the culture so that "Done" means the developer understands how the system will handle unexpected failures, edge cases, and scale.
My friend listened quietly, but he had two immediate concerns.
"Gunjan, if I take away their agentic tools and force them to do architectural reviews, it’s going to slow us down massively. I have a 7-month hard deadline from the board."
Me: "You aren't actually moving fast right now. You are just accumulating technical debt at the speed of light. If you automate a broken, mindless process, you don't get speed—you get a Distributed Denial of Service attack on your own team's focus when the bugs start rolling in. Slow down your generation so you can speed up your execution."
Friend: "So I shouldn't fire them?"
Me: "No. You don't have bad developers. You have unguided prompters. The race to type the fastest is over; the machines won that race. Your job as an Engineering Lead is to stop treating them like factory typists and start training them to be System Owners. Teach them to be mapmakers."
Conclusion
The future of software isn't just written. It's designed.
Agentic AI will allow anyone to build a shallow prototype. But when the system scales, breaks, or requires complex state management, the "vibe-coded" scripts will collapse.
Don't let the robot drive. It doesn't have a driver's license. Take back the wheel, own your systems, and teach your juniors to do the same.