When building things was the fun part
This Wednesday, I was travelling on a bus and there was a woman sitting diagonally across from me. She was reading a book while knitting. I looked at her for a few seconds and thought, that's a pretty nice way to spend an evening. Then I looked at my own screen. I was reading some code an agent had written and typing "What the fuck did you just do?"
She was doing something unnecessarily slowly because she enjoyed doing it. I was doing something cool and somehow having less fun.
I have always avoided managing people because they make me slow. I know, a very rude thing to say. But that's also why I liked working in products. I wanted to be close to the building. I liked having an idea, turning it into something real, and seeing that thing make someone happy.
It used to give me dopamine when I'd have some idea and spend weeks seeing the shape of it. You start with something in your head, spend days figuring it out, get stuck, solve something, break something else and eventually there is something sitting in front of you that didn't exist before.
I didn't just like the result. I liked getting the hang of reaching there.
Then AI made getting there very fast
With AI in the picture, I can see a lot of that happening within one afternoon.
That is obviously a benefit. I can execute faster, reach validation faster, throw away bad ideas faster and even try five things in the time it used to take me to properly build one.
But somewhere in making that journey shorter, I also removed a part of the journey that I enjoyed.
Maybe the problem isn't that AI removed the hard parts of engineering. It made it too easy to hand those hard parts away.
I read an article on Substack talking about friction not just as an obstacle between you and the result, but as part of how you develop craft. The frustrating parts of building something can also be the parts where you develop the ability to build it well. (What If AI Removes the Friction That Makes Good Engineers?, that article in case you would like to read it)
This resonated to me as well.
I didn't lose the problems. I lost the time I used to spend solving them.
If something takes three hours and an agent can do it in ten minutes, doing it myself feels almost irrational. Except sometimes those three hours were the part I actually enjoyed.
I thought this was just what happened when you got senior
"You shouldn't code." My ex-mentor used to say this to me when I switched roles.
I understood what he meant. As you move up, coding starts to disappear. You spend more time reviewing, discussing, planning, unblocking people and making decisions.
I thought that was simply how careers worked.
You start by building things yourself. Then you help other people build them. Eventually, you spend more time talking about things other people are building than building anything yourself. I wasn't particularly happy about that transition, but I understood it.
Then AI came along and gave me another reason to stop coding.
Everyone can code now or at least they can make something that looks like code. (Had bad hires and bad interviews good enough to get that)
Now I manage agents
When you manage a team, your day can become reviews, discussions, scrums, follow-ups, explaining things, correcting things and trying to get everyone moving in the same direction.
Now with agents, it's unsurprisingly similar.
You give them a task. You give them context. You review what they did. You tell them what they misunderstood. You ask them to try again.
Then you have the same conversation ten times.
- That's still broken.
- That's not what I asked you to do.
- Why did you change this?
- No, don't rewrite the whole thing.
The funny part is that the coding itself has become much faster, but the work around the coding hasn't necessarily disappeared. It moved.
And the more agents you use, the more this starts looking like management. That is a strange career progression. I spent years trying to avoid managing people, only to end up managing machines.
Your AI has the powers of a very fast engineer, but the understanding of an intern who joined yesterday and has confidently decided that your entire architecture needs to be rewritten.
Everyone can code. So what are we hiring for?
This is where it gets uncomfortable.
Last week I was taking interviews. There's a good change now since last I took them - people have got smooth in cheating with AI and making it not look like AI. What an incredible set of resumes, until the interview starts and then coming out with answers that make you wonder what exactly they have been learning. I unlocked a new achievement this time - ending an interview in 7 mins.
But honestly, what else did we expect?
AI has made execution incredibly cheap. You can ask it to build something and it will. You can ask it to fix something and it will. You can ask it to explain something and it will confidently explain the wrong thing.
The problem is that execution and understanding are no longer tied together.
I somewhat know how to make AI go in the right direction because I've spent years building systems. I've spent time reading libraries and understanding where they break. I've seen architectures that looked good on paper and became terrible six months later. I've developed some sense of what doesn't look right.
A person who has only seen things from the abstraction may not have any of that. So maybe the skill we need to teach people now isn't how to code. Maybe it's how to think. How to understand systems. How to question an answer. How to know when something is wrong even when everything looks completely correct. And I know half of the tech community hates this, otherwise a book like The inmates are running the asylum won't have been written.
When execution becomes cheap, judgment becomes expensive. And that changes what we should probably be looking for when we hire people. It also changes how we should train them. If AI does most of the execution for someone from day one, they can get surprisingly far without developing the mental models that used to come from doing the work themselves.
That doesn't mean we should make people code everything manually to prove they suffered enough. It means we need to be much more deliberate about where the learning happens.
So should we keep the friction?
This is where I keep coming back to the woman knitting.
Why would you spend your evening doing something that could be done faster? Why wouldn't you just buy the thing?
Because the sweater isn't really the point.
The knitting is.
We have spent years treating friction as something to remove. If something takes too long, automate it. If something is repetitive, automate it. If coding takes weeks, make it take an afternoon.
And that's exactly what we've done.
But maybe not all friction is waste.
Some friction is where you learn. Some friction builds intuition. Some friction is where you understand why something works instead of just knowing that it works.
And some friction is simply enjoyable.
That's why I don't think the answer is to stop using AI. The answer is to get better at knowing which friction is useless and which friction is actually part of the experience.
Maybe we need to choose what we outsource
If I'm building something for work and an agent can write the boring parts in ten minutes instead of me spending two hours doing it, I'm going to use the agent.
- If I'm trying to ship something, I want speed.
- If I'm trying to validate an idea, I want speed.
- If I'm fixing something that nobody will care about six months from now, please let the machine do it.
But that's not the only reason we build things.
Sometimes I'm building because I want to understand something. Sometimes I'm building because I have an idea and I want to see what it becomes. Sometimes I'm building because I enjoy building.
Those are different goals, and maybe they shouldn't have the same workflow.
- If I'm learning something, I probably shouldn't immediately hand the difficult part to an agent.
- If I'm trying to understand a system, maybe I should spend some time fighting with it.
- If I'm building purely for the outcome, I should probably let the agent do as much as it can.
The point isn't to preserve coding. The point is to preserve the parts of building that have value.
Maybe productivity isn't the only thing we should optimize
For a long time, the obvious measure of progress was simple: how quickly can we get from idea to outcome?
AI is incredibly good at that. We are getting very good at optimizing the act of building around the outcome. But not everything we build is valuable only because of what it produces. Sometimes the building is valuable too.
Maybe that's what I liked about building things in the first place. Not just having built somethin, but building it.
Perhaps that's the strange trade we're making with AI. We are getting much better at making things and we now have to decide which parts of making them we still want to experience ourselves.
