I didn't love coding. I loved building.

Modesty aside, I considered myself an excellent developer, and I imagine most people reading this do too. I cared about clean code, SOLID, architecture, performance, and all the supposed best practices we've studied over the past few decades. I was proud of putting something into production and watching people use it, something I'd made with my own hands. I saw myself as a craftsman: someone who read a diff the way others read prose and lost sleep over a badly named variable. Even if only 30% to 50% of my day was actually spent with VS Code open, it was, without a doubt, the best part of it. Picking good names for classes and functions, laying out a clean folder structure, solving an architectural problem by fitting in the right design pattern, finding the one line behind a production bug after an hour of digging.

I loved coding!

Or did I? At the end of the day, when I closed VS Code, did my satisfaction come from having written code, or from having solved a problem? Today I know the answer. But back when AI started writing the code, I didn't, and that gave me a few identity crises.

The sentence that slipped by

Let me go back to a sentence from above:

I was proud of putting something into production and watching people use it, something I'd made with my own hands.

That's it. That was the reward. Code was the means; the goal was always to solve a problem, to build something.

Think of a feature you spent weeks, or months, on before the AI era, and it got cancelled. Or worse: it shipped and nobody used it. How did that feel? Did the pride in well-named classes make up for it? If your answer is "no", or "only a little", then you, like me, are a builder.

Source code became a commodity

"Source code is a commodity." You've probably read that sentence dozens of times in recent months. And after the latest frontier models, it's hard to argue that code written entirely by AI is inherently worse than code written by a developer. In my experience, the inflection point was Opus 4.8; some will say it came a bit earlier, a bit later, or never. This post isn't about that debate, which is covered plenty elsewhere.

The point is a different one: code became a commodity, engineering didn't. Writing code was always just one part of the job, maybe a third of it. The rest is understanding the problem, deciding what's worth building, knowing it works, and keeping it running.

A pot of gold for builders

For people who build, the AI era is a pot of gold. I've lost count of how many shelved projects, blocked by the bottleneck of writing the code, I brought to life. Projects I'd never have had a chance of finishing before.

Astrodoro. One of my main hobbies is astrophotography. No software on the market fit my setup (a Mac plus a Dobsonian telescope), and the ones that covered part of my needs weren't cheap. So I built my own: with what was good in the existing tools, plus what I needed and couldn't find. It's a complex piece of software, with tracking, live stacking and camera SDK integration. I now use it at least twice a week on my observing nights.

Drawdoro. A whiteboard drawing tool in the spirit of Excalidraw. I've always liked whiteboards: sketching flows and diagrams before getting my hands dirty. Same story: options exist, but none had the set of features I wanted. Drawdoro has real-time collaboration, per-diagram documentation and an MCP server, so AI agents can read, comment on and edit diagrams alongside us. We also run an adapted version internally at my company, without paying for a SaaS license.

Engineering Pulse. An internal tool to manage all engineering metrics in one place: DORA metrics, team KPIs and KRs, and, beyond those, the people side, with PDIs and 1:1 tracking. What used to be scattered across spreadsheets, dashboards and loose notes now lives in a single system, built exactly the way our engineering works.

There are others. Astrodoro and Drawdoro are open source on my GitHub.

There's a satisfaction that's hard to explain in using, every day, a tool that didn't exist a few weeks ago and that I put into the world myself. Setting up the telescope, opening Astrodoro and watching the image form on the screen. Opening a diagram and seeing someone on the team drawing on it at the same time. Watching the team check Engineering Pulse without me asking. It's the same reward as always, just arriving much faster.

"But what about code quality?"

I have to admit: it's still hard for me to fully let go of the code being generated. But reviewing everything AI writes is impossible, and AI loves adding lines, not removing them.

What I'm learning to do is stop trusting the code and start trusting the pipeline. On every PR, before it reaches production:

• Boot smoke test: the application actually starts and answers on /health and /ready.
• import-linter: architecture contracts that AI can't violate without CI complaining.
• mutmut (mutation testing): deliberately breaks the code to prove the tests actually test something.
• Quality Report: a single comment per PR summarizing everything.

And, of course, the usual quality tools running alongside: ruff (lint and formatting), mypy (types), bandit (security), vulture (dead code, great against AI's tendency to only add) and xenon (cyclomatic complexity).

All of it lives in my template (py-awesome-template) and is inherited by each project. If an agent writes a thousand lines, the pipeline decides whether they get in.

All of this was fast. And that has a price.

The projects above became usable in days, some (like Drawdoro) in two nights. I've been refining them since: fast to first use is not the same as finished.

I think SaaS companies should start getting worried. Not only because competitors will appear (that will happen too), but because the more likely scenario is each company building its own version in-house, tailored to its taste, and no longer paying licenses for tools it only partly uses.

Here at my company, after Drawdoro, Engineering Pulse and other tools, we've already talked about having our own versions of bigger tools, like GitHub and Jira. Would we need a 1:1 clone? Of course not, and I'm not naive: even with AI, that would take months. The point is to build only what we use day to day.

The honest counterpoint: a tool you own is a tool you maintain, secure and document. If the one person who understands the system leaves the company, the gain turns into debt. Building got cheap; maintaining didn't.

Conclusion

Code is no longer the bottleneck. What remains, and always was the essential part, is knowing what's worth building and how to be sure it works. Maybe the market will need fewer developers in the near future, but it will keep needing builders.

I didn't lose the craft; I lost the middleman between the idea and the product. And I found out that what I loved was never the typing. It was seeing the problem solved, live, in someone's hands.