What I build now that the machine writes the code

A third piece, after "What's left when the machine writes the code" and "How to start when the machine writes the code." Those were arguments about engineers in general. This one is just about me.

I have written twice now about what AI means for software engineers: what stays valuable when the machine can write the code, and how someone starting out can build those things. This time I want to be concrete and personal, because something specific changed in my own work this year, and it is not the thing people usually talk about.

The headline is not that I type faster, though I do. It is that the list of projects worth starting got much longer. There is a whole category of project that used to be automatically off my list, not because I did not want to do it, but because the cost was obviously higher than the payoff. AI lowered that cost. And when you lower the cost of building, you do not simply do the same things faster. You start things you would never have started at all.

Three of those came off the shelf for me this year. One was too big. One needed a skill I do not have. One was too small to ever justify the time.

The one that was too big: WordPress

For more than fifteen years, HikaShop (an ecommerce solution I started more than 15 years ago) ran only on Joomla. A common request I got was some version of "will this work on WordPress?", and for years my honest answer was no. Not out of stubbornness, but arithmetic. WordPress has a different API, a different templating system, a different plugin model, a different idea of almost everything. Supporting it looked like rewriting fifteen years of mature, battle-tested code from scratch, and a small team does not have those years to spend. So it sat on the shelf, indefinitely.

With AI I tried an approach I would never have attempted by hand, because by hand it was simply too much typing: a bridge that emulates Joomla's API on top of WordPress, so the existing HikaShop code could run mostly unchanged. I had it working in a few weeks, not the years I had always assumed. The project was never impossible. It was priced out of reach. AI changed the price, and a multi-year undertaking became a multi-week one.

The one that needed a skill I do not have: a good template

For a long time I have been frustrated with the choice of templates for HikaShop, the exact same frustration our users have. I wanted to build a genuinely nice one. The problem was simple and, I assumed, final: I am not a designer. That is not a gap you close by working harder or longer. It is a skill you either have or you do not, and I did not.

AI did not hand me taste, and I want to be careful here, because this is the part people get wrong. What I already had was the outward kind of taste I wrote about in the first piece: a feel for how the thing should look and where it should go. What I lacked was the craft to execute it. AI closed enough of that execution gap that I could turn a direction I could feel into something real on the screen. Vessel, our first HikaShop template, exists because the skill barrier dropped low enough for me to climb over it. The judgment was mine. The hands were partly the machine's.

The ones that were too small to justify: tools just for me

The change I did not see coming is at the small end. Everyone has a list of daily annoyances they have simply learned to live with, because solving one properly would cost a weekend (or more) you would rather spend on anything else. The annoyance is real, but the fix was never worth it. AI moved that line. A weekend now clears problems I had put up with for years. Two of mine.

I sit on the board of an association that runs in Japanese, which is not my first language, and I was drowning in email I could not keep up with. So I built JARLIS, a triage system that reads the flood and tells me what actually needs me. I told that story in the last piece. I built it for myself, and ended up publishing it.

The other is Omnitext. Opening documents on my phone was genuinely miserable. To cover every format I had accumulated a small museum of apps: one with ads, one that wanted my personal data, one that was not free, one that was simply slow. I wanted a single thing that opens anything, keeps my files on my device, costs nothing, and is fast. So I built it. Omnitext opens basically any file - code, PDF, Word documents, spreadsheets, images, archives, the lot - in the browser or as an Android app, with nothing ever leaving the device. It even grew its own little family of reusable libraries along the way, which is its own answer to the question of how much one person can take on now.

The thread

None of this is really about speed. It is about cost. AI made building cheaper, and the interesting consequence of a cheaper anything is not more of the same. It is that things sitting just on the wrong side of "worth it" cross the line. The too-big becomes a few weeks. The out-of-reach becomes reachable. The too-small becomes a Saturday.

My old list of "someday, if I ever have the skills and the months" projects mostly collapsed, some into shipped products, some into little tools I now use every day.

I will keep the honesty from the first two pieces, because this cuts both ways. If building is cheap for me, it is cheap for everyone, and the result is a flood of built things. So the scarce, valuable part is no longer the building. It is the judgment about what is worth building at all, and whether what you made is any good. Those are the human questions, the ones the machine does not answer for you.

The constraint on my work used to be "can I make this." Now it is much more often "should I, and is it any good," and I think that is the better question to be stuck on. The machine writing the code did not shrink what I do. It widened it.