VibeOverflow

This is what one day looks like in the simulation, in the order it happens. The reference world is a Clothier town with a target population of 500, seeded at 100, growing 10% per week, trading against a single infinite-liquidity port that stands in for the rest of England. What this town actually does for a living The town is specialized in cloth. The clothier comes with twenty spinning wheels, four hand looms, a fulling mill, and pays wages for spinning, weaving and fulling. It buys wool and sells cloth. ...

In an earlier post about picking a game engine I claimed that I try to write the core of the game in an engine-agnostic way. The post ended on a hedge — in theory I could switch engines, in practice I did not believe it would be easy. Time to actually find out. So I wrote a copy of the Godot project in three.js. If the claim is true, everything should work. A couple of Claude sessions later, three.js is running. It more or less works — buildings render, you can click them. ...

Clean code is bad for vibe-coding. For decades, the software engineering industry has put a lot of effort into making code readable — for example, books like Clean Code and Refactoring became influential because they focused on readability, maintainability, and improving existing code. And the progress is remarkable: we have come up with a lot of architectures to make code readable. And for LLM agents readability is even more important. If an agent is like a senior software engineer with amnesia, they need to be able to understand the project with the least effort. ...

After seven months of building a strategy game with Claude Code, a handful of habits have stuck. None of them are profound in isolation. The compounding is what matters. TDD is king Every new behavior must go through the red-green approach. If you do it the other way around, the agent is going to lie to you. It will make fake implementations with TODO, for now, or “temporary” logic, then write a perfectly green test and claim that everything is done. ...

One technique I keep returning to is improving a small, well-tested piece of code over a metric, in many small autonomous passes, with the worst attempts thrown away. The unit of work is one cycle: an isolated git worktree, an open-ended prompt, automatic tests, an automatic merge or discard. No single cycle is dramatic. The whole point is that they compound. It works when two things are true: the code under improvement is well tested, and the metric you care about is honestly definable. It does not work otherwise — the gate becomes either meaningless (no tests) or gameable (the wrong metric). ...

After seven months of vibe coding it’s time to look at what came out of the box. Below are two angles on the same project: the C# codebase itself, and the Claude Code sessions that produced it. Code, in lines Hand-written, EF migrations excluded: Bucket Files Lines of code Production 1,065 51,441 Tests 263 58,690 Total 1,328 110,131 Test-to-production ratio is 1.14 — slightly more test code than production code. That is the goal: as many tests and as little production code as possible. I will write a separate post about why. Median hand-written file is 22 lines. ...

If I wanted to vibe-code a game, which game engine should I choose? Which game engine is the best for vibe coding? Unity The first engine that came to mind was Unity. I know C#, it is popular, there are a lot of resources to learn from, and in general it is indie-friendly. On the other hand, Unity has a track record of bad behavior toward the community and controversial licensing decisions. The most obvious example is the Runtime Fee controversy: Unity introduced a per-install fee in 2023, then cancelled it in 2024 after strong backlash from the developer community.1 ...

My name is Azat. I am a software engineer who has recently become very interested in AI and LLMs, especially in coding. Why this blog? For the last seven months, I have been trying different approaches and techniques for agentic coding. There have been a lot of learnings along the way, and so far they have mostly lived in my head, which is honestly not the best storage. Another reason is that I want to track both my own progress and the progress of the AI ecosystem. Since I am starting this blog after seven months of experiments, there will be some retrospective posts until I catch up to the present. ...