Note: This video and podcast was generated using AI, adapting the original content and technical insights created by the author of the Jax London blog post.

Most of us still picture DNA as a blueprint of life: a precise architectural drawing of a complete human being — or a cat, or an iguana. A left arm here, an eye there, every dimension fixed. That blueprint does not exist.

Instead of a blueprint, DNA provides a set of rules. They determine when a gene becomes active, where, and under which conditions. Those rules only work together with what is already there — the cell, its structure, and the signals from its environment. Without the cell, the rules do nothing.

Eoin Woods describes something very similar when he talks about software architecture. His cell just goes by a different name. Woods is a software architect and has been a regular JAX speaker for many years. He will give two sessions at JAX London this year. I recently sat down with him for an extended conversation. Here’s what I learned.

AI Does Not Forgive Bad Software Architecture

We know that AI is helping teams produce code dramatically faster than they could just a few years ago. On top of that, AI itself keeps improving, and so do the teams that learn new and more effective ways to build software with it. Imagine a tenfold increase: work that took a week not long ago now takes less than a day.

At that pace, architecture decisions multiply as well. More of them have to be made, they become smaller in scope, and they are distributed across more people. Before Gen AI, there used to be time to weigh options, align with others, and reflect. Now the same complex decisions have to be made in a fraction of the time — continuously, because the flow of new artifacts never really stops.

Woods points to a second consequence as well: testing, validation, and architectural work. These are practices that teams have always known were important, yet they could afford to neglect them because enough developers and enough budget would eventually compensate for the gaps. A team without proper tests could still reach its goal. It would simply take longer, cost more, and rarely attract much attention. At ten times the speed, the cost of those shortcuts does not increase proportionally. It multiplies. “At least by a factor of ten,” Woods argues.

AI does not change what good architecture looks like. It raises the cost of having no architecture — or only fragments of one.

AI Agents Never Hear the Hallway Chatter

Take an example Woods likes to give: an AI agent whose job is to scan code for security vulnerabilities. It filters out false positives, opens tickets, fixes some issues itself, and routes others for approval — reliable, unremarkable, but narrow. The agent decides what a fix looks like — nothing more. That’s the nature of the agent’s job, Woods says: “It’s very much about how we’re building the system. Not about purpose. Not about why.”

An AI agent doesn’t judge the way a person does — it recognizes patterns, and only where patterns exist to recognize: in code, in comments, in documentation, in tickets. The problem: much of what teams learn over the years is never written down anywhere. That one department is difficult to work with, that an approach blew up spectacularly last year and nobody wants to repeat it. That knowledge lives in people’s heads, not in repositories — among humans, it never had to be written down. That’s exactly the limit: agents can only pattern-match. And they only recognize patterns in what’s machine-readable — not in what exists implicitly, inside someone’s head.

Until now, people never had to close the gap between what was documented and what they actually knew, because they closed it intuitively — over coffee, in hallway conversations, with a casual question dropped into a meeting. That’s why, in the world before AI, nobody noticed how incomplete documentation and principles actually were. 

With an AI agent, that background disappears. It doesn’t flag an error when it’s missing context. It makes a decision anyway. But a decision made in an information vacuum is rarely the best one. 

Learn more: Sessions at JAX London dig deeper into what it actually means to work alongside AI agents that only know what’s written down.

• The AI Team Is Not a Team: Leading Human-Agent Teams in the Age of AI — Anna Lavrova, Wemanity Belgium
• Patterns and Anti-patterns of Agentic Engineering — Victor Rentea, Independent Trainer
• Four Green Ticks – Yet Still Hacked: Threat Modelling for AI Agents — Christian Schneider, Schneider IT-Security

AI Agents Are the New Readers of Documentation

Documentation rarely got written because someone wanted to read it. It got written because it had to be. What was missing, almost always, was an idea of who would actually read it. The reader stayed a blank space. And nobody writes well for a blank space.

That’s a lesson I learned myself, years ago — and it’s stayed with me ever since. At that time, I asked an employee for a handover report before she went on vacation. The reports I’d gotten up to that point were consistently weak — nobody seemed to understand what they were actually supposed to be good for. This time, I said something different, on the spot: don’t write this report for me — write it for yourself, for the moment you get back from vacation and need to know where things stand within five minutes. Best report I’ve ever gotten.

With that one sentence, she suddenly had a reader in mind — herself, in the future, with five minutes to spare and a need for instant clarity. That picture was precise, not vague. And once you have a clear reader in mind, writing something precise and understandable suddenly becomes easy.

An AI agent removes that vagueness entirely. There’s no waiting for some future reader who may never open the file — the agent is the reader, right now. In the past, bad documentation mostly went unpunished: it got written, filed away in a wiki, and nobody read it, so nobody acted on it. Feed it to an AI agent as context, though, and it gets read immediately — and acted on, exactly as well or as poorly as the documentation itself is written. 

