AI, software delivery, and the team

Are Traditional
Software Teams
a Thing of the Past?

How AI changes the work, the workflow,
and the shape of effective teams.

The problem / the opportunity

The software engineering
process is broken.

The good news?

People and teams

You just got
promoted.

Captain Phillips meme: Look at me. I'm the captain now. — Captain Phillips / Know Your Meme

Audience question

What are we now?PMs? CEOs?
Super Humans?
Useless?

You have access to labor

Your output is
the team's output.

You are the manager now

Labor

Agents on demand, at any hour.

Process

How people and agents work together.

Output

What the whole team ships, verified.

You have access to labor. Your output as an engineer is no longer only the code you write; it is what the people and agents you direct ship, verified and worth having.

The Anthropic Economic Index found 79% of Claude Code conversations were delegation rather than collaboration. The work is shifting from doing to directing and verifying.

Managers figure out the process that gets people working together most effectively. GitHub's Agentic Engineering System calls the modes director, performer, and assessor. Engineers move between directing and assessing more often; we return to that framework later.

Being a manager here does not mean a change in title or an escape from engineering. It means taking responsibility for the work agents do: setting direction, choosing how people and agents coordinate, checking the evidence, and owning what the team ships.

BeamRS / choosing the tools

Same app. New tools.

Beam, 2018

Blazor WebAssembly

ASP.NET Core API

SQL Server

BeamRS, 2026

Rust + Leptos, server-rendered

Axum API

PostgreSQL + Docker

The fully agentic engineering rewrite

Switch to the BeamRS demo or prepared recording and show it working while this slide sets the scene. Beam is the presenter's pun-based social network, started in 2018: users join frequencies, post short rays, and prism other people's rays. BeamRS rebuilds it with the same features in a different stack.

Why rebuild it: the recorded goals were feature parity, safer behavior (no state-changing GET requests), easier deployment, and a demo that works out of the box with seed data. BeamRS is a demo app with an unauthenticated identity model, not production software.

Tool choice one, the product stack: a person chose it and wrote it into the goals as a constraint: "Use a PostgreSQL-backed stack with Axum and Leptos." The agents did not pick the framework; they had to respect it. One Rust codebase renders each page on the server and then brings it to life in the browser (hydration).

Tool choice two, the delivery tools: QRSPI+'s full twelve-step route for every change, local Copilot agent sessions, Copilot code review on every pull request, and a completion audit using a different model. The first parity version was planned, built, and merged on the day the project started.

Keep the thread: we chose tools for the product and tools for the process. The rest of the talk asks whether the work actually used them as chosen, and whether they fit the job. Transition: "It looked right. Let's look closer."

Sources: BeamRS docs/qrspi/2026-10-06-beamrs-parity/goals.md, design.md, and config.md; Beam's README and git history.

BeamRS

The app worked.
It just existed twice.

A good-looking demo is not proof of a correct system.

The thesis

The bottleneck moved
from writing code
to trusting it.

Plausible isn't Proven

The bottleneck moved

If code took no time,
what would still stop
your team shipping?

A three-year dead end / before AI

The Three-Year Rewrite

A great deal of work

Several teams.
More than three years.
A finished application.

No viable outcome

It cost more to run than
it could ever earn.
It was scrapped.

They didn't have a speed problem.

Value, not volume

Output
isn't outcome.

Tasks closed. Pull requests merged. Code generated.
None tells you whether it was worth doing.

Satirical illustration of a museum displaying lines of code, story points, pull requests, and tokens spent as exhibits. — “Museum of Meaningless Metrics” · Gamble Blog

The rewrite, revisited

Four questions
to answer first.

Ask up front

The Three-Year Rewrite

Value: What will it earn or save?

It could never pay for itself

Economics: What will it cost to run?

It cost more to run than it earned

Thin slice: What reaches users early?

Three-plus years to a finished app

Stop rule: What result stops us?

Scrapped only after it was done

With agents, the same dead end arrives faster.

