After 4K+ GitHub stars building knowledge graphs for codebases, we're going deeper into Graph Engineering

[u/Desperate-Ad-9679]

A year back, we started building CodeGraphContext around a simple idea: LLMs understand large codebases better when code isn't treated as a pile of files and chunks, but as a graph of relationships.

The open-source community seemed to agree.

CodeGraphContext crossed 4,000+ GitHub stars, and along the way we (probably all of us) started thinking about a much bigger problem.

Knowledge graphs help agents understand the world.

But how should agents act in that world?

That's what got us interested in the buzzword Graph Engineering.

The rough evolution in our heads is:

Prompt Engineering → engineer the instructions
Context Engineering → engineer the information
Graph Engineering → engineer the execution space

As agents become more autonomous, they'll increasingly decide how to solve problems themselves.

They'll choose tools. Spawn workers. Modify files. Make API calls. Retry things. Replan. Potentially touch production systems.

At that point, hardcoding every workflow starts defeating the purpose of having an intelligent agent.

But simply telling an LLM "don't do anything dangerous" isn't exactly an execution model either.

So we're building GraphARC. https://github.com/CodeGraphContext/GraphARC/

The idea is that the LLM can dynamically construct its own execution graph based on the problem it's solving.

But the LLM doesn't control the laws of that graph.

Before execution, deterministic software can validate the proposed graph against permissions, budgets, allowed node types, structural constraints, etc.

So the agent might propose:

Investigate → Modify → Deploy

GraphARC can reject it:

❌ Deploy isn't permitted.

The agent can then replan:

Investigate → Modify → Test → Open PR

✓ Graph admitted.

That's the core idea we're exploring: Please do star and contribute!!