Lessons learned while Vibe Coding
How OVM Diveplanner came into existence & what I'm learning
First half of 2026 I delivered my first agentic coded product: a scuba diver decompression planner in the Apple Appstore. The first version was build somewhere in 2004, using Excell en Visual Basic. Turning it into an actual usable application remained in the back of my mind.
Somewhere in 2023 I started using ChatGpt for my work. Fixing pieces of code. Writing code in languages I wasn’t fully versed in.
It was ….. ‘do-able’. On a good day. Copying code to your IDE, running it, copying the error messages back to the chat window. But calculating a decompression profile remained impossibe. Even when I gave every open source code available to do the work.
Then early 2026 I gave it another try with Github Copilot. Half a day, I had a website running that calculated dive profiles that I would actually thrust. This lead to a new challenge, turning it into Swift code for IOS. A language I had never seen before. Used for a OS I had never worked with. So I bought a Mac.
Below are the things I ran into and the lessons I learned. In no particuler order, just written down as the came to me.
Random Musings
Copilot
Switch between models. The limits seems to be thightening monthly and the costs seems to be increasing with every limitation. Use cheap models for simple stuff: a question you need answered or a color schema change. Use the heavy models for reviews, checks, and heavy coding.
ChatGPT
Connect it to your IDE. It won’t get better than that (even though the latest version works very well directly in your repo through the app itself.
I think 95% of the work was done using ChatGPT / Codex, for the simple reason I could connect it to Xcode. Since it was a hobby project, if I ran into any limits, I just waited untill next day and let it work while I continues my day job.
Costs
They can increase enormously. Decide up front what it’s worth to you. It can be done cheap, fast and good, but only 2 of those are possible at the same time. Also work smart. Any pdf’s as context, convert them to markdown using something like Google Docs. Tekst files are cheaper and faster to process.
As for implementing an Agent: some if..then..else action: just write a script or function (or let AI write the script). If no interpretation is needed, you probably will not need an LLM.
The big stuff
Context Matters
Instead of just asking to work on an idea, provide
- goal
- context
- required output
The more context you provide, the better the result will be. This is just like old-school waterfall coding. First think through the design, as detailed as possible, order your thoughts, write then down and now you have your context. The nice thing about a decompression algorithm is that it is deterministic. So you can put your variables and constraints in a skill doc, preventing stochastic outcomes. This is also context.
Testing
When I’m writing code myself, I know what I want to do, I can run intermediate results and apply fixes. An agent goes much faster. And when it’s using a language I do not know it’s just a black box. So, after the design (the context), testing is much more important. So you need to have an understanding of possible results and be able to determine the correctness. Automated tests (generated by the agent) can only capture so much. As additional context I provided example decompression schedules so sanity checks were possible. Domain knowledge will become one of the most important skills you have when working with agents.
This is also why I’m not worried about my job (yet). Where I used to write code for a day, I now work on the context for a day. And then testing also needs to be done. The work is changing, not disappearing.
Way of Working
Trying to have Codex build my app, I ran into issues like halucinations, memory loss, model limit, token limits and newer versions of a model with different ‘ideas’. Its like hiring a new engineer….. I started working with a to-do list in markdown. Finish what we are working on, but put your findings in the list. I also let it create a changelog containing the updates. Finally I let it created a memory doc, summarizing the things we worked on, decision I made, updates and test results each I was done for the day. And when starting I let it read those files. Also, every now and then, but mostly after big updates on the app or updates on the model itself, I let it do a full review of the design, architecture, security etc. it usually came with some improvements or bugs that were missed in previous updates. This is what makes it continues improvement. It also handles unknown Tech or Design Debt as part of the process.