Jarvis, Please Build Good Software

The second-order effects of code becoming a solved problem, and why design is the next frontier in software engineering.

Well, in the year 2026, AI has finally become a dev tool.

The promise of it replacing your engineering team remained unfulfilled (at least for now), and coding agents seem to work best in the hands of someone who speaks the language of the machine.

What happened?

All the defensiveness that engineers had about AI evaporated as soon as models became better. All the complaints, all the bitterness, are slowly disappearing. Once you reduce the time people spend fixing a model’s mistakes, they’d happily use it.

I don’t know if it’s emergent abilities, parameter tuning, larger data sets, or some agentic wizardry, but models like Claude Opus 4.5 feel significantly better than previous ones.

I don’t have the benchmarks, I don’t have a qualitative proof, but the temperature of the room feels different.

There’s less pessimism and more curiosity.

But as AI becomes a dev tool, engineers start treating it as one.

We try to min-max its usage like any other technology.

What’s the best workflow? What’s the best prompt? Is Claude Code marginally better than Cursor? How do you do TDD now? Should you review your code with AI? Can you now build software from your phone?

I find these questions largely insignificant, though.

The AI landscape seems to be changing far too often for them to have a meaningful answer. Last year, people were obsessing over adding the right context to the coding agent. Now it just figures it out on its own through a combination of human-like searches (like grep).

If we get too fixated on a model’s ability to one-shot a request, we miss the real question, which is what exactly you’re trying to one-shot.

You can get so focused on doing the cool thing that you forget that the goal is to build good software.

But what does good software look like?

What is good UI? AI is great at making something that looks designed but feels off to a real person. I need to learn what a good interface looks like.

What qualities does a good system have? I need to be better at understanding what underlying qualities a system needs to have to match the product I’m building.

What does maintainability look like in the future? At some point, you won’t be starting from scratch every morning. The services need to keep running.

And these questions are answered with fundamental software engineering knowledge.

Greenfield and brownfield development are fundamentally different. Once you need the system to keep running and pay the bills, you need to be a little bit more careful, and while UIs get fixed with a browser refresh, the same isn’t true for data.

You need to get used to these tools, but they remain as such.

Knowledge about how good software needs to behave is non-negotiable.

Maybe I’m just coping a little bit, so I don’t feel like I’ve wasted thousands of hours thinking about the intricacies of software design and architecture only for the industry to slap an abstraction over it.

I’m still not 100% sold on code being a black box. I still can’t quite detach myself from the idea that I need to understand what is going on. I need to learn how to use these tools productively, but also keep myself grounded and familiar with their work.

I’ve read too much Asimov, so I’d rather be a step behind. When you’re on the bleeding edge of technology, it’s you who’s bleeding.

Where to?

Those with a more entrepreneurial spirit are having a blast. The inner Henry Ford must be speaking to them like the green goblin mask, telling them that the software assembly line is right there for the making.

But on the builder-trader spectrum, I’m still leaning too far into the former.

The bottom line is that someone still has to be the bridge between the analog world and the digital one, but Ira Glass’s gap has been greatly reduced in size.

“Nobody tells this to people who are beginners, I wish someone told me. All of us who do creative work, we get into it because we have good taste. But there is this gap. For the first couple years you make stuff, it’s just not that good. It’s trying to be good, it has potential, but it’s not. But your taste, the thing that got you into the game, is still killer. And your taste is why your work disappoints you.”
— Ira Glass

The skill you need to develop to match your taste is now less. How much less, I don’t know. But as the engineers at Anthropic are doing their magic, this gap is slowly shrinking.

And this makes the destination on its other side that much more important.

When I know what output I’m aiming for, things are easy. I know exactly what I expect, and I can ask the agent about the specific thing I need. The trouble comes when I don’t know what I want to achieve.

That’s when I need to rely on the model and hope its weights are in my favor.

