生成廉价而审查昂贵：如何终结 AI 垃圾代码交付

[Speaker 1]: everyone, my name is gabriel martina as i go by gabble. i'm an engineering manager and residents, slop, boward and AG to i, 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 hope. but the thing it points that has long been around only now it happens at work speed. [Speaker 0]: 没有没有没有没有 ah. [Speaker 1]: slop is what happens when judgment when generation now runs judgment. slop is not ai generated code. i don't mean to define it, a some concrete objective thing that can easily be snifed out, although there are tells slop is output that looks finished before the thinking is finished. it is work. product is outks ambiguity was cleared with guesses where tradeoffs we're left a 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 about choice, the dangers 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 educase that would have changed the design. the work arrived already smooth over. and with it, the unknown unknowns stayed unknown, but software is a record of choices, technical choices, product choices, operational choices, user facing 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 the accepting output. we are just a code monkey hitting the merge button.

[Speaker 1]: i'm not the periothat's come here to it 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 drunk and ai stupid. it's absolutely understandable given the advancements mates since december twenty five, how we got to where we are, but we need ds to diet of 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 scuffled 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 system, m the long hohoexercising judgment and restraint at the system mararchitecture 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 got overly excited and build bohemets of spagheti product nonsense. it's almost as if they 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 red, 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, and the agent can operate with much more effectively inside a code base that has structure patterns, clear boundaries and rationnow. 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. the extra had this great line, if we get count lines of code, we would not think of them as lines produced. but as lines spent, it is a 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 on the bill that bill shows up as confusion, pttoflows features, nobody wants to judge because they don't fully understand. it shows up as product surfaces that technically do everything, but feel like amazed think about that special kind of beto bloated beat to b software, where every task requires training, where every screen has twelof escape patches. and nobody can explain whether the complexity is there, because users needed it or because teams just kept that tting things teams should be held accountable for work.

[Speaker 1]: they are producing accountability is the key word here taking ownership over the product of your 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, meriicthat can be made visible for each chunk of work product. we're entering the age of bloated loloated with spagetu UX on order order worworkinds of bitter b erp s. you may have ever been trained to use today. anyone can vigoat an application in an hour and end up with a working clicicicable 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 props turn into screens. they see a terminal obsession produce something that looks like 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 code base off that stakeholders do not live in the code base, often experienced that prototype as evidence that the heart part is over. they're not thinking about the parts where real battle harden engineers earin their keep. it's outside the happy path figuring out how to go inhesively inteagree, a new feature ure set 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 is in complete garbage. they're not at all thinking about the most time consuming bits, the human parts, the last mile, where the judgment lives. this is where someone has to read the code test the behavior, othe tratraoffs nonotice 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 you it costs the creative seeal life, who, on the topic of full request, says, you say, oh, it's free. no, it's not free. where 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 twenty five years. that is not free. and this really struck a cord with me. i couldn't have set it better. it's easy to eat of pr, but who has the own that thing whois responsible for the repercussions of what that means？ so external pressures from stakeholders, coupled with pressures of competing with slappt msters begeget smoooocho slappo. i'm sure most of you have seen this in the wild were the bad engineers, the ones who don't review the details that don't refine the spect that aren't detail oriented and the 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 a yields performance anxiety where an team environments can pressure engineers to merge pr faster than they can judge, leading to code being merged without full understanding short term thinking, getting that pr in winds over long term cold health. i personally felt this anxiety where engineers around me were emerging at an incredible pace. and i felt constant anxiety that i was not moving fast enough. and i can admit that it led me emerge 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're driven by incentive. and if incentives are driving people to get ps in, then we're going to be be in for a rute. awakening rewards should be centred around producing value, elegant wealth, factred, pragmatic system design and around clarity of test and evaluation harnesses. there's just something that really grinds my ears about seeing a multi thousand line PR. there's no way in hell that a human can fully understand all the important bits of a changed that big. it is. our job is 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 happened in the most mundanways ways. you give someone ten bullets of scope a few user journeys, something intentionally light weight. they come back with with twenty pages document. maybe it looks polished with fancy pros, but now i have to spend hours figuring out whether there's any real thinking, incited that is AI generated work. in the worst sense, it does not clarify the problem. it expanded. it took ambiguity that should have been resolved by the person dodoing work, work and handit back as a larger art effect for other stakeholders to do it in code of ague task becomes a large PRA. small feature becomes a pilofiles. 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 accelelerated the team. it has created a bottleer.

[Speaker 1]: one thing that i find particularly annoying is twitter. you've got all these self proclaimed experts and clickbaters summarizing some talk or promoting some truth that we've always known as if there's some novel genius idea. the rough loop was one of those. it was made to sound like a novel agentic breakthrough when it's just a wild 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 typed two sentences and expect a whole not fully thought out feature set back in one shot without really understanding. it is what it is. we're asking for the key point. i want a highlight here is that we do not forget the ground troops. we've always know sixty years of software wisdom hasn't been invalidated by ai composable code, good patterns and solid practices remain essential. a friend recently challenged me and why i spend so much time thinking about guard rail 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 implementation details 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 ablevel abstraction. i've tus to see then java, then languages like rube where the primary design was programmher happiness, just like in languages, we built abstractions for garbage collection and manual poinners. ai is abstracting away the imperative bits. it does not remove need to understand and how system comes together. coheciand food. this is why diagrams 's matter so much, not as decorative documentation after the fact, but as a way of making systems eligible, when agents can generate thousands of lines of implementation detail. humans need a compress review, surface service boundaries, data flows, stay 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 push to the ves ves. that is i have vowed for declative code and architecture patterns that create layers. humans can actually reason about goal. als is not just code generation. goal is human knowledge, human understanding and human review. we need to optimize for that human layer. carcargave overhead is attacks. every engineer has to pay before they can make a meaningful change. that 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 taines it exererates, an asian can generate five plausible patterns in five different styles. and now the human reviewer has to reverse engineer, not just the code has to retent behind it. an proper conventions in 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 ten different ways to structure the same contecept to 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, four agyes with rails. i had a gap of four years. it was beautiful to come back after that gap that they see that the same patterns and defacctto libraries were still the same patterns and defacctto libraries. i got hop right back into a code base and immediately understand intent without needing to pass through architecture. it allows engineers to easily move between projects latterally with minimal rampop. the same camp beatten said about other language equissistems have a script 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 ames ames optized for programmer, happiness and convention over configuration as cord pillars, and describes convention as a way to eliminate recurring decisions and lowering the barrier to getting started. it is the reduction of cognitive overoverod.

[Speaker 1]: everything i've talked about today is what let us to build dork. 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 art because we kept seeing the same failure pattern ai could generate code, but the surrounding discipline was still missing the planning the review that veryerial checks the context management. over time, we found ourselves repeating the same human processes to fight slop, break down the work, manage context, wait out your options and make sure the output enters the code base in the way the team that can can still reason about ork 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 shiship more generated code. the goal is the ship software that is still coo here and 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, offer your time and remember, [Speaker 0]: don't get sloppy.