What Is Graph Engineering?

People talk about graph engineering with a certain reverence. After reading a few industry articles and trying it myself, my definition is simple. You break a large problem into small tasks and get a swarm of agents to work towards the same goal. The graph shows which tasks can run together, which need an earlier result, and where the work comes back together to be checked.

Defining the requirements

I was trying to clean up a product I was working on. Its codebase had grown to about 45,000 lines, and I thought we could deliver the same functionality in roughly 10,000. There was a lot of redundant code and unnecessary complexity, so I decided to refactor it.

Fable mapped the architecture by spinning up several Opus subagents (one per part of the platform). Each read its share of the documentation and sent back a summary of how that part worked and what it connected to. Fable could follow the whole system without loading every document into its context window.

Fable then sent a second group of agents to check the platform. Were the APIs returning what the frontend expected? Was the same data being stored twice? Were different parts of the code doing the same job? The agents created a Trello card for each issue they found.

Breaking down the work

Say the audit turns up 400 possible points of failure. Fable groups them by what they affect and works out which groups need attention first. Several broken screens might all depend on the same API. Fixing it first tells the agents which screens still need work. Changes to the architecture and core flows come first for the same reason. The UI audit and documentation are more useful once those changes are in place.

For platform upkeep, the phases might look like this.

1. Phase 1: Fix bugs. Reproduce failed requests, fix the cause and check the response.
2. Phase 2: Simplify the architecture. Clarify which part of the system owns each responsibility, then fix dependencies and interfaces so changes do not have to be repeated across unrelated parts.
3. Phase 3: Consolidate duplicate features. A new feature can replace an older one on another screen while both remain in the product doing the same job. Choose the version to keep, redirect the old entry points and callers to it, and remove the duplicate UI and code.
4. Phase 4: Test core flows. Submit a form, reopen the record and edit it. Try invalid input as well.
5. Phase 5: Consolidate code and UI. Move shared logic into one place, standardise the components and document the finished flow.

Within each phase, Fable identifies which tickets can run in parallel and which have to wait. Each ticket specifies the prompt, inputs, expected output, complexity and subagent to use. The acceptance criteria say exactly how to check the result (for an API fix, the response a particular request should return).

Executing the work

One Fable chat coordinates the project. I use that chat for an overview (what tickets are coming out of the audit and where the work is concentrated in the codebase). Fable handles the individual assignments.

1. Assign the work. Fable opens worker chats for the tickets that are ready. Independent tickets start together.
2. Check each result. The worker checks its output against the ticket and reports back. If a check fails, the worker fixes the issue on that ticket.
3. Start dependent tasks. Fable records completed work in Trello (Notion works too) and passes the results to the agents that need them.
4. Release the phase. Fable checks the combined changes against the phase criteria. Once they pass, it closes the phase and starts the next one.

The future of graph engineering

Graph engineering reflects how engineering teams work in real life, including the design, testing, QA and analysis involved. Its future could include better tools for managing this work: building the steps visually, seeing how they connect and understanding the workflow more intuitively.

I think engineers will become team leads, each managing a swarm of agents. Their job will be to keep the agents working efficiently, remove roadblocks and restructure the graph when the work needs to be divided up differently.

Longer term, I think the agents will get better at organising the work themselves. Given a goal, access to the code and a way to test it, they could decide how to divide the project and adjust the plan as they learn. One person could then build and maintain a complex platform without writing the code. Their job would be to set the objective, check that the agents are solving the right problem and judge whether the process is efficient.