DEV Community: dqj

The Bottleneck Moved: Why a Team Topology Cannot Absorb AI

dqj — Sat, 14 Nov 2026 03:55:46 +0000

SAFe's cross-functional team was built on a forty-year constraint. AI removed the constraint and left the org chart holding the bottleneck.

Every scaled agile framework rests on a single organizational axiom: the cross-functional team is the atom of value delivery. SAFe 6.0 calls it an Agile Team, sizes it at five to eleven people, and gives it a Program Increment of eight to twelve weeks to plan against. Everything else in the framework — the ceremonies, the roles, the planning board, the dependency red lines — is scaffolding erected around that atom.

The axiom is not stupid. It was derived from a hard constraint that held for roughly forty years: no single engineer could simultaneously hold deep frontend craft, a distributed backend, serious quality engineering, and cloud-native operations. Breadth that large did not exist in one head, so the work had to be distributed across several heads, and once work is distributed across heads you need an interface layer. Standups, sprint planning, backlog refinement, estimation poker — these are not rituals in the religious sense. They are the protocol that lets a group of partially-informed people coordinate without sharing a brain.

Then the constraint that justified the protocol went away, and the protocol stayed.

This series is about what happens next. The argument is not that teams are obsolete, or that agile was a mistake, or that everything must be rebuilt on Monday. It is narrower and more uncomfortable: the unit that AI most directly attacks is the unit the entire framework is built on. When synthesis becomes nearly free, the scarce input moves from producing the change to judging it, and a structure whose every component is priced by the person-hour cannot absorb a resource that is priced at zero.

What AI actually changed

Most enterprise AI programs measure the wrong thing, so start with the cost structure.

Three costs matter in software delivery, and they did not move together.

Synthesis. Writing code, writing the tests around it, scaffolding a service, producing three alternative implementations of the same interface. This cost collapsed. Not to zero — models still need context, and context is expensive to assemble — but the marginal cost of one more candidate implementation is now low enough that "try three approaches" is a reasonable engineering move rather than a budget request.

Context assembly. Getting the right repository, the right conventions, the right failure history, the right business rule into the model's window. This cost fell, but far less than the first one, and it falls unevenly: it is cheap for a well-instrumented codebase and brutal for a system whose rules live in six people's heads.

Verification. Deciding whether a candidate is correct, safe, and within the boundaries the organization actually cares about. This cost barely moved. In some organizations it rose, because the volume of candidates arriving at the review gate went up while the gate itself stayed the same size.

A delivery system is governed by its most expensive term. For forty years that was synthesis, and the team topology was optimized for it: many hands, shared context, tight synchronization. The most expensive term is now verification and judgment, and almost no scaled framework has a structure for it.

Bottleneck displacement, and the capacity that isn't

Here is the first structural failure, and it is arithmetic rather than cultural.

The old constraint was the capacity to produce code and unit tests. Organizations encoded that constraint into the planning system: capacity is measured in person-days, the PI is forecast from team velocity, and the roadmap is a queue of work sized against both.

If you add a zero-marginal-cost synthesis engine but keep planning by team capacity, you do not remove the bottleneck. You move it downstream and then fund the wrong side of the move. Teams generate more change per unit time; the review queue, the integration environment, the cross-team dependency, and the release gate do not. The organization experiences a rise in local output and a rise in global work-in-process, and it reads the first number as progress.

It is not progress. In a system with a fixed downstream gate, extra upstream output is inventory. It sits in a branch, in a review queue, in a staging environment, waiting for the same number of human adjudicators it waited for before. The only thing the AI bought was a longer queue and a stronger feeling of momentum.

The tell is in the metric itself. A capacity plan that measures generation is measuring the term that just became free. When a constraint moves, every plan, estimate, and dashboard still pointed at the old constraint becomes an instrument for producing confident wrong answers.

The velocity illusion

The second failure follows from the first, and it corrupts the framework's forecasting layer rather than its execution layer.

Story points and lines of code inflate quickly under AI assistance. That is not fraud; the work genuinely feels larger, because more artifacts exist. But the gates downstream — architecture review, cross-team environment integration, test gates, the security review nobody scheduled — are still on human calendars with human throughput.

Put the two facts together and you get a system where individual generation is fast and organizational integration is slow. Raise the arrival rate at a fixed-throughput queue and work-in-process grows without bound, and by Little's law, cycle time grows with it.

