The Tool That Was Missing

The advice turned out to be the easy half. I have written several papers now about an AI-first development cycle replacing the methodologies we grew up with, and about the human roles that collapse into each other when it does. Then I went and practiced it — different shapes of the model, eight applications built with it — and one thing became plain that no paper had prepared me for.

The electronic tools to facilitate, record, marshal and document the actual work — the ideas, the plans, the sketches, the screenshots, the test output, the deployment answers — do not exist. Not badly. They are simply not what any of the tools we have were built to be. We still need a system to document, manage and deliver software. It is just not the current one.

Every structure in the tools we have — the queue, the fortnight, the points, the sub-task, the hand-off — exists to divide scarce engineering time between competing demands and pass the work along a line of specialists. That was the right design for that problem. The ticket is the atom because the hand-off was the process.

The documentation fields were always the aspirational part. Everyone has seen the acceptance criteria that say see attached, and the attachment that was never attached. That is not a failure of discipline. It is what happens when writing something down is a separate act from doing the work — the two compete, and the work wins every time.

Now look at where the time actually goes:

The one box that got cheap is not the one the tools were built around. And there is a second thing the picture hides: with the middle box collapsed, the work does not simply arrive faster. It arrives unorganized. Code sits in repositories with no way forward, and nobody can say which of it is ready, which was tested, which was approved, and which reached a customer.

In this model the AI authors and consumes most of the documentation in the pipeline: the build plan, the phase plan, the design notes, the schema changes, the test output, the deployment script. A tool whose every screen, field and notification is designed for a human reader is serving the wrong customer.

It is also wasteful in a way that shows up on the bill. It is expensive for the AI to spend tokens producing prose for a person who was never going to read it, in a register that is not what the AI itself wants back. For the roles that have genuinely collapsed into the machine, the language and the documentation should be created and stored in the form that serves the machine. It is serving itself.

Where a human will genuinely read something, render it beautifully. Where only machines read it, keep it dense and cheap. One store, two projections.

The needs are not as far apart as that sounds, because the model is language-based and was built by reading what people wrote. But the two audiences are real, and a tool that pretends there is only one of them will either bury the person in machine exhaust or bill you for prose nobody reads.

The humans are not gone, and the temptation to say so is the single most misleading thing in this whole conversation. They put in the parts nobody else can: the concept, the sketch, the big plan, the design somebody drew, the years of experience that tell you a screen is wrong the moment you look at it.

The job of the tool is to ask for those at the moment they are worth the most, and then get out of the way. Three things follow from that, and they are the whole design:

1. Ask each person for what only they can give, at the stage it is needed. A thin sketch and a few sentences beats a signed-off specification that is out of date before anybody reads it. The tool should make the long document the harder thing to produce.
2. Let the machine keep its own record, in its own form. The plan it wrote, the decision it made, what it changed, what it left for next time — written as a by-product of working, not as a documentation act afterwards.
3. Make the record something the work leaves behind. If keeping it requires a separate effort by a separate person, it will die exactly the way every wiki has died.

Mechanical documentation that records pass and fail against a test script is not the testing we need people to do any more. That has collapsed into the machine. The testing in question is real-time interaction with the thing: iterative design, stress-testing it the way a non-conforming human would, and cycling through polish and refinement — applying years of subject-matter experience to a product by experiencing it and reacting.

People struggle to record that, and the tools give them nowhere sensible to put it. So make the ask trivially small: a screenshot and a few sentences, entered in seconds, from any device. That is the whole of what anybody should be asked for. And treat the loop as the healthy thing it is — neither a person nor a machine can express the whole desired outcome at the outset, no matter how long the specification took, so iteration should be celebrated and facilitated rather than tolerated as a sign that the planning failed.

The same argument applies one step earlier, to engineering. Where a feature will run, what it touches, what data it holds, what it has to be certified against — all too often a thing is specified, designed and built, and only then does somebody ask the operations team how it will be hosted and managed. That question belongs at the start, answered in minutes, and folded into the plan before a line is written.

Work may be feature-shaped as it moves through the pipeline, but that is not how organizations actually accumulate anything. People bank experience from separate projects into a shared memory, and that memory then drives and constrains everything that follows. You learn from the past. It is most of what experience is.

One of the real challenges of AI coding today is that every new session is fundamentally a new day. When the context dies, we start over.

The harness's own memory is generic and single-folder by necessity — it has to accommodate every kind of work anyone might do with it. What is missing is the layer above: memory that survives a session, then a feature, then a project, and finally becomes the organization's own — the house rules, the decisions, the scars, the things we do not do and the reasons. Served to the machine at the start of every session, so nobody has to say them again, and so the organization's beliefs constrain the next build without anyone having to be in the room.

A system that does that is not a documentation tool with AI features bolted on. It is a different object: something humans can touch and feel, that also carries extended context over time for the machine doing most of the building. Both, from one store.

That system is Riverbank. It is an SDLC management tool that embraces AI-first coding and doesn't forget all the other roles a successful implementation still needs — that somebody has to buy it, that people have to test and deploy it, that QA, regulatory and compliance have to review and approve it, and that features have to be documented and supported long after the excitement has moved on.

It runs Bluefish's own work today: fifteen phases of Riverbank itself were built and remembered inside it, and it is carrying four products on its board. It is not finished, and I would rather say that than pretend otherwise — what has been proved is the concept, not yet that it survives contact with somebody else's organization. There is a short film that shows it running, and it works with the sound off.

The claim I am confident about is the smaller one, and it is the one this whole piece is for: we still need a lifecycle. It is just a different one. And the tool for it had not been built.