vDL's Engineering AI Workflow

AI did not enter our engineering workflow as a productivity hack. It entered because the shape of our work demanded more leverage.

vDL is a small team building trust technology: blockchain infrastructure, decentralized identity, dataspaces, open-source tooling, and AI-native operating systems for ourselves and our clients. Those projects are context-heavy. They involve technical trade-offs, standards work, security assumptions, partner constraints, and long-lived decisions that cannot disappear into chat history.

So our AI workflow is built around a simple rule: use AI to compress the repeatable work around engineering, while keeping humans responsible for architecture, quality, and trust.

Our tooling choices

We use a mix of AI coding agents, chat tools, local utilities, and project-specific skills. The exact model changes as the landscape changes, but the workflow principles stay stable.

For implementation work, we use coding agents that can inspect the repo, make scoped edits, run tests, and report what changed. The useful part is not autocomplete. It is the closed loop: read the code, understand the local pattern, make the change, verify it, and leave a clear trail.

For broader reasoning, we use frontier models where they are strongest: architecture review, unfamiliar code exploration, refactoring plans, and second-pass critique.

For sensitive or bounded work, we increasingly route through local models and local tools. Local inference is not a replacement for everything, but it is valuable when privacy, cost, or resilience matters.

Skills over tool sprawl

One of the biggest lessons is that more tools do not automatically make an agent better.

We prefer project-specific skills and command-line tools over loading every possible integration into the agent context. A skill can encode the local rules that matter: how this repo is structured, which commands prove correctness, which files are fragile, what tone the site should use, how a PR should be prepared.

That keeps the agent focused. It also makes the workflow auditable. When behavior needs to change, we edit the instruction or script that caused it instead of relying on tribal knowledge.

The best AI workflow is not the one with the longest tool list. It is the one where the agent receives the smallest useful amount of context and has a reliable path to verify its work.

How we write code

Most changes start with exploration. The agent reads the relevant files, finds the local conventions, and identifies the smallest safe edit. For larger work, we separate planning from execution so the approach can be reviewed before code changes.

Implementation happens in a tight loop:

1. Inspect the surrounding code.
2. Make the smallest coherent change.
3. Run the focused check.
4. Fix what broke.
5. Run the full gate before shipping.

On this site, for example, the full gate is npm run verify: lint, typecheck, content smoke, and build. On client projects, the command changes, but the principle does not. An AI-generated patch that has not passed the same checks as human code is not done.

How we review AI output

We do not treat agent output as trusted just because it compiles.

The first review question is intent: did the change solve the actual problem, or did it only satisfy the prompt literally?

The second is fit: does it match the codebase's architecture, naming, content model, and failure modes?

The third is blast radius: did the agent touch files it did not need to touch, introduce a new abstraction, or weaken a constraint that existed for a reason?

This is where senior engineering still matters. AI can generate good code quickly, but it does not own the consequences. We do.

What we automate

AI is useful across the engineering lifecycle, but not all automation looks like code generation.

We use agents for repository exploration, implementation support, test repair, documentation updates, release notes, and review passes. We also use them for operational work around engineering: summarizing meetings, extracting decisions, preparing handoffs, and keeping project memory current.

That last part matters more than people expect. A small team gets fast when context stays alive. Decisions, constraints, and trade-offs need to be searchable weeks later. AI helps maintain that memory, but only if the team treats documentation as part of the system rather than cleanup after the work.

Guardrails

The guardrails are deliberately practical.

• Agents work inside explicit task scope.
• Risky changes get reviewed before execution.
• Generated code must pass the same checks as handwritten code.
• External data and internal data are routed through different paths.
• Human owners make architecture and product decisions.

We also write down STOP conditions for larger implementation plans. If the repo has drifted, a dependency behaves differently, or a test failure points outside the intended change, the agent should stop and surface the issue instead of improvising.

What this changes for clients

For clients, the visible result is not "we use AI." The visible result is faster delivery with cleaner handoff.

AI lets us map a codebase faster, preserve context across conversations, generate implementation options, test assumptions, and keep documentation closer to the actual work. The client does not just receive code. They receive a system with more of its reasoning still attached.

That is especially important in trust technology. Blockchain infrastructure, identity systems, and dataspaces fail when the reasoning behind them is lost. AI helps us keep that reasoning available.

What comes next

The workflow will keep changing. Models will improve, local inference will become more useful, and agent orchestration will get less fragile.

But the direction is already clear. Engineering teams will not be judged by whether they use AI. They will be judged by whether they can turn AI into a reliable operating system: scoped work, persistent memory, reproducible checks, and human accountability.

That is what we are building at vDL.