The Centaur Era

The role of the human engineer in AI-accelerated software development

I’ve been coding for over thirty years. I really love writing code - getting into the flow, thinking about the problem at all scales, feeling the dopamine, seeing ideas become real.

However in early 2026 I realised that AI had got better than me at coding. With the right setup, AI agents can now write code and tests to a very high standard and complete large, complex tasks with superhuman speed.

I’m so much faster building software with AI that I can’t imagine going back to coding by hand. I really enjoy it too. Although I do miss some parts of coding, I don’t miss the regular frustration and drudgery. Best of all, ideas become reality much more quickly.

But is software engineering dead? Are we just meat proxies now, typing product requirements into Claude Code? Could non-engineers just get coding agents to build everything for them?

I think the answer to all of these is no, at least for now. AI can write all the code, but there’s much more to building software than that.

I wrote this to help me understand the present and the future of software engineering. I’ll explain why I think that the skill and judgement of a human engineer are still essential for building healthy software products.

Change will continue, and I think we’ll see more and more of the engineering role handed over to AI. But ideas will be shipped faster than ever, so there’s a golden age ahead for anyone who loves building things and can adapt.

Vibe coding

Vibe coding means using AI to build an app without looking at the code at all. Almost anyone can ask an agent to create a simple app and get a pretty nice-looking result in a few minutes. It probably won’t be quite what you had in mind, but it’s a good starting point and you can start to ask for changes. I’ve built many small apps and games this way.

At the start of 2026 vibe-coded apps were very brittle. After a few changes, existing functionality would break and progress would soon grind to a halt. If an engineer looked at the code, they’d see needless complexity, weird patterns and quality issues everywhere.

Coding agent capabilities are advancing at a surprising rate. Now I find that I can get much further with vibe coding. The app stays stable and functional over many changes, and with a tiny bit of nudging the agent will write tests to ensure existing functionality doesn’t break. The codebase looks really quite good.

However the code does tend to accumulate complexity as changes are layered over changes, and the agent still sometimes makes weird technical decisions. The app’s foundations can get shaky as it evolves.

Furthermore, building commercial-grade software requires a lot of looking at and shaping your app from many angles. Quality, security, scalability, consistency. Whether the code follows your org standards and integrates with your other systems. Doing all this needs engineering input, and looking at the code - simple vibe coding isn’t enough.

So how do we take advantage of the coding speed of agents while keeping the codebase fit for the real business world? We put the agents in the hands of human engineers, who have the context, strategic awareness and judgement that agents don’t yet have.

The Centaur

In chess, a Centaur is a human working with one or more chess engines. Garry Kasparov came up with the idea in 1998 and called it Advanced Chess. It took off in the mid-2000s with online “freestyle” tournaments, where humans, engines and human-engine teams could all enter.

A chess Centaur usually runs several engines at once and treats them like a panel of advisers. The engines figure out the moves. The human uses their judgement to decide which engine to trust when they disagree, which positions deserve deeper analysis, and how to prepare, for example by planning opening moves in advance.

The first big freestyle tournament, in 2005, was won by two American amateurs, Steven Cramton and Zackary Stephen. Running four chess programs on three ordinary PCs, they beat teams of grandmasters who were also using computers, and finished ahead of Hydra, the strongest chess machine of the day. Writing in 2010, Kasparov put their win down to their skill at working with their computers:

“Weak human + machine + better process was superior to a strong computer alone and, more remarkably, superior to a strong human + machine + inferior process.”

So a Centaur isn’t just a human plus a machine. It’s a human, a machine, and the process that joins them together.

I think we’re currently in the Centaur Era of software engineering. Human engineers and coding agents, joined together by a good process, form an AI-accelerated beast that can build great, healthy software much faster than ever before. And just like chess, what makes a good Centaur isn’t just raw technical skill. The agent has plenty of that. It’s the engineer’s judgement about what to build, how the system should fit together, and whether the agent’s work is good enough.

