In a kitchen, mise en place means everything in its place before service begins.
Not everything in the pantry.
Not every knife the restaurant owns.
Not a tray full of ingredients someone might need if the night gets weird.
Everything this step needs, nothing it does not.
That is the simplest way to understand Lucena Coder.
We are building a coding harness around digital mise en place.
The Model Wakes Up Hungry And Blind
AI products love to talk about memory as if the model is sitting there with a cup of coffee, remembering the last thirty minutes like a person.
It is not.
Every provider call is a wake-up. The model opens its eyes and sees whatever world the harness prepared for it.
If the harness prepared a garbage table, the model works from garbage.
If the harness prepared a clean station, the model can move.
That is the entire game.
The user experiences a continuous conversation. The model experiences a series of carefully staged moments. The harness is responsible for staging those moments.
This is why token efficiency is not a surface-level concern for us. We do not think "save tokens" means "write shorter prompts." We think it means "stop making the model do work the architecture already knows how to do."
Everything A Step Needs
A step has a shape.
Research has a shape. Editing has a shape. Verification has a shape. Deployment has a shape. A user asking "did that go live?" has a different shape than a user asking "add a comparison panel."
Most tools flatten those shapes into one huge bag:
Here is the conversation.
Here is the workspace.
Here are all the tools.
Here are all the files we touched.
Figure it out.That is not empowering the model.
That is outsourcing architecture to the model.
Lucena Coder is built on the opposite belief. The system should know which step we are in and prepare the bench accordingly.
If the agent needs to inspect, give it inspection.
If it needs to mutate, give it live edit targets.
If it needs to verify, give it proof and the current touched state.
If it needs to answer the user, stop handing it reasons to wander.
The model should not be forced to rediscover the shape of the step every time it wakes up.
Nothing It Doesn't
The second half is harder.
Everyone likes adding context. It feels safe. It feels generous. It feels like giving the model more chances to be smart.
But too much context is not neutral.
Extra context is another surface for confusion.
An old failure can become a live problem again. An old file copy can compete with the current file. A stale plan can suppress a fresh user request. A tool that does not belong can become a detour. A debug artifact can look like truth.
If the model sees contradictory state, that is our fault.
If the model re-checks a file because our receipt was thin, that is our fault.
If the model retries a command because we gave it a half-result, that is our fault.
If the model gets trapped in a loop because the world we prepared still smells like an unfinished task, that is our fault.
Mise en place is not only about what you put on the bench.
It is about what you refuse to put there.
Sealed Systems, Not Defensive Theater
A lot of software is written as if every impossible state deserves a fallback.
We disagree.
If the architecture says a file edit requires a live snippet, then the system should produce live snippets before edits are possible. If the architecture says a completed mutation returns proof, then the edit result should own that proof. If the architecture says terminal commands complete into receipts, then transport noise should not masquerade as terminal truth.
Do not build a door into a room that should not exist.
That principle matters even more with language models because models are very good at rationalizing bad state. They will try to make sense of whatever we give them. If we give them a contradiction, they may politely spend money resolving a contradiction we created.
The best prompt is the one that never has to explain an impossible state.
The best tool surface is the one that never offers the wrong next move.
The best context is the one that makes the right next action feel obvious.
Token Obsession Is Moral, Not Cosmetic
"Token efficient" can sound like a growth-hack phrase.
For us it is closer to a moral position.
The major AI labs make money when tokens move. The default economic incentive is not to make your workflow lean. The default incentive is to normalize waste, hide it behind abstraction, and tell you bigger context windows are the future.
Sometimes bigger context is useful.
Often it is just an expensive refusal to choose.
We care about the API bill because users care about the API bill. Solo builders care. Freelancers care. Small teams care. People shipping real work without enterprise procurement theater care.
That means we cannot treat token burn as an implementation detail.
Every wasted re-read is a product bug.
Every duplicate file body is a product bug.
Every stale failure left in live context is a product bug.
Every broad tool menu that causes a pointless round trip is a product bug.
Not because the number is ugly on a dashboard.
Because the user is paying for our lack of discipline.
Current Reality Is Everything
The model does not need a perfect archive.
It needs current reality.
What is the user trying to make true? What files matter now? What code is current now? What changed? What proof exists? What remains unresolved? What tool belongs to this step?
That is the world.
Everything else is storage, debugging, analytics, or archaeology.
A haunted agent sees ghosts: old failures, old snippets, old plans, old tool calls, old uncertainty. It keeps checking rooms that are already empty.
A well-prepared agent sees the bench: what is current, what has proof, what needs action, and which tools belong to this exact step.
That is mise en place.
Everything a step needs. Nothing it doesn't.
Tokenmaxxing is for suckers because it treats mess as inevitable. We would rather clean the station.