I designed a control layer for agentic software development

Alucify builds a model of an existing codebase so people and coding agents can reason about it. I designed the interfaces that show what the model knows, what it has inferred, and where a person still needs to decide.

Coding agents make implementation faster. That speed is useful only when the agent understands the system it is changing.

In an established product, that understanding cannot come from the code alone. Requirements explain why the product behaves as it does. Schemas and interfaces reveal dependencies. Tests encode expectations. Engineers and product managers hold decisions that may never have been documented.

Because this context is scattered, an agent may see a valid local solution without seeing why it is wrong for the larger system. Alucify brings those sources together before the agent begins to build.

Turning system knowledge into a decision

Alucify connects requirements, schemas, interfaces, code, and tests in a queryable model called the AppGraph. When a team proposes a change, the AppGraph identifies the parts of the system that the change may affect.

The model produces evidence, but evidence alone does not tell a team what to do. A graph can show a dependency without explaining its importance. A score can signal uncertainty without identifying what remains unknown.

I designed the product to close that gap. Each summary answers a practical question, explains how it reached the answer, and links to the underlying evidence.

The interface also separates verified facts from agent inference. This distinction matters because the two should not carry equal weight. A team can act on confirmed evidence, question an inference, or add the missing context.

The dashboard begins with the three questions a team needs to answer before delegating work:

• What did the agent create?
• Which decisions have enough supporting context?
• What else could the proposed change affect?

The dashboard also estimates agent hours and token use. These figures help the team compare the likely effort behind different tasks; they are not presented as a bill.

Three analyses support that decision

A team needs different evidence at different stages of a change. Alucify therefore separates its analysis into three parts: Coverage Analysis finds missing context, Impact Analysis predicts consequences, and Invariance Analysis finds undocumented conventions.

Each analysis reduces uncertainty. None makes the final decision for the team.

Coverage Analysis finds missing context

Before an agent can implement a decision, the team needs to know whether that decision is grounded in evidence or filled with assumptions.

Coverage Analysis measures that distinction. It shows which parts of a decision come from verified context and which depend on inference.

Decisions with the least support appear first because they carry the greatest risk of invention. The score is therefore not a grade of the work. It is a way to prioritize clarification.

A user can open any score to see the decisions and evidence behind it. This makes the summary useful without asking the team to trust an unexplained number.

Impact Analysis shows what a change could affect

A well-specified change can still cause problems elsewhere in the system. Before implementation begins, Impact Analysis traces the proposal through the AppGraph.

It shows which concepts the change touches, how far its effects may spread, what could break, and what data may be exposed.

Seeing those consequences early gives the team a chance to revise the requirement before an agent implements it. The product therefore moves review to the point where changing direction is still cheap.

Each finding combines a severity label with a plain-language explanation. The user does not need to infer the meaning of a score or colour.

Invariance Analysis finds unwritten rules

Established codebases contain patterns that function as rules even though no one documented them. Engineers may learn these conventions through experience, but an agent cannot rely on that shared history.

Invariance Analysis recovers repeated patterns from the code and identifies places that do not follow them. For example, if 48 related tests pair setup with cleanup and one does not, the exception may deserve review.

The exception is not automatically an error. It may reflect an intentional decision. Alucify shows the pattern and the departure from it, then leaves the judgement to the team.

Together, the three analyses answer three successive questions:

• Is the proposed work based on enough context?
• What else could the work affect?
• Does it conflict with an existing convention?

Deciding who should act next

The analyses are useful only if they lead to a clear next step. Alucify therefore translates its findings into three work states.

1. Agent-readyThe available context is sufficient for an agent to proceed.
2. Needs clarificationThe intent is ambiguous, so a person must clarify it first.
3. Requires expert judgementThe possible consequences extend far enough to require deeper review.

These states are not permanent labels. When someone adds missing context or resolves an ambiguity, Alucify updates the state. The measurement therefore helps work move forward instead of merely describing its problems.

The same principle applies to the analysis itself. A result may still be running, may return no findings, or may become outdated when the repository changes.

An outdated result should not look current. When an audit becomes stale, the interface says why it is no longer reliable and places the action to refresh it beside that warning.

Twenty screens across four flows

The product follows the sequence in which a team encounters these questions.

First, onboarding connects the repository and builds the context that every analysis needs. The dashboard then summarizes the current state. From there, users can follow a finding to its source.

That sequence produced four connected flows:

The first flow prepares the system. The other three begin at the dashboard and move from a summary to the evidence beneath it.

What changed

Alucify was used during the LangBuilder engagement. Its analysis exposed a gap in the requirements before implementation began. Resolving that gap early prevented the missing intent from becoming code.

The AppGraph also grounded the prototype in the same system context used during development. As a result, the implemented product remained close to the prototype, and the team reported less implementation time.

• 15%Requirements gap identifiedThe analysis exposed missing intent before implementation.
• 97%Prototype fidelityThe implemented product preserved the prototype’s decisions.
• 62.5%Implementation time savedClearer context reduced interpretation and rework.

These are results from the Alucify system and the engagement as a whole. They should not be attributed to the interface design alone.

What I designed

I was the product designer.

The central design problem was not how to display more technical information. It was how to help a person judge whether an agent should proceed.

To support that judgement, I designed the information architecture around four distinctions:

• verified evidence and agent inference
• summaries and their sources
• identified risks and human decisions
• current results and outdated ones

Those distinctions shaped the dashboard, analysis flows, detail views, and system states.

I also designed the company website and its narrative. Alucify overlaps with code intelligence, development infrastructure, and agent governance, but none of those categories explains the product on its own.

Instead of introducing a new category, I began with a problem software teams already know: an agent can change code without understanding the system around it. The story then explains how the AppGraph supplies that missing context and how the product turns it into decisions.

The result makes three things visible before implementation begins: what the system contains, what remains uncertain, and what a proposed change could affect.

Notes