DCT

Scale AI software development without slowing delivery down

We rebuild your software lifecycle around agents. Our engineers embed with your team, wire them into the tools your developers already use, and stay through delivery.

Talk to a DCT AI EngineerSee the operating model ↓

  • 80%

    faster legacy code comprehension

  • 75%

    less production code effort

  • 40%

    shorter feature delivery cycles

  • 100%

    of changes approved by a human

The operating model

Six stages, one artifact chain, two gates

The traditional lifecycle was built to maximise efficiency when writing code was the expensive stage. Once agents write most of the diff, the bottleneck moves to the steps either side of build - planning, review and release - which still run at human speed. DCT Forge re-architects those steps. Pointing a chat window at the middle one speeds up the part that was never the constraint.

Swipe to see more →
HUMAN SETS INTENTAGENT EXECUTES - AND VERIFIES ITS OWN WORK BEFORE A HUMAN SEES ITPlanDesignBuildTestDeployMaintainGATE 1plan approved beforea line is writtenGATE 2 - PRODUCTIONthe agent may act up tothis line and cannot pass itintent.mdspec.mdplan.md → difftests + evalsreview findingsprod signalsTHE AUDIT TRAILEvery stage commits an artifact the next stage can read. Together they are the record of how the change was reasoned, built and approved.CLAUDE.mdskillshooksREVIEW.mdMCP connectors— the context layer every session reads before it starts.Institutional knowledge stops living in heads and wikis.production signals re-enter as the next intent
Active stage

Plan

A human writes the intent - the problem, the proposed outcome, the systems affected and the constraints. Nothing downstream starts without it.

01 - Context

Knowledge becomes a file, not folklore

Conventions, architecture, domain rules and the mistakes your team keeps repeating are written where the agent reads them at the start of every session. Policy that must be applied consistently becomes a versioned skill, distributed across the organisation rather than remembered by whoever was on the project last.

  • CLAUDE.md per repository
  • Versioned, policy-triggered skills
  • MCP connectors to your real systems
02 - Gates

Approval that is enforced, not encouraged

Reviewing every line by hand made sense when a person wrote it. It cannot keep up once agents write most of the diff. We move human attention to the gates: deterministic hooks that block, ask or allow, a written review policy with severity tiers, and branch protection the agent cannot pass. Policy is applied while the spec is written - not discovered in review three weeks later.

  • Hooks as hard approval gates
  • REVIEW.md - passes, severity, ranking
  • Production gate enforced in the repo
03 - Loops

The agent checks itself first

Every session gets a way to verify its own output - tests, builds, screenshots - before an engineer opens it. Evals run whenever the agent's configuration changes, so a change to how the system works is gated on results rather than on optimism. Monitoring closes the loop by writing the next intent.

  • Self-verification before human review
  • Continuous evals on config change
  • Parallel sessions in isolated worktrees
The same team · The same codebase

What actually changes on Monday morning

  • Requirements re-read and re-interpreted at every handoff
    Intent and spec committed as files every stage reads
  • Legacy comprehension takes days before anything can safely change
    The full call-path map in hours, before the first edit
  • Tests written last, thinnest exactly where defects hide
    Tests generated with the change, edge cases by default
  • Review spent hunting defects line by line
    The agent reviews every diff first; humans review intent and risk
  • Documentation reconstructed after the fact, stale within a sprint
    Docs drafted alongside the code, accurate at merge
  • Policy breaches discovered in review, weeks later
    Policy enforced by hooks while the spec is being written
Claude Preferred Partner

Claude Partner Network

What the partnership gives you:

  • Model selection

    The right Claude model per workload, chosen on latency and cost rather than by default.

  • Implementation speed

    Forward-deployed engineers who have shipped this before, working in your repositories.

  • Technology access

    Early access to new Claude releases and the Claude Agent SDK.

  • Cost optimization

    Model and token spend engineered down as usage scales.

Case Study

Delivery, proven on real engagements

  • FinTech

    A 5,000-hour roadmap delivered inside a budget that could not stretch

    The estimate came back at more than 5,000 engineering hours across four concurrent workstreams - well outside budget. Adding people raised cost. Cutting scope shipped a weaker product into a market where the product is the position. Neither lever was acceptable.

    • 40%

      less engineering effort

    • 40%+

      cost vs. estimate

    • 100%

      standards adherence

    On time, in budget, with no trade. Scope intact, team size unchanged, and every tool provisioned under client-owned accounts so intellectual property never left the client's boundary.

  • Product Development Enterprise Transformation

    A software product team ships more, with the same people and no extra defects

    Engineers were losing hours to the work around the code: requirements re-read at every handoff, designs rebuilt by eye, boundary tests written by hand, demo data hand-crafted before every review. DCT put AI across the whole lifecycle, not just code generation.

    • 75%

      faster requirements analysis

    • 80%

      faster test creation

    • 90%

      faster demo & QA data prep

    More features shipped, same team size, no rise in escaped defects. Requirements, design, tests and documentation now stay in step with the code instead of trailing it.

Common questions

What engineering leaders ask first

DCT Forge is delivered by DCT AI engineers working inside your team, on your repositories, under your accounts. These are the questions that come up before anyone signs anything.

Do I need to buy or license DCT Forge?

No. DCT Forge is a way of working, not a licence. DCT AI engineers embed with your team and set it up on your repositories, in your accounts, using our AI engineering platform and agent SDK. Everything we install (the context files, the hooks, the review policy, the eval suite) lives in your version control and stays yours if we walk away.

What happens in the first few weeks of a DCT Forge engagement?

It starts with an engineering assessment. We index the codebase and the delivery toolchain, baseline how long each stage actually takes on your team today, and agree the conventions the agent will follow and the guardrails it will not cross. You keep the map and the numbers whether or not the work continues.

After that, a single team ships one real release end to end: intent, spec, plan, generated tests, agentic review, gated deploy, measured against that baseline. Nothing scales until that has happened.

Does AI-generated code go to production without a human checking it?

No. We are AI software engineers, and one of us approves every change. The agent works up to the production gate and cannot pass it, and that limit is enforced in the repository by branch protection and hooks rather than stated in a policy document.

What changes is where our attention goes. Instead of reading every line of a diff, our engineers review the intent, the plan, and whatever the agent flagged as risky.

Is my source code or data ever sent outside my own environment?

No. Your code and your data do not transit to a DCT environment. On engagements where this has been the binding constraint, data-boundary compliance was established before the first accelerated commit rather than negotiated afterwards.

Will I have to switch to new development tools to use DCT Forge?

No. DCT Forge connects to your existing issue tracker, documentation platform, design tool and version control through MCP and native connectors, so a session starts with the same context a senior engineer on your team would have. There is no tooling migration, and no period where the team is learning a new way of working instead of delivering.

Does DCT Forge mean I need fewer engineers?

No, that is not what we sell, and it is not what happens. Team size stays as it is; the same team ships more. What changes is the shape of an engineer's week: less time reconstructing context, writing boilerplate tests and hunting convention violations in review, more time on the problems that need judgement.

Which programming languages and platforms does DCT Forge support?

Java, .NET, Node.js, TypeScript, Python, Angular, React, and native iOS and Android, on codebases running Docker, Kubernetes, Jenkins, GitLab and SonarQube. DCT Forge follows the conventions already in the codebase rather than importing its own, so the stack matters less than whether those conventions are discoverable. Where they are not, writing them down is part of the assessment.

Start with the assessment, not the pilot

0/255