DEV Community: stzifkas

You Are the Bottleneck

stzifkas — Mon, 19 Oct 2026 08:24:53 +0000

AI agents can save developers time. Who gets to spend it?

A developer gives an agent a ticket, goes to make coffee, and comes back to a pull request. Implementation, tests, documentation. The whole little ceremony of software production, compressed into the time it takes the kettle to finish.

Then comes the review.

The agent has misunderstood a permission boundary. The tests confirm its misunderstanding. The implementation works beautifully for a version of the requirement nobody asked for. Somewhere inside four hundred lines of plausible code is a decision the developer now has to reconstruct.

This is a hypothetical morning. It is also a useful place to begin thinking about what agents do to development, because the productivity conversation tends to stop just before it.

The code appeared. The developer was still needed. What happened to the time?

In the August 2026 version of Artificial Intelligence in the Firm, Fiona Chen and James Stratton examine 300 million work events across 718 firms. Agent adoption increases lines of code by about 30%, while estimated changes in finished software output are statistically insignificant. Average pull-request review time rises by 49%. This is observational working-paper evidence, dependent on assumptions about adoption timing, rather than a verdict on every agent or team.

Demirer, Musolff and Yang find a related pattern in Writing Code vs. Shipping Code: gains diminish as measurement moves downstream towards released software. Their account of the research emphasises complementary stages of production.

There is a reasonably simple way to think about this. Suppose finished work requires both generation and verification:

Q = min (G, \frac{H}{h})

Here, $G$ is the number of candidate changes generated per day, $H$ is the developer-hours available for verification, and $h$ is the verification time each change requires. $Q$ is the number of changes that can actually be completed. Assume comparable changes and fixed requirements; this is an illustrative model, not the papers' estimated specification.

If agents generate a hundred changes and developers can verify twenty, output is capped at twenty. Doubling generation gives you a larger queue. If the additional changes are harder to understand, verification time rises and completed output can fall.

There are plenty of engineering responses. Smaller changes. Better specifications. Better tests. Agents that check their work more effectively. Some teams will find substantial gains through exactly these improvements.

But the equation also leaves something out: who decides how much human attention the system is entitled to consume.

Calling a developer a bottleneck is a perfectly legitimate description of throughput. It becomes a different kind of statement when the proposed solution is that the developer must supervise more concurrent tasks, switch contexts faster, and sign off on more work in the same afternoon.

The bottleneck is where human judgment still takes time. A production system organised around increasing throughput will experience that time as a constraint. The developer experiences it as the time required to understand what they are being asked to approve.

Both descriptions can be accurate. They carry very different priorities.

An agent can therefore make coding easier while making the job more demanding. There may be less time spent implementing a solution and more time spent reconstructing someone else's solution, except the someone else can generate another one before you finish reading the first.

Responsibility survives the automation. The failed migration still belongs to a team. The permission bug still wakes a person. The agent's confidence does not take the incident call.

This is one possible reorganisation of development: a smaller amount of direct implementation supporting a larger volume of supervision, with developers carrying responsibility for decisions they had less opportunity to form.

The papers establish a narrower empirical pattern. This account of its possible consequences is an interpretation, and the distinction matters. A review bottleneck does not by itself demonstrate intensified work, deteriorating autonomy, or declining pay. Those require their own evidence.

Still, it gives us a better question to investigate than whether the agent writes good code.

What happens to the developer's control over the working day?

Suppose the engineering problems get solved. Agents become reliable. Review gets easier. The same useful software can genuinely be delivered with fewer developer-hours, after accounting for inference, integration, maintenance and failures.

At this point the technical success is real. The distribution of its benefits remains open.

A team could work fewer hours for the same pay. It could keep its hours and tackle a useful backlog. It could finally spend time on accessibility, maintenance and the awkward architectural repair that never survives planning.

The company could also reduce headcount, leave vacancies unfilled, or raise delivery expectations until the saved time disappears into a new baseline.

These possibilities do not require different models. They require different decisions about the use of the models.

We can make that separation explicit. Let $S$ be the net economic gain from adoption over some period, after its costs. In a deliberately simplified accounting exercise, divide it between developers and owners:

