On 1 June 2026, 650 developers packed into The Brewery in Barbican for AI Native DevCon London, with another two thousand watching the live stream, including me. Forty-six sessions, fifty speakers, four tracks, two days of some of the most concentrated technical thinking on AI-native development happening anywhere in Europe right now. I built contAIn to solve exactly the problem they spent two days circling.
I kept hearing the same thing over and over: they are describing the direction layer but they don’t have a name for it.
Guy Podjarny, founder of Tessl and the organiser behind DevCon, opened with a keynote called Skills are the New Code, and the argument was precise: “the instructions and context you give agents are becoming a real unit of software, which means they need intent, review, testing, versioning, and maintenance in exactly the way that code does.” A SKILL.md file, he said, cannot be the chaotic group chat of your engineering process. He was not talking about code. He was talking about the governance of what directs the code, and he was talking, in developer language, about the layer that sits above the tool. The Tessl Registry, which now holds over 2,000 evaluated skills, gives you some sense of the scale of the problem.
Dana Lawson, CTO of Netlify, followed with a talk on what happens to a developer platform when half the users are no longer human. Agents need structured signals, machine-readable feedback, and clear next actions, because without them they guess, retry blindly, or break something with full confidence. She was describing what happens when there is no system telling the agent what it is actually supposed to do, and she was not calling it that, but that is what it was.
Then Paul Stack took the stage.
Paul is co-founder of Swamp Club, the company that grew out of System Initiative after they shut down six years of Rust code in January, let most of the team go, and started again with five people and a blank Miro board. He opened with a statement like a controlled detonation: “not a single line of code have I written since the end of January. Not a guideline, not a preference, agents write every line, and any pull request from a human gets deleted, not closed, deleted.” He is from Northern Ireland, and he mentioned in passing that if he swears he probably will not notice, which in the context of what he was describing I could relate to, having sworn at my laptop more than once before his segment.
What Paul does instead of writing code is own the architecture. The constraints, invariants and things that make the system coherent for a user across time. He wrote a blog post a few weeks before DevCon called The Vibes Don’t Scale, and the TLDR, as he put it himself, is that they do not. A single-line prompt will get you somewhere, but whether that somewhere is secure, useful, or coherent over time is a different question entirely. His bottleneck now, he said in response to a question from the floor, is not writing software at all. It is deciding what to build, because when you can spin up ten agents at the same time, building the wrong thing just means you have built the wrong thing ten times faster, and the system has no drive and no consistency going forward.
The bottleneck is thinking and direction.
Patrick Debois, who co-hosted the event alongside Sam Hepburn and has been described as one of the founders of DevOps, delivered his own session on The Rise of Agent Enablement, the organisational function that owns reliable agent adoption, defines standards for skills, evals and workflows, and sits alongside DevOps and Platform Engineering. He spent two days introducing speakers who were, in various registers and with various vocabularies, circling the same problem from different angles: generating output is no longer the constraint. Knowing what to generate, why, toward what end, and on whose authority is the constraint that nobody in the room has cleanly solved. They agreed on the problem with remarkable consistency, they did not name the solution.
Liran Tal from Snyk made a related point from a security angle, arguing that if a skill can influence agent behaviour it becomes part of your supply chain, which means you need to audit what you are using, understand what it instructs agents to do, and stop blindly installing context files because they look useful. The implication underneath that argument is that somebody has to be responsible for what the agents are told and somebody has to own the direction. The talk named the risk without quite naming the governance structure that would address it.
The answer was obvious to me, because I had already built it, organically, under pressure, while trying to contain my own projects. That is what contAIn is. Not a product I designed in the abstract, but a methodology that emerged from the precise problem this room spent two days circling. I can also tell you from the inside that things change fast and need checking regularly. The system is not a one-time build, it is a practice.
What DevCon named collectively, and without quite meaning to, is what Guy Podjarny called the context development life cycle: generate context, evaluate it, optimise it, distribute it, observe what happened, repeat. The human lives in that cycle. The agents handle the rest. The question that nobody fully answered across two days and forty-six sessions is what governs the human’s part, who owns it, and what it looks like when it is built properly.
That is where contAIn lives, not in the code, above it, and that is exactly why I keep saying the same thing; “humans above the AI loop, always because without a human to direct it, AI just goes off on its own little tangent and the amount of rework is more time consuming than the work itself.”
configure YOUR system. contAIn™ the chaos. control YOUR outcome.
This article was originally published on Substack.