I designed the control layer for agentic software development

Alucify makes complex codebases legible to people and coding agents. I designed the product surfaces that expose missing context, predict the consequences of a change, and show teams where human judgement is still required.

• Product reconstructionThe working screensThe screens →
• Complete design system20 screens, 4 flowsThe Figma →
• CompanyThe public siteThe site →

Alucify began with a mismatch.

Coding agents can generate implementation far faster than most software teams can specify, evaluate, and absorb it. But commercial software is rarely a clean, self-contained project. It is a brownfield system shaped by years of requirements, dependencies, exceptions, and decisions that may never have been documented.

That context is fragmented across tools and people. Product managers understand intent. Designers understand behaviour. Engineers carry architectural history. The code contains another version of the truth.

When an agent cannot see those relationships, it can produce code that is reasonable in isolation and wrong for the system.

Alucify gives teams a structured model of what their software is, how its parts relate, and where a proposed change conflicts with what is already known. I designed how that intelligence becomes understandable and actionable.

The transformation runs in three stages. Fragmented context — requirements, designs, code, tests and tribal knowledge — becomes the AppGraph, one queryable model of what the system means, which in turn produces grounded decisions that people and agents can both act on.

1. Fragmented contextRequirements · designs · code · tests · tribal knowledge
2. The AppGraphOne queryable model of what the system means
3. Grounded decisionsEvidence people and agents can both act on

The context gap

Agents are fast. Understanding the system is still slow.

Most software-development workflows evolved around human-paced coding. Requirements moved into design, design moved into implementation, and people reconciled the differences along the way.

Agents compress implementation time without automatically compressing the work around it. They still need answers to questions such as:

• Which requirements are authoritative?
• Which parts of the system will this change reach?
• Which decisions are supported by verified context?
• Which conventions exist only in the code?
• Where is human interpretation unavoidable?
• Has the system changed since the analysis was produced?

Without those answers, people become the integration layer between disconnected tools, incomplete specifications, and fast-moving agents. Alucify is designed to reduce that context gap.

The system model

A shared model of what the software means

Alucify converts requirements, schemas, interfaces, code, and validation artifacts into a queryable representation of the application: the AppGraph. Its nodes represent the elements of the system and its edges capture the relationships within and across them.

• SchemaEntities and the relationships between them
• LogicStates, flows and the rules that move between them
• InterfaceScreens and the components that compose them
• ValidationAcceptance tests and the checks that prove behaviour

The graph is not the final user experience. It is the grounding layer beneath the decisions the product helps teams make.

Instead of asking an agent to reason from a large pile of undifferentiated context, Alucify can supply the relevant portion of the system for the task at hand. Instead of asking a person to inspect the whole repository, the product can identify the decisions, dependencies, and exceptions that warrant attention.

The model captures relationships. The interface turns them into decisions.

The decision layer

The design problem was not showing more analysis. It was showing what to do next.

Alucify can produce a large amount of technical evidence. Raw graphs, scores, and model output would only create another interpretation problem. My work turned that evidence into a decision system: summarise the state without concealing uncertainty, let every score open into the evidence beneath it, separate verified context from agent interpretation, explain why a finding matters rather than only how severe it is, make incomplete and outdated analyses unmistakable, and direct attention without pretending the software can make the final judgement.

• ArtifactsWhat information has been created, integrated, or flagged?
• CoverageWhich decisions are grounded — and which still require interpretation?
• ImpactWhere could a proposed change propagate through the system?

Agent hours and token usage sit beside them as planning evidence — what the work is likely to cost in effort — not as a bill.

Coverage analysis

Making ambiguity visible before it becomes rework

Coverage Analysis measures how much of an implementation decision is supported by verified context and how much depends on inference.

The summary provides an overall signal. The detailed view reveals the individual decisions underneath it, organised by categories such as scope, architecture, and data. Each is fully covered, partially covered, or not covered. Incomplete decisions appear first, because they are the most likely sources of hallucination, disagreement, or later rework.

A coverage score is not a quality grade and it does not prove a result is correct. Its purpose is to identify where a product manager, designer, engineer, or customer needs to clarify intent before an agent proceeds.

The score does not finish the review. It tells the team where the conversation should begin.

Impact analysis

Predicting the consequences before changing the code

Impact Analysis projects a proposed change through the AppGraph before implementation: how much of the system it could reach, which components and concepts may be affected, where regression or compatibility risk appears, and how much agent effort the work may require.

That gives product and engineering a shared basis for scope and sequencing. A team can revise a requirement while it is still inexpensive to change, rather than after an agent has implemented the wrong interpretation.

• Without grounded impactEstimate → implement → discover dependencies → rework
• With grounded impactModel the change → inspect dependencies → adjust scope → implement