B_{d} = βS, B_{o} = (1 - β) S

$B_{d}$ is the benefit reaching developers through compensation or paid time released; $B_{o}$ is the benefit retained by owners. The parameter $β$ , between zero and one, records the division. We are holding customer benefits and other claimants outside this small example.

This is bookkeeping, not an estimated law. Its usefulness is that it makes a missing variable visible.

A benchmark can help us understand whether a system might increase $S$ . It says nothing by itself about $β$ .

The division depends on contracts, bargaining power, ownership, hiring conditions and developers' ability to influence how work is organised. Technical indispensability may strengthen that influence. It does not automatically turn into authority over staffing, deadlines or compensation.

You can be essential to approving the output and have very little say over how much output arrives.

The same separation appears at a larger scale in Korinek and colleagues' September 2026 working paper, Economic Scenarios for Transformative AI. Its extreme scenario combines rapid growth with a fall in labour's income share from roughly 60% to 45%. These are conditional outcomes from an Anthropic Institute model, not forecasts of developers' salaries.

The point worth carrying back to software is the distinction between producing more and receiving more.

An expanding company can afford better conditions. Affordability does not decide whether it provides them. That decision runs through institutions and competing claims on the additional income.

There is another reason developers should pay attention to this, even when the tools feel empowering.

Software expertise lives partly in individuals and partly in a shared working environment: code, documentation, conventions, review discussions, remembered failures. An agent connected to that environment can make parts of its knowledge easier to reuse. Decisions that once required a conversation with a particular developer may become available through a system.

That can be useful. It can reduce tedious repetition and let more people contribute.

It can also change who controls access to the team's accumulated knowledge. A developer's skill remains theirs. The repository, internal records, agent configuration and permission to deploy the resulting system may belong to the company. The model itself may be accessed through infrastructure controlled by another company again.

The ability to use a powerful tool during employment is a particular kind of access. Whether developers can retain that access, change its terms, take their contributions elsewhere, or participate in deciding its purpose are separate questions.

This is why the cheerful image of every developer becoming a manager of agents feels incomplete. Giving someone ten automated implementers expands their capacity to execute. It does not necessarily give them authority to choose the product, refuse a deadline, control the budget, or decide what happens to the additional revenue.

They may get a larger span of responsibility inside the same employment relationship.

None of this requires rejecting the tools. There are tasks developers would gladly stop doing, and good reasons to want software to become cheaper and easier to build. A credible argument for better working conditions should take those gains seriously.

It should also ask what changes developers can actually observe.

Has paid working time fallen? Has compensation improved? Is there room to maintain the system properly? Can the team limit incoming work when verification capacity is exhausted? Can developers challenge an adoption decision whose costs are being hidden in their evenings?

Those are concrete measures of whether saved time has become a benefit to the people doing the development.

The pull request is ready when the kettle finishes. That is an impressive technical achievement.

Whether the developer gets to drink the coffee depends on who controls the schedule.

Cover: Adolph Menzel, The Iron Rolling Mill (Modern Cyclopes), 1872–1875. Alte Nationalgalerie, Berlin. Public domain, via Wikimedia Commons.

Originally published on Fire Walk With Middleware.

Pluto-ecss: A transpiler and runtime for PLUTO procedure language

stzifkas — Sat, 30 May 2026 11:22:34 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

pluto-ecss is a transpiler and
runtime for PLUTO — the procedure language standardised by ECSS
(ECSS-E-ST-70-32C)
for spacecraft testing and operations. It's the DSL ground operators write to
bring up a star tracker, run a parallel safety sequence, or react to an on-board
event.

You hand it a PLUTO procedure and it gives you back readable, runnable Python
— plus a small runtime library, a CLI, a live TUI, and a browser playground.

$ pluto-ecss run examples/01_original.pluto
[ACTIVITY] Switch on Star Tracker2
[ACTIVITY] Switch on Reaction Wheel3 of AOC of Satellite
[ACTIVITY] Switch on Star Tracker1

