QCon London: The Shift from Prompt Engineering to Context Engineering

At QCon London this week, Birgitta Böckeler (Thoughtworks' global lead for AI-assisted software delivery) described AI for developers as being in a "dangerous state." Her point: AI agents are too useful to skip, but developers are losing the experience they need to review what agents produce.

She's exactly right. This is the tension we deal with at Hype Lab on every client engagement.

Our approach: keep humans responsible for architecture decisions and let agents handle implementation within defined boundaries. The agent writes the code, runs the tests, and proposes the PR. The human decides what gets built, reviews the output, and approves the merge. The boundary between "agent territory" and "human territory" is explicit and enforced.

Böckeler's other observation — that the main skill is shifting from "prompt engineering" to "context engineering" — tracks with our experience. The agents that work well are the ones with carefully curated context, rules, and sub-agent delegation. Not the ones with clever prompts.

Context engineering means controlling what the agent sees, when it sees it, and how that information is structured. A well-designed context gives an average prompt great results. A poorly designed context makes even a perfect prompt fail. We've watched this play out across dozens of deployments: teams that invest in context architecture outperform teams that iterate on prompts by a wide margin.

The "dangerous state" framing is useful because it avoids both extremes. AI agents aren't a threat to skip. They aren't a magic solution to adopt blindly. They're a powerful tool that requires a specific kind of management — one the industry is still figuring out.