In chess, the age of the Centaur didn’t last. I’ll come back to that later.

Centaurs at work

Let’s look at how a Centaur fits into a typical software product organisation:

The engineer sits between the organisation and the agent. On one side, they trade trust, ideas, feedback and context with the rest of the team. On the other, they pass their intent to the agent, then plan, build and review with it. Underneath is the codebase. As well as the application code and tests, it holds the docs, rules, skills and linters that teach the agent how to work there.

The people around the engineer are probably Centaurs too. Other engineers have their own agents, and product people, designers and managers use AI in their own work, from drafting specs to building quick prototypes.

The human part

So what do human software engineers do in the Centaur, and why can’t AI just take it over?

The human work falls into five groups:

1. Working in the organisation

Only a human engineer can be ultimately responsible for their changes and for the ongoing health of the system, whether they use AI or not. Only a human can build or lose trust with stakeholders.

Engineers also work with each other in all the usual messy ways: Slack threads, meetings, hallway and pub chats. We make plans and pick up on gaps, opportunities, risks, rumours and politics. We follow a tech world that’s moving at blinding speed. Human engineers build up far more situational context than any agent can today.

And someone has to decide what’s worth building. Engineers take ideas from the rest of the team and use their product and technical knowledge to come up with their own. Then they work with the team to turn them into packages of work: scoping, breaking down, and dealing with risks and unknowns.

2. Deciding what to build and how

The first job is telling agents what to build. How do you tell the agent to “do the thing”? The engineer uses what they know about the task, the system and the agent to get the intent across. Bigger pieces of work need a plan that tackles the uncertain parts first and phases the work to reduce risk.

The engineer also describes the domain. Eric Evans’ Domain-Driven Design calls this the “Ubiquitous Language”. What exactly is a Customer, or an Order? What does it mean when an Order is Placed or Fulfilled? Clear, written definitions are vital for communication between the human and the agent.

Then there’s the architecture. What are the layers and modules? What’s the data model, how does data flow, how does security work? The agent could decide these on the fly, but there’s no guarantee its choices will fit the organisation or its goals.

Below that sit the technical standards: languages, code structure, security scans, testing, accessibility, error handling, and a thousand more, all shaped by organisational context. The human team decides these too.

3. Setting up the agents’ world

Agents are like genius new hires, with incredible coding skills and book smarts but not the first clue about your codebase. Before they shoot off and make a huge mess, they need onboarding: your architecture, standards and domain written up as docs they can skim for an overview and dive into for detail. Agent “skills” describe how to do particular tasks. The engineer curates all of this and keeps it up to date as the system moves on.

Docs alone aren’t enough - agents need constraints. As Robert C. Martin observed, they sometimes treat written standards like the Pirate’s Code: “more what you’d call guidelines than actual rules.” So engineers move more of their standards into linters and other tools, which check the agent’s work automatically and force it to fix any violations.

Agents also need safe access to the system, data and observability tools, so they get feedback on their changes and can help diagnose problems in production. If that access isn’t properly controlled, your data can be deleted or sent to the bad guys, or your whole system compromised. Engineers ensure that agents get only the access they need.

4. Working in the loop

Unless a task is perfectly scoped for the agent to build on its own, there’s a lot of back and forth between agent and engineer. This is the “inner loop” of working with agents, and the engineer’s job is to help the agent build. They keep a lid on the agent’s tendency to charge ahead, and break the work into small steps that are easy to understand, so careful review stays practical.

A lot of this is wrangling. Different models have their own personalities and quirks. They can be overenthusiastic, neurotic, prone to disappearing down rabbit holes, keen on towering abstractions, lazy, massively overconfident or sickeningly sycophantic. And no sooner are you used to one than a new version comes out. Engineers learn these quirks and pick the right model for each job. AI is expensive, so they might use a cheaper model for simple work, or have a top-tier model hand tasks to cheaper sub-agents.

