There is difference between coding and engineering. Coding is about writing code. Engineering is understanding that piece of code in its bigger context.

Before 1901, Ohio State had a grassy field between their library and University Hall. No paths laid down yet. Students walked to class anyway, carving routes through the grass as they went. Over time those worn trails became permanent, and eventually the university paved them. The geometric pattern they form is still there today, defining The Oval at the center of campus.

Product builders do something similar when they make tools flexible enough that people can bend them in unexpected ways. Boris Cherny at Anthropic calls this finding latent demand. You build something hackable and open-ended, then watch how people abuse it for cases you never designed for. Those unintended uses show you what people actually want. That’s apparently how Claude Code gets built. They watch what people hack together, then build features to support those patterns.

Both approaches are trusting the same thing. That observation beats assumption. That the people using something will show you what they need if you give them room to move and then pay attention to where they go.

The impact is remarkably similar too. You end up building what people actually need instead of what you thought they needed. The paths get laid where people already walk. The features get built where people are already working.​​​​​​​​​​​​​​​​

When gen AI is “thinking,” it’s deciding which part of its knowledge to search more carefully. Like a librarian checking a specific shelf instead of running around grabbing random books.

Two years ago we called this prompt engineering. We told the chatbot where to look. Now it figures that out itself. That’s the main difference.

The thinking lets it course-correct too. It can start at one shelf, realize that’s wrong, and move to another. With prompt engineering we had to guess right the first time.​​​​​​​​​​​​​​​​

Build products from real friction, not from ideas that sound good.

The current AI boom feels like the late 90s, reminiscent of the GeoCities era when anyone with Notepad and a few lines of HTML could create history. Now everyone’s building tools using AI in their spare time. That was a crazy time to be alive, and this is similar.

Infrastructure doesn’t need to be planned. It can emerge from experiments when keeping them around costs nothing.

I pay $5 a month for Cloudflare Workers. That gives me room for hundreds of microservices. So when I build something, I just add another one.

Right now I’m building LLM-specific microservices. One for Claude, one for OpenAI, one for each model I use. Could I build one service that handles all of them? Sure. But that gets complex. Separate services means separate simplicity.

No roadmap. No grand design. Just solving problems and keeping the solutions around.​​​​​​​​​​​​​​​​

Even though your company doesn’t think AI will improve your work and doesn’t invest in it, others might expect that you’re on top of it. Otherwise they might choose other companies that can prove it works for them.

It’s about keeping you relevant.​​​​​​​​​​​​​​​​

Someday in a distant future people will complain that your code is the reason they are in this mess.

Understanding someone else’s work is not the same as being able to do the work yourself. Watching is not practicing.

Becoming engineering manager and later CTO meant becoming a worse developer.

Not because I forgot how to code. Because I stopped feeling the friction.

I used to know when the build took too long. When a dependency broke randomly. When the deploy process made you hold your breath.

Now I have to ask people to describe pain I no longer experience.

You get promoted away from the thing that made you good at your job.

You lose the direct feedback loop. The thing that told you what actually mattered.

It’s a different kind of work. Sometimes I miss just feeling it myself.​​​​​​​​​​​​​​​​