Now Is a Great Time to Be a People-Oriented Engineer

Right now I’m running four instances of Claude Code on different projects, one instance of Codex, and one of Gemini. Two of the projects are serious. The rest are toy apps I may never ship. I glance at each one every few minutes, approve a change, redirect an approach, catch a hallucination. It feels like spinning plates.

It also feels familiar. This is what happened when processors went from single-core to multi-core. The individual cores were actually slower than the single-core chips they replaced. Measured in isolation, it was a downgrade. But it didn’t matter, because you could run things in parallel, and the aggregate throughput was so much higher that it felt like magic.

That’s what programming feels like now. Each AI “core” is worse than me at writing code. If I sat down and wrote everything myself, the resulting codebase would be cleaner, the abstractions more elegant, the architecture more coherent. I know this. And I also know I’d get far less done. So I don’t sit down and write everything myself.

This is a strange thing to come to terms with if you spent years caring about craft.

For a long time, the thing that separated great engineers from average ones was taste in abstraction. You’d look at a massively distributed system and find a way to position the blocks so the whole thing became easy to reason about. It was a puzzle, and a beautiful one. You could look at someone’s code and know within minutes whether they were good. We built identities around this. The elegance of the solution was the work.

That kind of intelligence is becoming less valuable. Not worthless, not yet, but less valuable, in the way that beautiful handwriting became less valuable after the printing press. The press didn’t make handwriting ugly. It just made it matter less.

I think most engineers feel this and don’t want to say it out loud. So let me say it: if your sense of professional pride is grounded in the craft of writing elegant code, the next few years are going to be painful. That deserves to be acknowledged, not hand-waved away.

But there’s something on the other side, if you’re willing to care about people more than you care about code.

A friend of mine runs a small accounting firm. A couple of years ago, he wanted custom software: a client tracking system that would tie into Canopy and his tax tools. Simple enough, he thought. He just needed an engineer. What he actually needed was a PM, a designer, and a small team of developers. He couldn’t afford that, so the project died. This is the normal outcome for small businesses with software needs. They settle for generic tools that half-fit, or they go without.

Now the world is different. A single engineer with a multi-core AI setup could build what my friend needed in a week or two. No PM, no designer, no team. Just someone technical enough to wrangle the AI tools and curious enough to sit down and understand the actual problem.

My friend was ready to pay for this. And he’s one accountant. Every niche professional, in every small town, is overpaying for generic software that half-serves them. The long tail of underserved businesses isn’t just long, it’s deep. There are so many real problems that were never worth solving before, because the cost of building software was too high.

Most people are missing something: the engineers are the ones with the most power right now.

Despite all the coverage about AI replacing programmers, we’re the ones who actually know how to use these tools well. We know when Claude is hallucinating. We know what good architecture looks like even if we’re not writing it by hand. We know when to approve a change and when to redirect. My accountant friend cannot do this yet. Neither can most product managers, designers, or entrepreneurs.

But they will. The tools will get better. The supervision will get lighter. The window where technical fluency gives you an unfair advantage at building products, not just writing code, is real, but it’s finite. Maybe two to five years. Maybe less.

The question is what you do with it.

My first instinct was to do nothing. To keep writing my own code, keep polishing my abstractions, and wait for the hype to pass. That instinct was pure self-preservation. The old craft was the thing I was good at, and I didn’t want it to stop mattering. I think a lot of engineers are in that same place right now.

Or you could do the other thing. You could go find that accountant. You could sit with them and understand their actual problems. Not the abstracted, generalized version of their problems that enterprise software solves, but their real, specific, messy ones. You could build something for them in a week. And then you could do it again for someone else.

The obvious objection is that this is just consulting. And in the old world, software consulting was something most engineers avoided for good reason: it was expensive to deliver, hard to scale, and the margins were thin. You needed a team and months of work for every client.

But when the cost of writing the software drops to nearly zero, the economics change. You can serve clients who could never have afforded custom software before. You can maintain what you build in a few hours a month. Retainers, hosting fees, ongoing support: there are ways to make it recurring. I won’t pretend this is as sexy as “my SaaS just hit $5M ARR.” It’s not. But at this point, when nobody knows what the winning model even looks like, maybe that’s fine.

Nobody knows exactly how the economics of this new world will shake out. Maybe consulting with retainers is the thing. Maybe you build for 15 accountants and notice they all need the same feature, and that becomes a real product. Maybe it’s something nobody has a name for yet. I don’t know. But I’m fairly sure that the engineers who spend the next two years out in the world, talking to people and building for them, will stumble into whatever the model turns out to be. And the ones who stay home writing elegant code will have elegant code and nothing else.

Say you take that path. You spend a year building small, tailored tools for real people. The code is mediocre. You know it’s mediocre. But the products are good, because they solve real problems, and along the way you develop something more valuable than clean abstractions: you develop an understanding of what people need.

That understanding builds on itself. When the tools get good enough that non-technical people can build their own software, the engineer who spent the window writing beautiful code will have beautiful code and nothing else. The engineer who spent it learning what accountants and dentists and farmers and logistics managers actually need will have something durable: domain knowledge, customer relationships, product instincts.

The code was always ephemeral anyway. We just pretended it wasn’t because it was so satisfying to write.

I think the new craft is understanding people’s problems. Which, if you think about it, is what software was always supposed to be about. We just got so caught up in the elegance of the medium that we forgot it was a medium at all.