Return to the Three-Year Rewrite. The team didn't fail because they built slowly; they failed because nobody tested whether the work could pay for itself until it was finished. Each row pairs a question with what happened in that story.

Economics: estimate the cost per user or transaction, including agent and model costs, against what it will earn or save. Thin slice: ship something small to production early to find out. Stop rule: agree what result would make the team stop, before sunk cost makes stopping feel impossible.

Unfinished work is inventory: until it reaches users, it is a cost, and agent-written code adds to that pile faster. Every line still has to be reviewed, run, secured, and maintained.

"We measured how much we finished. Nobody measured whether it was worth finishing." Transition: the process has to start with why the work is worth doing, which leads into how our agent workflows evolved.

First agent workflows / RPI → QRSPI → QRSPI+

Building with AI, Good prompts are not enough

Instruction
overload

Important guidance gets lost.

Magic
words

Behavior depends on knowing what to say.

Persuasive
plans

Readable does not mean correct.

RPI means Research, Plan, Implement. QRSPI made questions, design discussion, and structure explicit before implementation. QRSPI+ extends that approach with goals, delivery phases, parallelization, integration, acceptance testing, and replanning. Here's what that looked like in practice: The Relay.

From RPI to QRSPI explains the earlier evolution; QRSPI+ documents the expanded implementation. They are related approaches, not interchangeable names or guarantees of correctness.

Ask whether one person knows exactly what to say to make the agent behave. That is a single point of failure.

Chroma's Context Rot study supports focused context rather than ever-longer prompts. Practitioner context-window budgets are practical heuristics, not universal model limits.

Case Study A / The Relay

A Relay Workflow

Ideator

Planner

Coder

Tester

AI Grades itself

Required coverage

>90%

Reported evidence

83%

Written handoffs shipped features.
The evidence said otherwise.

An evolution of workflows

RPI → QRSPI → QRSPI+

RPI

Research Plan Implement

Understand the code before writing it.

QRSPI

Questions Research Design Structure Plan

Work tree Implement Pull request

QRSPI+

Goals Questions Research Design Phasing Structure Plan

Parallelize Implement Integrate Test PR

Simplified main paths; QRSPI+ also has a quick-fix route.

Read each path left to right; the bent arrow continues on the next row. RPI established a deliberate research-before-code sequence. QRSPI adds explicit questions, factual research, design discussion, and a structure outline before the tactical plan, followed by work-tree organization, implementation, and human pull-request review.

QRSPI+ is a separate implementation extending that approach. Goals capture why the work matters, Phasing defines delivery slices, and Parallelize organizes isolated task work. Implement includes test-first development and per-task reviews. Integrate checks the combined work; Test checks acceptance and includes human code review before creating the pull request.

The QRSPI+ full route is shown, not every error or approval branch. For additional phases, Replan returns to Goals. Integration or acceptance failures can return to implementation. The quick-fix route retains Goals, Questions, Research, Plan, Implement, and Test.

Sources: RPI and QRSPI overview; QRSPI+ pipeline overview. The point is explicit alignment and independent evidence, not that more boxes alone make a workflow better. Next: see Case Study B put the workflow to work on its next release.

Case Study B / QRSPI+ / 2026

A workflow built its next release.

38

Tasks

20

Waves of work

2,083

Passing tests

Scale is context. The important part is what slipped.

Case Study B / what the gates caught

A safeguard vanished in a merge.

Wrong tasks
merged

Integration
missed it

Acceptance
caught it

The fix restored the safeguard.
The next release added a merge-content check.

What evolved

From confidence to evidence.

The Relay

The builder grades itself.

Instructions keep growing.

A report says it passed.

QRSPI+

Independent checks, then a person.

Focused steps, measured budget.

A miss becomes a new check.

What's next

QRSPI+ → what's next

QRSPI+

A fixed route of up to 12 steps, heavy on ceremony.

Reduced complexity

Only the steps
the task needs.

Evaluation

Measured against
a baseline.

