Studio 03. The load-bearing block.
Nothing writes to my code without a plan I approved first.
Plinth is an IDE built on one inversion: the model plans, the human approves, and only then does code move. On large codebases it remembers, it proves its work, and it stays inside the lines it was given.
Spec-01
Sheet 1 of 1
Intent, drawn as a graph.
The model cannot bypass any node. That is the product.
Where the trust went.
I wanted to hand the repetitive parts of my work to a machine. I tried the tools everyone names. Each one earned the same three disappointments.
The amnesia.
Every session starts from zero. The tool greps, it guesses, it re-derives decisions that were made years ago, and then it does all of that again on the next prompt. I have watched the same question produce three different architectures in one afternoon.
A large codebase is not a search problem. It is a place, with history. The current tools are tourists.
The lie.
The models optimize for the green checkmark. They say the tests pass when the tests were never run. They invent APIs that do not exist and call the work complete.
The polite word is hallucination. The honest word is a lie with good manners.
The overwrite.
Ask for one line and the agent edits forty files. Each edit locally reasonable. Together, an architecture nobody chose.
That is not speed. That is sprawl with a progress bar.
So I stopped shopping for a model to trust and started designing the structure that makes trust unnecessary. Machines do not earn trust. Constraints do.
The glass box. Rebuilt.
Plinth is not a chat window with better manners. It is a glass box with four doors, and the model walks through them in order.
G-01
It remembers.
A codebase brain that persists across sessions. Symbols and dependencies, the reasons decisions were made, the approaches that failed and why. The tool stops being a tourist.
G-02
It plans.
Every task begins as a directed graph of intended changes. Files, lines, order, impact. Reviewable before a single line of code exists.
G-03
It proves.
Completion is not a claim. The work enters a verification chamber that compiles, runs the tests, and grounds every API against live documentation. The tests are locked. The model cannot touch them.
G-04
It stays inside.
Execution is cryptographically locked to the approved plan. The blast radius of a mistake is the plan, not the repository.
What actually holds it up.
Strip the interface and three structures remain. Remove any one of them and the whole idea collapses into another assistant.
LOAD-BEARING 01
The memory.
The moat is not the model. Models are rented by anyone with a budget. The moat is that the environment gets smarter the longer it is used. Preferences accumulate. Failure patterns accumulate. After a year, the tool knows the codebase the way the team does, and a faster model from a competitor does not replicate a year of living there. Data gravity, not features.
LOAD-BEARING 02
The proof.
Verification is the difference between generating code and generating code that works. When a run fails, the exact compiler errors route back and the loop retries. Same input, same checks, same verdict. It is the only component I fully trust, because it is the only one with no incentive to please me.
LOAD-BEARING 03
The consent.
Every plan ends at a gate with a human name on it. The model can propose anything. It can execute only what survived review. Autonomy is not the absence of approval. It is what remains after the approval is already won.
The shape of the work.
The chat window is a straight line. Engineering is not. One decision branches into constraints, into state, into consequences the prompt never mentioned. Plinth renders the branch itself. When a ten-step task breaks at step six, I open node six, correct the assumption, and resume from there. No babysitting loop. No starting over.
Which is why the page you are reading is shaped like the product. A plan, a gate, then the work. This is not a toy for autocomplete. It is for hundred-thousand-line codebases where a bad merge is a bad week, and the build feeds revenue.
Every competitor row in my analysis optimizes the same numbers. Plinth optimizes the ones nobody prints on a landing page.
The market counts
Plinth counts
- tokens per secondwhat it refuses to touch
- context window sizewhat it still remembers tomorrow
- tasks run unattendedwhere it stops and asks
- how well it talkswhat it can prove
- cloud scale, seat pricingan office that can go dark
Sheet 2 of 2
Approved by
M. Farahat
Date
Every plan ends at a signature. This page is the plan. The signature is yours.
Plinth is not a faster way to generate code.
It is a slower, stricter way to deserve it.
The plan is the product. The last gate is human.