A developer posted something this week that stuck with me. They'd been using spec-driven AI development, and early on it felt great: simple requirements, the model writes most of it, a quick read-through and done. Then the requirements got complex. The spec ballooned. The latest one came back at 40,000 words for a single feature, before the design doc and task breakdown. Scanning it felt risky, reading it fully felt heavier than just writing the code by hand. Their words: hand-coding is at least logically clean and orderly.
That complaint isn't an outlier. Read across what people are actually shipping and you see two very different outcomes sitting side by side.
The split: tiny tools fly, complex ones drown
On one side, people are building small, self-contained things end to end with AI and they're happy. A coin-flip helper with flip animation, sound, haptics, and local history. A browser plugin that mirrors a side-panel conversation navigator from one chat UI onto another. A card game done entirely through a coding agent, pure front end. These ship, they work, and the builders sound relaxed about it.
On the other side, the moment scope grows, the same tooling turns into a firehose. The spec gets longer and more padded, the boilerplate phrasing multiplies, and the human is left either rubber-stamping output they didn't really read or re-reading everything and losing the time the AI was supposed to save. One person even noted that a faster, chattier model felt more exhausting to work with than a slower, terser one, purely because of how much text they had to process.
The common signal: AI coding didn't remove the bottleneck, it moved it. The work is no longer typing the code. It's reviewing output you didn't write and keeping the model anchored to decisions it keeps forgetting. Small projects dodge this because the whole thing fits in your head. Big ones don't, and regenerating a giant document every time is the wrong fix, because it reproduces the context from scratch instead of storing it.
There's a pressure layer on top of this too. Someone described a manager who decided that because AI writes code, a two-week task now ships in two days. A reply nailed the trap: deliver the two-day version, show it honestly, because if you grind to fake the old timeline, that becomes the new baseline. The volume problem and the schedule problem feed each other. If your review process is slow and manual, you can't honestly push back on unrealistic timelines, because you don't actually know how solid the output is.
What this means for a builder
If the expensive part is grounding and review, then the thing worth building isn't another code generator. It's the layer that keeps the model's knowledge persistent and retrievable, so you stop paying to regenerate a 40k-word spec every session.
Concretely, treat your project's decisions as durable data instead of disposable prose. Every time you settle a requirement, a naming convention, an edge case, or a "we decided not to do X because Y," that's a fact that should live somewhere queryable, not get buried in a document the model rewrites from zero next time.
Building the grounding layer on VicroCode
Here's a shape I'd actually build. Store those decisions and spec fragments in a LanceDB knowledge base so the content is retrievable by meaning, not by scrolling. Then instead of asking the model to emit a full specification each round, you do AI agent development where the agent pulls only the relevant slices from that knowledge base to answer the question in front of it: what did we decide about auth, what's the current data shape, what did we explicitly rule out.
The mechanics map cleanly onto the platform. The agent calls models already available through Model Center, uses in-platform tool calls to fetch from the knowledge base, and you expose the whole thing through API Endpoint Hosting so your editor or a small front end can hit it. For anything beyond retrieval, write the glue in Python, run it online, and keep structured records in a SQLite database you can edit directly, things like a review log, open questions, or a changelog of accepted decisions. If you want a dashboard over it, ship a hosted HTML app and publish it, no separate deployment pipeline to wire up.
The review-pile problem has a home here too. A small Python backend can take each AI-generated change and check it against the decisions already in the knowledge base, flag the parts that contradict a prior ruling, and surface those first. You still review, but you review the conflicts instead of 40,000 words of mostly-fine filler. That's the part that makes an honest two-day estimate possible: you know what was checked and what wasn't.
Where the boundary is
A couple of the shipped examples in the wild lean on things VicroCode doesn't do, and it's worth being blunt about that. The coin-flip tool is a WeChat mini program, and two of the plugins are Chrome extensions, those are platform-specific packages, not HTML web apps you host and publish here. The card game and a few others deploy to Cloudflare's edge or Docker; VicroCode's hosting is for HTML web apps and Python, not those targets. One PaaS post advertises PostgreSQL, MySQL, MongoDB, Redis, and S3-compatible storage. VicroCode gives you SQLite and LanceDB, which is plenty for a decision store and a knowledge base, but it isn't a managed Postgres cluster, so size the project to that.
What fits squarely inside the lines is the grounding-and-review layer itself: the agent, the knowledge base, the Python checks, the SQLite records, the hosted interface, and an endpoint tying them together. That's the piece addressing the signal everyone's complaining about, and it happens to be exactly what the platform is built to run.
I haven't measured how much review time this saves on a real team, so treat any time-saving claim as unverified until you run it on your own backlog. The design rationale holds regardless: store decisions once, retrieve what's relevant, review the conflicts instead of the wall of text.