Review

A person decides
what ships.

QRSPI+ runs a fixed route of up to 12 steps, with a shorter quick-fix route for small changes. It helped ship real features, but the process is heavy, and every step costs time, tokens, and attention. BeamRS, coming up shortly, shows the cost: every change, even a framework version bump, was configured for all twelve steps, and on the smaller changes steps were quietly skipped. The next step keeps the lessons and drops the ceremony that no longer earns its cost.

Reduced complexity: start with the smallest organization the task needs and add steps, agents, or specialists only when evidence says they help. The Autonomous delivery skill is one example: an orchestrator adapts task boundaries, context, and concurrency as it learns, rather than following a fixed pipeline.

Evaluation: changes to the workflow are tested against a baseline of representative tasks, measuring first-pass acceptance, defects, rework, and time to a usable result. This is hill climbing: observe friction, guess a cause, make one small change, compare against similar work, then keep, revise, or undo. Speed that adds defects or rework is not a gain.

Review: people still decide what ships and what counts as done. Independent checks and human review stay; what changes is how much process wraps around them.

The evals are the hard part: a fixed set of representative tasks and a baseline. Small samples support hypotheses, not fleet-wide statistics. Next: how do we prove a change actually helped?

Evaluate the process

Prove the new process is better.

Past tasks

Baseline
run

Changed
run

Compare
outcomes

Same tasks

Real past work,
not demos.

Many runs

One good run
can be luck.

Outcomes

Acceptance, defects,
rework, cost.

A process change feels better long before anyone shows it is better. Treat the workflow like any other change: test it.

Pick a fixed set of representative tasks from real past work: features, bug fixes, and refactors your team actually shipped. Run them through the current process to set a baseline, then through the changed process. Change one major thing at a time so you know what made the difference.

Agents are non-deterministic, so one run proves little. Run each task several times and compare the spread, not a single best result.

Measure outcomes, not activity: first-pass acceptance, defects found later, integration rework, review effort, time to a usable result, and cost to run. Reject a change that adds speed but increases defects or rework. Small samples support hypotheses, not fleet-wide statistics.

"If you can't show it's better, it's just different." Transition: but tune a process too closely to what is in front of you, and it stops fitting what comes next.

Avoid overfitting

Overfitting the process
to today's problems.

The risk

Every incident adds a rule.

Built around today's model.

Tuned to familiar tasks.

The guard

Retire steps that stop catching.

Re-test when models change.

Hold out tasks you never tune on.

A process tuned to the problems we have today can fail on the problems we'll have tomorrow. Three ways it happens, each with a guard.

Every incident adds a rule: a miss leads to a new step, check, or instruction, and they pile up. The process grows to fight last quarter's failures and brings back instruction overload. Track what each step catches; retire or merge steps that stop catching anything.

Built around today's model: steps and workarounds compensate for the current model's weaknesses. When models improve, those steps become pure cost, and new weaknesses go unchecked. Re-run the evaluation whenever the model or harness changes, and remove workarounds that no longer earn their place.

Tuned to familiar tasks: every tweak that improves the same handful of tasks can make the process worse at everything else. Borrow the train-and-test split from machine learning: keep a held-out set you only run to confirm a change, never to tune it, and rotate in fresh, live work as the codebase and team change. When replaying past work, start from the commit before the fix, so the agent can't find the answer in history. When a measure becomes the target, it stops being a good measure.

"Build the process for the work you'll have, not just the mistakes you've made." Transition: evaluation tells us whether the process improved; review catches what slips through on each change.

BeamRS / choosing tools / local review

Choosing a tool isn't using it.

Stack

Rust UI chosen. Agent wrote 227 lines of JavaScript.

Toolchain

A clean Docker build needed a newer Rust.

Load testing

Built in-house. Real HTTP added when it mattered.

Process

Same 12-step route for a rewrite and a version bump.

Return to BeamRS and the tools chosen on slide 6. Every finding on this slide came from agents in the local workflow; people decided what to do about them.

