Talk by Gabriel Martinez, engineering manager at G2i, on "slop": work that looks finished before the thinking behind it is done, which he frames as missing judgment rather than AI-written code. He argues that generation is cheap but evaluation is expensive, and covers code as a liability, pressure to merge faster than teams can review, large PRs and long AI-generated docs, and the prototype illusion. Proposed remedies, as presented by the speaker, include conventions, diagrams as the review surface, small reviewable changes, and clear ownership, drawing on Rails and G2i's ORC. Recorded at the AI Engineer World's Fair 2026. # Channel Identity Observations: Gabriel Martinez (G2i) ## Observable Presentation Evidence ### Speaker Self-Identification - **Explicit**: "Hi everyone, my name is Gabriel Martinez. I go by Gabo. I'm an engineering manager and resident slop warden at G2I." - Claims the role of **engineering manager** at G2i. - Self-describes humorously as **"resident slop warden"**, signaling a defined internal focus on code-quality oversight. - The talk appears to be a **conference or meetup presentation** (addressed to an audience: "Hi everyone… I'm here to talk about…", closing "Thank you all for your time"). ### Intended Audience - **Software engineers and engineering managers**, evidenced by: - Repeated use of practitioner terminology: PRs, merge buttons, codebases, abstractions, garbage collection, imperative code. - Direct address to shared experience: "I'm sure most of you have seen this in the wild," "We are just a code monkey hitting the merge button." - References to team dynamics: "in team environments can pressure engineers to merge PRs faster than they can judge." ### Claimed Scope and Topics - **AI-assisted software engineering quality**: defining "slop" — "Slop is output that looks finished before the thinking is finished." - **Engineering judgment and accountability**: "Accountability is the key word here. Taking ownership over the product you're building…" - **Architecture and conventions**: "I vouch for declarative code and architecture patterns that create layers humans can actually reason about"; special praise for **Rails** conventions. - **Organizational incentives**: "Rewards should be centered around producing value… and clarity of test and evaluation harnesses." ### Product / Organizational Promotion - The talk concludes with a **product pitch for "ORC"**, built at G2i: > "Everything I've talked about today is what led us to build ORC." - Framed as encoding review discipline into workflow: "It is a system for preserving that responsibility while letting agents do more of the lift." - Positioning statement: "The future is orchestration with judgment." - Demonstrates that the channel/presentation serves partly as **thought-leadership marketing for G2i's tooling**. ## Demonstrated Presentation Patterns (vs. Claims) - **Opinionated, candid tone**: "by passionate, I mean angry"; "There's just something that really grinds my gears about seeing a multi-thousand-line PR"; criticism of "Twitter… self-proclaimed experts and clickbaiters." - **Personal vulnerability as credibility**: "I can admit that it led me to merge code that I didn't necessarily review with a level of detail that I normally do or should have." - **Use of external authorities**: quotes Dijkstra on "lines spent" and the SQLite creator's PR quote — demonstrates a style of grounding arguments in established software wisdom ("60 years of software wisdom hasn't been invalidated by AI"). - **Balanced stance on AI**: explicitly not anti-AI — "I'm not the purist that's come here to tell you that AI is bad" — while critiquing its misuse. ## Notes on Limits - No channel name, subscriber base, upload cadence, or curated metadata were present; observations are limited to this single talk's content. - No statements about the channel's mission beyond the speaker's G2i affiliation and the ORC product framing; private motivations are not inferred. # Delivery Observations — Gabriel Martinez, "Generation Is Cheap, Review Is Expensive" ## Tone - **Conversational and confrontational-energetic.** Opens playfully: *"I'm an engineering manager and resident slop warden at G2I. And I'm here to talk about slop."* Self-describes the energy: *"I'm here to talk about slop because I'm rather passionate about the topic. And by passionate, I mean angry."* - **Deliberately informal register** mixed with technical argument: *"It's easy to yeet a PR"*, *"There's no way in hell that a human can fully understand all the important bits."* - **Direct-address coaching mode** in key moments: *"We need to dial it in. We need to slow down. We need to sober up."* - **Self-inclusion rather than finger-pointing.** Admits personal vulnerability: *"I've personally felt this anxiety... it led me to merge code that I didn't necessarily review with a level of detail that I normally do or should have."* ## Vocabulary and Recurring Phrases - **"Slop"** is the anchor term, used constantly — definition, diagnosis, and closing line: *"don't get sloppy."* - **Judgment vs. generation** as the framing pair: *"Slop is what happens when generation outruns judgment"*, *"Slop is not about AI as a tool... it is about the absence of judgment."* - **Ownership / accountability** family recurs: *"if we do not own them, we are not really engineering"*, *"Accountability is the key word here"*, *"who has to own that thing?"* - **Cost/spending metaphors**: *"any line of code you write is a liability"*, *"lines spent"*, *"you own the bill"*, *"Cognitive overhead is a tax."* - **Understanding as the counter-currency**: *"Output was produced, sure, but understanding was not"*, *"code being merged without full understanding."* - Occasional playful bilinguality and slang: *"competin with slot misters begets mucho slopp"*, *"yeet a PR."* ## Teaching Habits - **Definition-first structure**: spends the opening minutes defining the term ("Slop is not AI-generated code... Slop is output that looks finished before the thinking is finished") before diagnosing causes. - **Contrast pairs as a teaching device**, repeatedly: > "Generation is cheap, but evaluation is expensive." > "The cost of creating code is falling, but the cost of understanding a software program is not." - **Rhetorical questions** to drive points: *"who has to own that thing? Who's responsible for the repercussions?"* - **Borrowed authorities**: Dijkstra (*"lines of code... as lines spent"*), the SQLite creator's PR quote, the Rails doctrine — each deployed to support, not replace, his own argument. - **Concrete scenario sketching**: *"You give someone 10 bullets of scope... and they come back with a 20-page document"*, *"every screen has 12 escape hatches."* - **Anticipating objections**: *"I'm not the purist that's come here to tell you that AI is bad. It's not bad, okay?"* and *"I'm not saying every line of code needs to be personally read, blessed, and understood."* - **Closes with a product pivot and a memorable sign-off**: *"The future is not vibe coding better, faster. The future is orchestration with judgment... don't get sloppy."* ## Communication Patterns - **Anaphora / triplet lists** are a signature rhythm: > "We need to dial it in. We need to slow down. We need to sober up." > "They never hit the ambiguity. They never felt the constraint. They never discovered the edge case..." - **Negation-then-restatement** ("X is not Y. It is Z.") appears throughout: *"Slop is not AI generated code"*, *"It is not a magic box"*, *"not as decorative documentation after the fact, but as..."* - **Historical framing** to legitimize claims: *"60 years of software wisdom hasn't been invalidated by AI"*, plus the machine-code → assembly → C → Java → Ruby progression. ## Stable Patterns vs. Isolated Moments - **Stable (repeated enough to trust):** the slop/judgment/ownership lexicon, contrast-pair aphorisms, triplet lists, and objection-anticipation moves. - **Less certain (single appearances):** the personal Rails anecdote (*"between my first and second [year] with Rails, I had a gap of four years"*), the Twitter/"Ralph loop" rant, and the bilingual wordplay — these read as one-off flourishes, though the Rails convention argument is supported by the surrounding abstractions discussion. - **Caveat:** this is a single transcript; some transcription artifacts exist (*"Important important"*, *"gropped"*), so exact wording at those spots carries some uncertainty. # Observation Record: "Generation Is Cheap, Review Is Expensive: How to Stop Shipping AI Slop" **Speaker:** Gabriel Martinez ("Gabo"), self-described engineering manager and "resident slop warden" at G2i **Source basis:** Transcript only. Speaker identity is stated in the transcript's opening. Third-party references are recorded as attributed within the talk. **Stance on AI:** The speaker explicitly disclaims being an opponent of AI: "It's not bad, okay?" --- ## 1. Core Definition ### 1.1 "Slop" as a judgment gap - **Position:** Slop is "what happens when generation outruns judgment." - **Stated characterization:** Slop is "output that looks finished before the thinking is finished." - **Qualification:** The speaker says he does not mean slop as "some concrete objective thing that can easily be sniffed out, although there are tells." - **Attributes of slop, as described:** - Ambiguity "cleared with guesses" - Trade-offs "left to chance" - Ownership "not taken" - **Central concern:** The engineer "never noticed that there was a choice to make," so "unknown unknowns stayed unknown." ### 1.2 Ownership of choices - **Position:** "Software is a record of choices" (technical, product, operational, user-facing). - **Implication stated:** If choices are not seen, they cannot be owned. If they are not owned, the engineer is "just accepting output" and is "just a code monkey hitting the merge button." ### 1.3 What agents can and cannot do - **Can (as stated):** Write code, scaffold screens, and "with right tuning can build whole features or systems." - **Cannot (as stated):** Replace "deciding what matters," understanding what is being built, interpreting ambiguity, owning the system long-term, exercising architectural judgment and restraint, and "knowing what not to build." - **Summary claim:** "SLOP is not about AI as a tool. Rather, it is about the absence of judgment." --- ## 2. Causes and Pressures ### 2.1 Cost asymmetry - **Core thesis (title and body):** "Generation is cheap, but evaluation is expensive." - **Stated consequence:** If AI produces more than humans can evaluate, "it has not accelerated the team. It has created a bottleneck." - **Related claim:** "The cost of creating code is falling, but the cost of understanding a software program is not." ### 2.2 Stakeholder perception - **Position:** Stakeholders often treat a quick prototype as "evidence that the hard part is over." - **Qualification:** Prototypes "sometimes" are "real enough to be useful" and "a great way to explore an idea." - **Work described as invisible to stakeholders:** Cohesive integration, requirements clarification, manual testing against expected behavior, and UX quality ("the last mile where the judgment lives"). ### 2.3 Incentives and performance anxiety - **Position:** Pressure to merge quickly produces code "merged without full understanding." - **Observation (anecdotal, stated as "I'm sure most of you have seen this"):** Less careful engineers "end up producing more faster," while detail-oriented engineers "might seem like they're doing less and moving slower." - **Personal admission:** The speaker reports feeling "constant anxiety that I was not moving fast enough" and says this led him to merge code he "didn't necessarily review with a level of detail that I normally do or should have." - **Second-hand reports:** He has "seen horror stories of people merging code they don't fully understand or haven't even tested themselves." No specifics are given. - **Mechanism:** "We're all human. We are driven by incentive." ### 2.4 Lines of code as a metric - **Position:** "Lines of code is a garbage metric for productivity," yet teams have treated token burn as a productivity proxy. - **Attributed quote (Dijkstra, per the speaker):** Lines of code should be thought of "not as lines produced, but as lines spent." ### 2.5 Over-generation and expansion - **Examples given:** - A 10-bullet scope returned as a 20-page document: "It did not clarify the problem. It expanded it." - A vague task becoming "a large PR," and a small feature becoming "a pile of files." - **Summary:** "The output arrives with the shape of completion, but the real work has just moved to the reviewer." ### 2.6 Shift in workflow - **Past practice (as described):** Features were broken "into small atomic pieces we could reason about." - **Current practice (as described):** "We type two sentences and expect a whole not fully thought out feature set back in one shot." --- ## 3. Positions on Code Quality and Architecture ### 3.1 Less code is better - **Position:** "Any line of code you write is a liability, that the best code is no code at all." - **Qualification:** The speaker is "not saying every line of code needs to be personally read, blessed, and understood in isolation." Large systems always exceed one person's memory. The requirement is that "the logic has to be understood": main flows, boundaries, data model, and product behavior. ### 3.2 Coherence - **Position:** "The code should reflect the shape of the domain." - **Claim:** "AI can generate code, but it cannot magically give a messy system coherence." - **Conditional claim:** An agent works better in a structured codebase, but "if the system is already a big ball of mud, the agent does not rescue you from the mud. It just builds the ball bigger, faster." ### 3.3 Generating more is not a mandate - **Position:** "Just because you can generate another component does not mean the product needs another component." ### 3.4 Review surface - **Position:** Diagrams are important "as a way of making systems legible." - **Stated reasoning:** Agents can generate "thousands of lines of implementation detail," so humans need a "compressed review surface": service boundaries, data flows, state transitions, and failure modes. - **Recommended approach:** Keep the main process or workflow as the reviewable surface, with implementation details "pushed to the leaves." - **Stated preference:** "Declarative code and architecture patterns that create layers humans can actually reason about." ### 3.5 Cognitive overhead - **Definition:** Cognitive overhead is "a tax every engineer has to pay" to decide where code belongs, which pattern to follow, and what proper implementation means. - **Claim:** "AI does not remove this tax. Unless tamed, it exacerbates it." An agent can produce "five plausible patterns in five different styles." - **Proposed remedies (stated):** Conventions, documented flows, small reviewable surfaces, clear ownership boundaries, and definitions of done. "The more obvious the path, the less room there is for slop to hide." --- ## 4. Accountability and Ownership ### 4.1 Maintenance cost - **Position:** "You say, 'Oh, it's free.' No, it's not free." This is a quoted statement attributed to the creator of SQLite about pull requests, read from a tweet in the talk. - **Speaker's endorsement:** "I couldn't have said it better." - **Key question posed:** "Who has to own that thing? Who's responsible for the repercussions?" ### 4.2 Proposed accountability - **Position:** "Teams should be held accountable for work they are producing." - **Mechanisms proposed:** - Visible accountability metrics "for each chunk of work product" - "Positive or negative reinforcement" tied to ownership - **Stated expected effect:** Knowing someone else will review will make engineers "pay just a little bit more attention to the finer details." - **Stated principle for rewards:** Reward "value," "elegant, well-factored, pragmatic system design," and "clarity of test and evaluation harnesses." ### 4.3 Size of changes - **Position:** Large PRs are a problem: "There's no way in hell that a human can fully understand all the important bits of a change that big." - **Prescription:** It is an engineer's job "to decompose needs into its simplest chunks." --- ## 5. The Abstraction Argument ### 5.1 Abstraction is the trajectory of software - **Position (stated with qualification, "to an extent I agree"):** Much implementation detail will eventually be abstracted away from humans. - **Historical framing:** Machine code → assembly → C → Java → Ruby ("where the primary design goal was programmer happiness"). Abstractions for garbage collection and manual pointers followed. - **Claim:** "AI is abstracting away the imperative bits." - **Counterclaim (stated):** This "does not remove the need to understand how a system comes together cohesively." ### 5.2 Ground truths persist - **Position:** "60 years of software wisdom hasn't been invalidated by AI." Composable code, good patterns, and solid practices "remain essential." - **Context:** The speaker responds to a friend who asked why guardrails, conventions, and architecture matter if an agent writes the code. The speaker's answer is that "the goal is human knowledge, human understanding, and human review." --- ## 6. Conventions and Frameworks ### 6.1 Rails - **Position:** Rails is praised for reducing "decision surface." "When conventions reduce your overhead rather than ending up with 10 different ways to structure the same concept, you end up with one." - **Personal experience:** After a four-year gap, the speaker returned to Rails and found "the same patterns" still present, allowing him to "immediately understand intent" and move "laterally with minimal ramp up." - **Qualification:** Rails "may not be perfect in everyone's subjective opinion, but it's understood and it works." - **Cited doctrine (per speaker):** Rails names "optimize for programmer happiness" and "convention over configuration" as core pillars and describes convention as a way "to eliminate recurring decisions." ### 6.2 JavaScript claim (see Section 9 for tension) - **Position as transcribed:** "JavaScript environments with a single correct way of doing things are superior for agentic development because agents aren't confused by dozens of competing approaches." --- ## 7. Commentary on Industry Discourse - **Position on "Ralph loop":** It was "made to sound like a novel agentic breakthrough when it's just a while loop." - **Broader critique:** Social media "self-proclaimed experts and clickbaiters" present long-known truths "as if there's some novel genius idea." - **Observed amnesia:** "Somehow we've completely forgotten that lines of code is a garbage metric for productivity." --- ## 8. ORC - **Stated origin:** The team kept seeing "the same failure pattern": AI could generate code, but "the surrounding discipline was still missing." - **Disciplines named:** Planning, review, adversarial checks, and context management. - **Stated purpose:** Bake these human processes into the workflow. - **Explicit disclaimers:** - Not built "because we think the answer is more agents" - Not built "because we think engineering judgment can be automated away" - "It is not a magic box that makes correctness disappear as a human responsibility." - **Stated goal:** "Ship software that is still coherent, tested, maintainable, and owned after the generation happens." - **Closing thesis:** "The future is orchestration with judgment." --- ## 9. Qualifications, Tensions, and Open Points | # | Tension or qualification | Notes | |---|---|---| | 1 | "Every line needs to be read" vs. "not saying every line needs to be personally read" | The speaker distinguishes understanding the logic from reading every line. The boundary of acceptable understanding is not defined. | | 2 | Abstraction is the historical direction vs. "AI does not remove the need to understand" | Presented as a qualified agreement, with the speaker stressing the continued need for human understanding. | | 3 | "AI is not bad" vs. "the danger" and "horror stories" | The speaker frames AI as a tool and the failure as human judgment, while describing serious risks. | | 4 | Agents "can build whole features or systems" vs. they "cannot replace" judgment | Capability is presented as real, with limits on responsibility. | | 5 | Prototypes "sometimes … real enough to be useful" vs. stakeholders wrongly treating them as "evidence that the hard part is over" | Prototypes are acknowledged as useful within a stated limit. | | 6 | "JavaScript … with a single correct way … superior" vs. the surrounding Rails discussion | The transcript attributes this claim to JavaScript ecosystems in a passage otherwise about Rails. The text does not clarify whether this is the speaker's intended point or a transcription issue. It is recorded as stated and not resolved. | | 7 | Accountability metrics and rewards | The speaker proposes these but does not describe how they would be measured or prevent gaming. | | 8 | Bad engineers "produce more faster" | This is an anecdotal observation with no data cited. | | 9 | Transcript wording "since December 25" | Likely a transcription of a date. Recorded as transcribed. | **Unresolved questions raised by the talk (not answered within it):** - How much code must an engineer understand before merging? - How should accountability metrics be designed without creating new incentive distortions? - Where exactly should the line fall between acceptable abstraction and opaque generation? --- ## 10. Source Attribution Summary | Claim or quote | Attributed to | Basis | |---|---|---| | Core positions on slop, judgment, ownership, cost asymmetry, incentives, abstraction, conventions, ORC | Gabriel Martinez | Speaker's own statements in transcript | | "Not free" pull request argument | Creator of SQLite (quoted via tweet) | Speaker reads and endorses; attributed within talk | | "Lines spent" | Dijkstra | Speaker attributes; wording as transcribed ("Dystra") | | "Ralph loop is a while loop" critique | Speaker | Speaker's own commentary | | Rails doctrine on convention and programmer happiness | Official Rails doctrine (as described by speaker) | Speaker's paraphrase; not verified in transcript | | Friend's question about guardrails | Unnamed friend | Speaker reports; friend's position is only summarized | | Horror stories and team anecdotes | Unspecified | Speaker reports second-hand; no sources given | # Speaker Roles & Provenance Record ## Video Overview - **Title:** *Generation Is Cheap, Review Is Expensive: How to Stop Shipping AI Slop — Gabriel Martinez, G2i* - **Video ID:** `01a15ca6-b255-782c-b86f-db35d77aa0e7` ## Speaker Inventory | Speaker | Role | Basis | |---|---|---| | **Gabriel Martinez ("Gabo")** | **Sole speaker — creator/presenter**, self-described "engineering manager and resident slop warden at G2I" | Self-introduction at transcript start; attribution in title | - No guests, interviewers, or narrators appear; the entire talk is delivered by one voice. - Closing remarks ("Thank you all for your time") suggest a **conference-style talk** with an audience, though no audience voices appear in the transcript. ## Referenced Sources & Third-Party Claims - **SQLite creator quote (via tweet):** Martinez cites a tweet quoting the SQLite creator on pull requests: > "You say, 'Oh, it's free. No, it's not free. What you're doing is asking me to maintain it for you… for the next 25 years. That is not free." - **Dijkstra (paraphrased):** "If we could count lines of code, we would not think of them as lines produced, but as lines spent." - **Rails Doctrine:** Martinez claims it "explicitly names optimize for programmer happiness and convention over configuration as core pillars" — cited as support for his Rails argument. - **General references (unattributed):** "the internet," Twitter/X clickbait experts, the "Ralph loop" trend, industry incentive structures, and a "friend" who challenged his views on agent guardrails (anonymous). ## Promotional Segments - **Product promotion:** The closing section promotes **ORC**, described as a workflow tool built by Martinez's team to bake slop-fighting processes (planning, review, context management) into agent-driven development. This is a **first-party promotional segment** and should be flagged as such. - **Affiliation note:** Speaker is affiliated with **G2i** as engineering manager. ## Availability & Context Notes - No comments, links, or external resources are referenced as available with the video. - A closing music cue (`[music]`) marks the end of the talk. - No timestamps, slides, or visual materials are described in the transcript beyond a passing mention of "a tweet" (text not shown on record). ## Explicit Uncertainties - The exact identity of the tweet's author (beyond "the creator of SQLite") is not specified in the transcript. - Whether the "friend" anecdote is real or illustrative cannot be confirmed from the source. - The talk venue/event name is not stated in the transcript. Hi everyone, my name is Gabriel Martinez. I go by Gabo. I'm an engineering manager and resident slop warden at G2I. And I'm here to talk about slop. I'm here to talk about slop because I'm rather passionate about the topic. And by passionate, I mean angry. The term slop has been beaten to a pulp, but the thing it points at has long been around. Only now it happens at warp speed. All right. Slop is what happens when judgment when generation outruns judgment. Slop is not AI generated code. I don't mean to define it as some concrete objective thing that can easily be sniffed out, although there are tells. Slop is output that looks finished before the thinking is finished. It is work product where ambigu ambiguity was cleared with guesses, where trade-offs were left to chance, where ownership was not taken. Output was produced, sure, but understanding was not. And the real danger is not simply that the machine made a bad choice. The danger is that the engineer never noticed that there was a choice to make. They never hit the ambiguity. They never felt the constraint. They never discovered the edge case that would have changed the design. The work arrived already smoothed over and with it the unknown unknowns stayed unknown. But software is a record of choices. Technical choices, product choices, operational choices, userfacing choices. If we do not see those choices, we cannot own them. And if we do not own them, we are not really engineering. We are just accepting output. We are just a code monkey hitting the merge button. I'm not the purist that's come here to tell to tell you that AI is bad. It's not bad, okay? I'm here to describe some of the patterns that have led to our drunken AI stuper. It's absolutely understandable given the advancements made since December 25, how we got to where we are. But we need to dial it in. We need to slow down. We need to sober up. Agents can seem to make magic. And the internet would make you believe it is so. They can write code, scaffold screens, and with right tuning can build whole features or systems. But they cannot replace the human work of deciding what matters, understanding what is being built, interpreting ambiguity, owning the system for the long haul, exercising judgment and restraint at the system architecture level, and arguably the most important important knowing what not to build. SLOP is not about AI as a tool. Rather, it is about the absence of judgment. So, let's talk a little bit about what got us here. In a world where anything is possible, deciding what to build is more important than ever. People have gotten overly excited and built behemoths of spaghetti product nonsense. It's almost as if they've forgotten that any line of code you write is a liability, that the best code is no code at all. The cost of creating code is falling, but the cost of understanding a software program is not. And I want to be clear here. I'm not saying every line of code needs to be personally read, blessed, and understood in isolation. That has never really been the standard. Large systems have always contained more detail than any one person can hold in their head. But the logic has to be understood. The main flows, the boundaries, the data model and product behaviors have to be understood. Good software has a kind of harmony to it. Not in some precious aesthetic sense, in a practical sense. The code should reflect the shape of the domain. AI can generate code, but it cannot magically give a messy system coherence. An agent can operate with much more effectively inside a codebase that has structure, patterns, clear boundaries, and rationale. But if the system is already a big ball of mud, the agent does not rescue you from the mud. It just builds the ball bigger, faster. Just because you can generate another component does not mean the product needs another component. Dystra had this great line. If we could count lines of code, we would not think of them as lines produced, but as lines spent. It is the cost of building. AI makes it easier to spend lines. It makes it easier to spend on files, abstractions, and complexity. But at the end of the day, you own the bill. That bill shows up as confusion, brittle flows, features nobody wants to touch because they don't fully understand. It shows up as product surfaces that technically do everything but feel like a maze. Think about that special kind of B to bloated B2B software where every task requires training where every screen has 12 escape hatches and nobody can explain whether the complexity is there because users needed it or because teams just kept adding things. Teams should be held accountable for work they are producing. Accountability is the key word here. Taking ownership over the product you're building and having a way to tie that to positive or negative reinforcement. Just in the mere fact of knowing that someone else will review your work will force engineers to pay just a little bit more attention to the finer details and be a bit more meticulous, especially if there are accountability metrics that can be made visible for each chunk of work product. We're entering the age of bloated bloated products with spaghetti UX on the order of worst kinds of B2B ERPs you may have ever been trained to use. Today, anyone can buy code an application in an hour and end up with a working clickable prototype. And that has changed expectations because once people see software appear that quickly, they start to believe software can be built that quickly. They see a few prompts turn into screens. They see a terminal session produce something that looks real. And to be fair, sometimes it is real enough to be useful. Sometimes that prototype is a great way to explore an idea. But the problem is that stakeholders do not live in the codebase of off that stakeholders that do not live in the codebase often experience that prototype as evidence that the hard part is over. They're not thinking about the parts where real battleh hardened engineers earn their keep. It's outside the happy path. Figuring out co how to cohesively integrate a new feature set. The the work involved in clarifying requirements. the work of actually manually testing a feature set to ensure that it works as a human should expect and that the UX isn't complete garbage. They're not at all thinking about the most timeconuming bits, the human parts, the last mile where the judgment lives. This is where someone has to read the code, test the behavior, own the trade-offs, notice the missing requirements, and decide whether this thing deserves to be a part of the system. Here's a tweet that emphasizes the point I'm trying to make here. It quotes the creator of SQLite who on the topic of pull request says, "You say, 'Oh, it's free. No, it's not free. What you're doing is asking me to maintain it for you, to document it for you, to test it for you, to maintain it for you for the next 25 years. That is not free." And this really struck a chord with me. I couldn't have said it better. It's easy to yeet a PR, but who has to own that thing? Who's responsible for the repercussions of what that means? So external pressures from stakeholders coupled with pressures of competing with slot misters begets mucho slopp. I'm sure most of you have seen this in the wild where the bad engineers, the ones who don't review the details, that don't refine the spec, that aren't detail oriented, end up producing more faster. The folks who pay attention to the detail and go above and beyond are the ones that might seem like they're doing less and moving slower. How this propagates is it yields performance anxiety where in team environments can pressure engineers to merge PRs faster than they can judge leading to code being merged without full understanding. Short-term thinking getting that PR in wins over long-term code health. I've personally felt this anxiety where engineers around me were merging at an incredible pace and I felt constant anxiety that I was not moving fast enough. And I can admit that it led me to merge code that I didn't necessarily review with a level of detail that I normally do or should have. I've seen horror stories of people merging code they don't fully understand or haven't even tested themselves. At the end of the day, we're all human. We are driven by incentive. And if incentives are driving people to get PRs in, then we're going to be in for a rude awakening. Rewards should be centered around producing value. elegant, well-factored, pragmatic system design and around clarity of test and evaluation harnesses. There's just something that really grinds my gears about seeing a multi,000line PR. There's no way in hell that a human can fully understand all the important bits of a change that big. It is our job as engineers to optimize for this new world, to decompose needs into its simplest chunks, which lends to understanding. understanding simpler code surfaces and controlling of our code bases. AI is supposed to have been eradicating jobs and engineers are supposed to be moving at the rate of token production. So there is a lot of pressure to be in producing more faster. What AI is really doing is producing more faster. More characters that eat more human time. I've seen this happen in the most mundane ways. You give someone 10 bullets of scope, a few user journeys, something intentionally lightweight, and they come back with a 20page document. Maybe it looks polished with fancy pros. But now I have to spend hours figuring out whether there's any real thinking inside it. That is AI generated work in the worst sense. It does not clarify the problem. It expanded it. It took ambiguity that should have been resolved by the person doing the work and handed it back as a larger artifact for other stakeholders to do it. In code, a vague task becomes a large PR. A small feature becomes a pile of files. The output arrives with the shape of completion, but the real work has just moved to the reviewer. And that is the part that we need to be honest about. Generation is cheap, but evaluation is expensive. If AI produces more than humans can possibly evaluate, it has not accelerated the team. It has created a bottleneck. One thing that I find particularly annoying is Twitter. You've got all these self-proclaimed experts and clickbaiters summarizing some talk or promoting some truths that we've always known as if there's some novel genius idea. The Ralph loop was one of those. It was made to sound like a novel agentic breakthrough when it's just a while loop. Somehow we've completely forgotten that lines of code is a garbage metric for productivity. But then we decided that it's different than deciding the engineer who burns the most tokens must be producing the most. We used to break a feature into small atomic pieces we could reason about. Small enough to hold in your head and actually review. Now we type two sentences and expect a whole not fully thought out feature set back in one shot without really understanding it what it is we're asking for. The key point I want to highlight here is that we do not forget the ground truths we've always known. 60 years of software wisdom hasn't been invalidated by AI. Composable code, good patterns, and solid practices remain essential. A friend recently challenged me on why I spend so much time thinking about guard rails for agents, coding conventions, architectural styles, and and constraints around how the system should be shaped. His question was basically what's the point if the agent writes the code why should we care about what the code looks like and to an extent I agree there will eventually be a world where much implementmentation detail is completely abstracted away from humans that has been the soft the direction of software from the beginning we went from machine code to assembly which another of level of abstraction up got us to C then Java then languages like Ruby where the primary design goal was programmer happiness. Just like in languages, we built abstractions for garbage collection and manual pointers, AI is abstracting away the imperative bits. It does not remove the need to understand how a system comes together cohesively. This is why diagrams matter so much, not as decorative documentation after the fact, but as a way of making systems legible. When a agents can generate thousands of lines of implementation detail, humans need a compressed review surface. service boundaries, data flows, state transitions, and failure modes. A good diagram lets us see the shape of the system in a way code often obscures. We can leave the main process or workflow as the reviewable surface with implementation details pushed to the leaves. That is why I vouch for declarative code and architecture patterns that create layers humans can actually reason about. The goal is not just code generation. The goal is human knowledge, human understanding, and human review. We need to optimize for that human layer. Cognitive overhead is a tax every engineer has to pay before they can make a meaningful change. It is the time spent figuring out where code belongs, which pattern to follow, and what proper implementation actually means. AI does not remove this tax. Unless tamed, it exacerbates it. An agent can generate five plausible patterns in five different styles. And now the human reviewer has to reverse engineer not just the code but the intent behind it with proper conventions intent is more easily gropped. The answer to this is conventions standards documented flows small reviewable surfaces and clear ownership boundaries and definitions of done. The more obvious the path, the less room there is for slop to hide. I want to give special recognition here to Rails and its place in my heart. Rails matters here because it shows what happens when a framework aggressively reduces decision surface. When conventions reduce your overhead rather than ending up with 10 different ways to structure the same concept, you end up with one. It may not be perfect in everyone's subjective opinion, but it's understood and it works. In my career, between my first and second 4A with Rails, I had a gap of four years. It was beautiful to come back after that gap to see that the same patterns in de facto libraries were still the same patterns and de facto libraries. I could hop right back into a codebase and immediately understand intent without needing to parse through architecture. It allows engineers to easily move between projects laterally with minimal ramp up. The same can't be said about other language ecosystems. JavaScript environments with a single correct way of doing things are superior for agentic development because agents aren't confused by dozens of competing approaches. This is well supported by the official Rails doctrine. It explicitly names optimize for programmer happiness and convention over configuration as core pillars and describes convention as a way to eliminate recurring decisions and lowering the barrier to getting started. It is the reduction of cognitive overhead. Everything I've talked about today is what led us to build ORC. Not only because we think the answer, not only because we think the answer is more agents and definitely not because we think engineering judgment can be automated away. We built ORC because we kept seeing the same failure pattern. AI could generate code but the surrounding discipline was still missing. The planning, the review, the adversarial checks, the context management. Over time, we found ourselves repeating the same human processes to fight slop. break down the work, manage context, weigh out your options, and make sure the output enters the codebase in the way the team can still reason about. ORC is taking those lessons and baking them into the workflow. It is not a magic box that makes correctness disappear as a human responsibility. It is a system for preserving that responsibility while letting agents do more of the lift. The goal is not to ship more generated code. The goal is to ship software that is still coherent, tested, maintainable, and owned after the generation happens. Because the future is not vibe coding better, faster. The future is orchestration with judgment. Thank you all for your time and remember, don't get sloppy. \>\> \[music\]