AI Has Shifted Engineering from Production to Judgement: Insights From a Senior Developer 

KRS collage

AI-assisted development is changing how quickly software can be built. But faster code generation doesn’t mean the developer’s role disappears; it just changes where their time and expertise go.

In this blog post, KRS senior developer Miengha Behardien shares what AI-accelerated development looks like from inside her workflow: where AI adds the most value, what still requires human judgement, and why the developer’s role is shifting toward directing, reviewing, and improving what AI produces.

AI has changed where we spend our time

I use AI throughout my day, from planning and debugging to writing code and working through possible solutions. Claude Code is my main tool, but I don’t approach every task the same way.

If something is well defined and I can give the agent clear instructions, it’s relatively easy to hand over. More nebulous, discovery-type tasks require a more hands-on approach with the AI agent, guiding it in the direction I want.

That changes constantly depending on the work. You learn to read the problem first and decide where the tool can actually add value.

The questions we ask before code ships

Regardless of how much AI contributed to the code, I still need to understand what it produced and whether it is actually the right solution. 

At KRS, we work through the same questions before anything goes out: 

  • Should I let AI do this? 
  • Did it misunderstand the brief? 
  • Is this over-engineered? 
  • Is this maintainable? 
  • What should I test? 
  • What don’t I need to test? 

AI can produce a lot of code very quickly, so you can end up with a lot more to review if you’re not deliberate about what you’re asking it to do. The developer still needs to make that judgement. 

The challenge isn’t always that AI is wrong

My biggest issue with AI-generated code isn’t that it’s constantly wrong. It’s that it doesn’t always find the simplest way to solve the problem. It can take the longest route when a much simpler approach would have worked.

That’s where code bloat becomes a concern. The fact that something works doesn’t automatically mean it’s good software. It still needs to be understandable, maintainable and appropriate for the system it’s going into.

There’s evidence this is a broader concern. Sonar’s 2026 State of Code Developer Survey found that 40% of developers say AI has increased technical debt by generating unnecessary or duplicate code.

Part of that makes sense when you think about how these models work. AI has access to a wealth of knowledge, but it was trained on human code with human errors, which can be inadvertently perpetuated.

When AI gets it wrong, I look at the instructions

When an AI agent produces something that isn’t right, I don’t just fix the code and move on. I go back to the instructions I gave it.

If it misunderstood something, I’ll explain what it got wrong and why. I’ll go back and re-engineer, and note the issue so I can avoid the same problem in future.

There’s a feedback loop there. You’re not just improving the code that came out of the interaction; you’re improving how you communicate with the agent too.

That doesn’t mean I trust everything it produces. Every response still needs review. The point is to get better output over time while keeping the developer responsible for deciding whether that output is good enough.

My AI agents have boundaries

There are things I don’t allow my agents to do without my approval.

The first: my agents are never allowed to commit or push code without my approval, because AI can produce something that looks right on the surface while completely missing the underlying problem.

The second: if requirements are unclear, the agent asks questions. It doesn’t guess.

These rules sit alongside KRS’s existing engineering processes. AI is another tool in the development workflow, not a replacement for the processes that keep software reliable.

AI has changed how I brainstorm

This is probably one of the areas where AI has genuinely improved my work.

Previously, we would bring the whole team together to brainstorm an approach from scratch. Now I can take a technical problem to Claude first and ask it to suggest possible solutions, work through the pros and cons, and point out gaps I might not have considered. Then I bring those findings to the team.

The team discussion hasn’t gone away. If anything, we get further into the discussion because we aren’t starting from a blank page. AI gives us something to react to. We can challenge the suggestions, combine ideas, and decide what actually makes sense for the project.

It hasn’t replaced collaboration. It has given us a better starting point for it.

What clients should ask about AI-generated code

My answer is that trust comes from the process, not the tool. All code gets checked and tested by me and by the rest of the team. We put focused review and testing where it actually builds confidence, rather than trying to test everything equally.

Part of that process is adversarial QA: using a different AI model to review code than the one that wrote it. Two models checking each other’s work catches things one model working alone would miss.

If you’re evaluating a development partner, questions about the review process and testing matter just as much as understanding how they use AI.

AI doesn’t replace the fundamentals

It’s tempting to think that because AI can write code, developers no longer need to understand the fundamentals of programming. I don’t agree.

Understanding the fundamentals is more important than ever as many developers now work heavily with AI. You need to know what good code looks like before you can reliably judge what an AI has produced.

Training in prompt engineering and agentic development can help developers get more out of these tools, but those skills sit on top of software engineering knowledge. They don’t replace it.

The better you understand the technology, the more effectively you can use AI, because you can tell it what you need, recognise when it’s gone in the wrong direction, and steer it back.

What this means for developers

AI is changing the skill set developers need, but I don’t think it’s making experienced developers less relevant. If anything, the parts of the job that require judgement matter more.

The most exciting part of AI-assisted development for me isn’t that I can write code faster. It’s that I can take on problems that might previously have felt too large to tackle alone. I can explore more options, get through unfamiliar codebases faster, and arrive at team discussions with more ideas already worked through.

AI gives me another way to think through a problem. But the value comes from the combination of the tool and the developer using it. The AI can generate possibilities and implementation. The developer brings the context, judgement, and accountability needed to turn those possibilities into software that actually works.

If you want AI-accelerated development without losing engineering rigour, get in touch with KRS.

Previous posts