What Is Context Engineering? A Step-by-Step Build Workflow
Your settings page looks right, but it may allow an edit you meant to exclude. Record the decision that sets the boundary, verify the behavior, and note where to pick up next time.
A useful AI coding session starts with a clear task, the relevant project files, and a way to check the result. By the end of this workflow, you will have given your coding tool that context and left enough behind to resume the build. You need a project you can inspect and one small change to make. Context engineering is the practice of selecting, organizing, and updating the information an AI tool needs to work on that change.
This matters when you vibe code because a chat can contain plenty of text while missing the one decision that explains your app. A tool may generate a plausible settings page without knowing that your users must confirm an email address before changing account details. Better context helps you request a bounded change and spot when the result ignores a constraint.
Step 1: Define the outcome
Write down one observable result before asking for code. For a small SaaS, that might be a settings page where a signed-in user can change a display name and see it persist after refresh. Keep the sentence about behavior rather than implementation, so you can judge the result without defending a particular file structure.
Include the boundary in the same note. Perhaps billing settings are out of scope, and an unauthenticated visitor must not reach the page. When you can say what should work and what must remain unchanged, you have a usable target for the session.
Step 2: Find the relevant project context
Inspect the existing code before assembling a prompt. Locate the route, the data write, and any nearby pattern the new behavior should follow. If you cannot tell which files matter, ask your coding tool to identify likely entry points and explain its reasoning, then check those files yourself. Some relevant context lives outside the code, such as the details of an open issue. An MCP server can let your coding tool request those details directly instead of relying on pasted text.
For the settings page, the useful context might include the current profile form, the account data model, and the authentication check. A full chat transcript is a poor substitute for those specifics. The output of this step is a short file list you can refer to when reviewing the proposed change.
Step 3: Record the decision that shapes the change
Capture one choice the code alone may not explain. You might decide that display names can be edited but email addresses require a separate confirmation flow. Write why you made that choice and what it excludes. This gives the next prompt a constraint rather than asking the tool to infer product policy from nearby code.
Decision notes are particularly useful when you return after a few days away. You can change your mind later, but you will know whether a surprising behavior came from an intentional choice or an AI-generated assumption.
Step 4: Give the tool a bounded request
Combine the desired behavior, file references, and decision into a task prompt. Ask the tool to describe its proposed changes before editing when the scope is unclear. For example, request the display-name update, point it to the existing form and account model, and state that email editing is excluded.
Keep the prompt close to the current task. A long project manifesto can bury the constraint you need the tool to notice. You should be able to read the request back and identify the expected behavior, the relevant code, and the boundary without hunting through old messages.
Step 5: Verify the result against the outcome
Review the diff and exercise the behavior you defined first. Save a display name, refresh the page, and check that the change persists. Then try the boundary conditions, including an unauthenticated visit and an attempted edit to a field that should be excluded. A passing build alone cannot tell you whether the feature matches your decision.
If a database write or authentication rule changed, inspect that change before deployment. When the result fails, describe the observed behavior and the relevant error to your tool rather than asking it to fix everything. The failed check becomes useful context for the next attempt.
Step 6: Leave a recovery note
At the end of the session, write a few lines about what changed, what you verified, and the next action. Include a prompt worth reusing only if you know what result it produced. This is the part of context engineering that protects tomorrow's build, when the details of today's chat have faded.
If you are unsure which prompts are worth saving, this guide to avoiding lost context in AI coding gives examples.
A recovery note for the settings page might say that display-name editing works, unauthenticated access was checked, and the email confirmation flow remains for later. Someone returning to the project can start from that state instead of reconstructing it from the commit history and chat logs.
Keep the next session ready
Context engineering works best as a small habit repeated around real changes. Define the task, supply the relevant context, inspect the result, and preserve the state you will need next time. To give those decisions, daily notes, and reusable prompts a durable home, keep your project context in VibeCrumbs.