How alterac.ai uses alterac.ai to build alterac.ai
One experienced engineer was already using coding agents to build this product. In the dated task record, the completed-task rate rose from 6.8 to 13.2 tasks per calendar day after alterac.ai began managing the workflow.
This is a rate 1.94 times as high, or approximately 94% higher, in a six-day snapshot, not a sustained delivery-rate claim, productivity multiplier, staffing formula, or customer outcome. The engineer still reviewed every proposed change.
- Before alterac.ai
- 6.8tasks/day
- Completed tasks per calendar day · July 6–28, 23 days.
- After alterac.ai
- 13.2tasks/day
- Completed tasks per calendar day · July 29–August 3, six managed days.
- Observed change
- 1.94
- Approximately 94% higher in the dated snapshot.
- Evidence source
- August 3
- Dated presentation calculated from the task record; every change remained reviewed.
Disclosure
alterac.ai is both the product being evaluated and the publisher of this study. Its builder had unusually high product familiarity and was learning and refining the workflow during the period. The dated observations are not an independent endorsement or a controlled benchmark.
The starting point
What was difficult before alterac.ai?
Coding agents could already produce useful work. The hard part was coordinating tasks, their context, and the next review decision so work moved the same product forward.
The engineer managed each task by hand.
The engineer opened a separate coding-agent conversation for each piece of work, supplied its context, tracked the branch and merge request, asked for revisions, and remembered what needed a decision next.
The coordination load made task progress harder to see.
The agents produced real software, but their work was difficult to see and direct as one team. The dated task record therefore compares completed tasks per calendar day before and after the managed workflow began, rather than treating concurrent conversations as an outcome measure.
Artifact 01 · Workflow comparison
Manual and alterac.ai-managed workflow comparison
Before: coordinate each task by hand
- 1Write or find the issue
- 2Open a separate agent conversation
- 3Supply context again
- 4Track branch and review state
- 5Remember the next decision
The July 6–28 task record later supplied the before period for the dated completed-task-rate comparison.
After: supervise one visible workflow
- 1Review a plan and its tasks
- 2Assign one clearly scoped task
- 3Let each agent work separately
- 4Review a clear summary of what changed
- 5Accept it, request changes, or restart
The first six managed days supplied the after period for that comparison, while the engineer still reviewed every proposed change.
The intervention
What changed when alterac.ai coordinated the work?
GitLab, coding agents, and worktrees stayed in place. alterac.ai gave the engineer one workflow for preparing tasks, sending them to local agents, and reviewing what came back.
- 1
Prepare the work
AI helped draft a plan and individual tasks. The engineer reviewed their scope, order, and acceptance criteria before publishing them.
- 2
Send each task to an agent
The task kept its goal, boundaries, and acceptance criteria when the engineer assigned it.
- 3
Let agents work in parallel
Each agent worked separately while shared repository instructions kept the work inside the task's boundaries.
- 4
Bring every result back for review
Each agent returned a summary, test results, manual checks, known risks, and a code-review link when one was available.
- 5
Request changes without starting over
A follow-up kept the earlier hand-off and review comments. The engineer could also choose a clean restart when that was safer.
- 6
Look back at completed work
After tasks finished, the product summarized what was completed and how long agent work and human review remained in progress.
Six more dated artifacts
How did the engineer stay in control of the work?
The opening workflow comparison showed the before and after. These six artifacts continue the story through a real plan, a published task, the agent's hand-off, a human review decision, the Metrics snapshot, and the repository's quality checks.
Artifact 02 · Published Plan
Public marketing site Plan
Plan #9
Public marketing site
Ten published tasks · selected dependency path shown
- Task #215Done
Sitemap and page briefs
Depends on Direction
- Task #216Done
Homepage design
Depends on #215
- Task #217Done
Marketing homepage
Depends on #216
- Task #219Agent working
Case-study system
Depends on #217
- Task #220Backlog
Product overview
Depends on #219
- Task #224Backlog
Launch verification
Depends on Discoverability
The complete Plan also retained the AI visitor entry point, Product page, use cases, and discoverability work. Publication created a durable dependency graph; it did not ask an agent to infer the order from a chat transcript.
Artifact 03 · Bounded task
Published homepage implementation task
Published task #217
Build the public marketing homepage
- Dependency
- Homepage design approved
- Execution
- Configured local coding agent
- Final state
- Done
Outcome boundary
A server-visible public homepage built from the approved marketing brief and shared shell.
Acceptance evidence
- • Canonical metadata and structured routes
- • Human-control language and one primary action
- • Keyboard and no-JavaScript content
- • Responsive screenshots at three viewports
Private task Markdown and run identity removed from the public rendering.
Artifact 04 · Work-run submission
Structured work-run hand-off
## Summary
What changed and the resulting behavior
## Validation
Exact focused checks and their results
## Manual verification
Repeatable routes, viewports, and expected result
## Risks
Known limitations and unavailable checks
## AI hand-off
Implementation map and continuation starting point
## Code review
The review URL when the delivery command returned one
The field sequence is retained from a submitted work run. Private text, identifiers, branch names, and the review URL are replaced by descriptions.
Artifact 05 · Human decision
Human review and continuation decision
1 · Submitted
Agent returns review evidence
The work run ends at a review decision, not an automatic merge.
2 · Follow-up
A person requests a bounded change
The next run receives the prior summary, hand-off, review link, and ordered comments.
3 · Accepted
The engineer resolves the work
Acceptance follows code review and product verification; alterac.ai records the decision.
Artifact 06 · Metrics
Project Metrics snapshot
66
completed tasks
30-day snapshot
1.94
observed rate change
Approximately 94% higher in the August 3 presentation
41m 33s
median AI work time
elapsed eligible agent intervals
The detailed charts and accessible tables appear in the Metrics section below. These values describe workflow records; they do not establish productivity, quality, effort, or ROI.
Artifact 07 · Quality controls
Repository quality-control map
- 01
Focused checks
Tests and static checks selected for the changed surface
- 02
Rendered review
Playwright flows plus mobile, tablet, and desktop screenshots where relevant
- 03
Maintenance gates
Direct-package freshness and .NET dependency auditing
- 04
Security gates
Gitleaks, Semgrep, Trivy filesystem, and built-image scans
- 05
Human decision
A reviewer checks the code and intended product outcome before merge
The controls are present in the repository, but not every check runs for every task. Their existence does not prove defect-free code. The human reviewer still owns the merge decision.
The merge boundary remained outside alterac.ai.
The same GitLab and worktree workflow remained. alterac.ai organized the task and review context around it. The product did not replace code review or merge proposed work automatically.
Controls are mechanisms, not outcome proof.
A repository can contain tests, browser checks, dependency maintenance, and security scans and still have defects. The study treats those controls as evidence of the review method, not proof of universal software quality.
Repository scope
What kind of product work did the study cover?
The study covered the real alterac.ai product rather than an isolated demonstration. By August 27, the repository included the application, CLI, documentation, deployment system, and delivery controls listed below.
- Product features for accounts, team access, planning, tasks, review, and project metrics
- Developer tooling for assigning work to local coding agents and returning each result for review
- Public documentation and a CLI for planning, task delivery, review, and recovery
- Production deployment work covering Kubernetes, data migrations, backups, routing, container images, and security checks
The public marketing pages themselves were the principal remaining product area at the cutoff.
Dated facts
What did the task record show?
The primary comparison is 6.8 completed tasks per calendar day across 23 manually coordinated days and 13.2 across the first six managed days. The August 3 presentation calculated those averages from the dated task record; later Project Metrics remains a separate snapshot.
| Period or snapshot | Part of the story | Recorded fact | How to read it |
|---|---|---|---|
| July 6–28 | Before the managed workflow | 156 completed tasks | AI-assisted coding was already in use and manually coordinated. The August 3 presentation calculated 6.8 tasks per calendar day across these 23 days. |
| July 29–August 3 | First six managed days | 79 completed tasks | The six-day presentation snapshot calculated 13.2 tasks per calendar day, a rate 1.94 times the preceding period. This point-in-time comparison did not establish a sustained productivity change. |
| After August 3, before Metrics coverage | Records between snapshots | 28 additional completed tasks | The task records existed, but Project Metrics was not available for them. This count fills the gap between the first six days and the later 30-day snapshot. |
| 30-day snapshot through August 27 | Project Metrics snapshot | 66 completed tasks | The time statistics use 60 of these tasks. Six were marked Done without the complete start and finish times needed for those calculations. |
| July 28–August 27 | Full managed period | 173 completed tasks | This total combines the 79 early tasks, the 28 tasks between snapshots, and the 66 tasks in Project Metrics. The work changed during the month, so the periods are not directly comparable. |
| July 6–August 27 | Full study period | 329 completed tasks | This combines 156 tasks before alterac.ai managed the workflow and 173 afterward. Tasks varied in size and are not equal units of output. |
The totals add up.
79 + 28 + 66 = 173 managed-period completions. 156 + 173 = 329 total completions in the study period.
The dated completed-task rate was higher.
The August 3 presentation calculated 13.2 completed tasks per calendar day for six managed days versus 6.8 across the preceding 23 days. The resulting rate was 1.94 times, or approximately 94%, higher.
The 1.94 observed change is not a sustained result.
Task sizes, task framing, infrastructure work, and Metrics coverage changed. The study does not call this a doubled delivery rate, a productivity gain, or a causal benchmark.
Project Metrics · August 27 snapshot
What do the project metrics mean?
This 30-day snapshot counted 66 completed tasks. The two time measures cover 60 of those tasks because six were marked Done without complete timing records. Each metric is defined before its values, and every chart has the same data in a table.
Completed tasks
A completed task is a workflow unit whose scope varies. The 30-day range uses UTC calendar days through August 27. Counts do not measure lines of code, effort, quality, or value, and a higher or lower number is not inherently better.
- Completed in range
- 66
- Time basis
- 30 UTC days
| Week beginning | Completed tasks | Coverage note |
|---|---|---|
| Jul 27, 2026 | 0 | No Metrics-era coverage |
| Aug 3, 2026 | 0 | No Metrics-era coverage |
| Aug 10, 2026 | 24 | 24 completed tasks |
| Aug 17, 2026 | 12 | 12 completed tasks |
| Aug 24, 2026 | 30 | 30 completed tasks |
The zeroes for July 27 and August 3 mean the Metrics-era completion evidence did not yet exist. They do not mean development stopped.
AI work time per completed task
For each completed task included in the sample, this metric adds the elapsed coding-agent time, including work done after a reviewer requested changes. It is not human effort, queue time, complete task cycle time, or a quality score.
- Included sample
- 60 tasks
- Average
- 1h 9m
- Median
- 41m 33s
- 90th percentile (P90)
- 2h 43m
| Week beginning | Sample | Average | Median | 90th percentile (P90) |
|---|---|---|---|---|
| Aug 10, 2026 | 24 | 1h 2m | 48m 32s | 2h 3m |
| Aug 17, 2026 | 10 | 1h 35m | 48m 49s | 3h 34m |
| Aug 24, 2026 | 26 | 1h 5m | 41m 5s | 1h 52m |
Working-hours human review time per completed task
This metric adds the organization's configured working hours from each agent submission until a person first accepted the work, requested changes, or chose a restart. It excludes nights and inactive weekdays. It measures elapsed review time, not active reviewer labor, individual performance, task quality, or raw wall-clock time.
- Included sample
- 60 tasks
- Average
- 8h 1m
- Median
- 1h 34m
- 90th percentile (P90)
- 1d 10h
| Week beginning | Sample | Average | Median | 90th percentile (P90) |
|---|---|---|---|---|
| Aug 10, 2026 | 24 | 12h 45m | 0 sec | 1d 11h |
| Aug 17, 2026 | 10 | 9h 2m | 5h 9m | 20h 20m |
| Aug 24, 2026 | 26 | 3h 15m | 1h 11m | 3h 28m |
For the 60 tasks with complete review records, half received a human review decision within 1 hour 34 minutes of configured working time. The 8-hour average was pulled upward by a smaller long-review tail; it does not mean reviewers spent eight active hours on each task.
Six of the 66 completed tasks were manually marked Done without the complete timing records required for either duration metric. The page reports 60-of-66 coverage and does not estimate or replace those missing values with zeroes.
Interpretation after the evidence
Why did the weekly pattern change?
The three weeks contained different kinds of work and only a small number of tasks, so the pattern needs context before it can support an interpretation.
Task boundaries improved during the month.
The builder became more effective at writing smaller, reviewable tasks. AI helped draft them; the person still reviewed and refined their scope.
The week of August 17 contained heavier infrastructure work.
Larger Docker-to-Kubernetes migration tasks required more manual action, including server preparation. That week had fewer completions and longer AI work and review times.
Better framing and easier verification may explain part of the later decline.
By August 24, tasks were better scoped and the Kubernetes-based local environment made manual verification easier. This is a plausible interpretation, not a controlled causal result.
What we learned
Which operating adjustments mattered?
The engineer changed how tasks were scoped and how each change was checked. Those adjustments are part of the result.
- 01
Agent work still benefits from human-sized boundaries.
Early tasks were sometimes too broad. The workflow improved as AI helped draft smaller tasks and the engineer reviewed their scope, acceptance criteria, and order before agents received them.
- 02
More validation is not automatically better validation.
The first agent instructions required the complete verification graph for nearly every change. They were refined so validation stays proportional to the changed risk while preserving repository quality gates and repeatable manual proof.
- 03
Infrastructure work distorts short comparisons.
The week of August 17 included larger Docker-to-Kubernetes migration tasks and manual server work. Its lower completion count and longer duration distributions reflect a different task mix, not a simple workflow regression.
- 04
The useful middle ground was supervised delegation.
The engineer retained architecture, task framing, verification, review, and merge decisions while alterac.ai carried more of the coordination between those boundaries.
Interpretation and limits
What can and cannot be concluded?
In this study, the observed completed-task rate was higher after alterac.ai began managing work without changing the review and merge boundary. The evidence does not prove the same productivity, staffing, quality, or financial result for another team.
A credible narrow conclusion
For this engineer, repository, and period, the dated completed-task rate was higher after alterac.ai began managing work while the engineer preserved architecture, verification, review, and merge responsibilities.
That makes the workflow relevant to evaluators with similar constraints. It does not guarantee that another team will reach the same completed-task rate, pace, or outcome.
Visible limitations
- The builder, user, and publisher are closely related, with unusually high product familiarity and stronger incentives than a typical new customer.
- This is one project, one experienced engineer, one repository, and the coding-agent and model configuration used during this period.
- The workflow change was observational, not randomized. The developer, product, AI-assisted approach, and core tools remained while the coordination layer changed.
- Task counts depend on how work is divided and cannot be treated as equal units of output, effort, quality, or value.
- Task framing and review behavior improved during the month, while the Docker-to-Kubernetes migration changed complexity and manual-verification needs.
- Metrics coverage began with the week of August 10. Six of 66 completed tasks lacked the complete timing records needed for the duration statistics.
- AI work time may include pauses or waits. Working-hours review time is elapsed time during configured working hours, not active reviewer labor.
- Another agent, model, repository, reviewer, hardware profile, task-writing practice, or quality bar may produce different results.
- Completed tasks, merge requests, tests, coverage, and scan gates are different evidence types. None alone establishes value, defect rate, ROI, or general software quality.
This study does not claim that alterac.ai replaces engineers, guarantees quality, makes every task faster, reduces active review labor by a stated percentage, proves a sustained 94% productivity increase, or eliminates the need for an engineering team.
The fit question
Could the same supervised loop fit your repository?
Use this first-party evidence as one input. Compare the workflow, constraints, and review boundary with your own before drawing an outcome conclusion.