cycle time = work in process / throughput

Throughput at the gate did not change. Work in process tripled. The organization now reports "we are shipping faster than ever" and "nothing gets through review" in the same retrospective, and both are true, because they describe two different layers of the same pipeline.

The deeper damage is to the forecast. PI planning is a prediction built on points, and points are a proxy for effort. If the proxy now measures generation instead of delivery, the PI is forecasting the wrong variable — precisely and at scale, which is worse than forecasting badly. A framework that plans an eight-to-twelve-week increment on inflated points is not aligning the organization to reality; it is aligning the organization to the part of the work that got cheap.

The cognitive cost of synchronization

The third failure is the one engineers feel first and defend worst, because criticizing a standup sounds like defending isolation.

Synchronization was a technology for a world where context transfer was expensive. A fifteen-minute standup across twelve people costs three person-hours a day. A two-week estimation session costs twenty-four person-hours per team per sprint. A two-day PI planning event for a hundred people costs two hundred person-days per increment. These numbers were rational when the alternative was a week of misalignment discovered at integration.

They stop being rational when one senior engineer, working inside a sandbox with the repository and the tests, can validate three competing architecture options in a single hour. At that point the information payload of the standup — what I did, what I will do, what blocks me — is generated faster than it can be spoken, and the meeting becomes the slowest component in the loop. Worse than slow: it fragments the flow state that makes the hour of parallel exploration possible in the first place.

This is not an argument for abolishing human contact. It is an argument about what the ceremony was buying. It was buying context transfer at a moment when context transfer was the binding cost. That is no longer the binding cost, and a protocol that is priced per person-hour to move information that is now nearly free is not a control system. It is a tax on the exact capability the organization is trying to acquire.

Where the constraint sits

The whole shift fits in five lines.

Unit of work — then: a five-to-eleven-person team. Now: one engineer plus a platform.
Scarce input — then: code and test authoring. Now: contextual judgment.
Planning signal — then: team capacity in person-days. Now: irreversible boundary decisions.
Coordination cost — then: one meeting per transfer. Now: one verification per decision.
Failure mode — then: slow delivery. Now: fast generation, slow merge.

Read the last two lines together, because they explain each other. Coordination was cheap relative to synthesis, so organizations coordinated more. Now verification is the scarce act, so the cost of a decision is the cost of proving it — and the structure that used to prove things by putting twelve people in a room is not the structure that proves things fastest.

What the incrementalist move actually is

SAFe's answer so far is to keep the container and swap the motor. Teams become "AI-Empowered" or "AI-Native"; the model is added as a tool, or in the stronger version, as a synthetic team member. The shell — five to eleven people, two-week cadence, PI planning, the dependency board — stays exactly as it was.

Two things are wrong with this, and neither is about culture or change management.

The first is that every component of the container is a function of headcount, not of throughput. A standup that fits in fifteen minutes fits because twelve people speak briefly. A PI that fits in two days fits because a hundred people can be in one room. Add a zero-marginal-cost generator to a system whose interfaces are all sized by the number of humans and you have not increased the system's throughput; you have increased the load on its interfaces.

The second is authority. The team still owns delivery, so the individual never receives authority proportional to their new capability. You have increased the supply of decisions without changing who is allowed to make them. The engineer can now generate and evaluate three designs in an hour, and still cannot commit to one without a refinement session, because the unit of accountability never moved. What you get is a very fast producer inside an unchanged approval structure — which is exactly the configuration that produces the queue described above.

None of this makes the incrementalist step irrational. Adding AI inside a two-week sprint, with a private gateway and a security baseline, is the correct move at the bottom of a maturity ladder; most organizations that skipped it are worse off. It is simply not a destination, and frameworks are treating it as one.

What the team still buys

A critique that concedes nothing is not worth reading. The team is not only a coordination protocol, and pretending otherwise would be dishonest.

A team buys fault isolation, so one person's bad week does not take down a service. It buys on-call rotation, redundancy of knowledge, a hiring surface, psychological safety for junior engineers, and the informal learning that happens when two people look at the same problem. All of that is real, and none of it is delivered by a model.

But the word "team" is currently doing three jobs at once, and separating them dissolves most of the argument:

The unit of delivery — what actually produces a change end to end. AI attacks this directly.
The unit of accountability — who owns the outcome when it fails at 3 a.m. This should be as small as it can be made, because accountability dilutes with size.
The unit of coordination — how context, constraints, and standards reach the person doing the work. This does not have to be a meeting. It can be a platform.

The team topology collapses all three into one object, sized for the era when all three were expensive. AI makes the first cheap, demands the second shrink, and turns the third into a platform problem. A structure that insists they remain the same size is not preserving safety. It is preserving the queue.

The question this forces

If the atomic unit of delivery is a single engineer carrying end-to-end responsibility, the immediate question is not "how do we motivate them". It is: what has to be true for that to be safe?

Three things, and none of them can be supplied by the engineer alone.

Someone has to own the business intent and the semantic boundary — what the thing must mean, what the acceptance gate is — and must be structurally forbidden from decomposing the work into micro-tasks. Someone has to hold the global technical context and the governance constraints, and must not be the person who writes the performance review, or the engineer will optimize for the reviewer instead of the system. Someone has to own the human-AI practice itself: pairing, context engineering, hallucination control, and the conversion of every incident into a deterministic rule so the same failure cannot recur.

Those are not team roles. They are roles around a cell, and the cell is one engineer with the authority to decide. That is the shape ANTcell proposes, and it is where Part 2 goes: the three-role decoupling, the physical separation that makes it more than a relabeling, and the reason a single engineer can hold accountability that a team of nine currently cannot.

Part 3 takes the timing question — why a twelve-week PI and a sixty-minute pipeline are not in conflict but are the two halves of one control system. Part 4 is the part enterprises will actually use: the four-level maturity path, and why skipping levels fails in a predictable way.

The takeaway

The failure of AI adoption inside scaled agile is usually described as a culture problem, an adoption problem, or a skills problem. It is none of those first. It is a unit-of-accountability mismatch.

You cannot bolt a zero-marginal-cost synthesis engine onto a coordination structure whose every component is priced by the hour, keep the same approval topology, and call the result a transformation. What you get is more inventory, an inflated forecast, and a meeting schedule that costs more than the information it moves. The bottleneck moved. The org chart did not.

Part 1 of 4 in AI-Native, Deconstructed: From SAFe Incrementalism to the ANTcell Rewrite.

Running a high-end bakery in the age of industrialized code

dqj — Wed, 28 Jan 2026 14:16:03 +0000

When considering productivity, this analogy always comes to mind:
High-end bakeries vs. industrial bread factories.
High-end bakeries produce bread of superior quality. They are meticulous, skillfully crafted, expensive—and serve a relatively small customer base.
Factory bread, on the other hand, mass-produces "good enough" bread.

As artificial intelligence begins to generate massive amounts of production code in an industrialized manner, I can't help but wonder if the software industry is heading in a similar direction.

When AI can generate code that passes most code reviews in seconds, and most users won't even notice the difference, what does it mean that we spend ten times as much time writing elegant code?

Software engineers may be in a worse position than high-end bakeries.
Will anyone pay ten times more for your software simply because they appreciate its beautiful code?

I genuinely want to understand in what areas human effort can still create significant value, and in what areas might this effort quietly lose its due reward.

The full story on Medium

The Regression Bug Was the Most Important Result

dqj — Tue, 13 Jan 2026 09:55:20 +0000

The Feature Wasn’t the Point

Two AI systems successfully implemented the requested UI feature.

That part wasn’t interesting.

What mattered was what broke outside the requested scope.

The Regression

After the change:

Select text in the editor

Trigger the “Replace with” contextual action

Nothing happened.

No error.
No exception.
Just silent failure.

This is the most dangerous class of bug in production software.

Why This Happens with AI-Generated Code

From an engineering perspective, this failure is predictable:

The prompt emphasized new functionality

Existing behavior was implicit, not asserted

No test explicitly protected that interaction

AI systems optimize for local correctness,
not global behavioral invariants.

Where the Implementations Differed

A closer look at the code revealed meaningful trade-offs:

One approach prioritized UX richness and localization

The other emphasized modular helpers, safer selectors, and test coverage

A concrete example:

encodeURIComponent(...) vs CSS.escape(...)

Both work, but only one is designed for DOM and selector safety.

These choices matter months later, not minutes after generation.

