Can an AI-augmented engineering team run a 25-person operation?

A 25-person operation did not become two engineers because a language model suddenly became a twenty-third colleague. It became smaller because we removed work that existed only to coordinate people, made production behavior visible, and gave the remaining engineers tools that could complete bounded tasks quickly.

The claim needs careful limits. At AppMaster.io, operations moved from 25 people to two AI-augmented engineers while output and uptime held. I can state those results. I will not invent a percentage change in incident count, a fictional deployment frequency, or a neat quarter-by-quarter graph that was never published. What matters is the operating sequence, the controls that prevented speed from becoming recklessness, and the human work that did not disappear.

The useful lesson for founders is not "cut twenty-three people." That is the lazy reading. The useful lesson is that a product team can carry far less coordination and manual execution than most organizations assume, but only after it replaces those activities with explicit systems of work.

Why a 25-person operation had more than 25 jobs

A 25-person operation usually contains a long queue of activities that no customer would recognize as product delivery. Someone translates a request into tickets. Someone asks another person where a service lives. Someone waits for a reviewer who owns an old module. Someone repeats a deployment checklist. Someone collects logs after an incident, then copies the useful lines into a chat thread.

None of those people are lazy. The organization created the work because the system was difficult to understand, the process was only partly written down, and knowledge sat in individual heads. As headcount grows, each local uncertainty creates another handoff. Handoffs create meetings, status updates, prioritization rituals, and waiting. Then the company mistakes the resulting activity for capacity.

That distinction matters. A team can reduce headcount only if it reduces the work itself. Reassigning the same coordination burden to two people is not a transformation. It is a short path to missed releases, exhausted on-call coverage, and a slow decline in product quality.

We treated the old operation as a collection of work types, not a collection of job titles. Each type went into one of four buckets:

• Work that could be eliminated because it existed only to bridge a broken process.
• Work that could be automated with deterministic tooling.
• Work that AI could draft, investigate, or execute inside a defined boundary.
• Work that still needed an accountable human decision.

That last bucket is not an embarrassing remainder. It is where engineering leadership belongs. AI has no commercial judgment, no personal responsibility for a customer outage, and no right to trade future maintenance cost for a launch date. Keep pretending otherwise and you will pay for it later.

The first change was to make work small enough to trust

AI works best when the task has a narrow objective, relevant context, a way to test the result, and a clear stop condition. "Improve the billing system" is management language, not an executable instruction. "Add validation for this request field, update these tests, run this command, and do not change the schema" is a task that an engineer can review.

Before shrinking the operating model, we had to break broad responsibilities into work packets with visible inputs and outputs. That changed the role of the engineer. Instead of acting as a human router for dozens of ambiguous requests, the engineer increasingly acted as a designer of constraints and a reviewer of evidence.

A work packet should answer five questions before anyone hands it to an AI tool or another engineer:

1. What user or system behavior must change?
2. Which files, services, or interfaces are in scope?
3. What must not change?
4. Which automated checks prove the intended result?
5. Who can approve production release, and who can stop it?

This is more demanding than asking for a feature in a chat window. That is the point. A vague prompt produces plausible code with unknown consequences. A clear work packet makes a result inspectable.

The popular advice to give an AI agent broad repository access and ask it to "handle the ticket backlog" is wrong for production engineering. It is popular because it offers a dramatic demo. In a real company, backlog items differ in business impact, data risk, and hidden dependencies. A fast agent can create a large batch of changes that each look reasonable in isolation and become expensive together.

We kept changes small enough to review, test, revert, and explain. Small changes also reduced the amount of context an engineer had to reconstruct at 2 a.m. when something behaved differently in production.

Removing coordination came before replacing execution

The hardest part of a staff reduction is rarely code generation. It is deciding who no longer needs to be in the loop.

Large teams often use people as interfaces between systems that should communicate directly. A release coordinator gathers updates because pipeline status is unreliable. A project manager chases approvals because nobody can see ownership. A support layer rephrases technical reports because product behavior is not observable. An operations specialist repeats a manual rollout because deployment scripts cannot safely express the sequence.

The small-team model forced us to remove those intermediaries or give the underlying system a direct, auditable path. That meant fewer private decisions and more written defaults.

For example, an engineer should not need to ask three people whether a change can go live. The repository and deployment process should answer most of the question:

release_candidate:
  stage: release
  script:
    - ./ci/run-contract-tests
    - ./ci/check-migrations --production-safe
    - ./ci/build-release-manifest
  rules:
    - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'
  artifacts:
    reports:
      dotenv: release.env

production_deploy:
  stage: deploy
  needs: ["release_candidate"]
  script:
    - ./ci/deploy --environment production --revision "$RELEASE_SHA"
    - ./ci/smoke-test --environment production
  when: manual
  rules:
    - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'

This fragment does not make production safe by itself. It prevents a familiar failure: an engineer deploys an untested branch, forgets a migration check, and discovers after release that rollback is no longer simple. The manual production gate remains because somebody must decide whether the release belongs in production now. The machine handles the repeatable evidence collection.

