Stefan Wittwer

I wrote my first line of code over 15 years ago (I got into it quite young).

Over the years, I moved from Visual C# to the web, picking up new technologies as they came and went. I got into web development when PHP and jQuery was still popular, and eventually learned React and TypeScript.

But something changed at some point. Building things felt repetitive, and I found myself increasingly disengaged from the process.

I tried building web apps with new technologies like Next.js and serverless functions in an effort to embrace the new way of doing things, but I only ended up increasingly irritated – particularly having to now also deal with the strange implicit limitations and rules around Next.js.

Every line of code felt like a chore and the more I wrote, the more I hated it. I felt like I'd seen it all before, always writing the same thing over and over again in slightly different ways, and was just going through the motions.

But something changed in late 2024, when I got access to the Copilot Workspace technical preview – my first glimpse into agentic coding at the time. It was still early days and was useful on basic tasks, but I immediately realised this was going to be the way we write code in the future, and I loved using it every chance I got.

Then, in 2025, I moved tried out Cursor, Claude Code, Devin, Replit and Codex. It's been insane to witness the rapid evolution of code quality possible with these tools, and it's since completely how I write code.

Today, coding feels fun again. I can go and try out a bunch of new things that would've taken me forever to setup and tinker around with.

I can let AI agents write the features I've written a thousand times before by just writing a good spec, and I can focus on the things that are truly unique and interesting to me, like playing around with the right design for something or refactoring a piece of code to my liking. I can even collaborate with agents on these more advanced tasks too, which is extremely fun.

It also makes it possible to work on things that would've been very hard to maintain in the past, like writing native apps in Swift or Kotlin, or building new custom CLI tools for my own use.

It's a little strange – AI doing more of the typing somehow made me feel more like a builder again, not less.

For the first time in years, I feel like that kid who stayed up way too late just to see if he could make something work.

Everyone is using AI in product engineering to ship more. Some people think this means lower quality products – and it's not hard to see why when people brag about their terrible vibe-coded products. But I disagree. In fact, I think AI can help set the bar for quality a lot higher than it ever was.

I'm not necessarily talking about automated testing or code review here. There are good tools for that and AI certainly is helping greatly with those.

I'm talking about the more nuanced elements of product quality. Improving the surface area of rushed features, fixing papercuts and onboarding stumbles, UX writing, documentation, removing outdated features, and generally polishing the small things no one ever has time for.

My relentless product improvement workflow

When using my own product, or when watching a user test, I keep a notes file open where I jot down every tiny thing that annoys me. Anything that's small enough to not be worth a ticket, but still annoys me enough to remember it, I jot down as a short bullet point in Markdown. If I notice anything that's more complex to fix or requires some more thought, I ask Claude Code to create a ticket in the Linear triage.

Then I take the entire list of improvements and bugs, put it into a IMPROVEMENTS_TODO.md file in the root of the project, and let Claude Code just work on it for a while. This way, everytime I use the product, we get to ship usually 20 small improvements. The entire process takes less than an hour.

This is akin to the concept of "kaizen" in Japanese business, invented by Toyota in the 1950s. Kaizen is the practice of continuously improving the small things in a process. It's a practice where a strong feedback loop is created in order to make processes better over time.

Even though a single improvement might not be worth a ticket, the cumulative effect of all these tiny improvements are really significant and compound into a much higher quality product.

I used to track a lot of these bugs and papercuts in the past too, but since they were often hard to prioritise in the day-to-day with a small team before AI, they often ended up forgotten somewhere in a massive backlog.

Continuously improving a software product every day and at every level of detail now comes with almost zero opportunity cost.

A while back, I started sharing some of my thoughts on product design over at Intentional. However, I want to get into the habit of writing more regularly and sharing more thoughts across wider topics of my work, especially since writing is a great way to clarify one's own thinking.

Since many of the things I wanted to write about never really fit into the format of Intentional, I've been trying to find a different space to write, in a more free-form, almost journalesque way.

This is my attempt at doing that. Let's see how it goes.