AI Journal 2: Vibe-Coding for Fun and Profit
2026-06-22
I wrote earlier about how I started used agents for coding a bit later than everyone else who were into AI. I think I'm not the only of in my generation having a bit of a hard time coming to terms with the new reality of not actually writing much code myself. This journal entry is mostly just a dump of my thoughts on agentic coding and vibe-coding based on my experiences so far in 2026.
A Bit of Background
I started with OpenAI Codex back in February, and a few weeks later I moved on to Claude Code just before Opus 4.7 was released. At home, I adopted pi to customize my own agentic environment for coding, using it mostly with gpt-5.5 and Deepseek V4 Pro, which came out a bit later, occasioanlly trying out other models on OpenRouter as well.
I even bought a Geforce RTX 5060 Ti 16 GB to try local LLMs (and for some gaming). Qwen 3.6 27b works pretty well locally, though with only 16 GB, it's still just a toy (context too small with only 16 GB vram).
At work, I still review all the code I produce, but Claude produces about 95% of it. The last 5% is written by gpt-5.5. I write less than 1%.
At home, I haven't programmed much for the last three years for various reasons, mostly because of lack of time (familiy, kids, house) and health-related reasons (back pain after long hours at work).
Vibe Coding
So I wanted to try to vibe-code for real. Not at work -- the stuff I do is too important (and the customer hasn't agreed to it either -- yet), but I still wanted the experience. So I picked a project: A web-based, mobile-first, front-end for pi. I named it "Pi Pocket". It is now my daily driver. I never use ChatGPT or Claude web apps anymore. Pi Pocket fullfill all my needs. It reached 300 commits the other day. Early on, I did reviews. Now I almost never look at the code.
Development process of Pi Pocket:
- I basically just ask it to extent itself. If I find a bug, I describe it, and it gives me a plan for development. Then I say "go do it".
- I have a skill set up so it knows how to redeploy itself. I works fairly well.
- I can extend Pi Pocket "on the go" just by telling it what I want in a chat on my phone, and let it do its thing. I still think this is pretty cool.
Things that work well in general with vibe-coding:
- Giving the agent a small, clearly scoped task that is easy to reason about. Like "I want a button that does this" or "this doesn't work when I click right here under these circumstances".
- It is good a reviewing and refactoring, but you have to initate those tasks manually.
- It works well for planning. I often ask it what state the code needs to be in before a new major feature, and it will list things we should improve first. Then I review and pick those I think are actually important (often only half of them).
- Want to convert your whole code base from JavaScript to TypeScript? An agent will do so with no mistakes. I actually did that three weeks into the project.
Things that LLMs don't do well:
- The code that it produces is always at least a little over-engineered. Depends on the model, but they all have this issue to some extent. It takes time and effort to make it write less code for the same task. I estimate the code base it about 10-20% larger than If I had written it myself. But the agent did it in six weeks. I doubt I could have done it in six months.
- It is fairly good a writing UI code, but styling and layout always looks a bit generic or a bit off -- sometimes both. So I still manually tweak CSS sometimes, since iterating with the agent takes a lot of time with these kinds of tasks.
- It writes documentation well, but as with all LLM writing, it's verbose and follows the same patterns that all LLM writing does. I would never publish a readme by an LLM. I never understood people who did. LLM readme's are an instant turn off for me when I browse projects on GitHub. In fact, I still prefer to rewrite them completely in my own voice.
- This one is not specific for agentic coding: the LLMs will always agree with you on subjective matters. If I want to repriotize, it will always tell me that the new priorization makes more sense than the old one. Always be your own judge instead of relying on the reponses of a sycophantic AI model.
Pi Pocket Status
Right now, it has plenty of features, and I'm reached a point where it does more or less all I need. In fact, I might delete a few features I don't need after all. That's the downside of vibe-coding. Often you create stuff that you don't actually need because the barrier is so low.
Some current Pi Pocket features:
- Chat with any model using Pi as the backend
- Scheduled Jobs -- yes, schedule a prompt to happen later
- Integration to a local OpenAI Voice-compatible API (which I also vibe-coded)
- Integration to whisper (for voice input)
- File-sharing with the agent
- Color themes
- Workspaces
- Jobs can run detached from the front-end -- losing connection doesn't kill the job
- Various settings for "current work directory" and such.
- Sort, delete, and move sessions in the UI.
- Lots of other small features
It's basically how I want it. A few features I'm considering, but are still sleeping on:
- Sandboxing. Right now, scheduled jobs have a very limited tool set. I might open it up if I can sandbox it right (maybe using bubblewrap).
- Shared artifacts between sessions in the same workspace. Still debating if this will be useful or not.
- Shared tasks, prompts, skills, etc in the workspace -- same as above.
- I'm considering whether having backend runnings on different machines, connected by the same UI, would be useful or not (probably not)
- Shared secrets (environment variables). Maybe does not need to be part of Pi Pocket.
So yes, I'm basically designing, testing, and evaluation a nice web app without any coding, and without involving any other humans. This is pretty fun. I recommend everyone try it out.
For profit?
I've only covered the fun part so far.
Would I use this for work? Not unless the customer explicitly asked for it. I work mostly on contracts and never own the code that I write for work. I think it's very important to experience vibe-coding first hand so you know what works and what doesn't, and you can communicate this to other stakeholders. Maybe this would be fun for a fast PoC, but for maintaining critical infrastructure?
I'm sure I'll revisit this topic on some later date.
Thanks for reading.