The detailed view explains impact across four dimensions.

• Blast radiusHow far the change reaches
• Regression riskWhat existing behaviour could break
• Data integrityWhat information may be exposed
• Backward compatibilityWhat existing use may stop working

Severity is carried by a label, a visual marker, and a written explanation together. The user never has to infer what “critical” means from a colour.

Impact Analysis turns “what might this break?” from a late review question into an early planning input.

Human involvement

Better automation begins by identifying where automation should stop

Coverage gaps indicate where intent must be clarified. Impact findings indicate where domain or architectural judgement is required. Artifact states indicate whether the available analysis is complete and current.

The goal is not to remove people from software development. It is to stop spending their attention everywhere equally.

• Agent-readyGrounded enough for an agent to build from
• Needs clarificationA person has to resolve the ambiguity first
• Requires expert judgementSystemic impact warrants a deeper look

These are not permanent classifications. As context improves, work moves from one state to another — which is the point of measuring it at all.

The product makes human involvement intentional instead of accidental.

Invariance and drift

An agent can follow a local pattern while breaking the system’s pattern

Every mature codebase contains unwritten conventions: behaviours most files, methods, or call sites follow even though nobody documented them. They often live as tribal knowledge until the people who established them leave.

Invariance Analysis recovers those patterns from the codebase itself. It identifies conventions, finds exceptions, and names the precise file, method, or call site that moved — so a team can inventory existing drift, check agent-assisted pull requests before they ship, and supply codebase-specific conventions back to the agents.

• Convention48 of 49 sibling tests pair setup with cleanup
• ExceptionOne named test omits the cleanup call
• Human decisionFix it, document it, or accept it as intentional

The analysis does not declare every exception a defect. Some are accidental drift; others are intentional evolution. The product supplies the evidence.

Invariance finds the gap between precedent and change. People decide whether that change is residue, risk, or progress.

Incomplete knowledge

The product has to expose the limits of its own analysis

A semantic model is not permanently correct. An analysis may still be running. A result may be empty. An artifact may change after an audit completed. A finding may go stale as the repository evolves.

These are not secondary states. They determine whether the user is acting on valid evidence. I designed explicit states for context still being created, analysis in progress, no available result, an artifact changed after analysis, and a deprecated audit requiring another pass.

Predictability includes knowing when the system does not yet have a reliable answer.

Still running

The interface explains what is happening in the background, how the user will be told when it is done, and that they do not need to keep the tab open.

• Context still being createdProduct · reconstruction
  What the system is doing, and permission to leave while it does it.

No longer current

A stale audit does not sit on screen as if it were valid. The product states that the result has been deprecated and puts the action that restores it beside that admission.

The complete system

Twenty screens connect context creation to grounded decisions

Onboarding establishes the codebase context every later analysis depends on. The dashboard provides orientation. The detailed flows let the user trace each signal back to the evidence underneath it.

The company narrative

I also designed how Alucify explains an unfamiliar category

Alucify sits between code intelligence, development infrastructure, and agent governance — a category that did not have a name to borrow. I designed the company website and the narrative system used to explain why faster generation creates a context bottleneck, why brownfield systems are the hard case, how the AppGraph supplies grounding, and why human oversight stays in the operating model.

The communication problem mirrored the product problem: expose enough of the system to make it credible without requiring the audience to understand the whole architecture first. The story opens on a constraint the reader already recognises, then reveals the model beneath it.

Evidence

Grounding changed the work before implementation began

On the LangBuilder engagement, analysis identified a requirements gap before implementation, AppGraph-grounded prototyping held fidelity between prototype and product, and the team reported time saved during implementation.

• 15%Requirements gap identifiedMissing intent became visible before it became code.
• 97%Prototype fidelityDesign decisions stayed connected to what was implemented.
• 62.5%Implementation time savedBetter grounding reduced avoidable interpretation and rework.

These are results from the Alucify system and that engagement, not from the interface design alone.

My role

I turned semantic analysis into a product people could act on

I was the product designer on the Alucify team.

I translated the company’s technical model into a product architecture, designed onboarding and source connection, defined the dashboard’s hierarchy, designed Coverage Analysis from summary through decision-level evidence, designed Impact Analysis and its severity model, connected artifacts, audits and re-audits, designed the running, empty, deprecated and stale states, and built a consistent system across twenty documented screens. I designed the company website and helped make the product thesis understandable outside the building.

The product sits between complex machine analysis and consequential human decisions. My role was to make that boundary legible: what the system knows, what it inferred, what could be affected, and where a person needs to intervene.

Alucify does not make agentic development predictable by asking people to trust AI more. It makes the codebase, the uncertainty, and the consequences of change easier to see.