I’ve learned to apply the age-old principle of abstraction in these scenarios. I put boundaries around the code that the model will generate. I put it in a separate file, a separate module, and create an interface around it.

Then I let the model go wild inside.

I can treat its output like a black box, but I make the box.

I need a better understanding of what I’m trying to make. I need to be able to recognize good designs, good architecture, and good software.

Otherwise, I’d just be putting more shovelware out into the world.

And while I believe that creating anything is a noble pursuit, I’ve given the world my fair share of shitty software, so I’d much rather contribute to something more meaningful.

If code becomes less and less of a bottleneck, then design becomes the next frontier, both system design and user interface design.

I want to get better at recognizing when a UI looks good.

I want to know what it lacks, how it needs to be structured, and what needs to be removed. A designer friend of mine recommended the Interaction Design Foundation for a more structured approach to studying UI/UX, and I’ve been liking it so far.

And I want to learn the same about larger, more complex systems, so I’m re-reading Designing Data-Intensive Applications for I don’t know which time (I should just keep it on my desk at this point), and I’m reading papers about distributed systems.

The second-order effects

The industry shift is not limited to the way we code.

Every change has second and third-order effects that are difficult to predict. One of them is that people seem less interested in low-level (if we can even call it that) programming educational content anymore.

I recently saw a post from an engineer and content creator who got laid off from Laracasts.

I guess it’s hard justifying spending money on learning something that Claude can one-shot for a fraction of the price.

Adam Wathan shared how Tailwind has been struggling, so he had to lay off 75% of his engineers as well.

Honestly, it leaves a bitter taste in your mouth to see some of the best developers out there struggle. Especially Adam, because Tailwind is the LLMs’ favorite way to write CSS.

But it’s difficult to monetize these tools when code reusability is not that much of a problem anymore, and people don’t even open the docs.

Personally, as someone who has self-published a few programming books, I can attest that I’ve heard fewer Gumroad sales notifications in the last 6 months.

Management and delegation

I stepped back from engineering management a few years ago because I was afraid that I was getting detached from programming.

I didn’t want to get rusty and become unable to code. But now this seems like an irrational fear. It may be possible to have your cake and eat it, too. When coding agents don’t require you to be that hands-on, retaining a good intuition about good software may be enough.

Jason Fried from Basecamp posted something that made me think.

This is certainly something I’m getting used to.

Not only are you delegating to total competency, but to someone who will follow your directions. It’s rare to make a technical request that doesn’t get questioned, dissected, or argued about. That’s our job at the end of the day.

But now I can ask for something specific and obscure, and actually get it.

Somehow related to that, Boris Cherny (the creator of Claude Code) posted about how he uses coding agents.

It seems like the best base for programming is not mathematics but Starcraft.

If you’re good at context switching, you can manage a whole economy of agents to build things. I don’t have the focus of a pro gamer, but I watch Serral playing Zerg from time to time for inspiration.

Where’s the speed?

While corporate software engineers are slowly feeling increased benefits from AI, it still feels like there are two Stranger Things-esque parallel dimensions between startups and corps.

Developers may be faster, but companies don’t move as quickly because they’re bottlenecked by processes - approvals, holidays, regulations, and budgets.

“Great progress. Let’s catch up next week and continue.”

You may be able to generate your code more quickly, but the company moves with the speed of the weekly sync.

Also, the more niche your work is, the less assistance coding agents can give you.

Go ask an engineer at SAP whether they feel the boost in productivity as they’re wrestling with their tailor-made highly scalable infrastructure and in-house programming language.

---

The uncomfortable truth is that once you can start working productively with a coding agent, it’s very hard to come back from heavily assisted development.

I can feel the tension in my programming-related braincells reducing with each prompt I send Claude, and some days I’m half-tempted to ask it to change a button’s color. But it’s unethical to contribute to melting the ice caps for a prototype.

Regardless, I will be doing my best to build good products.

“Don’t waste time thinking how to build good software. Build good software.”

Or whatever Marcus Aurelius said.