AI Engineer Code Summit · Thu 12 Nov 2026 · Engineering Track

Loops, backpressure, and asymmetric slop

Dexter Horthy brought HumanLayer into Factory a week before the talk; a software factory is forward pressure plus automated backpressure—buy the undifferentiated stack below, but own verification and human judgment because slop is asymmetric.

Dexter Horthy, HumanLayer / Factory · 20 min · Links and further reading · Video
The loop

Forward pressure and automated backpressure

Three months after “software factories” peaked online—and right alongside studies showing roughly 30% of AI-authored PRs merging unreviewed—people took his earlier talk, “Why software factories fail”, to mean he rejected factories altogether. His real claim is simpler:

“But I think the main takeaway here, and I think we've heard this from a lot of folks, is software factories is just good engineering.”00:01:11

Walk through a software team circa 2022 and every box is already familiar: product and leadership queue work in a tracker, engineers implement and poke at a local build, and pull requests wait for CI checks and peer review before rollout.

“We're around for thirty years, right? You take stuff off the tracker, you build it, run some unit tests, automated tests. Maybe you poke it locally when you're ready. You make a pull request.”00:03:03

Dropping an agent into implementation speeds up only one node. Forward pressure is what triggers work automatically from customer complaints or 3 a.m. incidents; backpressure is everything—agentic code review, headless browsers, screenshots, linters, and formal checks—that pushes back before a person reads the diff.

“So, forward pressure—what causes new work? Start and back pressure, which is sort of like okay, cool. Now we can build things in minutes or hours. But the review and testing still takes hours or days if we're doing it in the old way. So we bring in agentic code review, agentic testing.”00:04:20
From the notes: “Forward pressure, backward pressure: what are these ideas in the new factory? What causes new work to start?” and “Loops = forward pressure + backpressure”. The reading: loops stop being buzzwords when you split pull triggers from automated verification gates so human review only touches diffs that survived machine critique—the same move behind Cognition’s self-testing VMs.

Evidence: transcript 00:01:11, 00:03:03, 00:04:20

The failure mode

Know your enemy: SlopCodeBench

Agents can clone Redis or Excel in days when the full specification is known upfront. Real product engineering lands one incremental change at a time, and without deliberate refactoring, unattended models quietly pile on dead code and brittle abstractions:

“So if you are just hands off pushing features into the machine. You may not find that it autonomously will make things better over time.”00:06:50

To measure that decay instead of relying on vibes, he cites SlopCodeBench (paper, benchmark repo), which scores models over sequential codebase checkpoints across more than 200 rules checking complexity, verbosity, broken abstractions, and even regressions back to Python 2 patterns—where frontier models drop around 15%–16.3%.

“We should probably maintain understanding of the system and the code.”00:06:50
From the notes: “Look up the 'slop bench' stuff”, “We should maintain and understand the codebase”, and “Anti-slop repo”. The reading: SlopCodeBench supplies the empirical evidence behind Lauren Tan’s “Code is memory”—unless repo-level linters and complexity gates push back on every checkpoint, each agent turn teaches the next turn worse habits.

Evidence: transcript 00:06:50, 00:11:26

Where to spend attention

Expected pain and Show Me

When coding gets cheap, teams often overcorrect into six-hour Markdown specification sessions. Rather than planning every pixel identically, budget human friction using expected pain: how likely something is to change later multiplied by how hard it will be to change once shipped.

“But I think about this in terms of expected pain. Like, how likely will this have to change later? Times, how hard will it be to change? I don't argue with the model during planning about what color the button is going to be, but I do want to make sure we get like our database schemas right and stuff like that.”00:09:49

Where behavior is visual or easy to iterate, replace walls of text with artifacts humans and models can both inspect—using tools like Show Me (~40k installs) alongside screenshots, real browsers, and video runs so agents hill-climb against observed outcomes:

“You should help agents test their work, screenshots, browsers, videos. Whatever you can do to help the agent, again, he'll climb against an outcome.”00:11:26

He also draws a pragmatic boundary around “slop”: temporary prototypes belong in isolated buckets behind feature flags rather than shared core paths.

