WEBVTT NOTE Sentence-level transcript of https://www.youtube.com/watch?v=6qkzlT962es NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/6qkzlT962es.html. A cue ends where the next begins, or 2 s after its last word. s1 00:00:01.309 --> 00:00:03.309 [music] s2 00:00:12.559 --> 00:00:14.880 Hi everyone, my name is Gabriel Martinez. s3 00:00:14.880 --> 00:00:16.320 I go by Gabo. s4 00:00:16.320 --> 00:00:20.240 I'm an engineering manager and resident slop warden at G2I. s5 00:00:20.240 --> 00:00:22.800 And I'm here to talk about slop. s6 00:00:22.800 --> 00:00:26.480 I'm here to talk about slop because I'm rather passionate about the topic. s7 00:00:26.480 --> 00:00:29.359 And by passionate, I mean angry. s8 00:00:29.359 --> 00:00:34.960 The term slop has been beaten to a pulp, but the thing it points at has long been around. s9 00:00:34.960 --> 00:00:38.559 Only now it happens at warp speed. s10 00:00:39.440 --> 00:00:41.200 All right. s11 00:00:41.200 --> 00:00:45.760 Slop is what happens when judgment when generation outruns judgment. s12 00:00:45.760 --> 00:00:48.480 Slop is not AI generated code. s13 00:00:48.480 --> 00:00:55.360 I don't mean to define it as some concrete objective thing that can easily be sniffed out, although there are tells. s14 00:00:55.360 --> 00:00:59.199 Slop is output that looks finished before the thinking is finished. s15 00:00:59.199 --> 00:01:08.640 It is work product where ambigu ambiguity was cleared with guesses, where trade-offs were left to chance, where ownership was not taken. s16 00:01:08.640 --> 00:01:13.040 Output was produced, sure, but understanding was not. s17 00:01:13.040 --> 00:01:16.720 And the real danger is not simply that the machine made a bad choice. s18 00:01:16.720 --> 00:01:20.720 The danger is that the engineer never noticed that there was a choice to make. s19 00:01:20.720 --> 00:01:22.479 They never hit the ambiguity. s20 00:01:22.479 --> 00:01:24.320 They never felt the constraint. s21 00:01:24.320 --> 00:01:28.400 They never discovered the edge case that would have changed the design. s22 00:01:28.400 --> 00:01:35.680 The work arrived already smoothed over and with it the unknown unknowns stayed unknown. s23 00:01:35.680 --> 00:01:37.920 But software is a record of choices. s24 00:01:37.920 --> 00:01:43.840 Technical choices, product choices, operational choices, userfacing choices. s25 00:01:43.840 --> 00:01:46.720 If we do not see those choices, we cannot own them. s26 00:01:46.720 --> 00:01:49.439 And if we do not own them, we are not really engineering. s27 00:01:49.439 --> 00:01:51.200 We are just accepting output. s28 00:01:51.200 --> 00:01:54.159 We are just a code monkey hitting the merge button. s29 00:01:54.159 --> 00:01:58.399 I'm not the purist that's come here to tell to tell you that AI is bad. s30 00:01:58.399 --> 00:02:01.119 It's not bad, okay? s31 00:02:01.119 --> 00:02:06.719 I'm here to describe some of the patterns that have led to our drunken AI stuper. s32 00:02:06.880 --> 00:02:12.879 It's absolutely understandable given the advancements made since December 25, how we got to where we are. s33 00:02:12.879 --> 00:02:14.640 But we need to dial it in. s34 00:02:14.640 --> 00:02:15.920 We need to slow down. s35 00:02:15.920 --> 00:02:17.840 We need to sober up. s36 00:02:17.840 --> 00:02:19.920 Agents can seem to make magic. s37 00:02:19.920 --> 00:02:22.560 And the internet would make you believe it is so. s38 00:02:22.560 --> 00:02:28.560 They can write code, scaffold screens, and with right tuning can build whole features or systems. s39 00:02:28.560 --> 00:02:44.400 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 s40 00:02:44.400 --> 00:02:46.879 knowing what not to build. s41 00:02:46.879 --> 00:02:49.200 SLOP is not about AI as a tool. s42 00:02:49.200 --> 00:02:52.000 Rather, it is about the absence of judgment. s43 00:02:52.000 --> 00:02:55.920 So, let's talk a little bit about what got us here. s44 00:02:56.239 --> 00:03:00.720 In a world where anything is possible, deciding what to build is more important than ever. s45 00:03:00.720 --> 00:03:06.319 People have gotten overly excited and built behemoths of spaghetti product nonsense. s46 00:03:06.319 --> 00:03:13.040 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. s47 00:03:13.040 --> 00:03:18.319 The cost of creating code is falling, but the cost of understanding a software program is not. s48 00:03:18.319 --> 00:03:19.920 And I want to be clear here. s49 00:03:19.920 --> 00:03:25.040 I'm not saying every line of code needs to be personally read, blessed, and understood in isolation. s50 00:03:25.040 --> 00:03:27.200 That has never really been the standard. s51 00:03:27.200 --> 00:03:31.760 Large systems have always contained more detail than any one person can hold in their head. s52 00:03:31.760 --> 00:03:34.000 But the logic has to be understood. s53 00:03:34.000 --> 00:03:39.680 The main flows, the boundaries, the data model and product behaviors have to be understood. s54 00:03:39.680 --> 00:03:42.239 Good software has a kind of harmony to it. s55 00:03:42.239 --> 00:03:46.000 Not in some precious aesthetic sense, in a practical sense. s56 00:03:46.000 --> 00:03:49.120 The code should reflect the shape of the domain. s57 00:03:49.120 --> 00:03:54.000 AI can generate code, but it cannot magically give a messy system coherence. s58 00:03:54.000 --> 00:04:00.959 An agent can operate with much more effectively inside a codebase that has structure, patterns, clear boundaries, and rationale. s59 00:04:00.959 --> 00:04:05.599 But if the system is already a big ball of mud, the agent does not rescue you from the mud. s60 00:04:05.599 --> 00:04:08.480 It just builds the ball bigger, faster. s61 00:04:08.480 --> 00:04:13.599 Just because you can generate another component does not mean the product needs another component. s62 00:04:13.599 --> 00:04:15.439 Dystra had this great line. s63 00:04:15.439 --> 00:04:20.320 If we could count lines of code, we would not think of them as lines produced, but as lines spent. s64 00:04:20.320 --> 00:04:22.240 It is the cost of building. s65 00:04:22.240 --> 00:04:24.639 AI makes it easier to spend lines. s66 00:04:24.639 --> 00:04:28.320 It makes it easier to spend on files, abstractions, and complexity. s67 00:04:28.320 --> 00:04:31.759 But at the end of the day, you own the bill. s68 00:04:31.759 --> 00:04:38.320 That bill shows up as confusion, brittle flows, features nobody wants to touch because they don't fully understand. s69 00:04:38.320 --> 00:04:43.360 It shows up as product surfaces that technically do everything but feel like a maze. s70 00:04:43.360 --> 00:04:58.639 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. s71 00:04:58.639 --> 00:05:01.759 Teams should be held accountable for work they are producing. s72 00:05:01.759 --> 00:05:03.919 Accountability is the key word here. s73 00:05:03.919 --> 00:05:09.440 Taking ownership over the product you're building and having a way to tie that to positive or negative reinforcement. s74 00:05:09.440 --> 00:05:18.560 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, s75 00:05:18.560 --> 00:05:23.919 especially if there are accountability metrics that can be made visible for each chunk of work product. s76 00:05:23.919 --> 00:05:33.919 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. s77 00:05:34.080 --> 00:05:39.360 Today, anyone can buy code an application in an hour and end up with a working clickable prototype. s78 00:05:39.360 --> 00:05:47.280 And that has changed expectations because once people see software appear that quickly, they start to believe software can be built that quickly. s79 00:05:47.280 --> 00:05:49.520 They see a few prompts turn into screens. s80 00:05:49.520 --> 00:05:52.880 They see a terminal session produce something that looks real. s81 00:05:52.880 --> 00:05:56.240 And to be fair, sometimes it is real enough to be useful. s82 00:05:56.240 --> 00:05:59.520 Sometimes that prototype is a great way to explore an idea. s83 00:05:59.520 --> 00:06:09.360 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. s84 00:06:09.360 --> 00:06:14.000 They're not thinking about the parts where real battleh hardened engineers earn their keep. s85 00:06:14.000 --> 00:06:15.840 It's outside the happy path. s86 00:06:15.840 --> 00:06:19.919 Figuring out co how to cohesively integrate a new feature set. s87 00:06:19.919 --> 00:06:23.840 The the work involved in clarifying requirements. s88 00:06:23.840 --> 00:06:32.560 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. s89 00:06:32.560 --> 00:06:40.560 They're not at all thinking about the most timeconuming bits, the human parts, the last mile where the judgment lives. s90 00:06:40.639 --> 00:06:50.240 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. s91 00:06:50.240 --> 00:06:53.600 Here's a tweet that emphasizes the point I'm trying to make here. s92 00:06:53.600 --> 00:06:59.039 It quotes the creator of SQLite who on the topic of pull request says, "You say, 'Oh, it's free. s93 00:06:59.039 --> 00:07:00.479 No, it's not free. s94 00:07:00.479 --> 00:07:07.840 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. s95 00:07:07.840 --> 00:07:09.199 That is not free." s96 00:07:09.199 --> 00:07:10.639 And this really struck a chord with me. s97 00:07:10.639 --> 00:07:12.240 I couldn't have said it better. s98 00:07:12.240 --> 00:07:15.759 It's easy to yeet a PR, but who has to own that thing? s99 00:07:15.759 --> 00:07:19.680 Who's responsible for the repercussions of what that means? s100 00:07:19.680 --> 00:07:28.319 So external pressures from stakeholders coupled with pressures of competing with slot misters begets mucho slopp. s101 00:07:28.319 --> 00:07:37.759 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, s102 00:07:37.759 --> 00:07:40.880 end up producing more faster. s103 00:07:40.880 --> 00:07:47.840 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. s104 00:07:47.840 --> 00:07:59.440 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. s105 00:07:59.440 --> 00:08:04.800 Short-term thinking getting that PR in wins over long-term code health. s106 00:08:04.800 --> 00:08:12.240 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. s107 00:08:12.240 --> 00:08:19.120 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. s108 00:08:19.120 --> 00:08:25.360 I've seen horror stories of people merging code they don't fully understand or haven't even tested themselves. s109 00:08:25.360 --> 00:08:27.840 At the end of the day, we're all human. s110 00:08:27.840 --> 00:08:29.840 We are driven by incentive. s111 00:08:29.840 --> 00:08:36.479 And if incentives are driving people to get PRs in, then we're going to be in for a rude awakening. s112 00:08:36.479 --> 00:08:39.120 Rewards should be centered around producing value. s113 00:08:39.120 --> 00:08:46.159 elegant, well-factored, pragmatic system design and around clarity of test and evaluation harnesses. s114 00:08:46.399 --> 00:08:51.440 There's just something that really grinds my gears about seeing a multi,000line PR. s115 00:08:51.440 --> 00:08:56.480 There's no way in hell that a human can fully understand all the important bits of a change that big. s116 00:08:56.480 --> 00:09:05.360 It is our job as engineers to optimize for this new world, to decompose needs into its simplest chunks, which lends to understanding. s117 00:09:05.360 --> 00:09:11.440 understanding simpler code surfaces and controlling of our code bases. s118 00:09:12.720 --> 00:09:19.680 AI is supposed to have been eradicating jobs and engineers are supposed to be moving at the rate of token production. s119 00:09:19.680 --> 00:09:23.279 So there is a lot of pressure to be in producing more faster. s120 00:09:23.279 --> 00:09:27.279 What AI is really doing is producing more faster. s121 00:09:27.279 --> 00:09:30.240 More characters that eat more human time. s122 00:09:30.240 --> 00:09:32.880 I've seen this happen in the most mundane ways. s123 00:09:32.880 --> 00:09:41.120 You give someone 10 bullets of scope, a few user journeys, something intentionally lightweight, and they come back with a 20page document. s124 00:09:41.120 --> 00:09:44.080 Maybe it looks polished with fancy pros. s125 00:09:44.080 --> 00:09:48.880 But now I have to spend hours figuring out whether there's any real thinking inside it. s126 00:09:48.880 --> 00:09:51.760 That is AI generated work in the worst sense. s127 00:09:51.760 --> 00:09:53.440 It does not clarify the problem. s128 00:09:53.440 --> 00:09:54.880 It expanded it. s129 00:09:54.880 --> 00:10:03.920 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. s130 00:10:03.920 --> 00:10:07.600 In code, a vague task becomes a large PR. s131 00:10:07.600 --> 00:10:10.399 A small feature becomes a pile of files. s132 00:10:10.399 --> 00:10:16.240 The output arrives with the shape of completion, but the real work has just moved to the reviewer. s133 00:10:16.240 --> 00:10:19.120 And that is the part that we need to be honest about. s134 00:10:19.120 --> 00:10:23.600 Generation is cheap, but evaluation is expensive. s135 00:10:23.600 --> 00:10:28.800 If AI produces more than humans can possibly evaluate, it has not accelerated the team. s136 00:10:28.800 --> 00:10:31.760 It has created a bottleneck. s137 00:10:32.560 --> 00:10:37.120 One thing that I find particularly annoying is Twitter. s138 00:10:37.120 --> 00:10:46.480 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. s139 00:10:46.480 --> 00:10:48.480 The Ralph loop was one of those. s140 00:10:48.480 --> 00:10:53.279 It was made to sound like a novel agentic breakthrough when it's just a while loop. s141 00:10:53.279 --> 00:10:58.320 Somehow we've completely forgotten that lines of code is a garbage metric for productivity. s142 00:10:58.320 --> 00:11:04.640 But then we decided that it's different than deciding the engineer who burns the most tokens must be producing the most. s143 00:11:04.640 --> 00:11:09.279 We used to break a feature into small atomic pieces we could reason about. s144 00:11:09.279 --> 00:11:12.079 Small enough to hold in your head and actually review. s145 00:11:12.079 --> 00:11:22.560 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. s146 00:11:22.560 --> 00:11:28.560 The key point I want to highlight here is that we do not forget the ground truths we've always known. s147 00:11:28.560 --> 00:11:32.959 60 years of software wisdom hasn't been invalidated by AI. s148 00:11:32.959 --> 00:11:38.800 Composable code, good patterns, and solid practices remain essential. s149 00:11:40.079 --> 00:11:51.519 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. s150 00:11:51.519 --> 00:12:05.600 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 s151 00:12:05.600 --> 00:12:18.240 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 s152 00:12:18.240 --> 00:12:23.279 then languages like Ruby where the primary design goal was programmer happiness. s153 00:12:23.279 --> 00:12:30.480 Just like in languages, we built abstractions for garbage collection and manual pointers, AI is abstracting away the imperative bits. s154 00:12:30.480 --> 00:12:35.440 It does not remove the need to understand how a system comes together cohesively. s155 00:12:35.440 --> 00:12:43.519 This is why diagrams matter so much, not as decorative documentation after the fact, but as a way of making systems legible. s156 00:12:43.519 --> 00:12:50.240 When a agents can generate thousands of lines of implementation detail, humans need a compressed review surface. s157 00:12:50.240 --> 00:12:54.399 service boundaries, data flows, state transitions, and failure modes. s158 00:12:54.399 --> 00:12:59.920 A good diagram lets us see the shape of the system in a way code often obscures. s159 00:12:59.920 --> 00:13:06.399 We can leave the main process or workflow as the reviewable surface with implementation details pushed to the leaves. s160 00:13:06.399 --> 00:13:12.800 That is why I vouch for declarative code and architecture patterns that create layers humans can actually reason about. s161 00:13:12.800 --> 00:13:15.279 The goal is not just code generation. s162 00:13:15.279 --> 00:13:19.839 The goal is human knowledge, human understanding, and human review. s163 00:13:19.839 --> 00:13:23.600 We need to optimize for that human layer. s164 00:13:23.839 --> 00:13:30.079 Cognitive overhead is a tax every engineer has to pay before they can make a meaningful change. s165 00:13:30.160 --> 00:13:38.560 It is the time spent figuring out where code belongs, which pattern to follow, and what proper implementation actually means. s166 00:13:38.560 --> 00:13:40.639 AI does not remove this tax. s167 00:13:40.639 --> 00:13:43.440 Unless tamed, it exacerbates it. s168 00:13:43.440 --> 00:13:48.000 An agent can generate five plausible patterns in five different styles. s169 00:13:48.000 --> 00:13:58.160 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. s170 00:13:58.240 --> 00:14:07.839 The answer to this is conventions standards documented flows small reviewable surfaces and clear ownership boundaries and definitions of done. s171 00:14:07.839 --> 00:14:12.800 The more obvious the path, the less room there is for slop to hide. s172 00:14:14.959 --> 00:14:19.199 I want to give special recognition here to Rails and its place in my heart. s173 00:14:19.199 --> 00:14:24.720 Rails matters here because it shows what happens when a framework aggressively reduces decision surface. s174 00:14:24.720 --> 00:14:33.600 When conventions reduce your overhead rather than ending up with 10 different ways to structure the same concept, you end up with one. s175 00:14:33.600 --> 00:14:39.600 It may not be perfect in everyone's subjective opinion, but it's understood and it works. s176 00:14:39.600 --> 00:14:45.199 In my career, between my first and second 4A with Rails, I had a gap of four years. s177 00:14:45.199 --> 00:14:54.480 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. s178 00:14:54.480 --> 00:15:01.040 I could hop right back into a codebase and immediately understand intent without needing to parse through architecture. s179 00:15:01.040 --> 00:15:07.279 It allows engineers to easily move between projects laterally with minimal ramp up. s180 00:15:07.279 --> 00:15:11.440 The same can't be said about other language ecosystems. s181 00:15:11.440 --> 00:15:23.519 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. s182 00:15:23.519 --> 00:15:26.880 This is well supported by the official Rails doctrine. s183 00:15:26.880 --> 00:15:39.600 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. s184 00:15:39.600 --> 00:15:43.760 It is the reduction of cognitive overhead. s185 00:15:44.399 --> 00:15:47.600 Everything I've talked about today is what led us to build ORC. s186 00:15:47.600 --> 00:15:57.360 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. s187 00:15:57.360 --> 00:16:00.639 We built ORC because we kept seeing the same failure pattern. s188 00:16:00.639 --> 00:16:04.480 AI could generate code but the surrounding discipline was still missing. s189 00:16:04.480 --> 00:16:09.839 The planning, the review, the adversarial checks, the context management. s190 00:16:09.839 --> 00:16:14.320 Over time, we found ourselves repeating the same human processes to fight slop. s191 00:16:14.320 --> 00:16:24.000 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. s192 00:16:24.000 --> 00:16:27.680 ORC is taking those lessons and baking them into the workflow. s193 00:16:27.680 --> 00:16:32.639 It is not a magic box that makes correctness disappear as a human responsibility. s194 00:16:32.639 --> 00:16:37.600 It is a system for preserving that responsibility while letting agents do more of the lift. s195 00:16:37.600 --> 00:16:40.240 The goal is not to ship more generated code. s196 00:16:40.240 --> 00:16:47.440 The goal is to ship software that is still coherent, tested, maintainable, and owned after the generation happens. s197 00:16:47.440 --> 00:16:51.120 Because the future is not vibe coding better, faster. s198 00:16:51.120 --> 00:16:54.720 The future is orchestration with judgment. s199 00:16:54.959 --> 00:16:59.360 Thank you all for your time and remember, don't get sloppy. s200 00:17:14.911 --> 00:17:16.911 [music]