My Updated AI Workflow

A few months ago, I wrote about my AI workflow, which is basically forever ago given how fast things are moving nowadays. I figured I’d write an update with a few things I changed over the months. It’s worth noting that most of my work nowadays is on my boxing app, which is a fairly small codebase where I’m the only one merging code in… so if you’re at a large company, it probably won’t translate very well.

I Still Write Code By Hand

Maybe it’ll change, but there are some cases where it’s just simpler to write the actual code than to prompt an agent.

Building New Features

Let’s take a new exercise I added to my app: working up to a combo one step at a time. Basically, you take a boxing combo, break it down into smaller pieces that make sense on their own and then call it out over time. It’s not that complex, but there are many small details: what combos to use, how to break them down, how much time to give each step, how to adapt to the user’s boxing level, whether the app should give advice or not… It’s those many small choices that make the feature good or not!

I could:

• Spend time writing a spec, thinking about all cases and making sure things make sense.
• Yolo a prompt and iterate over whatever it gives me.

However, I spent years building a form of DSL that allows me to create new exercises. It comes with a live preview of what it will look like, hooks into every relevant part of the workout engine, and I can easily add to it when needed. The feedback is almost immediate and I can tweak everything right away.

I’d much rather define how the exercise will work there than give that to my agents in plain English.

Visual Design

It’s the same thing for design. In some cases, I really care about what the end result will look like, so I can’t just tell Claude to build whatever it wants. In this situation, I’m much more efficient defining the layout in SwiftUI than in Figma. Not to mention prompting, where it can become maddening to explain exactly what you want.

I Still Value Stability

I don’t believe in shipping fast and breaking things for my production apps. Yes, I could ship like crazy and fix as I go, but I don’t feel like it’s good business. Not only would it disappoint users, but it would also drown me in support tickets.

I really value the peace of mind of knowing that my app is stable and I can just go pay attention to something else without fear of things breaking down. For instance, I recently went travelling to see family for a week and didn’t even take my laptop, as I was convinced things couldn’t fail.

I Let Agents Do Much More

While I still code “manually”, more and more of the code produced for my business comes from agents.

Internal Tooling

First of all, I have many more vibe-coded tools than earlier this year. Simple productivity apps, monitoring dashboards, video editing assistants, financial analysis tools, support ticket management… I built software to help me with basically every facet of my solo business. This was already the case earlier this year, but I’m building more and more.

I haven’t seen any maintenance issues so far, but the bar is pretty low, as the tools only have me as a user.

No More Planning

In April, I was using planning modes a lot. Now, it feels just as efficient and fast to just do the thing. I sometimes ask for a general outline before actually coding, but I’ve greatly reduced the amount of planning. So far, I’ve been good just building a vertical slice of a feature and looking at the code and how things behave instead of producing markdown plans.

Android

For years, I had a constant stream of complaints that the app wasn’t available on Android, but I just couldn’t build it in a way that would make sense financially. Learning Kotlin and the entire Android stack on top of everything else I had going on was not realistic. Hiring someone to do it would take a lot of time and money I couldn’t spare.

However, earlier this year, given the improvements in models and the general agentic approach available, I thought it had become possible to port the app to this new platform. The main thing I had going for me was that it was “simply” a move to a new platform: what’s a better spec than a complete codebase?

So, in May, I released my boxing app on Android mostly using Claude, and it’s been running in production since then. For this one, I couldn’t review 100% of the code as before, and had to rely much more on automated tests and better monitoring. To keep things stable, I leveraged the iOS app heavily, using it to generate test scenarios and to check that things were working correctly.

This part is a huge change compared to earlier this year, and I’m still struggling to find the right level of oversight for my agents. Still, the app is in production with thousands of monthly active users and pretty good reviews.

I also got many thanks from Android users who had been pushing for an Android version on my social media for a very long time.

I Have New Tricks

As time passes and I spend more energy using Claude, I’m getting better at avoiding pitfalls and saving time. I won’t go into detail, as each trick could be its own blog article, but for instance, I…

• Started including manual QA in my cost estimates before starting a feature. 1h of Claude, but a day of manual QA? Maybe it’s not worth doing. I never skip manual QA for production apps.
• Significantly improved my monitoring to account for possible regressions, and I’m ruthless about fixing any issue.
• Wrote a few skills for code reviews and release preparation that are much more helpful than generic ones, as they perfectly fit my use case.
• Saved a lot of review time by writing a bit of code (function signatures, class outlines) before prompting the agents, basically telling them to continue where I left off. This way, they produce something more predictable, fitting how I would have done it.
• Stopped using the best model for all tasks and instead paid more attention.
• Stopped stressing out when my agents are not running. It was getting unhealthy, but I think I got out of it.
• Started using MCPs more to access live data and take some actions.