Loading today’s stories
Leadership1 distinct publisher3 min readPublished
Debugging, code review and abstractions that failed under load were the reps that produced engineering judgment. If agents absorb them, someone has to put those reps back on the calendar on purpose.
The Board Room · Leadership desk
Compiled by The Board RoomSomething wrong?How this is made
Follow any of these and your For You feed starts watching them — no settings page required.
build
JetBrains asked 15,000 developers how much code agents write. The answers add up to 112 percent1 distinct publisher
build
Allow-list the closed set, block-list the open one: 193 thin geo pages, one gate1 distinct publisher
build
Rust's from_str waves through a tenth of the JSON that RFC 8259 says to reject1 distinct publisher
product
AI writes the Dockerfile, and the pipeline is still checking the app code1 distinct publisher
A rep, in this essay's account, has a specific shape. You form a hypothesis about how something will work, you try it, and reality contradicts you in a way you can trace [5][6]. That is why the advice it offers a newcomer is so mechanical: hypothesise before prompting, ask why often, read the diffs, predict what might fail, and occasionally work the problem manually [6]. None of those steps ships anything faster. Each produces a record of having been wrong on purpose, which is the only raw material the essay credits for judgment.
The tradeoff is worth naming rather than implying. Manufactured reps cost throughput this quarter and buy supervision capacity several years out. The essay says most people never ask a model to teach as it goes, partly because they do not know that is an option and partly because velocity expectations reward shipping and moving on [8]. A junior cannot opt out of a velocity expectation alone. The essay puts the burden on junior engineers being proactive about their own education [10]; on the evidence it presents, the burden sits with whoever sets the sprint.
One common framing is that juniors paired with agents will learn faster because they see more finished, working code. That framing skips over where the essay says its own judgment came from: debugging failures, reviewing other people's code, and living with abstractions that looked good until a real system pushed back [5]. Those require owning a consequence, not observing one. Reading correct output teaches what correct looks like, but not why the plausible alternative fails in month nine.
Every prior abstraction removed reps too, and seniors still emerged from each round. What's different is what the next cohort is being asked to do. The four skills the essay names for practice are decision making, specifying, steering and verifying [3], and by inspection none of them is the writing of code [11]. Supervision is the job description. The essay's warning is about timing rather than capability: three years in, plausible code may arrive faster than the ability to judge it [4]. Earlier abstractions did not imitate the output of the judgment they displaced, which is what makes this gap hard to see from a status report.
The honest limit here is the evidence. This is one practitioner's account, experiential, with no measurement of whether deliberately staged reps build the same taste as accidental ones, and no cohort data on how long the gap takes to show up in review quality. We do not know yet. What the record does support is that a completed task is not automatically a rep [9], which means throughput dashboards cannot tell you whether learning happened.
That argues for something small and reversible rather than a policy: a defined fraction of the week where work is done manually, picked because the code is instructive rather than because it is urgent, is cheap to run and cheap to stop. The cost lands this quarter, in visible output, while the consequence of skipping it lands later, in whichever quarter someone first needs to reject confident agent output for a reason they can articulate.
Ranked by verification strength, evidence, and original report placement.
An essay on agentic skill decay argues that mastery still comes from doing the reps, and that before agents those reps came as part of writing code: trying different approaches, debugging what went wrong, reviewing others' code and reading a lot. Agents can skip much of that work, so building reps has to be deliberate.
The author writes that most of the judgment used today came from thousands of small reps: debugging failures, reviewing other people's code, and living with abstractions that looked good until a real system pushed back, and that agents can now skip much of that work.
The essay states that good agent work depends on two abilities: deep expertise, meaning understanding the problem domain (and user, product and business) well enough to define a good outcome; and applied judgment, meaning using taste to turn that into a clear, testable plan by choosing the right context, constraints, tests and verification.
To build those abilities, the essay says the skills it would practise are decision making, specifying, steering and verifying.
The essay states: "If you're three years into your career, plausible code may arrive faster than your ability to judge it."
For someone new to the industry, the essay advises forming a hypothesis before prompting, asking why a lot, reading the diffs, trying to predict what might fail, and occasionally working through the problem manually.
Distinct publishers with included, body-backed reporting in this cluster.
1 article · September 1, 2026
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
A memoir asked to do a study's job
The strongest parts of this story are the parts that only need internal consistency: the definitions, the four-skill list, and the observation that a closed ticket teaches nothing. The moment it makes a claim about the world — that many AI labs deliberately optimise for the fast answer over the learner — it rests on conversations the author neither names nor dates, and on addyo.substack.com alone. No cohort, no review data, no before-and-after; the causal spine of the argument is one engineer's recollection of how he became good.
No usage signal in view
Nothing here can be counted. There is no release, no rollout, no benchmark and no disclosure of how many engineers actually work this way — the essay describes one person's practice and recommends it, and our coverage contains nothing that would tell you whether anyone adopted it.
Diagnosis a step ahead of the demonstration
The prose is careful — 'in my experience', 'I think', 'may arrive faster' — and it sells nothing, which keeps the gap small. What tips it positive is the confident causal shape: skill decay is treated as underway and attributed to agents, when the only support offered is that the author learned differently. The reps-and-reflection prescription is modest enough to be roughly the right size for its evidence.
Nothing on sale but standing
No tool is recommended, no employer is named, no vendor is thanked. What the format does reward is resonance: this is a personal newsletter, and a thesis that flatters experienced engineers while warning juniors is the kind that circulates. The author also discloses talking to AI labs and then criticises their priorities without naming them — a mild conflict left unresolved on the page rather than a hidden one.
Plausible, coherent, unchecked
We can be confident about what the essay says and how it reasons; we cannot corroborate any of it. One publisher, one post, no second account, and the two claims about the wider world are the two least verifiable. The internal logic is tight enough that the argument would survive scrutiny — but scrutiny has not happened yet.