Principles, Not Approvals

Not every decision can be documented one by one — there are simply too many now, made too fast. What can be documented is the logic behind them: the principle that guides the decision.

Agile, DevOps, and lean all pointed the same way: decentralize decisions. Let teams make the call themselves, in their own local context, without waiting for central approval. Still, the need for coherence is real — nobody wants ten teams pulling in ten different directions. So, in many organizations, an architecture board formed at the top, meant to sign off on every decentralized decision in the name of coherence — and promptly got in the way of the very speed everyone had just gained.

Woods lived through this himself: a small team at the top, every decision funneled through them. The outcome was predictable. Either teams ignored the approval because it came too slowly, or velocity collapsed because teams sat in their sprint waiting for an answer.

Eoin Woods explains how principles solve this. Instead of approving every decision, you hand teams the logic for making decisions themselves. His example: use open message protocols. Can’t do that? Use the organization’s own protocol. Can’t do that either? Build an ad hoc point-to-point connection — but don’t reach for that option first just because it’s cheap.

Notice what the principle doesn’t do: it doesn’t say which protocol a team should end up choosing — GraphQL, gRPC, a plain REST interface. That’s left open, for the team to decide. What the principle does dictate is the order of consideration: open first, then organization-wide, ad hoc only as a last resort.

That’s exactly the distinction: a principle describes the logic behind a decision, not the decision itself. If a principle reads like a finished decision — “we use GraphQL” — it isn’t a principle anymore. It belongs in the category of decisions already made. And here the circle closes back to DNA: a principle doesn’t determine what gets built. It determines the logic you follow when something needs to get built.

Still, principles shouldn’t pile up. At a hundred principles, Woods says, you’d need a language model just to interpret them — ten to fifteen is about the most people can genuinely work with. They also have to hold up in practice, or teams will spend their time fighting them instead of using them. And they have to be built together: for Woods, architecture has long been a team sport — principles nobody helped shape are principles nobody follows.

Learn more: Eoin Woods takes this further in two sessions at JAX London, alongside a talk on what human judgment still has to do once AI writes the code.

• Keeping Control by Driving Better Architecture Decisions with Architecture Principles — Eoin Woods, Artechra
• AI Literacy for Developers: Thinking Clearly While AI Writes the Code — Russell Miles, ClearBank
• Worth a Million Arguments — Venkat Subramaniam, Agile Developer, Inc. (Keynote)

Principles Work Differently on Machines

How do you actually check whether teams are sticking to the defined principles? Woods solved that for years through a technical leadership team — people from every team involved, living the principles and explaining them whenever someone had doubts. That works as long as people feel bound by the principles. An AI agent has no sense of belonging to appeal to.

That’s exactly what gave Woods an idea, about eighteen months ago: an AI agent has no conviction you can appeal to — in his own words, it’s “just a pattern matching stochastic machine.” But that’s precisely why principles can work differently on an agent than on a person. Write them into the context, and they feed directly into the pattern matching.

Woods tested this himself on Claude Code. He asks it how to best apply design principles. The answer is useful. Then he pushes further: if I define good principles, will you stick to them absolutely? The model immediately backpedals — well, maybe not entirely, is the gist of the answer.

So it’s not entirely reliable. Woods has kept his own experiments deliberately small — open-source codebases, a handful of generated web apps — and hasn’t run into ignored principles there. On very large projects with many principles, he suspects the risk isn’t principles being ignored but principles contradicting each other — conflicts between the rules themselves. For how you write them, that has a clear consequence: you narrate principles to people. You crunch them down for machines — short, directive, no detours.

Architecture Is What the Cell Does With the Rules

So what actually has to happen for a principle to do anything at all? That’s the question I put to Woods at the end of our conversation.

For him, architecture is a tangible thing. It comes out of three activities: understanding your stakeholders. Being clear about the quality attributes — the non-functional requirements — you actually need. And making the complex trade-off decisions that deliver those quality attributes to those stakeholders.

That’s the cell at work. Without it, a principle is just a string of sentences, meaningless to anyone. With it, principles become what DNA is for an organism: no guarantee, but a real increase in the odds that the right thing gets built — “to increase the probability of success,” as Woods puts it.

The alternative is deciding everything in the moment, whatever seems sensible at the time. That’s exactly what organizations can least afford in the middle of an AI-driven transformation — not for people, and even less so for AI agents.

Woods has two sessions at JAX London this year, among other brilliant software architects and engineers working on the integration of AI into enterprise systems. If you want to keep chasing the question of what good architecture work still means under these conditions, that’s where to do it.