From Prompts to Context Engineering
Part 2 of our Claude Code journey: the moment we stopped polishing sentences and started engineering what the model sees — and what it did to our delivery speed.
Part 2 of 3 — the Busoft Claude Code journey.
The turning point came when we admitted that our best prompts were failing for a reason no better wording could fix: the model simply could not see what it needed — or was drowning in what it did not.
From words to attention
A model's context window is a scarce resource, like RAM in the machines we grew up programming. Context engineering is the discipline of spending it well: which files, which documentation, which tool results, which history earn a place in front of the model at each step — and, just as important, what gets left out. The industry reached the same conclusion at the same time; Anthropic's essay on effective context engineering for AI agents and Sourcegraph's practical guide both frame it the same way: the question moved from "how do I phrase this?" to "what should the model be looking at?"
What changed in practice
We gave every project a ground-truth file — the project's constitution: architecture decisions, conventions, forbidden moves, the gotchas that cost us a day once and never again. It loads into every session, so nothing is re-explained. We stopped dumping whole repositories at the model and started retrieving only the code a task touches. We split big jobs into fresh-context sub-tasks instead of letting one long session decay. We made the model write down what it learned, so the next session starts smarter than the last.
The effect was not subtle. The same model, on the same tasks, went from a talented intern who needs supervision to a senior teammate who remembers the project. Corrections per task fell; the length of work we could hand over without checking in rose from minutes to hours.
The lesson under the lesson
Context engineering turned out to be an organizational skill wearing a technical costume. Deciding what the model must see is deciding what your company actually knows — writing it down, structuring it, keeping it current. Teams that never documented their judgment now had a business reason to start. That realization set up the final move in this series: if knowledge can be engineered into the environment, the checking and the discipline can be too. Part 3: the harness came — and now we are on the loop.