I agree, but for some projects, that first vibed version is just about good enough and becomes the final version. I have a few things like that and it was nice not to have to bother.

For work stuff, I don't dare 'vibing' anything, and force myself through torturous design cycles and regular refactoring runs. But thats serious stuff with hundreds of thousands of users.

Btw. Fable 5.2 seems to burn through tokens with gusto. I ran my benchmark suite on it, added a complex feature to a hobby project (a gothic cathedral designer), and voila, 2 resets gone.

Which effort level did you use for that? (Will do my own tests with fable today)

Xhigh for starters. Running the mediums for comparison now.

I think one-shorting avoids some of it because most of the project should still be in context.

I’ve noticed because I’ve been doing Clojure and turns are taking notably longer due to unit tests because it doesn’t really grok its own system anymore. It is like 20k LoC at this point with unit tests lol

I've been searching for the right term for this; you've nailed it: back pressure.

Whether the "cruft" is test accumulation, multiple conflicting architecture approaches, a bazillion ADRs/"laws", or just pure code sprawl, the outcome is token and time waste which gets worse as it compounds. And it compounds quickly.

I've tried automated code review through multiple lenses, more ADRs, instructions out the wazoo, but at the end of the day I just cannot figure out how to replicate the "through-line" consistency that responsible humans who need to maintain a system generally create.

Of course, most software projects do eventually fall victim to this same problem and need to be rewritten, but it takes place on the order of years, and by the time you need a rewrite the business has changed enough to demand one anyway. But with AI-owned products, this can happen in days or months.

I’ve been going sort of hybrid and using more targeted prompts. I skeleton the API most of the way and have the LLM fill it in and implement. This is at the code level, not the HTTP API.

Most of the time, anyways.

It keeps me in the code enough to feel the friction of bad APIs but high enough that I’m not reviewing every line of code.

I also try to scope my reviews to only the intersections between systems (SQL schema, library APIs, CLI flags, etc).

I’ve got nothing on the tests. Mine writes a million of them. Some are brilliant, some are stupid.

Like it once did TDD by storing transformations to the same base object in a list rather than specifying the whole object. Clever.

The very next test was an arity test to make sure it threw errors if you gave the function the wrong number of arguments. In a webapp, not a compiler or something. Stupid. Do not unit test the language’s runtime lol