GitLab's documentation makes a related point about rules: it evaluates them before jobs run, so a pipeline cannot rely on variables generated later in the job. That detail sounds minor until a team builds a release gate on information that does not exist when the decision is made. Read the actual execution model of your CI system. Assumptions about pipeline order create avoidable release failures.

The practical test was blunt: if a role spent most of its time copying status, chasing a response, or translating between tools, we asked why the product and process needed that person in the path. Often, they did not. The work needed a written owner, a default rule, or a machine-readable artifact.

AI took bounded execution, not accountability

Once the work had clear edges, AI could take on a serious amount of execution. It could inspect a repository for related code, propose a patch, write repetitive tests, explain an unfamiliar subsystem, compare an implementation against a specification, and help turn noisy logs into an incident hypothesis.

Those uses saved time because they removed setup and search work. An engineer no longer had to spend an hour locating every place a request type appeared before deciding what to change. The engineer could ask for an inventory, verify it, and start with a better map.

But the dividing line stayed firm: AI could prepare a decision, not own one.

A human had to decide whether a feature should exist, whether a customer exception justified technical debt, whether a schema change could lock us into a bad model, whether an alert represented user harm, and whether an incident response should favor restoration or data protection. Those decisions require context that is partly commercial, partly ethical, and often incomplete.

A useful review rule is this: the more irreversible a change is, the less autonomy the agent gets. Code behind a feature flag is easier to reverse than a deletion job. A test update is easier to reverse than a permissions model. A documentation correction is easier to reverse than a payment flow.

We used three levels of AI work:

• Drafting, where the tool produces code, tests, a migration plan, or an investigation note and a human reviews it.
• Executing bounded tasks, where the tool changes a limited area and must pass named checks before review.
• Assisting incident analysis, where the tool groups evidence and proposes hypotheses but never declares an incident resolved.

Do not confuse a passing test suite with approval. Tests check what you encoded. Human review checks whether you encoded the right thing, whether the change violates a product assumption, and whether the code introduces a maintenance cost that no test exposes.

Uptime needed controls that did not depend on team size

A two-engineer operation cannot preserve uptime by adding more on-call heroics. It preserves uptime by making routine change boring and by seeing trouble before a customer has to explain it.

The Google SRE Book defines a service level objective as a target measured through a service level indicator. It also argues against chasing 100 percent reliability, because that target can force an organization to spend too much on caution and too little on useful change. The important part is not the vocabulary. The important part is that a team agrees in advance on which user-visible behavior matters and what it will do when reliability degrades.

We used uptime controls as operating rules, not as dashboard decoration. A service needed a defined user-facing measure, an alert that someone could act on, a known rollback or mitigation route, and an owner. If one of those pieces was missing, the service was not ready for a small operating team.

OpenTelemetry's documentation describes traces, metrics, and logs as different telemetry signals. Teams often collect all three and still cannot answer the only question that matters during an incident: which customer action is failing, where does it fail, and did the latest change cause it? The answer comes from connecting telemetry to a service behavior, not from collecting a mountain of machine data.

A minimal service record can look like this:

Service: account provisioning
User action: create a production workspace
Success signal: completed provisioning requests / total requests
Target: set by product and engineering together
Alert: sustained failure rate above the agreed threshold
First responder: current on-call engineer
Mitigation: disable new provisioning, preserve existing workspaces
Rollback: redeploy previous approved revision
Escalation: product owner decides on customer communication and exceptions

The target value is deliberately absent. A copied 99.9 percent target is not an SLO. The product's actual promise, traffic pattern, and failure mode should set it. A report generator may tolerate a slower recovery than a provisioning flow. A payment action may require stricter controls than an internal admin page.

The Google SRE Workbook goes further and recommends an error-budget policy that says what changes when the budget is exhausted. That is the missing piece in many startups. They measure outages, discuss them afterward, then release at the same pace because the calendar says so. A written policy removes the argument during the worst possible moment.

For a small team, the policy can be simple: when customer-facing reliability exceeds the agreed failure allowance, pause nonessential production changes. Fix the cause, document the failure, and make the condition for resuming releases explicit. Security fixes and urgent restoration work remain exceptions, but somebody names them as exceptions.

Output measures had to describe delivery, not activity

Headcount reduction creates an incentive to report busy people as success. That is how teams end up celebrating hundreds of generated pull requests while customers wait for a broken workflow to be repaired.

We measured output through the delivery path. The measures should fit the product, but they must expose whether the smaller team is actually delivering and operating safely.

Use a compact scorecard:

• Customer-visible availability and failed critical actions.
• Time from an approved change to safe production release.
• Change failure rate, including releases that need rollback or urgent repair.
• Time to detect and restore a user-impacting failure.
• Open support issues that require engineering action.

None of these measures tells the full story alone. Faster releases can hide more failures. Better uptime can hide frozen product development. A small support backlog can hide a team that closes reports without solving root causes. Read the measures together, and inspect a sample of the work behind them.