And someone has to check the agents’ work. Is the code correct? Does it follow the architecture? Does it smell good? Reading every line of code is still the safest option, but it’s slow, and it makes human review the bottleneck. With better agents and guardrails like rules, linters and review agents, some teams no longer review every line. They save human review for critical code like data models, APIs and security. This is worth considering, but be conservative. Only loosen review when you have sustained evidence that your guardrails are working, and read the code when in doubt. You’re still answerable for every line that your Centaur writes, including the ones you didn’t read.

5. Staying in charge

The speed of agents is seductive, and it’s tempting to rush on to the next feature. But it’s easy to lose touch with how the system works if the agent makes code changes that you don’t keep up with. Margaret-Anne Storey calls this “cognitive debt”. If it builds up you’re back to vibe coding, and the system can drift away from your control. So the engineer has to keep understanding the system. Reading the agent’s code is the best way, but again this can become a bottleneck. Teams are starting to use other techniques to understand changes, like agent-generated summaries or diagrams of the change. Humans should decide whether to accept new architecture patterns the agent suggests, and keep the documentation up to date as the system evolves.

Above all, engineers use judgement. They bring their knowledge and accumulated wisdom to every level of the Centaur. Critical thinking is key. Don’t blindly trust the agent, and keep your wits about you.

Life as a Centaur

We’re almost a year into AI being able to write all the code. The Centaur Era is here, and human engineers are still a vital part of the AI-accelerated beast.

Like many other engineers, I love this new way of working and wouldn’t want to go back to the pre-AI era. I really enjoy working with agents every day, and I can turn ideas into reality faster than ever before. For example, I recently built a complex full-stack CRM feature in our plastic waste trading application, then migrated the whole app to a new cloud database provider. Both tasks would have easily taken 5 to 10 times as long without AI help.

But I understand the many engineers who are still nervous about handing control of the codebase to agents, or worry that their jobs will become less interesting or rewarding. Not everyone wants to write English instead of code, or wrangle agents all day.

The industry is also in an obvious Catch-22. Experienced engineers already have the judgement they need to work with agents. But how do new engineers get that experience without years at the coding coalface? My son is studying for a degree in video game development. How should he prepare for an industry that AI is changing so fast?

My advice to him is to take the time to learn to code, experiencing all the fun and the pain, and building an understanding of how software actually works. At the same time, he should get comfortable with using AI to build games, describing features in plain English, and learning when to trust the AI and when to trust his own growing coding skills and instincts. Above all, he should expect software development to keep changing, and change with it.

Galloping ahead

In chess, the age of the Centaur faded. Centaurs won most of the big freestyle tournaments into the mid-2010s, but engines kept getting stronger and the human’s edge kept shrinking. By the late 2010s there was little left for the human to add, and the big tournaments had died out. Centaurs survive today mainly in correspondence chess, where players get days per move and most top games end in a draw. Tyler Cowen, who did a lot to popularise the Centaur idea, summed it up in 2024: “centaur chess” is now run by computers. Even the human’s special job, choosing which engine to trust, can now be done by a program.

If AI agents keep improving at anything like their current pace, they’ll take over more of the engineer’s work. Will they eventually take over all of it?

Software isn’t chess, though. Chess is a closed game with fixed rules and a single clear goal. Software serves messy, changing human goals inside human organisations.

AI’s abilities are also uneven. Coding agents can be superhuman at some tasks and weirdly weak at others that look just as easy. Ethan Mollick calls this the jagged frontier. Chess engines had weak spots too, and that’s where the human in a Centaur filled in. In the closed game of chess, the engines eventually fixed all their weaknesses. Software has far more gaps across its complex and open landscape. Part of the engineer’s job is knowing where the jagged frontier is today, and covering the gaps.

Looking back at the five groups above, here’s how I see the “human parts” enduring.

