We Ship 60% Faster Now. It Wasn’t the AI Model

TL;DR

• We ship about 60% more features and improvements per month than with our traditional process.
• Our KBA feature went from start to production in two weeks, against about a month before.
• The gain came from the environment around the agent: every repository, specs for existing code, quality gates and a live preview. Not from the model.

Our last major feature, knowledge based authentication (KBA), went from start to production in two weeks. Under our old process, the same feature would have taken about a month.

That is not a one off. Across features and bug fixes, our team now delivers about 60% faster than with our traditional process. We did not get there by finding a smarter prompt. We got there by giving our AI agent a proper place to work: one cloud environment with every repository, every quality gate and a way to see the running app, shared by every engineer on the team.

This post covers how we got there, what is inside that environment, and what it changed about the way we work.

Where we started

Our stack is .NET on the backend, with Vue and React on the frontend, spread across several repositories. For years we built it the classic way:

• Product writes a spec, and we plan it into a sprint.
• Engineering is split into module teams, each owning one area of the product.
• When a feature crosses modules, the owning team hands requirements to the other teams, who fit the work into their own sprints.
• Everyone converges for a coordinated release.

It was predictable and it protected quality. It was also slow. Every line went through an engineer’s hands, and every cross module change waited in someone else’s queue. Meaningful features took months.

First attempt: AI in the IDE

We moved to BoldCreate IDE, with AI assistance inside the editor. Boilerplate disappeared and tests got written faster. Individually, engineers were quicker.

But we hit a ceiling fast:

• Context stopped at the laptop. Each engineer had a different checkout, a different setup and different config. The AI knew only what one machine knew.
• The engineer was still the loop. The assistant suggested; a human ran the build, ran the tests, read the failures and asked again.
• The process did not change. Sprints, hand offs and module boundaries stayed where they were.

We had faster typists, not a faster team.

The shift: move the agent off the laptop

The real change came when we moved to BoldCreate Cloud Agent, part of BoldCreate, the AI development product built by Syncfusion. Instead of an assistant inside one engineer’s editor, every task now runs in its own isolated cloud session, against an environment we configure once and everyone shares.

Three things made the difference:

• The agent sees the whole system. All our repositories live in the environment, so a change that crosses modules is one task, not a chain of hand offs.
• Setup happens once. Toolchains, packages and service configuration are baked into the environment. Nobody rebuilds it locally, and nobody gets a different result because their machine is different.
• Work runs in parallel. An engineer can kick off several tasks, step away, and come back to finished branches.

We stopped treating AI as a pair programmer and started treating it as a teammate with its own fully provisioned workstation.

What’s inside the environment

An agent is only as good as the environment it works in. Most of our effort went here, so a session can build, run and verify the real system without a human filling the gaps.

Feature specBug report

→

Shared cloud environmentCloud agent sessionAll BoldSign repositoriesWeb app, API, shared libraries, SDKsProject knowledgeGenerated specs of the existing code; project context and agent instructionsQuality gate harnessBuild, tests, coverage, security and frontend gates, pinned to the commit

→

Live previewTunneled from the session↓Pull request↓Engineer review↓Merge and release

1. Every repository

   The web app, backend services, shared libraries and the public API are all checked out in the session. The agent can follow a call from the UI to the database layer without anyone opening another project.

2. One time setup

   Setup scripts install the .NET and Node toolchains, restore packages and configure each service. A fresh session gets to a working build with zero manual steps.

3. Specs for a brownfield codebase

   This is the one we underestimated. Our product carries years of business rules across many modules, and an agent dropped into that cold will happily write code that compiles but ignores how the system actually behaves. So we had the agent generate detailed specs of our existing source: what each module does, how modules talk to each other and which rules they enforce. Every session starts from that map.

4. Project context and agent instructions

   Every session starts from the project context, which holds what a senior engineer would tell a newcomer: how the solution is laid out, the conventions we follow, which areas need a named human before anything changes, and the gotchas we learned the hard way. We keep it short and true, because it goes into every task whole. Alongside it, operating instructions tell the agent how to work: one task per work item, a written spec whose acceptance criteria a test or gate can check, a plan where every step names the test that covers it, and what to do when it gets stuck.

5. A harness that decides, so the agent does not have to

   The heart of the setup is one rule: the agent may narrate, but it may not assert. “Tests pass”, “this is covered”, “no secrets”, “the frontend still works” are not claims the agent gets to make. A gate measures each one.

   Before building, the agent declares which tests cover the change. The harness then builds with code analyzers on, runs exactly those tests, checks coverage on the changed lines, scans for secrets and vulnerable packages, and runs typecheck, lint and tests on the frontend when it changes. When a backend change touches an endpoint the frontend calls, the agent must trace every call site and record the impact, and a gate checks that each cited line really exists. Gate results are pinned to a commit, and a task cannot be marked done until a passing result matches the latest one.

   The effect is simple: nothing reaches a human reviewer on the agent’s word alone.