The phrase "keeping output" also needs discipline. It does not mean producing the same number of tickets or hours of coding. It means continuing to deliver the product changes, fixes, and operational responses that customers depend on. If a 25-person team spent half its time on internal coordination, replacing that activity with AI should make the ticket count fall. That is not a loss.

I would rather see a smaller team release fewer, better-defined changes with fast rollback than release a constant stream of uncertain patches. Delivery speed without recoverability is borrowed time.

The failure mode is usually hidden work returning through the side door

The first dangerous period comes after the organization believes the transformation is complete. The visible workload has fallen, AI handles common tasks, and the remaining engineers appear unusually productive. Then a hard request arrives: an unusual enterprise requirement, a data repair, an integration with undocumented behavior, or an incident that crosses several services.

If the organization removed people but did not retain the necessary knowledge, the hard request drags hidden work back into the system. The two engineers now have to reconstruct history, negotiate tradeoffs, talk to customers, repair production, and keep the normal release path moving. That is where smaller teams fail.

We handled this by treating knowledge capture as production work. Every recurring manual intervention had to leave behind one of three things: automation, a runbook, or a decision record. If none of those existed after the second occurrence, we had not fixed the work. We had merely survived it twice.

A good runbook is not an essay. It should identify the triggering symptom, the customer impact, checks that distinguish likely causes, safe mitigations, rollback limits, and the person who can make a business exception. If it cannot help an on-call engineer during an incident, it is documentation theater.

The same rule applies to AI prompts and agent workflows. Do not preserve a magical prompt that only one engineer understands. Preserve the assumptions, repository boundaries, test command, prohibited changes, expected output, and review criteria. Then another engineer can reproduce the result or find the flaw.

There is another failure mode worth naming: a small team begins trusting generated changes because the last twenty were fine. This is a normal human response to repeated success. It is also how review standards decay. Keep review proportional to blast radius, not to recent luck.

Human judgment became more visible, not less

The smaller the team, the more obvious it becomes that judgment is a separate form of work. It does not vanish into a prompt, and it does not become easier because code appears faster.

An engineer still has to decide which customer pain deserves interruption of planned work. A technical leader still has to say no to a feature that adds permanent operational burden. Someone must decide whether a revenue opportunity justifies an exception to an otherwise clean product rule. During an incident, a human must choose how much information to share, whether to disable a feature, and whether preserving data matters more than immediate recovery.

These are not edge cases. They are the work that determines whether a startup remains coherent while it grows.

AI also cannot resolve conflict between people with competing incentives. Product may want a launch. Sales may want a customer-specific concession. Engineering may see a dangerous migration path. A model can summarize the arguments, list risks, and draft options. It cannot carry the consequences of choosing one.

That is why the transformation required active technical leadership. The team needed someone who could set quality thresholds, decide which complexity was unacceptable, and protect the engineers from becoming a permanent emergency desk. In a founder-led company, this may be the founder. In a growing company, it is often the CTO or a fractional CTO who has authority across product, operations, and engineering.

A smaller operation needs a different management rhythm

Traditional management rhythms assume information moves slowly through a large group. They fill calendars with status meetings, planning rituals, handoffs, and approval chains. Once work becomes visible in repositories, pipelines, incident records, and short decision documents, much of that ceremony becomes waste.

The replacement is not zero communication. It is communication tied to decisions.

A weekly operating review should answer: which customer-facing behaviors degraded, which changes created rework, which work still needs a human queue, and which recurring intervention deserves automation or removal. It should end with named decisions. A dashboard review that produces no change in behavior is just another meeting.

A planning session should limit work in progress. Two engineers can manage a surprising amount of output, but they cannot safely carry ten unrelated initiatives at once. AI makes context switching look cheaper because it can retrieve code quickly. The cost returns when humans must review, integrate, explain, and support all those changes.

The operating model also needs an honest on-call arrangement. If two people are the entire production response, define backups, escalation paths, acceptable response expectations, and periods when neither person is expected to be instantly available. A company cannot claim a healthy small team while depending on uninterrupted personal sacrifice.

This is where an external review can help. A Team & AI Audit should identify the manual work, unclear ownership, unsafe release paths, and hidden coordination that prevent a lean team from operating safely. The point is to find the work you can remove before you make a staffing decision.

The sequence matters more than the headcount headline

The sequence was not "buy AI tools, reduce staff, hope." We first made delivery work observable and bounded. We removed coordination that had no customer value. We automated deterministic checks and gave AI contained execution tasks. We protected production with measurable service objectives, release gates, rollback paths, and a policy for degraded reliability. Then the remaining humans focused on decisions that required judgment.

That order explains how two AI-augmented engineers can carry an operation that previously involved 25 people. The people count changed because the work system changed.

Founders should take a hard look at their own teams before copying the headline. If a request still needs three meetings to become a ticket, if deployments depend on memory, if nobody can name the customer-visible failure signal, or if a critical engineer is the only person who understands production, AI will amplify the disorder before it reduces cost.

Fix the operating model first. Then let AI remove the repetitive work inside it. That is how you cut engineering payroll without quietly cutting the product's ability to keep its promises.