The part nobody warns you about

A developer on r/ClaudeAI wrote a post titled "the part nobody warns you about". We are linking it because the conversation that followed is one we recognize, not because we treat it as a case study for us.

The short version: they described the high of a three-day build giving way to weeks of cleanup around structure nobody had really reviewed. "Inheriting a house from a relative who hated me," they wrote.

The thread that followed was contested. Some commenters were sympathetic. Others were pointed: this is a skill issue, plan before you code, write tests, treat the model like a junior dev. The OP closed with "So it seems like the consensus is that I just shut up about it. thanks fam."

A few days earlier, a different post on r/ClaudeCode titled "Is it just me?" made the same point from the opposite direction. A senior game-engine developer with fifteen years of experience tried agentic coding on a small project. He wrote a meticulous architecture document. He spelled out his constraints, his desired patterns, his single-source-of-truth requirements. He had every advantage the first thread's commenters were recommending. He still ended the post saying he had never felt so bad about making software.

Two posts. One a vibe-coder told to plan better. One a senior who did plan meticulously. Same exhaustion. The pattern is not really about whether the developer knows what they are doing. It is about whether the workflow gives them somewhere durable to put what they know.

A short disclosure before we go further. We have commented in both of those threads recommending Storybloq. In one we corrected an undisclosed self-promotion after a fair callout. We are saying it here for both. We are writing this post in part to make the disclosure clean, and in part because the two threads taken together point at something neither one alone explains: the pain is real, the critique that discipline matters is also real, and the gap between them is what we are trying to close.

Why the cliff happens

Three structural things make AI-assisted coding feel fast at first and slow later.

Sessions start with partial context unless the project gives them something durable to read. Chat history, IDE state, and memory help, but they are not the same as a reviewed handoff. Tomorrow's session has whatever you happened to leave behind, structured or not.

Defaults compound. The agent's first guesses become permanent. Function names, scope decisions, naming collisions, the way state is organized: each one a default the model picked while you were watching it ship. Part of the speed came from defaults you did not review. Some were fine. Some became structure.

Self-review is correlated review. The same model family that produced the code often evaluates it through similar assumptions. Asking it "is this code good?" gets you back the assumptions that wrote it. Single-model loops can let issues through that an independent reviewer might have caught.

These three failure modes are not bugs in any specific tool. They are properties of how AI coding works today, and they compound.

None of this is new wisdom

Plan before you code. Get a second pair of eyes. Write things down. Make decisions auditable.

This is what experienced developers have always done. AI changes the picture in two ways. It makes it easy to skip the boring parts at a speed that outpaces your memory. And even when you do follow the discipline, like the senior dev in the second thread, the trust problem remains: you cannot tell which output to trust without reviewing the code, and reviewing AI output line by line often costs more time than writing it would have.

Storybloq is not replacing discipline. It makes that discipline harder to forget by turning it into files the agent has to read and checkpoints the session is guided through. And it tries to reduce the trust problem by routing the agent's output through reviewers that did not write it.

Concretely: plans written before code, in a place that can be reviewed and rejected. Independent review by a model that did not write the thing. Sessions that hand off to each other. Decisions you can audit when the cleanup starts.

What an actual session looks like

Last week we shipped a fix to GitHub issue #1. A user reported that the OpenAI Codex review toggle in the Mac app stayed disabled even after they correctly installed the bridge. The bug was real. The diagnosis was thorough. The fix took one session.

Here is what that session actually looked like.

It started with thirty seconds of context loading: project status, the last three handovers, the lessons digest, and recent commits. Just opening the file the previous session left for this one.

Then a plan. Not in a comment. Not in a commit message. A document submitted for review by Codex, a different model from a different provider. Codex returned with two minor findings: the build number assumption was unsafe, and the session close-out step was missing. Both folded in. Resubmitted. Approved.

The plan exists before the code does. The plan was reviewed by a model that did not write it. The important decisions have somewhere durable to live before the code lands.

Then the implementation. Three small edits in one file. Build green.

Then code review. Codex first, clean approve. Then a second reviewer, a Claude agent specialized for code review. The second reviewer found something Codex did not: a class-level default value that did not match the App Store posture. Small. Latent. Not a bug today. Cheap to fix. In our setup, that meant Codex plus a Claude review agent; other projects can wire the review loop differently.

That is the kind of finding single-model review is prone to miss. The value is not that another model is always right. It is that its blind spots are different.

Then a handover. Written for the next session. Pointers to the build number bump still pending, a suggested commit message, and the codex session ID for the precommit check. Tomorrow's session has something concrete to start from.

Total surface area: one file, about thirty lines of diff. Reviewed twice. Documented end to end. Resumable.

This was a small fix, not a heroic rescue. That is the point: the workflow is meant to make even small changes leave a trace before they become tomorrow's mystery.

It is the workflow we use to build Storybloq itself.

What it does not fix

We try to be honest about what this does not solve.

It does not make the first build faster. That is not the goal. The first three days were never the problem.

It does not eliminate the surprises that come weeks later. There will still be code you forgot you wrote. It only makes the trail warmer: what changed, why it changed, and what the last session knew.

It does not replace your judgment. Plans still need you. Reviews still need you. The loop is human-in-the-loop, not human-out-of-the-loop.

It also adds process. For a disposable prototype, that is probably too much. For code you expect to inherit, the overhead is the point.

Where this leaves us

The cliff is not only inevitable. Part of it is a property of how the workflow is shaped.

You can build this discipline yourself with docs, checklists, and review habits. Storybloq is our attempt to make that shape native to the workflow. When future-you comes back to the code, the plan, review, and handover should still be there.