Implementation Is No Longer the Scarce Resource
GPT 5.2 crossed the threshold where models can do the full job of a software engineer. Lopopolo banned his team from touching their editors for nine months, forcing all work through the models. Each engineer now has access to 5, 50, or 5,000 engineers worth of capacity, 24/7. The scarce resources shifted: human time, human attention, and model context window. Code is no longer the bottleneck.
“Code is free.” — Ryan Lopopolo
The job becomes systems thinking and delegation. Your role is to figure out how to productively deploy that capacity into real codebases rather than writing lines yourself.
Specifying What Good Code Looks Like
A single patch requires roughly 500 small decisions about non-functional requirements: timeouts, naming conventions, type safety, file length. Models trained on trillions of lines have seen every possible choice. They default to whatever is most common in training data. Write the non-functional requirements down explicitly, and agents make the right calls.
“You can just simply say do not produce slop. Don’t accept slop. You won’t get slop in your codebase.” — Ryan Lopopolo
Taking a short-term velocity hit to document what acceptable output looks like pays back in every subsequent agent trajectory that gets it right without intervention.
Harness Mechanics: Lints, Review Agents, and QA Plans
Context gets paged out over long tasks. Lopopolo runs security and reliability reviewer agents on every push. They check whether network code has timeouts and retries, whether interfaces are impossible to misuse. A bespoke lint that fires every time fetch is called without a retry wrapper solves the outage class permanently. He also writes tests that assert structural properties of the source code itself, like a 350-line file-length ceiling, adapting the codebase to what models can hold in attention. He described the laptop-in-back-seat commute setup (11:36) as how he saturates token consumption even during the commute.
Daily Workflow: Tickets, Skills, and Avoiding Over-Engineering
The team starts with tickets, assigns each one to Codex along with a focused set of skills. Skills teach Codex how to launch the app, spin up local observability, and attach Chrome DevTools via a daemon. They cap the set at 5 to 10 skills, preferring to deepen existing ones rather than add more. When the team switched from Chrome DevTools Protocol to a daemon layer, Lopopolo didn’t notice for three weeks. The skill absorbed the change. The harness absorbs infrastructure churn, not the model and not the human.
Code Review at Scale and the Feedback Loop That Closes Itself
With each engineer producing 3-5 PRs per day on a team of three, merge conflicts were constant and humans were the review bottleneck. Lopopolo introduced garbage collection Fridays (37:47): one day a week, every engineer converted that week’s accumulated review slop into lints, docs, or review-agent prompts that eliminated the failure class permanently. Human comments became documentation. Documentation became reviewer agents triggered on every push, each scoped to a persona like front-end architect or reliability engineer. Slop frequency dropped steadily.
“Every time I have to type continue to the agent is like a failure of the harness to provide enough context around what it means to continue to completion.” — Ryan Lopopolo
Q&A
What’s your actual working setup — no laptop? Kicks off a task before leaving the office, tethers his laptop to his phone, buckles it into the back seat, and lets it run for the 30-minute commute; skills instruct the agent to go until tests are green without prompting. ▶ Watch (19:20)
How do you stop yourself from over-engineering harnesses? Do the bare minimum context management: a good harness surfaces instructions to the model at the right time via lints and tests rather than front-loading everything, and context delivery is the one thing that will never be obsoleted by capability increases. ▶ Watch (23:49)
Do you have recommendations for a collaboration platform? Markdown files in the repository plus GitHub PRs are the hub; agents and humans both post review comments, and the implementation agent can acknowledge, defer, or reject any feedback without being forced to address all of it. ▶ Watch (28:16)
How should engineers get started with coding agents? Start by using agents to write tests against existing code to build confidence, then audit where human time goes (editor, waiting on CI, flaky tests) and automate the biggest time sink first. ▶ Watch (30:06)
Where do your billion output tokens go, and how should people on a $200 plan maximize usage? Roughly a third each across planning and ticket curation, documentation and implementation, and CI; prioritize getting tokens into CI because writing code is no longer the hard part, getting it accepted is. ▶ Watch (39:28)
Is code a disposable build artifact? Yes; code is the compiled output of a spec, and swapping models is like changing the code generation backend — the constraints defined in the harness should produce acceptable output regardless. ▶ Watch (41:49)
What future are you building toward? 50 agents running 24/7 against a prioritized token budget, with humans providing only the ranking of success metrics; new phases of the software lifecycle (QA smoke testing, user feedback triage, runbooks) get agent-tooling built for them as each one becomes the next bottleneck. ▶ Watch (43:35)
Notable Quotes
Code is free. Ryan Lopopolo · ▶ Watch (3:39)
You can just simply say do not produce slop. Don’t accept slop. You won’t get slop in your codebase. Ryan Lopopolo · ▶ Watch (9:36)
Every time I have to type continue to the agent is like a failure of the harness to provide enough context around what it means to continue to completion. Ryan Lopopolo · ▶ Watch (33:29)
Key Takeaways
- Write non-functional requirements down explicitly; agents trained on trillions of lines of code need human-specified constraints to choose correctly.
- A harness should surface instructions just-in-time via lints and review agents, not front-loaded into a system prompt that overwhelms context.
- Treat code-review friction as signal: each recurring slop type gets converted into a lint rule or reviewer agent prompt that eliminates it permanently.