A change in direction

One baby, one iPhone, one week

About a week ago, I started Ultimate Kami, a simple iOS app that tracks calories, weight-loss and training targets. I built and released it on the Apple App Store within a week, while taking care of a four-week-old son, while signing for a home loan, and while cooking meals and cleaning. I developed 95% of it on my iPhone via Claude Remote Control, using Wispr Flow, often while cradling my little boy to sleep.

This has been such a large contrast to the approach I took to developing namagen, to the point where I experienced a we are now living in the future moment. Using a natural speech interface for development is a complete paradigm shift.

Every instruction spoken in plain English, without typing, without looking at a single line of code. The lightning speed with which I was able to get Ultimate Kami into a shippable state has made me fundamentally question my approach to building software.

Passion is a fool’s errand

In comparison with namagen, Ultimate Kami was never going to be a passion project. Its primary reason for being was to solve a simple but concrete set of problems. But I was able to solve them so quickly and completely, using a development method so completely foreign, that it shook me to my core. Some might call this AI psychosis. But that doesn’t really matter. The point is, I was detached from the process enough to be able to focus on the actual problem.

Since development and iteration times were so short, I was able to test it in the real world only a day or two after starting the project and apply that internal feedback straight away. Compare that to namagen, a passion project, where it has literally taken me many years to get the app to a testable, real-world usable state.

Falling in love with the problem

namagen was built with the Handmade philosophy from the start, in that I used minimal libraries, and everything was written from scratch. I understood every part of the code, from sample-level DSP to the overall architecture, data structures, memory allocation, serialisation, absolutely everything. I implemented my own programming language and VM, multithreaded synchronisation and serialisation, audio processing, a 2D renderer and infinite canvas, and an immediate-mode UI library. All without the use of agentic coding tools. Working on it has been an incredible learning experience, and I’ve produced something I’m very proud of. Something I didn’t think I was even technically capable of just a short while ago.

But therein lies the problem. I was in love with the work itself, and I was in love with the technology, more than solving real problems that real users have. I am now convinced I need to test my idea, figure out what problem I’m solving for users, and fail early if need be, before going all in and dedicating an insane amount of time to building something.

While this could be considered somewhat orthogonal to using agents, I think the contrast between falling in love with the problem and falling in love with getting things done has now been amplified by them. Similarly, the Handmade philosophy becomes harder to justify when iteration times are measured in months or even weeks, compared with days.

I’ve decided that if I want to be successful at creating and selling software that people want, I need to drastically change my approach. I’m going to do my best to avoid falling in love with the work, spending too long on a problem, or going too deep where the technically satisfying results may be great but the user-facing impact is diminishing.

I’m forcing myself to become customer- and product-focused. I will find problems that people are willing to pay to have solved. This is a very different approach for someone who has been a hardcore engineer for most of his adult life.

Engineer to manager

Using coding agents means taking off my engineer’s hat and resigning myself to becoming a manager. Agents are much more like a team of programmers available 24 hours a day to untiringly perform whatever tasks you wish. As a manager, I have to resign myself to the fact that I certainly won’t achieve quite the same level of control as if I had written the code myself. However, the trade-offs become worthwhile if I can assign tasks to my team of programmers in parallel and reap the associated efficiency gains. This is really where using agents comes into its own.

Being able to communicate with my team in plain English is also an incredible win. English is lossy and full of ambiguity, and I have to accept the inaccuracy that comes with it, but I no longer have to work in a terse, unforgiving, error-prone programming language.

I can see why this is a hard pill to swallow for many engineers. One is basically changing their entire job description.

For some hardcore engineers, it will become nearly impossible to make the switch. The hardcore engineer’s mindset of wanting to do everything for oneself, unable to trust any third party (another person, an external library, or an agent), is hard to reverse. I feel bad for people who have a love for the craft, because ultimately, they are the ones who will lose as this revolution really starts to accelerate. I’m convinced we haven’t seen anything yet.

Having said that, intimate domain-specific engineering knowledge is a massive advantage when working with agents. A manager who has a deep knowledge of engineering and process is much easier to communicate with, and generally produces much better results from a team of programmers. I do believe the same is true with agents.

Minimum viable ventures

I’m setting myself the challenge of iterating over many different minimum viable ventures. I believe that with agents, much more ambitious ventures can now be built in much less time. I can get an idea off the ground within days, test it, see if it has some tailwind, and lean into it if so. Ultimate Kami is the first iteration.

From here, I think as long as I can sustain output and keep funnelling ideas towards users and commercially viable products, I’m bound to find something that works. The old adage of aiming to fail is very apt here, and I think it’s a much better approach: short iteration times, testing user demand, and if there is none, chalking it up as a learning experience and moving on to the next idea.

Compare that with namagen: six years building, where the sunk cost is so absurdly high that the thought of giving up on it is almost unbearable. The contrast is night and day, a thousand times so in the age of agents.