Beyond coding agents: how AI rewires your organization

| In Tech
| 13 minute read |by Constantin Gonzalez
A fantastical illustration of a serene pond ecosystem at sunrise, surrounded by vibrant wildflowers and lush vegetation. In the water, a frog holds a lantern on a lily pad while a bee hovers nearby. Golden glowing lines connect various insects—including dragonflies, a beetle, and a snail—representing an interconnected network or ecosystem. Solar panel-topped greenhouse domes are visible in the misty background among trees. The warm, ethereal lighting and whimsical art style suggest themes of nature, technology, sustainability, and ecological harmony.

TL;DR: AI made the coding part of software fast, and that speed didn’t create chaos so much as expose where your organization was already slow: the hand-offs between teams. The fix isn’t a better tool, it’s better wiring. We rewired Dev and Ops once already and called it DevOps. The next wall, between business and engineering, is coming down the same way. Here’s how to see it, and one thing you can do tomorrow.

Picking up where I left off

In my previous article about Expert Generalists, I ended on a claim I didn’t really unpack: organizations are drowning in silos that can’t talk to each other, and projects fail not for technical reasons but because nobody sees the whole system. That post was about the Expert Generalist as a person, a way of thinking that helps you thrive when the ground keeps moving.

This one is about the organization. Because something has changed that makes those silos matter more than they used to, and I think this AI-catalyzed shift needs more discussion.

Here’s what I see: AI didn’t overwhelm your employees or make your organization more complex. It exposed a complexity that was already there, one you could previously afford to ignore.

The part that got fast

Let’s be precise about what AI actually does to software development. AI doesn’t replace software developers. It replaces the act of writing code. And it makes this task really fast. Turning a clear intent into working lines of code has become a single prompt and a quick run to the coffee machine.

Simon Willison, who has spent more time on AI-assisted programming than almost anyone, framed his six-year prediction like this: “the job of being paid money to type code into a computer will go the same way as punching punch cards.” Notice what he’s not saying: He isn’t saying software engineering disappears. He’s saying the typing does. In his words, “being able to read a detailed specification and transform it into lines of code is the thing that’s being automated away. What’s left is everything else.”

That “everything else” is quite a lot, and this article tries to capture a big part of it.

Because when you make one step in a process dramatically faster, the process as a whole barely speeds up. Instead, the next-slowest step becomes painfully visible. Eli Goldratt taught us this decades ago in The Goal: every system has a constraint, and optimizing anything other than the constraint is mostly theatre. I witnessed this first-hand: when I was explaining Amazon EC2 to a large German DAX company’s IT department, they told me “Mr. Gonzalez, our process for provisioning a new server is called `the 60-day process´. Your technology merely turns it into a `59-day process´.”

Speed up coding, and the constraint simply moves upstream, into the spaces between people. The review that waits three days. The spec that bounces back and forth. The approval that needs four signatures. The hand-off from product to engineering, and back again.

When the work itself was slow, those hand-offs didn’t hurt. Everyone was waiting anyway. Now the work is fast, and the waiting is the whole story.

What if the whole company got faster?

So let me plant an idealistic question, because it’s the one worth chasing: what if the whole company got faster as it adopted AI, not just the individual coders who then sit and wait for everyone else to catch up? What if the speed reached all the way to the customer, instead of piling up against the first wall it meets?

That’s not a tooling question. You can’t buy it. It’s a question about how the work is wired together. And that turns out to be a very old kind of question, with a surprisingly hopeful answer.

Who’s actually good at seeing this

First, who’s equipped to navigate a world where the bottleneck keeps jumping from one place to the next? Not the deepest specialist in any single box. The person who can see across the boxes.

That’s the Expert Generalist, the kind of person Martin Fowler and his colleagues described in July 2025, and the subject of my last article. I won’t re-make that whole case here, except to name the one habit that matters most for what follows: seeing the whole as a system, and getting genuinely curious about what the team across the hall actually does all day.

Because once you see your organization as a system, you can’t unsee the walls inside it.

Your company is a system, like a server

Here’s a picture that reframed my whole career. Sitting in meeting after meeting with enterprise customers who were struggling to adopt the cloud, it struck me that a company is also just a system. Like a server.