It started life in 2019 as a Google Summer of Code work product: a sample
parser that built a tree from one hard-coded script and "ran" it by walking the
tree. It never grew past that one file, and it sat dormant for nearly seven
years. Finishing it means closing a loop I'd quietly written off — turning a
"sample for a proposal" into something you can actually pip install and use.

Demo

Live playground (no install): https://stzifkas.github.io/pluto-ecss/playground/ — write PLUTO and compile/run it entirely in your browser via Pyodide.
Docs: https://stzifkas.github.io/pluto-ecss/
Repo: https://github.com/stzifkas/pluto-ecss
Install: pip install pluto-ecss

The TUI demo (pluto-ecss demo SCRIPT) lights up a fake satellite as the
procedure executes:

╭──────────────── Procedure: 05_full_bringup.pluto ────────────────╮
│                            EXECUTING                             │
╰──────────────────────────────────────────────────────────────────╯
                     🛰  Satellite (AOC subsystem)
  Component             │        Status
  ─────────────────────┼─────────────────
  Reaction Wheel3       │          ON
  Star Tracker1         │          ON
  Star Tracker2         │          OFF
📡 Activity feed: ▶ Switch on Reaction Wheel3 …   ⚡ Events: declared: boom

The Comeback Story

Before — the 2019 GSoC snapshot (still browsable on the
legacy/gsoc-2019
branch): two .py files, a ~30-line grammar covering five constructs, a
tree-walking interpreter tangled into the parser, zero tests, no CLI, no
packaging — and real bugs (setExecutionSatus typo, super.__init__ with no
parens, types never imported). It ran exactly one script and NameError'd on
anything else.

After — main today: a proper transpiler (PLUTO → parse tree → readable
Python), a standalone runtime, and a real toolchain.

	2019	2026
Grammar	~30 lines	168 lines
Tests	0	164 passing
Examples	1	16
Package LOC	~600	~3,600
CLI	none	`parse / compile / run / demo / fmt / gen`
Runtimes	inline tree walker	threaded + asyncio
Output formats	side effects only	Python (sync / async / class / no-runtime) + JSON
Docs	one README	mkdocs site + Pygments lexer
Playground	none	browser-based (Pyodide)
ECSS coverage	a handful of constructs	most of Annex A.1 and A.3

What I added/fixed to finish it:

Rebuilt the grammar with proper keyword-priority handling (the old one used brittle negative-lookahead patterns that broke on common words).
Replaced the interpreter with a transpiler that emits self-contained Python.
Implemented most of the ECSS spec: steps and sub-bodies (A.1.7), object property requests (A.3.9.8), in the context of … (A.3.9.10), reporting data and save context (A.3.9.5/.25), refer by (A.3.9.26/.27), record/array activity arguments (A.3.9.28), and continuation tests with all seven actions and A.2.5 defaults (A.3.9.33).
Added the everyday language layer (if/case/while/for/repeat, wait until, expressions), a runtime with concurrency primitives, friendly parse errors with file:line:column carets, a CLI, an mkdocs docs site, and the playground.

My Experience with GitHub Copilot

Copilot is genuinely visible in the history — several release commits are
co-authored by it. Where it helped most:

The grammar's keyword-priority resolution. Earley grammars for a DSL full of multi-word identifiers (Star Tracker2, Reaction Wheel3 of AOC of Satellite) are finicky. Copilot helped me reason through lexer priorities and surfaced an Earley lexer-priority bug that would have cost me hours to chase down alone.
The transpiler's parse-tree walker — a lot of repetitive _stmt_* emit methods where Copilot's suggestions removed most of the typing.
The runtime's threading/concurrency primitives (parallel_until_all, wait_for_event, watchdogs) — boilerplate it could draft and I could refine.

The architectural calls were mine — choosing a transpiler over an interpreter,
the src/ layout, the multiple compile targets, the test design. What Copilot
changed most was the psychology of returning to old code: the 2019 version was
full of bugs and missing imports that, back then, felt like cliff-edges. With
Copilot at hand, fixing those and then doing the real spec work felt like one
continuous flow instead of three separate undertakings. That's largely why this
finally got finished.