EasyStay hit the market, the agents grew bored and started asking for more work… No, of course they didn't. They're soulless machinery. It was my own inability to sit still that started digging old ideas out of unlikely corners of my head.
After two apps, those ideas no longer felt quite the same. Previously, “that would be fun to build” could simply stay there. Now I knew I could sit down, explain what I wanted to an agent and start. “Who would write it for me?” had quietly stopped being the main obstacle, while “what else could I build?” kept getting more interesting.
One of those old ideas was a dive computer.
I used to do quite a bit of diving, and having to carry a separate device or rent one every time annoyed me. A good dive computer costs money, especially if you'd also like to wear it on land. I've long had one requirement for gadgets: they should do more than one thing. It's the twenty-first century, for heaven's sake. Why does every activity need its own electronic object?
Then Apple released the Watch Ultra. A watch I could comfortably wear, with capabilities for underwater use — obviously I wasn't going to ignore that. I bought one, started investigating and found that the built-in app didn't really do what I wanted for diving. To me, it felt more suited to swimming and snorkelling than to being the dive computer I had in mind.
Fine, there were third-party apps. Download, investigate, meet the subscriptions. What stuck in my memory from the options I tried was a few free days, then a monthly or annual payment. But what if I only dive occasionally? I don't need a dive computer sitting ready for the rest of the month while I'm on dry land. I'd like to pay for the time when I actually need it.
That thought sat in my memory for a couple of years, until I learned how to turn dissatisfaction with other people's apps into work on my own.
That's where WeekendDiver came from. It also gave me a job I hadn't really tackled before: researching competitors. With ManiTalk and EasyStayTH, I'd been convinced there was nothing comparable in the stores. Here, a market with other people already working in it was plainly visible.
The agents and I looked through apps, subscriptions, prices, screenshots and features: what seemed convenient, what immediately made me want to change it. Before building something yourself, it's useful to find out whether somebody has already made exactly what you need. Perhaps the bicycle is sitting in the shop next door while you're preparing to invent its wheels.
We even found an option with short payment periods, but our research at the time suggested it primarily served a Chinese audience. I wanted to make something for a wider market. I also brought in a friend who's a dive instructor. She helped with the interface and some parameters, and told me what watches her students wore. According to her, Apple Watch Ultras were common, which gave me more confidence that a niche might exist.
We started building with established calculation algorithms and got as far as a partly working prototype. There's a considerable gap here between “something runs” and “you can give it to people”. A mistake in a reminder app and a mistake underwater can have very different outcomes. An established algorithm still has to be implemented correctly, so validation, comparisons with dedicated dive computers and the rest of the testing are still ahead of me. I certainly won't release it just because an agent cheerfully reports a successful build.
Alongside the projects, another need was growing: I wanted to automate the development process itself. If I had something that could write code, why was I still spending so much time explaining how it should work?
At the end of the previous article, I was still carrying most of the design in my head. Documents were appearing, project information was being collected, and I'd written down some preferences. Yet every new session began with introductions: this is what we're making, this is how it should behave, don't touch that yet, and yes, we've already tried this other thing, thank you, please don't try it again.
For someone fond of automation, it got irritating quickly. I wanted an instruction I could give the agent once, after which it would understand everything and do the right thing.
A magic prompt, basically.
Spoiler: there isn't one.
Easy for me to say now. At the time, I searched quite diligently. I read articles, followed people discussing AI, collected their prompts, edited them and added my own requirements. This had been going on since my earliest experiments, but as development continued, I hoped to assemble something final out of all those discoveries. There: the correct instruction. Now we can work. One-shot development, the fool's dream.
Advice on “how to talk to a neural network properly” wasn't exactly scarce. Usually, before finding something useful, I'd read several explanations of why the previous approach was wrong and I should do the opposite. By then, AI itself was helping me summarise articles and extract ideas worth trying. Otherwise, reading about saving time could consume all the time I'd meant to save.
I edited prompts, glued them together and pasted them into agent settings and the custom instruction fields. The logic seemed obvious: explain in more detail what sort of developer it should be, and it would develop things better.
Something like: “You are a great programmer, an architect of extraordinary ability. Your code should hang in the Louvre. Make no mistakes. Think carefully before every action. When finished, check your work seven times.” Several screens of this, just to make sure it appreciated the responsibility.
DO NO MISTAKES!!!
What more could a person — sorry, a machine — possibly need? I'd explained everything. Some of it was even in capitals.
Meanwhile, the skills were piling up. If you haven't encountered them, here I mean instructions telling an agent how to perform particular tasks, sometimes accompanied by tools or scripts. A little operating guide it can load instead of figuring out an operation from scratch.
There were whole libraries of these guides. I found new ones, checked whether they fitted, loaded them and tried them. Then I'd open another session and select the set again. These today, those tomorrow, and the day after that I'd need to remember where we'd put that useful one.
A delightful form of automation: to do less work by hand, first do all this extra work by hand.
The million instructions themselves weren't even the main annoyance. It was maintaining them. I wanted to work on the app; instead, I was selecting the things to give the agent before it could work on the app. Every time, it felt as though one more rule, the really correct one, would finally make the process come together.
Then I noticed something unpleasant. My magnificent megaprompt seemed to lose its magic rather quickly. Sometimes, by what felt like the third request, Claude behaved as though we hadn't discussed parts of that long introduction at all. I had to steer it back to the rules, clarify and remind it. Much the same work I was trying to eliminate.
At the time, I explained it to myself as the growing context pushing out the original instruction. We'd said so much that it had become lost somewhere. I didn't measure which parts, if any, had physically disappeared from the model's input. What I observed was the behaviour: the agent stopped following parts of the instruction, while continuing to produce code much as before.
That was interesting. I'd spent time telling it what an incredible specialist it was, yet it already knew how to write code without my explanation. Awarding it the title of “genius architect” didn't improve its memory of my decisions, either.
Gradually, a simple point got through to me: Claude didn't need me to tell it it was a great developer. I needed the result of good development. For that, it was more useful for it to know which app we were building, what we'd decided, and why it shouldn't improve this working piece into complete uselessness again.
Those are very different kinds of information. “Make no mistakes” says nothing about the bug we spent three hours finding yesterday, how we found it, or why we chose that fix. I'd quite like today's agent to start there instead of independently rediscovering yesterday.
With a one-off task, things were more straightforward. Want a picture? Explain what's in it, how it should look and what to change. There's a request and a result you can inspect. An app doesn't stay that simple: work on one part teaches you something about another, a decision changes, a constraint appears, and the original idea keeps acquiring detail.
What prompt could I write at the beginning that would contain everything I wouldn't learn until a month into development?
The hunt for a perfect instruction gradually faded. Recording what we'd learned about the project became more useful than awarding the agent another honorary title. Understanding what I wanted and how to check the result mattered more than finding the perfect wording. This wasn't an overnight revelation. I tried solving the problem with another paragraph of instructions plenty more times first.
Skills are a more complicated story. A ready-made guide to a specific operation can be useful, and my agents use them. But a collection of other people's guides doesn't know my idea, remember our decisions or notice on my behalf that a feature is unpleasant to use.
AI skills are debatable; my own human skills turned out to matter more. Understanding, explaining, asking “why are we doing this?” and examining the result were still things I had to practise myself. Nobody had uploaded a file I could load into my head to instantly understand the project, either. Now that would be useful. I'd download it.
Meanwhile, the ideas kept coming. Some could wait, others could be revisited later, but this particular queue always had one way of being rearranged without warning.
WeekendDiver went on the shelf because A. had another idea.
Coming up: there are plenty of bicycles out there, but this one's frame is bent and that one's wheels are rusty. Or: how we decided to build an actual messenger. Stay tuned.