A server has components: CPU, storage, I/O. A company has departments: product, development, operations. A server has buses connecting the components; a company has processes. And a server has bottlenecks, usually not inside the chips, but between the system bus and storage. A company’s bottlenecks live in the same place: not inside a department, but between departments, between silos, between Development and Operations.

In Wiring the Winning Organization, Gene Kim and Steven Spear give this a sharper frame with what they call the three layers of any organization. Layer 1 is the work itself, the thing that actually makes your customers happy. Layer 2 is the tools and infrastructure, the stuff everyone can name, and where, suspiciously, most people stop thinking. Layer 3 is the wiring: how the work is split up and put back together, who talks to whom, in what format, under what rules.

Layer 3 is the invisible layer. It’s also the one that decides whether you win or lose. And here’s the uncomfortable part, courtesy of Conway’s Law: your org chart is your wiring, made real. The boxes and lines you drew for reporting purposes are quietly deciding how your software, and your speed, turn out.

If you want to learn more about how to see organizations this way, read Donella Meadows’ Thinking in Systems. I put it on my short list of must-read books for tech executives a while back, and I’ll happily recommend it again here. It’s the clearest book I know on why pushing harder on the wrong part of a system makes things worse, and why the real leverage is almost always in the loops, not the boxes.

We have done this before

The good news, and why I’m optimistic rather than worried: we have rewired organizations around a technology shock before, and it worked.

Rewind to the last time a wave of automation made one part of software dramatically faster. Cloud made infrastructure instant: servers in seconds instead of months. Operations teams, organized around the careful, manual provisioning of scarce hardware, watched their world dissolve. Developers, suddenly able to define infrastructure in code, gained power. The gap between them widened, and the answer wasn’t a tool. It was a rewiring.

We called it DevOps. Dev learned to think like Ops, Ops learned to think like Dev, and the wall between them turned into a loop: a continuous feedback cycle instead of a sequence of hand-offs. Gene Kim told that story as a novel in The Phoenix Project, and a decade later DevOps is so normal we forget it was once heresy.

Yet, while working for AWS as a Solutions Architect, I was occasionally invited to a meeting to “discuss DevOps”, where the customer wanted to learn more about some code-related AWS services, where I had to remind them that DevOps is not the act of running a Jenkins server somewhere, or use an AWS service that starts with “Code”. Instead, I pointed them at Gene Kim’s seminal blog post The Three Ways: The Principles Underpinning DevOps and walked them through the critical principles they need to understand in order to rewire their way of working and become more successful. It’s very easy to forget about the principles, and become distracted by shiny tools.

History doesn’t repeat, but it rhymes. If you lived through that one, you already know how this works.

The next wall

So where’s the next wall? It’s the one between product and engineering. And it’s coming down the same way, for the same reason.

When coding is the bottleneck, you keep product and engineering apart: product writes a spec, throws it over the wall, engineering builds it, throws it back. Slow work, sequential hand-offs, and that was fine, because building was the slow part.

Now building is fast, and the wall is the constraint. So the two sides are starting to merge, in both directions.

Developers are drifting upward. When an agent writes most of the lines, a developer’s job shifts from typing syntax to managing a team of agents: writing the specifications and tests that steer them, and judging what comes back. That’s much closer to what we used to call a software development manager, or even a product manager. The skill that’s growing, as Adrian Cockcroft described in his talk on directing swarms of coding agents, is orchestration, not authorship.

And product people are drifting downward. With AI, someone who can’t really code can now build a rough working prototype to find out whether an idea is any good, before writing a single formal requirement. Tobias Goeschel calls this Domain Prototyping: a tight loop of understanding the context, designing a model, building it, and evaluating it against real stakeholder feedback, where the prototype becomes the conversation instead of the document. The prototype is the new spec.

Put those two drifts together and you get a loop where there used to be a wall. Product and engineering, feeding each other continuously. The same move as DevOps, one floor up.

Let’s be honest about the state of the evidence here, because this part is moving fast. Nobody has the final org chart for the AI era, and anyone who tells you they do is selling something. So I’m being deliberately broad on the shape of the answer. But on the core principle I’m quite confident: AI acceleration exposes organizational bottlenecks, and faster feedback loops between the people who used to hand off to each other are the right response, at least for now.