Stack: the approved design said the browser behavior lives in Rust. The first version rendered a Rust shell on the server, then handed the real browser behavior to about 227 lines of handwritten JavaScript. A completion audit run with a different model caught the mismatch; the design gate was reopened, the JavaScript was deleted, and the behavior moved to Rust (commit "hydrate BeamRS frontend from Rust"). Plausible isn't proven: the app worked, but not in the stack we chose.

Toolchain: during the Leptos upgrade, an independent clean Docker build found that the pinned Rust 1.89 was too old for the locked build tools; it was raised to 1.96. A developer's warm machine hid the gap; a fresh build exposed it.

Load testing: the goal said "add no new third-party dependency," so instead of adopting an outside load-testing tool, the agents built a small harness that drives the app's own router in memory. The design recorded what that leaves out: real networking. The next day, a follow-up added real HTTP. Choose the smallest tool that answers today's question, write down its limits, and upgrade when the limits start to matter.

Process: every BeamRS change, including a framework version bump, was configured for QRSPI+'s full twelve-step route. On smaller changes, steps were quietly skipped, and pull request review flagged the missing integration and replanning records on #4 and #7. A process that is too heavy for the task gets skipped. That is the case for "only the steps the task needs."

Transition: the local workflow caught these. Then the pull request got a second, fresh review. Sources: BeamRS docs/qrspi/ run records (parity phase review, Leptos migration review, load-testing designs and goals).

BeamRS / Leptos upgrade / pull request review

Working locally wasn't enough.

Duplicated UI

Attach to the server-rendered page.

Lost settings

Preserve runtime deployment settings.

Repeated requests

Make one API call per page load.

Missing process

Record integration and replanning.

BeamRS / load testing / pull request review

Success had hidden failure modes.

Memory

A setting could consume enormous memory.

False success

An incomplete response could count as passing.

Cleanup

Workers could outlive a crash or cancellation.

All three fixes added regression tests.

Close the loop

Every finding should
make the next run harder to fool.

Finding

Fix + reply

Regression
test

Better
process

Illustrative use case

The repository becomes a workplace.

Event or
schedule

Bounded
agent

Visible
evidence

This could be GitHub Agentic Workflows.

GitHub Agentic Workflows / Governed Automation

Define authority before execution.

Context

A defined trigger.
A focused task.

Permissions

Read-only by default.
Approved write actions.

Evidence

Issues, comments,
pull requests.

Natural language uncertainty

Imprecise instructions.
Unpredictable execution.

English is the programming language now.

Natural language uncertainty

It's natural language
all the way down.

Harness

A system prompt and tool descriptions.

Skill

A Markdown file of instructions.

Agent

A role described in prose.

Your prompt

One more paragraph on top.

More layers add more interpretation, not more precision.

Natural language uncertainty / an English example

I saw the man with the telescope.

Reading 1

I used the telescope
to see him.

Reading 2

He was the one
holding the telescope.

Implied

He stole
my telescope.

Implied

I already found
someone I was
looking for.

All are plausible. An agent picks one.

A classic ambiguous sentence: the grammar allows both readings, and only context tells you which one the speaker meant. People resolve this with shared context and by asking. An agent picks a reading, often without saying so, and may pick the other one on the next run.

It gets worse with implied information: what the listener fills in that the words never say. "I saw the man with the telescope" can imply he stole my telescope, or that I already found someone I was looking for. Neither is in the sentence; both come from assumed context. Agents fill those gaps too, confidently.

The same thing happens in instructions. "Only run the tests for files you changed" versus "run the tests only for files you changed": does "only" limit which tests, or whether to run anything else? "Make it faster" does not say faster for whom, by how much, or at what cost. Ask the audience for a prompt they wrote that an agent read the other way.

"When English is the programming language, every ambiguity is a bug you haven't found yet."

Natural language uncertainty

Pin intent down with
something precise.

Acceptance tests

Done is something that runs.

Worked examples

