I talked with Robert C. Martin, Uncle Bob, about AI agents, software architecture, and what still belongs to humans when implementation keeps getting cheaper.
Bob has been through more abstraction shifts than almost anyone in our industry. Binary gave way to assembly. Assembly gave way to higher-level languages. Frameworks came and went. Now agents are pushing us up another layer.
What stood out to me is that Bob is not nostalgic about the code. He is very direct: if we want the benefit of agents, we are going to have to walk away from the code, at least as the main surface of review.
But that is not the same thing as giving up on engineering quality.
Walk away from code, not from structure
Bob's framing is that the lower-level work keeps moving below the water line. We do not punch holes in paper tape anymore. We do not spend most of our time typing binary or assembly. Increasingly, we may not spend most of our attention on the exact code either.
The durable work is above that line: modules, boundaries, dependencies, data flow, and system behavior.
That matches how I have been trying to work with agents too. I still care deeply about the system. I just do not always need to inspect every implementation detail by hand. I can ask agents to show me the module structure, explain the dependencies, identify the weird data flow, and then change the system accordingly.
That is a powerful shift. It is also a dangerous one if you do not know what good looks like.
Agents need constraints because they do not have taste
One of Bob's strongest points was that agents can critique a design when asked, but he has not seen them reliably apply that discernment while building.
That is a huge distinction.
They can produce a cogent critique. They can run a tool. They can follow a constraint. But they do not seem to have the human concern for future consequences that makes an experienced engineer stop and say, "Something is wrong here."
So Bob uses tools. Complexity checks. Coverage feedback. Function and module structure review. He closes the loop around the agent so it knows what standard it is expected to meet.
That is not anti-AI. That is professional engineering with better leverage.
Product engineering is half technical and half human
Near the end, I asked Bob what product engineering means to him.
His answer came from an old job testing telephone lines. His boss sent him out in the truck with an actual phone repair person. Not to write code. To understand the person using the system.
That changed his perspective.
The product engineer, in Bob's words, lives half in the technology and half in the customer's house. That is exactly why this skill is becoming more important, not less. Agents can do more of the geeky implementation work, but they cannot replace the human connection to the customer's problem.
And honestly, that is where the reward has always been. The best kind of technical validation is not "look how clever this code is." It is a real person saying, "That solved my problem."
The homework
Bob's homework is to try SwarmForge, his tool for coordinating multiple AI agents.
Run it. Experiment with agents passing work back and forth. Then, if you find a problem or have useful feedback, leave an issue. That last part matters. It turns the exercise into a product feedback loop.
That is a fitting close for this conversation: use the tools, understand the material, and stay connected to the person on the other side.