Why Unit Tests Made the Difference

Only one implementation introduced unit tests covering:

State migration

Regex escaping

Replacement logic edge cases

Those tests didn’t just validate correctness —
they made the regression visible.

Without them, the bug would likely ship.

Takeaway

If you evaluate AI coding tools in real projects, ask:

What existing behavior is protected?

What assumptions remain implicit?

What breaks quietly?

Demos won’t answer those questions.
Production code will.

Final Thought

The most valuable result wasn’t the feature.

It was identifying where AI coding systems still fail like junior engineers —
and where they don’t.

That distinction is what matters in real-world software.

Why WebAuthn Feels Easy — Until You Try to Ship It

dqj — Thu, 08 Jan 2026 13:14:04 +0000

Every WebAuthn demo works. Production is where things quietly fall apart.

WebAuthn demos are dangerously convincing.

You follow a tutorial, register a passkey, authenticate successfully, and everything feels… solved.

No passwords. No OTPs. No friction.

Then you ship it.

And suddenly:

Users authenticate when they shouldn’t
Counters behave strangely
Different browsers disagree
Enterprise customers ask questions your demo never prepared you for

This gap — between “it works” and “it survives production” — is where most WebAuthn implementations fail.

After watching teams repeat the same mistakes for years, three gaps show up again and again.

Gap #1: Demo-Grade Database Access

Most WebAuthn demos include some version of this:

async function getUser(username) {
  const query = `SELECT * FROM users WHERE username = '${username}'`;
  return db.query(query);
}

It works in development.

It works in testing.

It even works in staging.

Until a real username contains a quote — or someone decides to try ' OR '1'='1.

This isn’t a WebAuthn problem.

It’s a production engineering problem that demos ignore.

Production systems parameterize everything, including dynamic IN clauses:

function buildInClause(values) {
  if (!Array.isArray(values) || values.length === 0) {
    return { clause: '(NULL)', params: [] };
  }

  const placeholders = values.map(() => '?').join(',');
  return {
    clause: `(${placeholders})`,
    params: Array.from(values)
  };
}

The difference isn’t elegance — it’s survivability.

Gap #2: “One-Call” Verification Illusions

Demo verification often looks like this:

await fido2.verify(response);

Clean. Minimal. Completely insufficient.

In production, this single call hides multiple attack surfaces:

Replay attacks
Counter rollback (cloned authenticators)
Origin spoofing
Challenge reuse across sessions
Native app origin edge cases

Real verification logic validates every layer:

if (counter <= prevCounter && counterSupported) {
  throw new Error("counter rollback detected");
}

if (origin !== expectedOrigin) {
  throw new Error("origin mismatch");
}

Counters, origins, encoding, challenge binding, RP ID — none of these are optional in production.

If you skip one, authentication still “works” — until it doesn’t.

Gap #3: The Myth of “Single-Domain” WebAuthn

Demos assume:

One RP ID
One domain
One policy

Production environments don’t.

Real systems need to handle:

Multiple subdomains
Wildcard RP IDs
Enterprise authenticator allowlists (AAGUID-based)
Device limits per user
Per-tenant timeouts
Device binding

Configuration stops being a constant and becomes data:

{
  "domain": ".example.com",
  "device_limit": 2,
  "registration_session_timeout": 999
}

This isn’t complexity for complexity’s sake.

It’s the minimum required to support real organizations.

What “Production-Ready” Actually Means

Area	Demo Reality	Production Reality
Database	String queries	Parameterized everywhere
Verification	Single function	Multi-layer validation
Domains	localhost	Wildcards & subdomains
Counters	Ignored	Rollback detection
Policy	Hardcoded	Per-tenant configuration

None of these failures are obvious in demos.

All of them show up after users trust your system.

The Hard Truth About WebAuthn

WebAuthn is easy to demonstrate.

It is hard to operate safely.

The problem isn’t the standard — it’s the illusion that a passing demo equals a shippable system.

If you’re planning to deploy passkeys beyond a prototype, treat demos as educational tools, not architectural references.

Because in authentication, failure rarely looks like an error.

It looks like success — for the wrong user.

I work on WebAuthn systems that need to survive real-world traffic, browsers, and enterprise constraints.

Most of the lessons above came from fixing things that “worked fine” — until they didn’t.