Show the reading you meant.

Schemas

Structure a script can check.

Scripts

The same steps every run.

The hard parts / run it like a system

The workflow is software.
Engineer it like software.

Evaluate

Fixed tasks, a baseline, outcome measures.

Limit

Budgets for tokens, time, retries, and cost.

Hand off

Structured artifacts a script can check.

An agent workflow is itself a system that has to be engineered: evaluated, limited, connected, and maintained. These problems remain even when the workflow works.

Evaluate: recap slides 20–21 briefly. Decide what a better run means before changing the workflow. Use a fixed set of representative tasks, a baseline, and outcome measures such as validated delivery time, rework, escaped defects, review effort, and cost. Case Study B filed 15 issues about its own process gaps and turned them into automatic checks in the next release. GitHub describes the same loop for Copilot code review: evaluation against known issues plus production signals.

Limit: agents spend tokens, model requests, time, and money, and can retry or loop without converging. Set budgets per task and per run, cap retries and parallel work, and stop or escalate at the limit. The cost to run the process belongs in the same economics as the cost to run the product. In the Stack Overflow 2026 survey, 38% of respondents said their organizations set limits on AI usage.

Hand off: prose handoffs force the next agent to interpret. Structured artifacts with required sections, task IDs, file lists, and test results can be checked by a script. The Relay passed long written plans forward; Case Study B added an automatic check that every merge contains exactly the planned tasks after a merge silently dropped a security safeguard.

Guard against ourselves

Judge the process by evidence,
not by favorites.

Confirmation bias

We keep what feels better.
We drop what failed once.

Trim the fat

Every step has a cost.
Cut what never catches anything.

GitHub's Agentic Engineering System

A framework that might help

AES

In this talk

Stocks

Governance, knowledge, value

Checks, context, outcomes

Activities

Define, deliver, detect

Goals, build, evaluate & review

Modes

Director, performer, assessor

People or agents, set by risk

GitHub's Agentic Engineering System (AES) is a tool-agnostic framework for scaling agent use. Implementation guidance is in GitHub Well-Architected. It is a vendor framework rather than an empirical study; use it to show that these lessons fit one model.

Stocks accumulate over time. Governance covers the unskippable checks, permissions, and usage limits. Shared knowledge covers focused context and structured handoffs: agents can only act on what they can access, so weak knowledge turns into fast, confident mistakes. Customer value is the value of completed work, not the amount of work completed.

Activities move work through the system: define, deliver, detect. They line up with the loop from earlier: goals, adaptive build, then evaluate and review. Detect feeds what was learned back into governance and shared knowledge, as Case Study B did with its own process gaps.

Modes describe how people and agents take part: director sets intent, performer does the work, assessor checks it. They are not job titles, and the same person or agent can move between them depending on risk and what governance allows.

AES's health check: as agent use grows, escaped defect rates should stay flat or fall, and shared knowledge should improve alongside delivery speed. If they diverge, the operating model needs attention. Return to the opening: directing agents changes responsibilities, but accountability stays. Transition into what that means for careers and teams.

Careers and teams

Responsibilities change.
Accountability stays.

Product & domain

Intent, constraints, value, success criteria.

Engineering

Architecture, decomposition, integration.

Developers

Implement, delegate, debug, inspect.

Team design

More agents need
more decision capacity.

Quality

Design evidence that can disprove success.

Platform

Provide context, workflows, permissions.

Management

Balance agent capacity with human review.

Audience exercise

Add agents to
your org chart.
Where do review arrows go?

The process is a product

This talk used the same loop.

Intent

Start with the abstract and audience.

Research

Check claims against original evidence.

Review

Separate passes for flow and messaging.

Human correction

Decide what is true and what matters.

Measure outcomes, not activity

Did value reach users?

User and business outcomes

Earned or saved value

Cost to run

Validated delivery time

Review, rework, late defects

≠

Activity signals

Tasks closed

Pull requests merged

Story points

Lines generated

Return to the opening