Same tools, same skills, different wiring

What makes me confident is that we have more than a tidy theory now. We have cases, highlighted in Gene Kim’s and Steve Yegge’s book Vibe Coding. And three cases, to me, is where something stops being an anecdote and starts becoming a pattern.

The clearest is Adidas. In a pilot of around 700 developers, they measured how much of the day people spent in “happy time”, the creative work of coding and design, versus meetings, troubleshooting, and admin. The result split sharply in two. Teams working on loosely coupled, modern e-commerce systems reached roughly 80% happy time. Teams stuck inside tightly coupled, legacy ERP architectures sat down around 30%. Same company, same tools, same caliber of engineers. The only thing that differed was the wiring. As their digital tech leader Fernando Cornago put it, if you offered those tightly coupled teams a shiny new AI tool, “they’d say: Fernando, are you crazy? Fix the environment, fix the test processes first.”

The second is Morgan Stanley, a regulated bank, exactly the kind of place where people love to say “we can’t, compliance” (I’ve heard that about cloud, too). They built a model that predicts the risk of a given change and routes low-risk changes into a fast lane instead of a multi-day approval gauntlet. In the pilot, change-related incidents fell from around 1.5% to zero, and critical fixes that used to take two weeks shipped in under an hour. The lesson I see here: control doesn’t require bureaucracy. A regulated bank rewired its Layer 3 and got more control and more speed.

The third is Booking.com, which paired AI tools with the thing most companies skip: actual training, workshops run per business unit, plus task-specific agents aimed at the genuinely dreaded work, like migrating ten-thousand-line legacy functions. The result was roughly 30% more coding efficiency, and noticeably smaller, faster code reviews. The lesson: enabling people beats merely giving them access.

One caveat: the book is a snapshot of mid-2025, and in this field the specific numbers age like milk. Let’s look at the patterns, not the digits.

Three companies, three industries, one shape. The organizations that win the AI transition aren’t the ones with the best tools. They’re the ones whose wiring lets the work flow.

Three moves, and one for tomorrow

If you take anything from this, take three moves.

First, apply the Expert Generalist habits. Stay curious about the box next to yours; you’ll usually find its people are more like you than you think.

Second, see the whole as a system, not a stack of departments. The leverage is in the loops between them, not inside any one of them.

Third, and this is the one I’d put on a sticky note: focus on the outcome, not the factory. Optimize for what makes the customer happy, not for the busyness of any single team.

A sticky note isn’t an action, though, so here’s something concrete for tomorrow. Look at your own team, department, or organization, and find one bottleneck in the system. Not a person, a seam. Maybe it’s a slow approval a model could route, Morgan-Stanley style. Maybe it’s the tight coupling that’s quietly making your colleagues miserable, Adidas style. Maybe it’s a dreaded routine task you could hand to a well-guarded coding agent, Booking.com style. Pick one. Then bring it to your next all-hands and name it out loud. Naming the seam is how the rewiring starts.

The good news

Let’s close with a reframe I find very reassuring: The common fear is that AI makes humans less important. To me, it’s the opposite. As Daniela Amodei, who co-founded Anthropic, told ABC News earlier this year, “the things that make us human will become much more important instead of much less important.” When she describes who her company hires for, she lists curiosity, communication, judgment, the willingness to help other people. Those aren’t the things AI replaces. They’re the things AI rewards.

Which brings me back to where I started. My business card used to say “Solutions Architect.” It never really described what I did, which turned out to be helping organizations see themselves as systems and rewire accordingly. Maybe your title doesn’t quite capture what you really do either. If so, that’s not a problem to fix. It’s a sign you’re already becoming the kind of person this new world needs: someone who looks past their own box, and helps the whole thing work.

Sources and further reading

If this resonated, I write about tech, work, and what comes next for experienced professionals navigating AI-powered change. You can subscribe through the simple form on the right of this page to get the next one. And if seeing your own organization as a system and rewiring it is the kind of problem you’re wrestling with, that’s a good part of what I help teams do. Either way: what’s the one seam in your system you’d name first?