Agentic Engineering Weekly for August 29 to September 5, 2026

Jo Van Eyck

Jo Van Eyck

— 8 min read
Share
Agentic Engineering Weekly for August 29 to September 5, 2026

Multiple model launches took the headlines, none will change how you work on Monday. What might: an engineer shipping 2,000 PRs a month explained their actual method, AWS published what happens when fifty ordinary teams get the same tool, and we further argue that the code review ritual we are all drowning in was solving the wrong problem long before AI showed up.

My top 3 picks this week

Verification is the skill you own, everything else is rented

Lauren (poteto) published the first part of a guide to pstack, the skill set behind roughly 2,000 PRs a month landing in production. The interesting part: the importance they give to enabling self-verification in agentic workflows. Not only a test suite, but a named, maintained skill an agent invokes to prove its own work, with a /maintain-verification-skill companion.

8th Light named the failure mode from the other direction: If the same context window writes the change and defines the proof of success, you have not produced proof. You have produced a tautology. This is the defect in most agentic setups right now. We ask the agent to implement, then ask the same agent whether it worked, and we accept the answer because the diff looks plausible and the tests are green. The proof has to come from somewhere the implementation cannot reach. A separate tool, a separate model, a screenshot, a trace, a person. Something with independent standing.

Most teams focus their attention on prompts, context files and orchestration, and treat verification as already solved because CI exists. Flip it. Ask what your agent can prove without your help, and what that proof costs to run. My own team's answer: lightning fast CI with high-level test automation, automatic screenshotting/video recording of UI changes, a whiff of more rigorous aproaches like formal methods and property-based testing (Hilel's new book is a great introduction). i.e. "boring non-value add work". Also the work that unlocks everything else, ignore at your own peril.

Worth reading:

Code review was always the wrong tool, AI just made it extremely obvious

Rachel Laycock spitting truths this week: AI did not break code review. It revealed that we had been using review to solve problems it was never good at. Knowledge sharing, design feedback, quality gating, onboarding, defect detection. We loaded all of these goals onto one ritual at the end of the pipeline. This used to "work" only because writing the code was slow enough to keep the review queues short. Remove that constraint on throughput and the whole argument breaks down. The instinct a lot of teams have is to review faster. Her argument is that we should review less, and move most of those goals to where they really belong.

We never had to treat understanding our own code as a cost separate from writing it, because writing it forced us to understand it. That relationship is gone. Understanding is a separate activity now. PRs get bigger. Reviewers start skimming. A failure mode appears that we have taken to calling "cognitive surrender", the (incorrect) assumption that someone further down the line will look at this properly, so we ourselves do not have to. When everyone in the chain strarts making that assumption, nobody looks at anything. The buck should stop with you.

The way out: What evidence would let a change pass without a human needing to read every line? Some changes do not need a reviewer. Some need two. Triaging them with confidence is an interesting problem, reviewing faster will just burn out your best engineers that still care.

Worth reading:

AWS watched 50 teams adopt the same AI tool and the spread was insane

This is the study the industry needed and mostly ignored. Amazon tracked around fifty ordinary teams for the better part of a year. Normal seniority mixes, existing codebases, no special selection. Ninety percent used the same coding assistant. Half saw under 3x improvement in deployment velocity. The other half saw a median of 4.5x (with some teams reporting the fabled "10x"), sometimes more. Whatever produced that gap, it was not the model.

Uber's numbers point at what fills it. More than seventy percent of Uber's pull requests now come from local or cloud agents, and lines of code per engineer has doubled year over year. Tessl tells a similar story from a much smaller base. 850 PRs in a week, 85 to 90 percent handled end to end by agents, and it started with skills rather than orchestration. In all three cases the visible output sits on top of unglamorous platform work. Gateways, sandboxes, ledgers, fast feedback, self-verification.

Worth reading:

You have to beat the models at something

Sean Goedecke has been sharpening the same idea for a year. You have to be better than the model at something specific, and you have to be able to name it. Most of us are starting to come to this realisation. The hard part: for a lot of people the answer changes every few months as the jagged frontier creeps up on them, and keeping it true is part of the job now. My colleague professors called it years ago in a moment of clairvoyance: "working in IT is signing up for lifelong learning".

From creators to orchestrators, from builders to overseers, and lands on a comparison that will sting a lot of readers. Whatever the future looks like, nobody will be getting in the zone hammering out some code and getting paid handsomely anymore. LeadDev reports research finding that the resulting burnout comes from changing identity rather than from workload. Adding headcount does not fix an identity problem. Neither does a better tool.

The compounding issue is that the reps are gone. Agents finish the task without teaching you anything, so building expertise has to be deliberate rather than a side effect of shipping. That breaks with how our profession has always trained people. Every senior engineer you know got there by doing the work badly for years under conditions that forced them to understand it. If the work is no longer the teacher, something else has to be. Deliberate practice, structured feedback and choosing friction on purpose.

Worth reading:

An agentic engineering curriculum is starting to take shape

A SoCraTes unconference workshop on augmented coding patterns. Tessl's academy quickstart. MEGA, a four-week cohort programme run by Kent C. Dodds, Theo Browne, Angie Jones and John Lindquist. A sixteen-week Johns Hopkins programme on agentics. You cannot teach a four-week course on something that changes weekly, so multiple structured programmes appearing at all says the practice is starting to settle enough to have a shape worth diving into.

The content is more interesting than the packaging. Kent C. Dodds argues for thinking in primitives and looser specifications, on the grounds that over-specifying makes agent output worse rather than safer. Counterintuitive enough to be worth testing on your own work. Theo Browne makes the matching case for prompting end to end rather than line by line. And IndyDevDan supplies the correction this field needs: Everyone is racing up the stack toward bigger agents and software factories, but the engineer who can only operate at the top is as stuck as the one who can only operate at the bottom. Altitude is a choice per task, not a promotion.

The gap between how much opinion and how much measurement this field produces has been embarrassing for two years. This week it narrowed a teensy little bit.

Worth reading:

Oh, and some more models dropped

Fable/Mythos 5.1 released. GPT-6 Astra arrived with an AGI claim attached. Lots of self-selected and trained-upon benchmarks get cited, lots of numbers going up, lots of pre-IPO smoke and mirrors. Yet nothing substantially changed about how you should leverage these models. They do start to draw a mean "pelican on a bike" though!

Worth reading:

Quick hits

Curated from 493 items across articles, podcasts, and videos. Week of August 29 to September 5, 2026.

Read more