How would your team
have known?

That it was correct.
That it was worth building.

The answer

Traditional teams
aren't a thing of the past.
Teams that only
write code are.

Acknowledgments

Special thanks

Daniel Frysinger

For his work on QRSPI+ and agent workflows.

Trash Pandas team

For their feedback.

Evan Boyle

For written research on adaptive agent delivery.

Alex Lavaee

For “From RPI to QRSPI” and its research on evolving agent workflows.

Discussion

Questions?

Plausible isn't proven.

Appendix / source trail

Follow the evidence.

Talk outline & research links

Complete source list and case caveats

BeamRS: upgrade review

Duplicated UI, settings, requests, process

BeamRS: load-testing review

Memory, false success, worker cleanup

QRSPI+: release run

Tasks, gates, and acceptance evidence

From RPI to QRSPI

Why the workflow evolved

GitHub Agentic Workflows

Repository automation and authority

Are TraditionalSoftware Teamsa Thing of the Past?

The software engineeringprocess is broken.

You just gotpromoted.

What are we now?PMs? CEOs?Super Humans?Useless?

Your output isthe team's output.

Same app. New tools.

Beam, 2018

BeamRS, 2026

The app worked.It just existed twice.

The bottleneck movedfrom writing codeto trusting it.

If code took no time,what would still stopyour team shipping?

The Three-Year Rewrite

A great deal of work

No viable outcome

Outputisn't outcome.

Four questionsto answer first.

Building with AI, Good prompts are not enough

Instructionoverload

Magicwords

Persuasiveplans

A Relay Workflow

AI Grades itself

RPI → QRSPI → QRSPI+

RPI

QRSPI

QRSPI+

A workflow built its next release.

A safeguard vanished in a merge.

From confidence to evidence.

The Relay

QRSPI+

QRSPI+ → what's next

QRSPI+

Next

Reduced complexity

Evaluation

Review

Prove the new process is better.

Same tasks

Many runs

Outcomes

Overfitting the processto today's problems.

The risk

The guard

Choosing a tool isn't using it.

Working locally wasn't enough.

Success had hidden failure modes.

Every finding shouldmake the next run harder to fool.

The repository becomes a workplace.

Define authority before execution.

Context

Permissions

Evidence

Imprecise instructions.Unpredictable execution.

It's natural languageall the way down.

I saw the man with the telescope.

Reading 1

Reading 2

Implied

Implied

Pin intent down withsomething precise.

The workflow is software.Engineer it like software.

Judge the process by evidence,not by favorites.

Confirmation bias

Trim the fat

A framework that might help

Responsibilities change.Accountability stays.

More agents needmore decision capacity.

Add agents toyour org chart.Where do review arrows go?

This talk used the same loop.

Did value reach users?

How would your teamhave known?

Traditional teamsaren't a thing of the past.Teams that onlywrite code are.

Special thanks

Daniel Frysinger

Trash Pandas team

Evan Boyle

Alex Lavaee

Questions?

Follow the evidence.

Are Traditional
Software Teams
a Thing of the Past?

The software engineering
process is broken.

You just got
promoted.

What are we now?PMs? CEOs?
Super Humans?
Useless?

Your output is
the team's output.

The app worked.
It just existed twice.

The bottleneck moved
from writing code
to trusting it.

If code took no time,
what would still stop
your team shipping?

Output
isn't outcome.

Four questions
to answer first.

Instruction
overload

Magic
words

Persuasive
plans

Overfitting the process
to today's problems.

Every finding should
make the next run harder to fool.

Imprecise instructions.
Unpredictable execution.

It's natural language
all the way down.

Pin intent down with
something precise.

The workflow is software.
Engineer it like software.

Judge the process by evidence,
not by favorites.

Responsibilities change.
Accountability stays.

More agents need
more decision capacity.

Add agents to
your org chart.
Where do review arrows go?

How would your team
have known?

Traditional teams
aren't a thing of the past.
Teams that only
write code are.