“Not all slop is bad. Vibe coding prototypes. Side projects. If you have something behind a feature flag, you just need to like figure out if people even want it.”00:11:26
From the notes: “Don't over-plan”, “Expected pain vs how hard it is to change”, and “‘Show me skills.’” The reading: expected pain gives engineering leaders an explicit attention budget—spend human precision on irreversible schemas and interfaces, and push UI validation onto visual evidence loops.

Evidence: transcript 00:09:49, 00:11:26

The forge

Unify the AI-native forge

Before GitHub, maintainers wrangled Git patches over mailing lists; GitHub centralized commits and pull requests. Right now, engineering teams sit in a fragmented Before AI-Native Forge state: commits live in GitHub, while product specs, Figma designs, Slack pastes, Linear issues, plans, and agent session traces scatter across half a dozen tools and laptops.

When agents write most of the implementation, reading the final Git diff alone hides why the architecture took the shape it did. Centralizing specs, prompts, plans, designs, and coding sessions beside the commit turns every run into inspectable evidence:

“So you can understand not just the code about what something was built, but all the decisions that went into it.”00:13:00
From the notes: “The forge lifecycle.” The reading: look at his four-stage diagram alongside Ramp’s public Inspect sessions—the session log and plan are becoming part of the permanent engineering record, not scratchpad chat history.

Evidence: transcript 00:13:00

Build vs. buy

Buy the plumbing, own verification

His stack diagram divides the modern software factory into eight horizontal layers—Models (01), Compute (02), Routing (03), Integrations (04), Agent harness (05), Orchestration across workstreams, automations, and sessions (06), and Surfaces from Slack to IDE and CLI (07)—flanked by cross-cutting Governance.

Layers 01–07 are undifferentiated infrastructure you can adopt off the shelf or swap as models evolve. Layer 08 Yours—your repos, skills, automations, and quality gates—cannot be bought as a turnkey vendor box:

“I don't think anyone can sell you verification of your code because only you know. If you have hundreds of engineers and hundreds of repos.”00:13:50
From the notes: “What can you buy, and what must you own?” The reading: commodities in the agent harness race to parity quickly; competitive reliability comes from domain-specific invariants encoded in layer 08’s automated backpressure and quality gates.

Evidence: transcript 00:13:50

Human judgment

Slop is asymmetric

Closing with the Slop Manifesto, Horthy defines slop around economic asymmetry rather than model aesthetics: producing a 1,000-line PR or a 10-page design doc approaches zero cost, while the cost for another person to verify and understand it barely moves.

“AI cannot replace human judgment. It can only amplify our judgment, or maybe perhaps our lack of judgment in certain cases. And the slop is asymmetric. The cost of producing a thousand line PR or a ten page doc is approaching zero. But the cost of reviewing it is still barely constant.”00:14:43
“And we own the intent and the taste and the consequences of what we ship. However much AI helps us to make it.”00:14:43

Even as humans stop inspecting every line of syntax, review simply moves up to plans, designs, and shipped outcomes—and teams that delegate thinking completely end up indistinguishable from everyone else’s default model output:

“As models get better, we may stop reading most of the code. We basically review a plan or a design or a result. But if you don't review anything, if you bring nothing to the table, no thinking, then you're just going to get the same AI output as everybody else.”00:18:40
“Swap is bad when it undermines our outcomes. We want to make a good product, maintainable system. We want to save people time and energy. If slop undermines that, then it's bad.”00:18:40
  • Factories are closed-loop engineering: speed in code generation only backs up PR review unless you pair forward pressure with automated, agentic backpressure (00:01:11, 00:04:20, 00:11:26).
  • SlopCodeBench proves unattended drift: green unit tests do not prevent complexity and bloat across sequential checkpoints without repo-owned anti-slop rules (00:06:50, 00:11:26).
  • Buy layers 01–07, own verification and judgment: generation costs approach zero while review cost stays flat, so direct human thinking at high-pain plans and quality gates (00:13:50, 00:14:43, 00:18:40).
Read alongside

Evidence: transcript 00:14:43, 00:18:40, 00:19:44