Context-Centered Development
From Sprint-Centered Development to Context-Centered Development
With AI coding assistants, the quality of the code depends less on how fast developers type and more on the context the tools receive. The team's most important operating asset is no longer the backlog. It is the context layer: the product briefs, architecture decisions, coding standards, API contracts, test strategies, prompt files and acceptance criteria that tell both people and AI agents how to work in a codebase.
In traditional Agile development, teams invest significant energy in ceremonies: backlog grooming, sprint planning, daily standups, sprint reviews and retrospectives. These rituals serve a purpose. They create shared understanding, surface blockers and keep the team aligned on priorities. But they also reflect an assumption that the main coordination challenge is managing a group of human developers through a fixed-length execution cycle.
AI coding assistants shift the coordination challenge. When an AI agent can generate a working implementation in hours, the quality of that implementation depends on the quality of the instructions it receives. A vague specification produces vague code, quickly. A precise specification, grounded in architecture standards and business context, produces useful code, also quickly. The differentiator is no longer execution capacity. It is context.
Why Context Matters More Than Ceremony
Agile ceremonies were designed to solve a communication problem. In a two-week sprint, a team of five to ten developers needs to stay aligned on what to build, how to build it and what to do when priorities shift. The ceremonies create structured moments for that alignment.
AI coding assistants do not attend standups. They do not absorb organizational knowledge by sitting in meetings. They understand a project only through the explicit context provided to them: files, instructions, the codebase and structured prompts. When that context is thin, the AI generates plausible-looking code that misses architectural patterns, violates naming conventions or ignores security constraints. When the context is rich, the AI generates code that fits the team's standards, as if a well-onboarded engineer wrote it.
This changes where teams should invest their energy. A sprint planning session that produces a list of ticket titles and rough point estimates gives a human developer enough to start working. It gives an AI agent almost nothing. The agent needs to know the technology stack, the file structure, the coding conventions, the existing test patterns, the API contracts, the error handling approach and what not to change. That information has always existed, in people's heads, in tribal knowledge and in Slack conversations. AI forces teams to write it down.
What the Context Layer Contains
The context layer is the set of structured artifacts that let both humans and AI agents work safely within a codebase. It includes everything a new team member, or a new AI agent, would need to understand the project without asking questions.
At minimum, a useful context layer includes:
- Architecture overview: how the system is structured and why.
- Coding standards: naming conventions, patterns and anti-patterns.
- Test strategy: what to test, how to test it and what coverage is expected.
- API contracts: the interfaces between services.
- Domain vocabulary: business terms and their precise meanings.
- Acceptance criteria: what "done" looks like for each feature.
Some of this has always been good practice. What is new is that AI tools now have standard mechanisms for reading it.
AGENTS.md, CLAUDE.md and Other Context Files
The industry has converged on a practical standard for giving AI coding agents project context. AGENTS.md, backed by Google, OpenAI, Sourcegraph, Cursor and Factory, is a shared format for project-level AI instructions. This matters because teams can write their standards once and have them apply across multiple tools.
AGENTS.md uses hierarchical directory scoping. A file at the project root applies to the entire codebase. A file in a subdirectory overrides the parent for that directory's scope. The nearest AGENTS.md wins. This mirrors how most codebases are organized: global conventions at the root, service-specific rules at the module level.
Some tools also have their own context file formats that predate the standard and remain in active use. CLAUDE.md is Anthropic's format for Claude Code. It uses full Markdown, reads like documentation and supports rules split by topic and file path, which keeps the main context file from becoming unwieldy on large projects. Cursor uses its own project rules files, which tend to be shorter and more directive: less explanation, more instruction.
The practical guidance is straightforward: write your core instructions once in AGENTS.md, and only create tool-specific files for features that are unique to a particular tool. The more you duplicate across formats, the more your instructions will diverge over time. Drift between context files is one of the most common causes of inconsistent AI output across a team. Our chapter on building the AI-ready repository covers how to lay these files out.
Context Files as Onboarding Documents
A useful mental model is to treat context files as onboarding documents for AI. They serve the same purpose as the document you would give a new developer joining your team, except the reader is an agent that will follow the instructions literally.
That framing clarifies what to include and what to leave out. A good onboarding document tells the new team member how the project is structured, what conventions to follow, what tools to use, how to run tests, what the deployment process looks like and what common mistakes to avoid. A good context file does the same.
The difference is precision. A human developer can infer conventions from existing code, ask questions when something is ambiguous and use judgment on edge cases. An AI agent will follow the instructions as written. If the context file says "use camelCase for variable names" but does not mention function names, the agent may use a different convention for functions. If it says "write tests for all new code" but does not name the testing framework, the agent may write tests in a framework the project does not use.
Teams that invest in high-quality context files see compounding returns. The instructions get refined as edge cases surface. Patterns that work on one project spread to others. New engineers onboard faster because the documentation already exists. And AI output becomes consistent across the team, not because every developer prompts the same way, but because the underlying standards live in a shared resource.
Rules and Skills: Encoding Patterns for Reuse
Beyond static context files, tools like Claude Code and Cursor offer more dynamic ways to encode team patterns. Rules are project-specific standards that load automatically as context whenever an engineer works in the tool. They encode architecture decisions, naming conventions, security constraints, accessibility standards and team-specific patterns. Every engineer on the project gets the same guardrails, regardless of which part of the codebase they are working in.
Skills take this further. A skill is a reusable, invokable workflow: a structured set of instructions that packages a proven delivery pattern so any engineer can run it the same way. Instead of re-prompting from scratch for a common task, an engineer invokes the relevant skill and gets consistent output.
The Talk Think Do engineering team, which publishes data on its AI-assisted development practices, reported that rules and skills had more operational impact on output quality than its MCP server integrations. The reason is that rules and skills address consistency: the same prompt structure, the same architectural constraints and the same testing expectations across every developer session. When one engineer finds a better approach, it can be written up as a skill and shared with the whole team. The same applies to prompts; see prompting as an engineering practice.
The Azumo SDLC is built this way. It is a shared kit of workflows, skills, rules and review checklists, and the same setup loads in Claude Code, Qwen Code, OpenCode and Pi. Business analysts, project managers, designers and DevOps engineers write down what they know as skills (how to do a step) and rubrics (what good looks like). Teams add their own steps and checks, such as an accessibility check, without changing the shared kit.
This compounding effect is what makes context-centered development worth the effort. It is not just about making the current sprint more efficient. It is about building a body of encoded knowledge that makes every future sprint better.
The Backlog Is No Longer the Main Artifact
In sprint-centered development, the backlog is the primary planning artifact. It is a prioritized list of tickets the team pulls from during each sprint. The quality of the backlog determines the quality of the sprint.
In context-centered development, the backlog still exists, but it is no longer the team's most important artifact. The context layer, the set of files, standards and encoded patterns that define how work should be done, takes precedence. A well-maintained context layer makes every ticket in the backlog more executable. A poorly maintained one makes every ticket more ambiguous, however well it is written.
This has practical implications for how teams spend their time. Traditional backlog grooming focuses on estimating effort and clarifying requirements for individual tickets. In a context-centered model, teams should also spend time maintaining their context files: updating architecture decisions when they change, adding conventions as they emerge, documenting edge cases as they are discovered, and refining prompts and skills based on what works.
GitHub's repository custom instructions reflect this shift. They let teams define project-level guidance that Copilot follows when generating code, reviewing pull requests or analyzing the codebase. The instructions define how the assistant should understand the project, how it should build and test changes and how it should validate its output. This is not a backlog item. It is infrastructure, and it pays off on every backlog item the team works on.
Making the Transition
Moving from sprint-centered to context-centered development does not require abandoning Agile. It requires shifting where the team invests its energy.
Start by auditing your current context. If a new developer joined your team tomorrow, how long would it take them to understand the codebase, the conventions and the deployment process? If the answer is more than a few days, your context layer is not sufficient for AI-assisted development. If a new human developer needs two weeks to become productive, an AI agent will not do better. It will produce inconsistent output faster.
Next, create the foundational context files: an AGENTS.md at the project root with your coding standards, architecture overview, testing conventions and common patterns, plus a CLAUDE.md or Cursor rules file if your team uses those tools, with the same content. Keep it lean at first. You can add specificity later. The goal is to give AI agents the same foundation your best developers have internalized.
Then build context maintenance into your workflow. When a retrospective surfaces a recurring issue, say AI-generated code that keeps using the wrong error handling pattern, the fix is not just a conversation. It is an update to the context file that stops the issue from recurring. Over time, the context layer becomes the team's institutional memory, available to both humans and agents.
This is how we build custom software at Azumo. Setting up the context layer is part of project setup for every engagement. When we start a new client project, one of the first deliverables is a structured context layer (architecture documentation, coding standards, test strategy and AI instructions) so our developers and their AI assistants can work within the client's system from day one. In the Azumo SDLC, context lives with the project, not in one chat: handoffs and decisions are saved to shared project memory, agents propose and people approve. This is also one of the reasons our nearshore teams can integrate with client engineering organizations quickly. The context layer bridges the gap between teams, time zones and individual working styles.
The most productive AI-assisted teams we work with share one trait: they treat documentation as part of their delivery process, not as overhead. The quality of their context sets the quality of their output.