From Vibe Coding to Contexted Work: Making AI-Mediated Development Reliable

AI made output cheap.

A developer can now generate code, tests, documentation, content, analysis, and interface ideas faster than a team can fully inspect them. That changes the bottleneck. The scarce resource is no longer production. It is judgment: knowing what to ask for, what to withhold, what to verify, and what to preserve for the next cycle.

That is why vibe coding only gets teams so far.

Vibe coding is useful for exploration. It helps people move quickly, test ideas, and discover what might be possible. But when AI-mediated work becomes part of real production systems, teams need something more durable than speed and feel. They need a discipline for shaping the environment around the model so the work can be sequenced, reviewed, trusted, and improved.

I call that discipline Extreme Contexting.

Extreme Contexting is a methodology for decomposing AI-mediated work into verifiable moves and giving each move the minimum sufficient context required to succeed.

The underlying shift is simple:

When code is cheap, context becomes the craft — and sufficiency becomes the discipline.

The problem is not generation. It is inspection bandwidth.

The first wave of AI coding was framed around acceleration. How fast can a developer generate a feature? How quickly can a model scaffold a component, write a test, or explain an unfamiliar file?

Those are useful capabilities. But in production work, the hard problem is not only whether AI can produce something. It is whether a human team can understand, verify, and safely integrate what it produced.

AI did not just make production cheaper. It made output exceed inspection bandwidth.

That matters because bad AI work often does not look obviously bad. It can be plausible. It can be well formatted. It can pass a superficial review. It can satisfy the immediate request while quietly violating architecture, duplicating logic, weakening conventions, or creating future maintenance problems.

The risk is not simply that AI makes mistakes. The risk is that AI can create more plausible work than humans can responsibly inspect.

That is where teams need a different operating model.

From vibe coding to contexted work

Vibe coding starts with intention and feel. The human has a direction, the model generates, the human reacts, and the cycle continues. That can be productive during exploration, but it becomes fragile when the work needs to be reliable.

Contexted work is different.

Contexted work gives the model a bounded move, sufficient context, explicit exclusions, a verification contract, and a place to capture what should improve the next cycle.

That sentence contains most of the method.

A bounded move prevents the model from trying to solve the whole project at once. Sufficient context gives the model what it needs without drowning it in irrelevant material. Explicit exclusions define what not to touch. A verification contract states what must be true before the output is accepted. Capture turns the lesson from one session into durable context for the next.

The difference is not whether AI is involved. The difference is whether the environment around AI is structured enough for the work to be trusted.

The environment is the compiler

The mental model I have found most useful is this:

The environment is the compiler.The model is the compiler engine.Context is the source material.Verification is the type check.

If the environment is poorly structured, the model has to infer too much. It has to guess at architecture, conventions, priorities, boundaries, and acceptance criteria. Sometimes it guesses well. Often it does not.

A well-structured environment changes the quality of the work. It gives the model a map of the project, the current move, the relevant constraints, the known traps, and the proof standard. The model is still doing the generation, but the environment is shaping what generation is allowed to mean.

That is the shift from treating AI as a magic assistant to treating AI-mediated work as a system.

The move is the unit of work

One of the most important practices in Extreme Contexting is to stop asking AI to “do the project.”

Ask it to do the next verifiable move.

A move is the smallest useful step that creates an inspectable artifact. In software, that might be mapping an existing flow, writing a failing test, implementing one narrow behavior, or refactoring after behavior is locked. In content or analysis work, it might be drafting an outline, building a comparison matrix, validating sources, or revising only the failed section.

A good move has:

• one intention
• one primary output
• a bounded context packet
• explicit exclusions
• a blast radius
• a verification condition
• a capture step

The phrase I use constantly is:

Do only this move.

That constraint matters. It prevents the model from combining discovery, implementation, refactoring, documentation, and strategy into one uncontrolled pass.

Why context needs sufficiency, not volume

The natural response to AI failure is to add more context.

Sometimes that is correct. Often it is not.

More context can create drift. It can introduce contradictions. It can cause the model to overfit on examples that are not relevant to the current task. It can make stale information compete with current instructions.

Extreme Contexting treats context as something that must earn its place.

Context is not storage. Context is instruction, evidence, boundary, and proof.

The question is not “How much can we fit into the context window?” The question is:

What is the minimum sufficient context required for the next verifiable move?

Sufficiency is not always knowable in advance. It is something the loop converges toward through generation, verification, failure, subtraction, and capture.

That is why the process matters.

Failure is a context signal

When AI fails repeatedly, the issue is not always the model.

Maybe the move was too large. Maybe the intent was ambiguous. Maybe the model had the wrong files. Maybe a relevant architecture decision was missing. Maybe the acceptance criteria were never stated. Maybe the examples were stale. Maybe the model was asked to infer sequence instead of being given one.

In Extreme Contexting, failures are not just corrected. They are studied.

If the same correction happens twice, it should not stay trapped in a chat thread. It should become durable context: a rule, a test, a validator, a gotcha, a handoff note, an architecture decision, or a better template.

This is the practice I call refactoring the context.

Traditional refactoring improves the code without changing behavior. Context refactoring improves the system that produces the work. It removes stale instructions, splits overloaded files, promotes repeated guidance into reusable rules, clarifies constraints, and captures decisions where both the human and the model can see them.

That is where AI-mediated work starts to compound.

What this looks like in practice

For a software team, contexted work might mean maintaining a small set of project files that guide the AI before it writes code:

• a project constitution such as CLAUDE.md
• a documentation index that routes the model to the right architecture doc
• a gotchas file that records failed approaches and project-specific traps
• a move card that defines the current unit of work
• a verification contract that states how the output will be accepted
• hooks or scripts that enforce rules the model should not be trusted to remember
• a handoff file that preserves session continuity

The goal is not to create documentation for documentation’s sake. The goal is to lower the cost of reliable collaboration with AI.

A good AI workspace should tell the model what to load, what to ignore, what to use, what to verify, and what never to touch.

Why this matters for teams

Individual developers can get impressive results from AI by intuition alone. But teams need repeatability.

They need work that can survive handoff. They need architecture that does not drift every time a new model session starts. They need code that can be reviewed. They need tests that prove behavior. They need conventions that are visible to humans and machines. They need a way to capture lessons so the same mistake does not get repeated in every new chat.

That is why AI adoption is not only a tooling question. It is an operating discipline question.

The teams that get the most value from AI will not simply be the teams that generate the most output. They will be the teams that structure the environment around AI so that output can be trusted.

AscendTech

At AscendTech, we are applying Extreme Contexting to AI-mediated development, content systems, workflow automation, and operational tooling.

The goal is not to replace human judgment. It is to protect human judgment from being overwhelmed by machine-speed production.

That means helping teams define the moves, structure the context, set verification standards, and capture the lessons that make each cycle better than the last.

I have published the full methodology at Extreme Contexting, including the origin story, manifesto, methodology guide, practitioner toolkit, and a Claude Code Starter Workspace.

The starter workspace is a concrete implementation of the method: a folder structure for verifiable moves, sufficient context, explicit exclusions, verification contracts, hooks, handoffs, and durable capture.

AI made output cheap.

The next discipline is making that output reliable.

That discipline is contexted work.

And the method behind it is Extreme Contexting.