• Likely to last: working in the organisation, telling agents what to build, describing the domain, and using judgement. These come from being a person inside a human organisation.
• Likely to shrink: defining the architecture, deciding the technical standards, constraining the agents, giving them safe access, checking their work, and understanding the system. Models, harnesses and platforms are getting steadily better at all of these. Accountability doesn’t shrink though. It moves up a level, from the lines of code to the guardrails and process that produce them, in the same way a manager is accountable for work they don’t do themselves.
• Likely to go: onboarding the agents, helping them build, and wrangling them. Handling model quirks, picking models, pacing the work and writing onboarding docs are mostly workarounds for the limits of today’s models and tools.

It’s virtually impossible to predict where AI is going, with so many interlocking technical, business, social and political factors in play. Setting aside the extreme civilisation-level scenarios (humanity is enslaved or wiped out, or frolics happily in a work-free utopia), here are some possible outcomes for the next decade or so. They aren’t mutually exclusive, and several could happen at once.

• Software development as a service. AI swallows the technical side of software engineering. The models, harnesses and platforms evolve to a point where engineers are no longer needed to set up the agents’ world, make decisions about architecture and technology standards, or worry about agents writing poor code. Software is built by people on the product and design side, talking to a service layer that takes care of all the building, maintenance and operation. Perhaps they keep a few old engineering skills like logic and data design, but the AI helps with those too. This is the vibe coding dream come true: software built just by talking to the AI, which takes care of the details for you. Only the “likely to last” parts of the list remain, and they move to the product side.
• Tiny teams become common. Software engineering skills are still needed, but a few excellent Centaurs can build huge products. Much of the messy human communication of traditional software development falls away as teams shrink to one or two AI-augmented brains. We see one-Centaur companies worth billions of dollars. Sam Altman says his tech CEO pals have a bet on when the first one-person billion-dollar company will appear.
• Jevons Paradox. When something becomes cheaper to produce, demand can grow so much that we end up using more of it, not less. Team sizes might shrink because fewer people can do the same work. Or the new speed might create more demand for software than ever before, and armies of Centaur-compatible engineers get hired.
• Solow Paradox. Some have asked: if software engineering is so much faster now, where’s all the great new software? The gains might take years to show up, just as the computer revolution took a decade or more to appear in the productivity figures. I think AI will be much faster than that, but a lot of adjustment is needed, and organisations have a lot of inertia to overcome.
• The Slopocalypse. Commercial pressure to ship the next feature, teams cutting back on review too soon, and dwindling experience and judgement in the engineering base lead to mountains of slop that harm businesses. Organisations spin in circles and spend billions trying to make AI software development work. Some succeed, but many drown in the torrent of slop or abandon AI altogether. The ones that abandon AI go back to hand-coding, and it’s an open race between them and the organisations that made AI work.
• AI stalls or goes away. Progress hits a wall, and the models we have in a few years are about as good as they get. Or the industry’s economics don’t add up, the big labs go bust and only the open-weights models remain. Or countries get cut off from AI in trade or geopolitical disputes, labs hoard the latest models in the race to superintelligence, or a public backlash brings laws that sharply limit AI. In all of these, the jagged frontier stops moving and the Centaur Era becomes the normal way to build software for a long time.

Conclusion

I think we’re firmly in the Centaur Era now. The best way to build real software today is with human engineers working in close partnership with agents. The agent brings speed. The engineer brings direction, context, judgement and accountability, and builds the process that turns that speed into healthy software.

It won’t stay like this though. Each time the agents close a gap in the jagged frontier, the technical side of the engineer’s job shrinks. I think market forces will push us towards software development as a service. It’s hard to say how long it will take for the models to close the gaps, and for businesses and society to catch up. My best guess is that something like today’s software engineering Centaur will be with us for a few more years.

Even then, I don’t think the Centaur will vanish the way it did in chess. The parts of the job that last, like telling agents what to build, describing the domain and using judgement, don’t need an engineer, but they do need a person. The Centaurs of tomorrow will include people who work more at the product level, coming up with ideas and getting agents to build them with far less technical input than today. There’s almost endless demand for great software, and I think there’ll be plenty of room in that world for people who love building things.