The model matters less than the scaffolding around it

AI Native DevCon is Tessl’s event for engineers building with and around AI agents. The framing is deliberate: not people using AI tools to write code the same way they always have, but people rethinking how software development itself works. Around 650 people were there in person, across four themes: context engineering, agent orchestration, the platform around the agent, and the organisational side of adopting any of it.

A lot of the speakers had already made the switch, and were reporting back from the other side of it. That made the day less about whether this is coming and more about what it actually takes.

The model is not the hard part

The clearest message across the talks was that the choice of model is becoming a smaller decision, and the scaffolding around it a much bigger one. What matters is the documentation, the tests, and the logs that let an agent tell whether it has succeeded, plus the context and the guardrails that let it work at all.

Put like that, development starts to look different. Less about the lines of code that come out, and more about the hypothesis going in, the plan, and the measure of whether it worked. A recurring idea was the reusable skill: when an agent hits a problem and works out the fix, you capture that as something the next agent can use, then version it and share it across the team.

Discovery matters more than ever

The line we keep coming back to was blunt: bad things get worse, and good things get better, with AI. If your tests, your delivery pipeline, and your coding standards are not in good shape first, an agent will find the gaps and amplify them. The groundwork we already believe in is not optional in an AI-native setup, it is the thing that makes it safe to let an agent loose at all.

Most of the case studies were greenfield, but a few speakers took on the harder problem of bringing this into existing systems, which is most of the real world. The approaches were familiar to anyone who has done careful legacy work: pseudo-greenfield for isolated new features, the strangler fig for gradual replacement, branch by abstraction where the old and new run side by side. The common thread was to map the codebase first, its coverage gaps, its dependencies, its performance baselines, before handing any of it to an agent.

Where the human goes

Opinions on this ranged widely, from “let the agent run” to “humans matter more than ever, just doing different work”: less writing and reviewing code, more discovery, planning, and judgement, with a much sharper eye on security. There was no clean answer on where the human belongs in the loop, only agreement that the oversight has to be deliberate rather than assumed.

What we took from it

The honest headline is that the shift is further along, in real production teams, than we had assumed. That is worth sitting with rather than shrugging off.

It also plays to our strengths. The care we put into discovery, tests, and code quality is exactly the foundation this approach needs, which puts us in a good place to adopt it on our own terms. The open question, and it is a real one, is how engineers keep their craft sharp when an agent is writing a lot of the code. We would rather work that out on purpose than back into an answer, and it is the same position we take on our AI page: a person owns the result.