1Effective output
Features and improvements shipped each month, not counting quick rewrites.
Changes shipped per month
020406080
50
59
Before AINow
Methodology & Process
Agent-Centric Development Cycle (ACDC): An AI-Native SDLC
Eastgate's own flavor of harness engineering
Eastgate Software - German Engineering Standards. Enterprise-Grade Results.
Methodology & Process 
Eastgate Software Engineering
Agent-Centric Development Cycle (ACDC): An AI-Native SDLC
Eastgate's own flavor of harness engineering
With AI, an engineer can write code much faster. However, writing the right code is a different story. When intent lives in chat history, teams lose a reliable record of why decisions were made. The result is faster output but more rework.
ACDC, or Agent-Centric Development Cycle, uses AI agents to implement code while engineers decide what to build. With this process, engineers resolve trade-offs as the work progresses and check the results before release. Most importantly, the people shipping the software remain responsible for its quality.
Eastgate Software Engineering 
Why Are Teams Using AI Still Shipping Bad Code?
Adoption is no longer the question. DORA's 2025 report found that 90% of respondents use AI at work, and more than 80% say it has raised their productivity.
AI coding assistants changed how fast we write code. They did not change how hard it is to write the right code. The harder problem was always the gap between what the business needs and what the developer understands.
While observing our own developers at work, we found that AI makes each task feel quicker. However, the review, rework, and fixes that follow can leave the overall work slower than it feels.
That rework starts when AI fills unclear requirements with plausible assumptions. It can produce code faster than engineers can validate it, making flawed output look complete. The problems often surface only after the work has moved closer to release.
Anthropic's 2026 research supports our observation. Their research on Claude Code usage found that software professionals reach verified success in about 30% of their sessions, while nearly 9 in 10 of their code-producing sessions reach at least partial success.
The gap between partial and verified is where a person still has to check and finish the work.
Our answer is a lightweight specification layer between intent and implementation, where requirements become concrete examples before any code is written. People remain accountable from the initial intent through final release approval. We call this method the Agent-Centric Development Cycle, or ACDC.
The original idea of ACDC
ACDC builds on harness engineering, an emerging practice that surrounds an AI model with a system for guiding its work and checking the result. The model provides the raw capability. The harness turns that capability into software a team can review and trust.
The principle predates generative AI. For more than a decade, teams have used concrete examples to agree on expected behavior before coding begins. OpenSpec now applies this spec-driven approach to AI coding assistants. The project has earned more than 70,000 GitHub stars.
We built ACDC on these foundations and the delivery practices we have refined through years of client work. It reflects lessons from our work for Siemens Mobility and for Seneca ESG, where we automated ESG scoring and regulatory reporting for institutional investors. The same discipline shapes enterprise products such as AmatriumGPT, the secure AI knowledge hub we built for materials engineering.
What Are the Risks of AI Coding Without Clear Controls?
When AI writes code without clear controls, the effects show up in the data. Independent research into AI-written code points to four risks:
- More defects to catch before release. AI-authored pull requests carried 1.7× more issues than human-only ones, averaging 10.83 against 6.45 across 470 real GitHub pull requests (CodeRabbit, 2025).
- Security gaps. The same study found up to 2.74× more security issues, most often improper password handling and insecure object references.
- Duplicated code that turns into technical debt. Blocks of five or more duplicated lines became eight times more frequent in 2024, so a single bug has to be fixed in more places (GitClear, 2025).
- Less clean-up of existing code. AI makes it easy to add new code, while less of the existing code gets cleaned up. The same research shows that in 2020, cleaned-up code made up 24.2% of all changed lines, almost three times the share of copied code (8.9%). By 2024, copied code had overtaken it for the first time, at 12.3% against 9.5%.
What Is an AI-Native SDLC, and Where Does ACDC Fit?
An AI-native software development lifecycle (SDLC) brings people and AI agents into one delivery process. Rather than stopping at code generation, it carries the original intent through to release validation. This prevents the business goal from getting lost as the work progresses.
At Eastgate, ACDC provides the operating model for this agentic approach. In practice, clear specifications tell each agent what to do and how the work will be judged. Throughout the process, your team remains responsible for every important decision.
As a result, progress is measured more broadly. Instead of asking whether individual tasks were completed faster, teams can assess whether delivery became more reliable and effective as a whole. The table below shows the changes in practice.
| Dimension | What Most Companies Do | AI-native delivery at Eastgate |
|---|---|---|
| Process | Add AI assistance to tasks within the existing workflow. | Connect AI-supported work from requirements through release and production feedback. |
| Roles | Use AI assistants within existing team roles. | Give agents defined responsibilities and name the person accountable for each result. |
| Quality checks | Apply existing review and testing practices to AI output. | Check output against agreed specifications, with enforced checks before human approval. |
| Decisions | Use AI recommendations to support decisions within the team. | Record key trade-offs and assign a clear owner for approval. |
| Measures | Track AI usage and time saved on individual tasks. | Measure overall delivery time alongside rework and defects after release. |
| Collaboration | Share AI outputs through standard team handoffs. | Carry shared project context and review evidence between people and agents. |
What Is Human-in-the-Thinking-Loop?
In many AI workflows, human-in-the-loop means asking a person to approve the final output. However, that model breaks down when agents generate more work than the team can examine properly. Approval becomes a skim, while the reasoning behind each change remains undocumented.
Instead, ACDC puts people in the thinking loop before implementation begins. Engineers and business owners first define the outcome and the cases that matter. As a result, the agent has clear boundaries for handling trade-offs before it writes code.
Once those boundaries are clear, agents carry out the agreed work. The brief becomes a specification that guides implementation. From there, tests are derived directly from the requirements, and an agent performs the first review. Finally, people step in whenever judgment is required and retain final authority over the release.
Where the Saved Time Goes
Agents reduce the time spent on implementation. However, the real value lies in how engineers reinvest those hours.
To measure that shift, we ran a controlled internal experiment using comparable work with and without ACDC. With ACDC, engineers spent less time on boilerplate and rework. This gave them more time to strengthen the design and investigate domain-specific edge cases. They also spent more time reviewing the results.
What Are ACDC's Five Layers?
ACDC combines five layers. Each answers a different question about the work, from who performs a task to who approves the result.
Together, these layers connect intent with evidence. They make delivery more disciplined, but they do not guarantee a defect-free release. Apply them according to the needs of your project:
- Reduce rework. Agree on the expected behavior before implementation. This gives reviewers a shared standard for assessing the result.
- Keep specs portable. Store requirements in plain text so teams can inspect or transfer them easily. A tool change may still require updates to the surrounding integrations.
- Centralize context. Create one clear entry point for the latest project information. From there, the team should be able to find the decisions and conventions that shape the work.
- Trace every change. Link each requirement to its code review. Then preserve the evidence that supports approval.
- Review documentation. Let agents draft documentation alongside the change. Checks and reviewers must still confirm that it matches the shipped behavior.
- Reduce recurring debt. Turn review findings into better shared rules or stronger tests. Then monitor whether the same problems return.
- Scale parallel work carefully. Define system boundaries and ownership before agents work in parallel. Increase concurrency only while the team can review the output properly.
Why Is This Called Harness Engineering?
For delivery purposes, an AI agent can be understood as a model operating inside a harness. The model provides the raw capability to generate code. The harness directs that capability toward a defined result. It sets clear boundaries for the work and checks the output against an agreed standard.
Without a strong harness, the same model can produce inconsistent results. A well-designed harness gives it a clear blueprint and a reliable way to verify the work. Therefore, when something fails, the question is not only whether the model is capable. The team must also identify what guidance is missing and make it enforceable.
How OpenAI Ships Software With Codex Agents
OpenAI calls this discipline "harness engineering." The term captures the role of the surrounding system: the model provides the capability, while the harness directs it toward dependable work.
OpenAI tested this approach by building an internal product with about a million lines of code in five months. Codex generated every line, while the engineers focused on shaping the environment and defining what the agents should achieve. Their summary was simple: "Humans steer. Agents execute." (OpenAI, 2026).
The same principle shapes the Codex app. It allows engineers to supervise multiple agents working in parallel. Each agent works in an isolated worktree, helping teams manage concurrent changes without conflicts or lost context.
Talk to our engineers
Want to see our ACDC process in action?
Walk through your gaps and quick wins with our engineering team.
Book a consultHow Does Harness Engineering Guide and Verify AI Coding Agents?
A harness controls a task at the start and at the finish. Before work begins, it gives the agent usable project context. Given/When/Then examples make the expected behavior concrete. Domain terminology is defined, and the relevant architecture rules are made explicit. The task also states its boundaries and expected outcome. Any unresolved question remains visible instead of being left for the agent to guess.
At the finish, the harness requires evidence before approval. Deterministic checks run first. The code must pass its linter and type checker before tests validate the intended behavior. An agent then reviews the result against the specification. Finally, people retain authority over risk and release. Project tooling enforces this sequence, so the process does not depend on someone remembering every step.
The harness should also improve whenever it misses a defect. Fixing the code is only the first step. The team must understand which control failed or was absent. Adding more instructions does not prove that the problem is solved. Instead, the corrected control must catch the original failure. This creates a four-step loop:
- Find the failure. Start with a concrete miss. It may be a production defect, a recurring review comment or a test that passed despite incorrect behavior. Record what happened and what should have happened instead.
- Trace the gap. Identify the control that should have stopped the problem. Often, the requirement was not explicit enough. In other cases, the test checked the implementation without validating the intended behavior.
- Strengthen the control. Update the specification or test that allowed the problem through. If the cause affects the wider workflow, revise the shared rule or access boundary. Wherever possible, encode the correction in the pipeline.
- Prove the correction. Run the updated control against the original failure. If it does not catch the problem, the control remains unproven. Once it works, keep it in place and use the next failure to improve the harness again.
How Do People and Agents Coordinate Daily Work?
The harness gives each agent a defined role and an expected output. Coordination keeps shared work aligned. Review checks the result against the requirement, while people remain accountable for decisions.
Give Each Role a Clear Responsibility
Every change begins with a shared reference: a specification built around concrete scenarios. It defines what must be implemented and how the result will be accepted, keeping the work aligned to one agreed record.
Where tasks are independent, agents can work in parallel. A backend agent updates services and writes unit tests linked to the requirements, while a frontend agent implements interface changes and integration checks. Before work begins, the team defines ownership of files and interfaces to prevent conflicts.
The remaining stages run in sequence, with evidence carried through each hand-off. A testing agent documents results, identifies coverage gaps, and adds regression checks. A code-review agent then assesses the change and raises any issues that must be resolved before human approval.
Finally, the decision remains with a person. An agent can recommend whether to proceed, but an accountable approver makes the release decision. Both the decision and its supporting evidence are recorded.
Beneath the workflow sits a shared foundation of rules, hooks, and project context. As the team learns, that foundation evolves, turning recurring lessons into clearer guidance and enforceable controls.
Challenge the Result Against the Requirement
To challenge a result properly, a code-review agent needs a clear basis for its assessment. Give it the agreed specification, followed by the proposed change and its test results. This allows the agent to compare intent, implementation, and evidence.
Ask the agent to flag contradictions first. It should also identify behavior that has not been tested and claims that lack evidence. However, an agent's "pass" remains a recommendation. The change can proceed only after it clears the required project checks and receives human approval.
Each role should leave evidence that the next reviewer can inspect:
- Agreed criteria. The business analyst defines the acceptance criteria and confirms them with the business owner.
- Test evidence. The engineer implements the agreed behavior and shows which tests verify it.
- Review findings. The code reviewer records any gaps and sends them to the accountable human approver.
For example, "Show orders securely" is too vague to test. Define the expected behavior instead: "Given a signed-in customer, when they request an order belonging to another account, the system denies access and returns no order details." A reviewer can verify that result.
Finally, treat words such as appropriate and user-friendly as unfinished requirements. The same applies to seamless, efficient, and fast. Replace each term with an observable result or a measurable threshold.
The Blind Spot When Measuring the Value of ACDC
Once the workflow is in place, the next question is whether it improves delivery. The answer must be measured across the full delivery cycle. More code and more pull requests show activity. They do not show whether customers receive better software sooner.
These counts are easy to collect but easy to misread. Lines of code can reward unnecessary complexity. Pull request counts can reward teams for dividing work into smaller fragments. Once a delivery metric becomes a target, people learn to improve the number rather than the result. None of these measures captures customer value on its own.
Self-assessment creates another blind spot. In a 2025 Stanford presentation, 43 engineers rated their own productivity. Researchers then compared those ratings with measured output. The correlation was weak at r = 0.17, and only one in three engineers placed themselves in the correct quartile.
The same presentation also shows why context matters. In one company case study, AI adoption increased rework by 2.6 times, while effective output rose by only 1%. Its broader guidelines estimate gains of 15–20% for simpler work in existing codebases. For complex work, the range falls to 0–10%. The more complex the codebase, the more of the time AI saves gets absorbed by rework.
2 in 3
engineers misjudged how productive they were compared with their peers.
What Do We Measure Instead?
Because activity counts and self-ratings can mislead, our own delivery reviews look at the code itself. Four measures tell us most of what we need to know, including how much of the work has to be redone. Here is an example readout for one team, with illustrative figures:
2Rework rate
Share of new code redone within three weeks, checked every week against a 30% warning line.
Rework rate (%)
0%10%20%30%40%
Warning line: 30%
12% Jul 3Jul 24Aug 14Sep 4Sep 25
3Maintainability
How easy the code is to change, measured by a static analysis tool before AI and now.
Code health score
0510
6.9
7.4
Before AINow
4AI-assisted changes
Share of lines rewritten within three weeks, for code written with AI and without it.
Lines rewritten in 3 weeks
0%10%20%
11%
14%
Without AIWith AI
The team now ships 59 changes a month instead of 50, an 18% rise. Since early July, rework fell from 22% to 12%, well under the 30% warning line. Code health also rose from 6.9 to 7.4, so the extra output is not making the code harder to change.
The weak spot is code written with AI. 14% of its lines are rewritten within three weeks, against 11% for code written without AI. The next step is to make requirements clearer and review AI-written code more closely before adding more AI agents.
The Four Levels of AI Maturity
These numbers show what changed, but not how the team uses AI to get there. For that, we place each repository on a four-level maturity scale, from ad-hoc prompting to orchestrated agents working under a harness. ACDC is the path from the first level to the fourth.
- L1 Ad-hoc prompting
People use AI tools one task at a time, with no shared rules or record.
- L2 AI in the existing workflow
AI assistants sit inside everyday tools, and the usual review still applies.
- L3 Spec-driven agents with checks
Agents build from agreed specifications, and automated checks run before approval.
- L4 Orchestrated agents under a harness
Several agents work together inside shared rules, with people in the thinking loop.
Most repositories may remain at L1 or L2, while a small number at L3 or L4 produce most of the useful output. Therefore, we weight each repository by the output it delivers instead of counting how many sit at each level.
For clients, the maturity level shows how effectively a team uses AI. It also reveals whether the strongest practices and controls support the highest-impact work. Because we reassess each level regularly, teams can move down when those practices weaken and move up when they improve.
How Do You Measure an ACDC Pilot?
A pilot should use the same kind of measures as the readout above. That's why we give you a tool to try out this method by yourself. Before you start, select the measures that match your goals and record a baseline for each. Then compare the same kind of work over a defined period.
Combine all the metrics you used together to find the real insights, so a gain in one place does not hide pressure in another. For example, shipping more changes brings little value if rework climbs toward the 30% warning line or changes wait longer for review.
For the Business: Software Delivery Metrics
For Engineering: AI Workflow Metrics
Your pilot measurement plan
No measures selected yet.
Tick the measures you will hold the pilot to, then record what each one reads today. Saved in this browser only.
Copy the plan and paste it into your own document to keep it.
Talk to our engineers
Want to see what these outcomes could look like for your roadmap?
30-minute scoping call. No commitment, no slide deck.
Book a consultWhat Does Eastgate's ACDC Harness Include?
Eastgate packages its approach in the EGS Engineering Kit, built around Claude Code and OpenSpec. It brings shared agent definitions and workflow guidance into projects so teams can work from a common starting point. The published kit inventory includes:
-
7 AI Agents
Defined responsibilities for planning, implementation, testing, and review. Each task should have an agreed scope and an expected output.
-
11 Lifecycle Hooks
Checks at configured workflow events. Command hooks can enforce deterministic rules; model-based checks still require judgment.
-
13 Coding Rules
Shared workflow conventions and standards for the relevant technology stack. Rules guide work; required checks verify compliance.
-
60+ Role Skills
Guidance for recurring work across business analysis, engineering, QA, DevSecOps, project management, and pre-sales.
-
24 Knowledge Packs
Reference material for specialist tasks, including architecture, security, and nonfunctional requirements.
Final Words
Put the kit in context. Start with the delivery problem you want to solve. Agree on the relevant controls, the authoritative project records, and how success will be assessed. Installation is the starting point; the team still defines how roles collaborate and who approves the result.
AI makes code cheap to produce. It does not make judgment cheap. ACDC spends the hours agents save on the decisions that determine whether software is right: the intent, the examples, the trade-offs, and the release.
Judge the result by what ships and how much of it has to be reworked, not by how much code was written.
Frequently Asked Questions
What Is the Agent-Centric Development Cycle? +
ACDC is Eastgate's software delivery methodology built around structured specifications, AI agents, and human approval. It connects implementation to requirements and review evidence.
Is ACDC an AI-Native SDLC? +
ACDC provides a foundation for an AI-native SDLC through shared specifications and controlled agent workflows. Its reach across the lifecycle depends on the processes configured for the project.
How Does ACDC Differ From AI Coding Tools? +
AI coding tools provide capabilities for producing and changing software. ACDC organizes how a team uses those capabilities, including requirements, checks, and responsibility for decisions.
What Is the Difference Between AI-Assisted and AI-Native Development? +
AI-assisted development adds AI support to tasks within an existing workflow. AI-native development redesigns the workflow around agent capabilities and the controls needed to use them responsibly.
Is an Agentic SDLC the Same as an AI-Native SDLC? +
The terms often describe overlapping approaches to using agents across software delivery. Assess the actual workflow and approval rules when comparing implementations.
Does ACDC Support Roles Beyond Developers? +
Yes. Eastgate's role pipelines also cover business analysis, QA, DevSecOps, project management, pre-sales, and solution architecture.
Does ACDC Replace Agile? +
No. Teams can keep their Agile practices while adding clearer specifications and checks for work performed by agents.
Does Spec-Driven Development Slow Down Small Changes? +
A full specification can add unnecessary overhead to a small, well-understood fix. Match the documentation to the change, while retaining the tests and approvals it needs.
What Is OpenSpec? +
OpenSpec is an open-source framework for spec-driven development with AI coding assistants. It helps teams maintain requirements and proposed changes alongside their code.
How Does Human-in-the-Thinking-Loop Differ From Human-in-the-Loop? +
Human-in-the-loop usually places a person at an approval gate after the work is done. In the thinking loop, people also set the intent, examples, and trade-offs before agents start, then approve changes at the project's defined gates. Agents perform approved tasks within scope, but cannot grant themselves broader authority.
Can ACDC Work With Existing Delivery Tools? +
Yes, ACDC can be applied alongside existing version control, CI/CD, and project management tools. The project must define where authoritative records live and how they connect.
Does ACDC Remove Vendor Lock-In? +
Plain-text specifications and project files make the methodology easier to inspect and transfer. Moving to another tool may still require changes to hooks, permissions, and integrations.
Read the Full White Paper
Detailed framework, implementation methodology, and actionable insights - available instantly with your business email.
Access granted - scrolling to full content...
About Eastgate Software
Eastgate Software is a strategic engineering partner headquartered in Hanoi, Vietnam, with offices in Aachen, Germany and Tokyo, Japan. With 200+ engineers, 93% team retention, and 12+ years of delivery excellence, we build mission-critical systems for clients including Siemens Mobility and Yunex Traffic.
Our ACDC (Agent-Centric Development Cycle) methodology combines German engineering discipline with Vietnamese engineering talent to deliver enterprise-grade results across Intelligent Transportation, FinTech, Retail, and Manufacturing.
Contact: [email protected] | (+84) 246.276.3566 | eastgate-software.com
Let's Work Together
Tell us what you're building. Our engineers will respond within 1 business day with a concrete next step - no sales script, no obligation.
- Email[email protected]
- Phone(+84) 246.276.3566
- Response TimeWithin 1 business day