Software Engineering with AI Agents: A Reality Check

Eighteen months ago, asking an AI tool to build a working application from a prompt still felt close to science fiction. Today, that experience is becoming normal.

At the Avalia Tech Forum 2026, Olivier Liechti looked at what this change really means for software engineering. His point was not that AI has solved software development. It is that AI has changed the speed and scale at which software can be created, while leaving many of the hardest engineering questions very much intact.

AI gives engineering teams more room to explore. It can help improve software, make ambitious ideas more realistic, and speed up delivery. But speed is only part of the value. As Olivier put it, what is most striking is that fewer things now seem out of reach.

That freedom also creates a new problem: more code does not automatically mean better software.

Who is accountable for AI-generated code?

Software engineers remain responsible for what reaches production, whether the code was written by a person or generated by an agent.

That raises familiar questions around correctness, reliability, security, performance and maintainability, but in a new context. If an AI agent can generate large amounts of code very quickly, how much of it should engineers review? And what does it mean to trust the result?

For Olivier, reading AI-generated code is not only about checking whether it is correct. It is also about maintaining an understanding of what the system does.

That distinction matters. AI can produce working software faster than a team can absorb it. Without enough attention, the codebase can gradually become a black box: functional, but increasingly difficult for the people responsible for it to explain.

This is where Olivier introduces the idea of cognitive debt.

AI does not remove the need for engineering fundamentals

The arrival of AI does not make decades of software engineering knowledge obsolete. Architecture principles, testing practices and established design approaches still matter.

In fact, they can become even more important because AI agents can be explicitly guided to follow them.

One example discussed in the talk is agent harnesses: giving agents the right instructions, tools, context, and verification mechanisms for a particular job across the software development lifecycle. These harnesses can support tasks ranging from building software to performance testing, infrastructure work, and operating production systems.

But more tooling does not necessarily produce better results.

Olivier shared an experiment comparing a simple AI coding approach with a much more elaborate system of skills, workflows and sub-agents. The sophisticated setup consumed considerably more time and budget, yet the simpler approach produced the stronger result.

The lesson was not that harnesses are useless. It was that teams need to keep testing their assumptions. What helped six months ago may no longer be necessary as models improve.

The bigger risk may be losing sight of the “why”

The talk ends with a deeper concern: intent debt.

Teams can measure more pull requests, more code, and faster delivery and conclude that productivity is improving. But those numbers do not answer the most important questions: Why are we building this? Is it helping users? Is it contributing to a business outcome?

As AI increases the pace of development, engineers may need to deliberately slow down at certain moments. That means explaining decisions, reviewing work together, and making sure the team still understands both how the system works and why it exists.

The challenge of AI engineering is therefore not simply how to generate more software.

It is how to use the new speed and capability without losing the engineering judgment, shared understanding and business intent that make software valuable in the first place.