Why AI coding tools need a new kind of engineering discipline, and what we’re doing about it

A while back, a team of our senior engineers tried something that is now pretty common. They took a feature they would normally estimate at around 16 hours and built it with an AI coding agent. It took about an hour, and it worked. The room was buzzing, and honestly, I was too.

Then a bug turned up. Not a crash, nothing dramatic. Just a quiet one that only appeared under certain conditions. The team spent more than 40 hours finding it.

I’ve thought about that a lot since. These weren’t beginners. They have debugged far messier systems than this one. What slowed them down was debugging code they hadn’t really thought through. Nobody on the team had a picture in their head of how the pieces fit together, because nobody had built that picture in the first place. The AI had. So they asked the AI for help, and it gave them confident answers that missed the actual cause. In the end, they did the thing they had skipped on day one: they sat down and read the code, line by line, until it made sense.

An hour saved. A week lost.

Then came campus hiring

Not long after, I was at a campus hiring drive. We gave final-year students a simple problem and asked them to write the logic on paper. More than one of them glanced at the sheet and then back at us. “I can’t do this on paper,” one said. “But give me VS Code and Copilot, and I’ll build you the whole application.”

What stuck with me wasn’t the answer. It was how comfortable they were giving it. There was no sheepishness at all, because as far as they were concerned, that’s just how software gets built now.

And to be fair to them, they’re not entirely wrong. These tools are remarkable. Give an AI agent a two-line prompt, and it will often hand back more than you asked for: error handling, logging, tests, sometimes even documentation. Anyone would be tempted to take that and move on.

But put the two stories side by side, and you see the same thing. A student who never learned to think a problem through, and experienced engineers who stopped doing it because the tool was fast enough to skip it. Different people. Same gap.

It’s not just the code anymore

If it were only about writing code, I’d worry less. Code has always been the easier part.

What concerns me is that engineers are now handing over the design thinking as well. Which database? Ask the AI. What happens when something fails? Ask the AI again. It will have an answer, and it will sound reasonable. It usually does.

But that thinking is the job. Understanding the problem, weighing the options, knowing what you’re trading away, making a call, and being able to defend it. That’s what separates an engineer from someone who operates a tool. Take it away, and you’re left with a very efficient prompt writer.

I said this to the students in the pre-placement talk that morning, and I’ll repeat it here. If all an engineer does is write prompts, they’re up against every clear thinker who writes good English. That includes arts and commerce graduates, many of whom will be better at it. Writing a good request is a useful skill. It just isn’t engineering.

I also told them what I believe is their real advantage: curiosity. AI knows a great deal, but it doesn’t know your situation. It doesn’t know your users or what went wrong the last time someone tried this. A curious person goes and finds out. They’re usually the person in the design meeting who says, “Wait, what happens if…?” and the room goes quiet for a second. Some of the best redesigns I’ve seen started with a question like that. The trouble is, curiosity needs a gap to grow in. If the AI fills every gap before you notice it, the question never comes.

More reviews won’t fix it

The obvious reaction is to add more checks, with more design reviews and more senior engineers signing off on everything.

I don’t think that works. AI lets one engineer produce in a day what used to take a week. If every piece of that needs a senior to review it, the seniors become the bottleneck, and we lose the very speed we were after. We’d be running a new-age tool through an old-age process.

So the question I kept coming back to was this: if AI helped create the gap, could it also help close it?

What we’re proposing: AI-Integrated Governed Engineering (AIGE)

That question led to something we’re calling AI-Integrated Governed Engineering (AIGE). The idea behind it fits in one line: AI should speed up engineering thinking, not replace it.

In practice, it changes how the conversation with the AI starts. Say an engineer tells the agent, “We need to send customers an SMS when their order ships.” A normal coding assistant would start writing code, but the AIGE agent asks questions first. What happens if the SMS provider is down? And if we retry, how do we make sure nobody gets the same message five times?
The engineer has to think through those answers. Once the picture is clear, the agent sums up the requirement and asks them to confirm it; from there, the work moves on to design.

Along the way, the agent keeps pushing. If an engineer picks a database, it asks why and what else they considered. Once the design is done, it changes the conditions. What if traffic grows ten times? What if the database goes down for five minutes? Someone who just accepted a generated design will struggle with those, while someone who understands it will usually enjoy them.

Only when the design holds up does the AI start generating code. At that point it can go as fast as it likes, because it’s building something the engineer actually understands.

Everything that comes out of these conversations, from the requirements to the assumptions nobody said out loud, gets linked to the code and tests that follow. So when something breaks six months later, the team isn’t guessing. They can trace it straight back to the decision behind it.

And because those links are checked automatically, gaps show up on their own. A requirement with no test gets flagged, and so does code that nothing asked for. Senior engineers don’t have to review everything anymore, so they can spend their time where their judgment really matters.

What this isn’t

I want to be clear about one thing. This is not about using less AI. Nobody is going back to writing everything by hand, and nobody should. AIGE works alongside Copilot, Claude, and the rest.

It’s about who does the thinking. The AI can suggest, challenge, and generate as much as it likes. The engineer still has to understand the problem, own the decision, and be able to explain it to someone else.

Think back to that team and their 40 hours. With the design questioned and understood up front, the code would still have taken about an hour. The bug would have taken hours to find, not a week. The hour saved would have stayed saved.

That’s the balance we’re after. Engineers who move at AI speed and still know exactly what they’ve built.

If that’s the kind of engineering culture you want to build, we’d love to show you how AIGE works in practice.