AI discussions often pretend that there are only two possible positions: complete delegation, where the machine produces everything and the human only supervises the result, or complete rejection, where using an AI tool is treated as abandoning the craft itself.

But using AI does not automatically mean believing that it should replace engineers, just as refusing to use it does not mean believing that it is useless. Especially in software engineering, the interesting question is not whether humans should use machines, but how humans and machines should work together.

To explain how I see it, I like to use a simple example: imagine a runner who has been asked to train a robot to run the famous 100-meter race.
People would imagine two different possibilities for that task. But, actually, there is a third (hidden) one…

The trainer on television #

The first possibility is that the runner stops running.

Instead, he watches the robot run on a television and gives it instructions from the sofa:

Lift your knee higher.

Take a longer stride.

Breathe more regularly.

The robot needs very precise instructions because it does not understand the sport in the same way as the runner. Every improvement must be translated into a new and specific order. As those instructions become more and more specific, they also become increasingly difficult for the runner to explain and for the robot to follow properly.

Meanwhile, the runner is becoming fat.

He is not training anymore, his own abilities are getting worse, and it becomes harder for him to understand what the robot is doing. He may still possess the theory of running, but he is losing the physical feeling of the sport.

This is a strange trainer.
He has the knowledge, but he does not practice. Eventually, he will lose both his knowledge and his ability to train.

This is what happens when an engineer completely delegates the act of programming and only watches an agent produce code: the engineer might still be able to give instructions, but the intuition developed by solving problems is slowly disappearing.

Running together #

The second possibility is more honest, but not necessarily more useful.

The runner and the robot run the same course together, at the same time. The runner trains the robot while also trying to beat it.

This is exhausting. The runner has to run, observe the robot, correct it, compare their performances, and continue running.

And what is the purpose of training a robot to run if the runner has to run the same course anyway?

This is sometimes how we use AI tools. We ask an agent to implement a feature, but we remain beside it for every line, every decision, and every generated file. We still do the work, but now we also supervise another worker doing a parallel version of the same work.
Now, imagine 10 robots in parallel instead of only one… This leads generally to burnout.

The result may be useful but it may also be a very expensive way to produce code, at the price of the runner’s health.

Changing the sport #

There is a third possibility.

Instead of making the runner and the robot compete on the same course, we can change the sport. We can turn the individual 100-meter race into a relay race.

The runner does not run the complete distance while the robot runs the complete distance; instead, they split the work: the runner runs one part, gives the baton to the robot, and the robot runs another part. They need each other to win.

This is not a compromise, but a different sport.

The runner still trains. The robot also trains.
The runner remains responsible for understanding the race, but doesn’t waste energy running the same part that the robot can run well. The robot doesn’t need to become a human runner. It only needs to become good at its part of the relay.

This is the kind of collaboration I am interested in with AI.

An engineer can keep working on the difficult parts: understanding the problem, designing the architecture, making trade-offs, reviewing the result, writing the most complex code, and debugging the system when reality disagrees with the plan.

An AI tool can work on other parts: exploring alternatives, writing repetitive code, preparing tests, searching documentation, or implementing a well-defined component while the engineer works on another problem.

The missing middle #

This is not the method generally promoted on the internet. Most discussions are binary because binary positions are easy to explain and easy to sell.

One side says that AI will make software engineers obsolete, and the other side refuses to use it (sometimes treating every generated line as an attack against the craft itself).

Both sides can miss the practical question: what kind of work should humans and machines do together?

Michael Hashimoto described a more interesting journey in his AI adoption article. He did not immediately accept every AI tool, and he did not reject them forever. He tried to reproduce his own work, learned where agents were useful, learned where they were a waste of time, and built a workflow around verification.

David Heinemeier Hansson (or DHH), very recently, described a much more radical position at Rails World. According to this report, 37signals now treats AI agents as the default code-generation tool, while writing code by hand has become an exceptional activity.

This may be productive for some kinds of work. But if the only metric is the amount of code produced, then we have already chosen the wrong sport.

Software engineering is not a 100-meter race where the winner is the person who produces the most characters per second, but much (much much) closer to a relay race where the quality of the handover matters as much as the speed of each runner.
The difficult part is not only producing code, but knowing what should be produced, why it should exist, and how to recognize when the result is wrong.

I don’t think DHH is a loser. But I think his conclusion is outdated: he is still treating software engineering as a race for maximum output.

As a collaboration #

Of course, a collaborative approach requires us to change our workflow.
We need to train ourselves enough to understand the machine’s output. We need to give it tasks that are clear enough to verify, but meaningful enough to save us time. And, of course, we need to keep running our own difficult courses instead of delegating every part of the sport.

This is harder than choosing a binary position because it requires experimentation, discipline, and a precise understanding of our own limits.
And, to be honest, I don’t know anyone who handles that in a correct way.

But the future of engineering may not belong to the people who use AI the most, or to the people who refuse it completely.
It may belong, instead, to the people who learn how to change the sport.