The 505-Commit Invoice — Tin's Posts — Tin Marković

3 min read Original article ↗

← Tin's Posts · May 29, 2026 · 3 min read

The project had started well. Solid client, interesting problem, concrete scope.

Then requirements docs started showing up. Long. Structured. The type that has every edge case covered, every user story mapped, every field labeled. Thorough.

Too thorough.

Something was off about the asks. They covered the surface exhaustively and missed the centre entirely. The framing was too even, the language too clean - clearly not raw notes. 'twas raw notes chewed through Gemini (or somesuch).

On its face: still rational. Here's a requirements doc, design and build what it describes.

The problem was that nobody asked the right questions. The LLM asks what it knows to ask. What it doesn't know - the constraints, the actual shape of the problem, the thing you could surface in a 20-minute call - just doesn't make it into the doc. Requirements went a mile wide. It's not wrong. It's just not the right conversation.

The client had started outsourcing the thinking before I'd noticed they've stopped doing it.

We parted ways a few months later. Amiably - no drama, no post-mortem call, no contact. They've never accepted my documentation milestone. Clean exit.

Eight months on, having been auto-tagged on some alerts, I pulled the git log.

505 commits since I left.


Most of them are fine. New features, dependency bumps, CI work. They're building. But the fix commits are where it gets instructive.

Read enough commit messages and you start to notice things. Here's one:

"fix distribution system's consistency bug where the system maintained worker state in two places without proper synchronization. The scheduling logic treats the upstream tracker as source of truth, but allocations are written locally first, creating the race condition window."

That's not a small team dev writing a commit message. That's an LLM narrating what it just did. The precise framing, the explanatory tone, the full-sentence root-cause diagnosis. A vibe coder doesn't write like that. They don't get that deep into understanding it.

Most of it blind iteration.

The financial layer alone accumulated 20+ fix commits over three months. The LLM fixed what it could see. The next run surfaced the next layer. A few human interruptions - "add in utility to test rate limit back off in production since i cant find logs." - when the LLM gets tangled up (notice the grammar lost).

Triangulated - not understood. Triangulated.

He thought he was eliminating a cost. He was deferring it.

505 commits. AI credits, accumulated technical debt, and recurring fixes on a system nobody fully models anymore. Paid monthly instead of in a lump sum.


This is the thing about vibe coding clients: they're not being irrational. The logic is sound. The build phase is done. I have the system. I have Cursor/Antigravity/Claude. I can extend this myself. From their seat, that's a reasonable calculation.

The flaw is that "extend" and "maintain" are different verbs. Extension is additive. Maintenance requires understanding what's already there — the constraints, the tradeoffs, the things that look like they can be changed but can't. The LLM can extend indefinitely. It can't model what it doesn't truly understand.

Institutional knowledge doesn't vibe code.


I've started asking new clients directly: do you plan to vibe code this after we're done?

It's not a gotcha. It's a real question. The answer changes how I architect it, what I document, and how I price it. Some clients are honest. Some go quiet.


Enjoyed this? Subscribe to get future posts by email.