Context Engineering vs Spec-Driven Development: Use Both

Context engineering selects the information an AI assistant receives; spec-driven development organizes building around an explicit description of intended behavior. A specification can be part of the context, but the assistant also needs current code, applicable rules, test evidence and the state of the work.

Use a specification to agree what should happen, then prepare context that helps the assistant implement and check that agreement. fenbs can preserve people-approved decisions and implementation progress so a new session does not have to reconstruct them from conversation history.

What is the practical difference between the two?

These are practices, not competing model features. You can use a small specification without a specialized framework, and you can prepare context manually. The useful choice is which uncertainty needs attention: an unresolved requirement, missing evidence for implementation, or both.

Anthropic’s context engineering guide↗ (opens in a new tab) treats context as information selected to support a desired result. GitHub Spec Kit’s documentation↗ (opens in a new tab) describes a specification moving through planning, tasks and implementation. The overlap is deliberate: an agreed specification becomes useful input for the assistant doing the work.

What does a specification settle before implementation?

A useful specification describes who needs the change, what they should be able to do, relevant constraints and observable acceptance conditions. It also names what is outside the change. The point is to make disagreements visible while they are still cheap to discuss.

Consider a hypothetical appointment app. “Let customers reschedule” leaves important questions open. Who can reschedule, until when, what happens to the old slot, and what should the customer see if the new slot becomes unavailable? Those are behavior questions that belong in the agreement.

A specification might say that a confirmed customer can choose an available replacement slot, that a successful change releases the previous slot, and that an unsuccessful change preserves the original appointment. Its acceptance examples should cover success, unavailable slots and a caller who cannot access the appointment.

It need not describe every implementation detail. If the database or interface pattern is already an established project constraint, reference it. Avoid copying every technical convention into each feature specification, where duplicated instructions can drift. The spec-driven development guide covers the method in more depth.

People must still approve the intended behavior. An assistant can draft alternatives and identify missing cases, but a fluent document does not prove that the product owner wanted its assumptions. Mark unanswered choices explicitly and resolve the ones that affect implementation before treating the document as agreed.

What context does an agreed specification still need?

The specification says what the appointment change should do. To implement it, the assistant also needs the actual appointment model, existing authorization path, interface conventions and relevant tests. To continue yesterday’s work, it needs the changes already made and the checks that remain.

• The active specification and its approval status, with the conditions relevant to this task.
• Applicable project rules, including the boundaries for actions that require a person.
• The specific code and source documents needed for the next implementation step.
• Known failures, test results and evidence from the current working state.
• Open questions and a precise next action, rather than an unqualified “continue.”

Select that information for the immediate task. An assistant investigating the unavailable-slot case may need the reservation code and a failing check, while one revising confirmation copy may need the agreed user flow and writing rules. Sharing the same specification does not mean each task needs the same supporting files.

This is also why a well-written request can fail when its supporting evidence is wrong. Context engineering vs prompt engineering separates those concerns; here, keep the approved behavior distinct from the changing material used to implement it.

Where does each approach fail on its own?

Strong context cannot settle a product disagreement. If the owner has not decided whether rescheduling is allowed on the appointment day, providing every relevant file still leaves a missing choice. The assistant should present the gap rather than quietly turn a plausible assumption into product behavior.

A clear specification also cannot guarantee correct implementation. The assistant may receive an outdated copy, overlook an existing permission check or repeat a change that another session already completed. It needs current evidence and ordinary review of the resulting work.

Treat these as starting questions, not automatic diagnoses. Inspect the evidence before changing the process. Sometimes a failing test exposes an unclear requirement; sometimes it exposes a straightforward defect. Asking which agreement or evidence was missing helps keep a correction proportional to the problem.

Which should you emphasize for your next change?

Emphasize the specification when several interpretations would produce different user behavior. Changes to appointment eligibility, access boundaries or data handling deserve explicit examples and review. A short spec can be enough when it resolves the actual uncertainties and makes acceptance testable.

Emphasize context preparation when the intended behavior is already settled but the assistant must navigate unfamiliar work. A narrowly scoped defect may need the expected behavior, reproduction, relevant code and current test result rather than a long new document.

Use both when implementing an agreed feature over several sessions. Begin from a reviewed specification, prepare the relevant working set for each task, and save what changed before stopping. That sequence is especially useful when different people or AI apps take turns.

If you are evaluating frameworks, the spec-driven development tools guide owns that comparison. For the editor side, context engineering in Cursor explains its context workflow. Choose tools after identifying the missing agreement or evidence, rather than adopting a larger process by default.

How do you combine them without creating stale copies?

1. Agree the behavior in one current specification. Give it an identifiable location and make unresolved choices visible.
2. Record who approved significant decisions and why. Point the task at the decision instead of maintaining several competing explanations.
3. Prepare context for the next task: the applicable spec section, project rules, relevant files and current evidence.
4. Ask the assistant to summarize its understanding and identify any conflict before it changes the work.
5. Check the result against the acceptance conditions, then save actual progress and the next action.

When the intended behavior changes, update the agreement and record the replacement decision. When implementation progress changes, update the task and handoff. Mixing those two updates can accidentally turn “we could not finish this today” into “this behavior is no longer required.”

A useful handoff names the relevant specification section, what is implemented, what was checked and what remains uncertain. “The unavailable-slot case is implemented; the simultaneous-request check remains” tells the next session more than “rescheduling mostly done.” Keep the evidence location available so a fresh assistant can verify the summary; fenbs AI handoffs preserve that work between sessions.

The wider context-driven development workflow covers organizing development around project context. For this comparison, the key boundary stays simple: the specification is the behavior agreement; the task context is the information needed to act on it now.

How to do this with fenbs

1. Create a free account and add the project you are building to your personal kanban board.
2. Add a task for the change, with a plan linking the current specification and naming the acceptance conditions to check.
3. Record the choices a person approved in Decisions and rules. Keep proposals open until a person decides, and reserve standing rules for instructions that continue to apply.
4. Connect a supported AI app through Integrations. Ask it to read the project context, then inspect the specification and implementation evidence before working.
5. Review the result and save progress with the checks actually performed. Use Where we left off to identify the next action and anything waiting on a person.

fenbs does not generate or execute a specification-driven toolchain for you, and it does not replace your code repository or tests. It is useful when decisions and handoffs need to stay readable across sessions. For a tiny one-time edit, a short written agreement and direct review may be sufficient.

Start with one change you can review today. If a fresh session can explain the agreed behavior, distinguish completed work from untested work and name its next step, your records are doing their job. The context engineering hub links to more focused guides for the remaining pieces.