- 10When are specifications not enough?
- 11Where is the state of the work kept?
- 12Who prepares a change before coding starts?
- 13What does impact analysis tell you, and when does it run?
- 14How do coding agents use the graph?
- 15How is each change checked, and how does the graph stay current?
- 16Who decides which work agents do?
- 17How do managers see what people and agents are doing?
- 18What happens across many products?
- 19What about existing systems and technical debt?
- 20What changes for the team?
- 21What results have teams seen?
Home / Follow the story / Act 3: Knowledge graphs and agents in the AI-driven SDLC, with Breeze.AI
Loading the video
Transcript
10. When are specifications not enough?
AI coding tools are fast for one developer working on small, contained tasks. A small application that its team can hold in mind works well with a written specification for each change, which the coding agent builds from and the reviewer checks against. Specifications start to fall short as the application grows complex: a large existing system, a legacy code base, or work that crosses team boundaries. Each specification describes one change, and knows little about the rest of the application. Specifications drift from the code under deadline pressure. A specification carries the product owner's functional knowledge, and little of the design, architecture and code knowledge the change depends on. Writing specifications becomes the slowest step in the process. The knowledge graph sits alongside the specifications and supplies the design, architecture and code knowledge they lack. Each specification still describes the change, and the knowledge graph describes the application the change lands in.
On the site: The Four Zones · When This Zone Stops Working · From SDD to SE
11. Where is the state of the work kept?
Three records hold the state of the work, and each answers a different question. The specification says what one change should do. The ticket system, such as Jira, says who is doing what, and how far the work has got. The knowledge graph says what the application does today. The ticket carries each change from start to finish. When a specification is written, a hook in the ticket system runs impact analysis and attaches the report to the ticket. Every later step updates the ticket's status and attaches its results, such as test results and a second impact analysis after coding. At the end, the final impact analysis uses the whole history of the ticket. The ticket works the same way whether people, agents or both do the work. Teams design the workflow between the steps to fit their own process.
On the site: Three Sources of Truth · How the Ticket Carries the Change
12. Who prepares a change before coding starts?
With AI, writing code is fast, so preparing good specifications becomes the slowest step. The methodology gives that work its own sprint, the spec sprint, which runs a step ahead of the implementation sprint. The custodians meet for one or two days and work through several requests together. The product owner drafts the specification from a standard template. Impact analysis reports everything the specification will touch. Each custodian reviews the report for their own layer: functional, design, architecture and code. Impact analysis can show that a change needs new items, and the custodians propose them in the specification; the items enter the graph only when their code merges. The finished specification, with its impact report, goes into the implementation backlog. The implementation sprint works from specifications whose risks are already known. A specification that turns out to be missing context goes back to the spec sprint.
On the site: Why a Separate Cadence · The Mechanics · What Happens in a Spec Sprint
13. What does impact analysis tell you, and when does it run?
Impact analysis follows the links in the knowledge graph from a specification to everything it touches: outcomes, components, services, database tables and code. For people, impact analysis writes a readable report with the reasons for each finding. For another agent, impact analysis returns structured data that lists the IDs of the affected items in each layer. When an agent owns the work, the agent reads the structured form and continues without waiting for a person. Impact analysis runs when the specification is written, again after the code is written, and again at the pull request, using the whole history of the change. One example is the saved-search alert feature, on an application of 1.6 million lines. The report found three things that would have been hard to find by hand. The report found that the database already had the column the feature needed, so no database change was required. The report flagged a likely and serious risk: without a new filter, weekly subscribers would also receive a daily email. The report also set the order of deployment across three repositories. A senior engineer would need three to five working days to produce a comparable analysis.
On the site: What It Does · Two Kinds of Output · When Impact Analysis Runs
14. How do coding agents use the graph?
Developers keep the coding agents they already use, such as Claude Code or Cursor. The coding agents connect to the knowledge graph through the Breeze.AI MCP server, a standard interface that AI tools use to call other services. The impact report goes into the coding agent's prompt. With the report in its prompt, the coding agent knows which services, components and tables the change must touch. The coding agent cannot ignore what the impact report found, and the specification tells it what to build. Rules for the functional layer are checked on the developer's machine before any change reaches the graph. Code generated twice from the same prompt still differs in detail, such as variable names and the order of operations. The impact report fixes the structure of the change, so the remaining differences are in detail only. Code review moves from asking whether the agent changed the right files to asking whether the details are right.
On the site: The Claude Code Plugin · Integration Surface · Ontology Guardrails
15. How is each change checked, and how does the graph stay current?
Every pull request goes through the PR Validation Agent before it can merge. The PR Validation Agent compares the change with the impact report, and checks the change against all four layers of the graph. The check fails when a change misses an outcome the specification required, duplicates an existing design component, crosses a service boundary, or breaks something that depends on it. A failed check names the violation and the item in the graph involved, and a mismatch with the impact report goes to a person for review. Style, linting and unit test coverage stay in the team's existing build pipeline. The BDD Generation Agent writes test scenarios from the functional layer, each describing how the application should respond to a user's action. Before the pull request merges, the KG Sync Agent updates the graph to match the new code. The graph then matches the main branch, and the next impact analysis runs against the application as it is.
On the site: The PR Validation Agent · What the Gate Checks · What the Gate Does Not Do
16. Who decides which work agents do?
Every agent has a named human owner, and no agent runs on its own without one. People decide which work goes to agents, in sprint planning or in support triage. Work with a repeatable pattern suits an agent: support requests, customer customizations, changes to workflows and forms, new fields and custom reports. An agent takes on a pattern once it has a record of reliable results on that pattern. New scope stays with people, because a new feature needs product, design and architecture judgment. Agents earn autonomy over five levels, from suggesting a change to acting without review. Each step up is recorded in a written agreement that names the evidence, the threshold, the person who approved it, and the conditions for stepping back down. When an agent's results fall below the threshold, the agent steps back down automatically. The agents that run impact analysis and pull request checks typically operate at the fourth level, where people review their results on a regular schedule.
On the site: Which Work Goes to Agents · Progressive Autonomy · The Five Levels
17. How do managers see what people and agents are doing?
Managers see the work of people and agents in the ticket system they already use. Every step of a change updates the ticket, whether a person or an agent did it. Some products receive support and data requests at a volume a ticket system handles poorly, because it holds no knowledge of the application. For those products, the requests can move to an agent workbench. Triage agents in the workbench classify every request, apply the product's own priorities, and route the request to a person or to an agent. Metrics are kept per product, per graph and per agent. Organizations bring these metrics into their own reporting.
On the site: How the Ticket Carries the Change · High-Volume Support Work · Governance and Metrics
18. What happens across many products?
Each product has one knowledge graph, shared by every team that works on that product. Graphs are kept to one product because queries slow down as a graph grows. A portfolio adopts the methodology one product at a time. The first product builds its graph, sets up the process, and hands its repeatable work to agents, and after a few months the next product follows. Some knowledge belongs to the whole enterprise: compliance and security rules, infrastructure preferences, shared deployment pipelines, and an enterprise design system. Enterprise knowledge is defined once, and every product's agents read it according to their access rights. Where products integrate, impact analysis follows the integration points into the other products' graphs. Every quarter, an agent looks across the product graphs for capabilities that are duplicated or no longer used.
On the site: Partition by Product · What Decides It · One Graph for All of a Product's Teams
19. What about existing systems and technical debt?
For an existing application, agents extract the knowledge graph from the code, and the custodians review it. Extraction typically takes two to three weeks for an application of more than two million lines. Extraction shows the application as it actually is, including duplicated and tangled parts that nobody had mapped. Agents that write code quickly can also add technical debt quickly. An enterprise often decides on a target that some products have not reached yet. One example is a new authorization service that some products have not adopted. Until the change reaches the code, the target lives in the specifications, because the knowledge graph keeps strict parity with the code. When a change touches that area, impact analysis shows everything in the current code that the change touches, and the specification can move that code toward the target. Large-scale legacy modernization is the exception: there, the target has a graph of its own.
On the site: Brownfield Extraction · Extraction as Rationalization · Paying Down Technical Debt
20. What changes for the team?
The sprint, the ticket system and code review stay as they are. The team adds a spec sprint ahead of implementation. The team works in three layers: the custodians, the implementation teams, and an enablement layer from Accion Labs. Forward-deployed engineers from Accion Labs fill any custodian role the client cannot staff yet. Specialists work part-time across several workstreams, and one architect can cover two or three of them. The custodians stay human. Much of what the custodians know comes from customer calls, compliance decisions, vendor contracts and user research, which no agent can read. Agents draft updates to the graph, and the custodians approve them.
On the site: The Layered Team Structure · Forward-Deployed Engineers · Fractional Allocation
21. What results have teams seen?
Engagements under Breeze.AI report these results, each in its own context. On one engagement across three products, deployments rose from 19 to 36 a month over a fourteen-week pilot. On the same engagement, lead time for changes fell from 2.0 to 1.42 days. Extracting the graph from a codebase of more than two million lines took two to three weeks. On one brownfield application, impact analysis replaced three to five days of investigation by a senior engineer before each change. In the first sprint of a new user-interface workstream, 53% of design components were reused. Defects fell 23% compared with the same team's results before Semantic Engineering, on the same codebase. Test coverage reached 93.4%, with test scenarios generated from the functional layer and no manual scenario writing. A cost model puts five-year total cost 81% lower when the AI runs on the client's own infrastructure; the figure comes from the model and was not measured on an engagement.
On the site: Numbers from Real Engagements · Case Archetypes: Continuous SDLC
Choose a path
The full video in six parts and an appendix, one part at a time.