A feature, start to finish

The engineer’s job has moved from writing every line to framing the work, steering the agent and owning the review. A typical feature now looks like this:

1. Spec first. Every change starts as a task tied to a work item. The agent writes the spec: the behaviour, what is out of scope, and acceptance criteria that a test or gate can check.
2. Plan and declare the tests. The agent reads the brownfield specs and the code, proposes a plan where each step names the test that covers it, and declares those tests to the harness. The engineer adjusts the plan before any code is written. Wrong turns are far cheaper to catch here than in a diff.
3. Build in small steps. One step at a time, backend and frontend in the same session. Gates run after every step, then the step is committed.
4. Gate the final commit. The full set of gates runs against the latest commit. Failures go back to the agent with the exact line, rule or test that failed. After three genuinely different attempts on the same gate, the agent stops, records why and hands off. Being blocked is a legitimate outcome; spinning is not.
5. Try it live. The engineer opens the running feature through the live preview and uses it like a customer would.
6. Two reviews, then merge. A separate reviewer agent reads the diff alongside the gate evidence first. Then the pull request goes to an engineer, who reviews it, asks for changes in the same session if needed, and merges.

The proof: KBA in two weeks

KBA asks signers to verify their identity by answering questions before they can sign. It touches the sending flow, the signing flow, the API and the audit trail. In the old model, that meant several module teams and several sprints of coordination.

This time, one engineer owned the feature across every module, in one environment. Every gate ran before review, and the team clicked through the working feature through the live preview long before it reached staging. Start to production took two weeks, against roughly a month under our old process.

Aspect	Traditional process	AI in the IDE	Cloud agent
Who writes the code	Engineers	Engineers, with AI suggestions	The agent, steered by engineers
Cross module changes	Hand offs between team sprints	Still hand offs, one project at a time	One session, one pull request
Quality checks	After the fact, in CI and manual QA	Engineer runs tests and feeds back failures	Every gate, before review
Parallel work	One task per engineer	One task per engineer	Several tasks at once, each in its own isolated session
Seeing the feature	Pull the branch and build locally	Pull the branch and build locally	Open a link
Overall delivery	Baseline	Faster individuals, same process	About 60% faster

The speed did not come from any single capability. It came from removing waiting: for another team’s sprint, for someone to reproduce a bug, for someone to run the tests and read the output.

What changed for the team

The biggest shift was not in the code. Once one environment could build, test and preview the whole system, it quietly became the standard way every engineer works. That forced us to rethink how we organize.

• Feature ownership instead of module ownership. When an agent can change any module in one session, splitting work by module mostly creates hand offs. An engineer now owns a feature end to end, wherever it lands in the codebase.
• Standards ship with the environment. We no longer send a memo asking everyone to adopt a new convention or test rule. The harness is versioned centrally and synced to every repository, and agents cannot change it from inside a task. We add a rule or a gate once, and every session follows it from then on.
• Improvements compound. A sharper spec, a clearer instruction or a new gate improves every engineer’s next task at the same time.

We are now rolling out this centralized environment and harness across the whole engineering team as the one way we deliver features and fixes.

Guardrails we kept

We build software people use to sign legally binding documents, so going faster could not mean lowering the bar.

• Humans own the merge. Every change gets a human code review. The agent proposes; engineers approve.
• No weakening a gate. Lowering a threshold, skipping a test or softening an assertion to get green is off limits, and the gate configuration is locked so it cannot quietly drift.
• Some decisions stay human. Scope changes, breaking API changes, anything that weakens security and irreversible data changes are written up as a decision with a recommendation. The agent keeps building whatever does not depend on the answer. Sensitive areas such as authentication need a named person to approve.
• Work survives the handoff. The next session reads files, not conversation. The spec, plan, impact and evidence live with the task and ship with the pull request.
• No fast lane. Agent written changes go through the same pipeline as everything else, and CI still runs the full test suite.

What we learned

If you are thinking about the same move, here is what we would tell you over coffee:

1. Fix the environment before the prompts. If a new hire could not build, test and run your system from the environment alone, neither can the agent.
2. On a brownfield codebase, generate specs first. The agent needs a map of what already exists. That map is the difference between changes that fit and changes that fight the codebase.
3. Never take the agent’s word for it. If a tool can measure a claim, let a gate decide it. Our best single rule: the agent may narrate, not assert.
4. Keep the context short and true. A short project context that goes into every task beats a long guide nobody keeps current.
5. Make the running app one click away. Removing the local build from review saved more time than we expected.
6. Make “blocked” an acceptable answer. An agent that stops after three honest attempts and explains why is worth more than one that keeps trying.
7. Centralize, and let the harness carry the standards. One shared setup beats a hundred team announcements.

What’s next

We are still early. The environment and harness keep getting better, and every improvement lands for the whole team at once. The lesson so far is simple: AI made our engineers faster when it lived in their editor. It made our engineering team faster when we gave it a real place to work.