Просмотр новости
Найдите то, что Вас интересует
Спутники
РН
SpaceX
Роскосмос
NASA
СпутникиРНSpaceXРоскосмосNASA
Image
85% of professional developers now regularly use AI coding agents. Forty-one percent of new code is AI-generated. Those numbers come from Google's own May 2026 paper, The New SDLC With Vibe Coding, the numbers themselves are interesting but not as interesting as how those people should work. Addy Osmani, Shubham Saboo, and Sokratis Kartakis have written the clearest account I've seen of what happens to software engineering once you stop writing syntax and start expressing intent. Their central equation, Agent = Model + Harness, seems sensible, and their instinct to blame the harness before the model is the kind of engineering discipline I wish saw more AI adoption conversations. When a team moved a coding agent from outside the Top 30 to the Top 5 on Terminal Bench 2.0 by changing nothing but the harness, it highlighted the harness's impact on delivery productivity. The paper was great and offered valuable ideas on how you can work vibe coding into your software development process. However, the paper was missing a few things, and from my experience, those are important. And they are also the things that Scrum was developed to support. Where the word "governance" doesn't appearI went looking for it. The word "governance" does not occur once in fifty pages. "Stakeholders" appears exactly once, in the requirements section, describing the old problem: the gap between what stakeholders want and what engineers build. The paper's fix for that gap is AI-accelerated requirements generation: "a conversation between humans and AI that produces specification and initial implementation simultaneously." The paper does not describe who is involved in that conversation on the human side, but from the rest of the paper it appears to be engineers. That's not a criticism of the authors' judgment; it's a symptom of where they were standing when they wrote it. This is a paper written from inside the engineering org, for the engineering org, about the engineering org's tools. Within that frame, everything they say about oversight is genuinely good: guardrails and hooks that block a commit with a hard-coded password, evaluations with explicit rubrics rather than "does it seem to work," and observability that traces why an agent made a decision. Architecture is called "the most stubbornly human-centric phase" because architectural trade-offs "depend on business context, organizational constraints, and long-term strategic considerations that AI cannot fully grasp."Read that sentence again. It's true, and it's also the whole gap in one line. The paper treats human authority over architecture as a capability limit of the model; AI can't grasp business context, so a human has to. It never asks who that human is accountable to, how that authority gets exercised in the open, or what happens when the human judgment call turns out to be wrong. Harness engineering answers "is the agent behaving the way we configured it to?" It has no mechanism for answering "are we building the right thing, and who has the standing to say so when we're not?"That second question isn't an engineering question. It's a governance question, and it lives one level up from the harness, at the level of the team and its accountabilities.What transparency actually requiresScrum's empirical pillars are old enough now that it's easy to skim past them, so it's worth being precise about what transparency actually says. It's not "make the code visible to the people writing it." The definition is broader by design: make work, progress, and impediments visible to all stakeholders, not just the people holding the keyboard. Inspection means examining that work against agreed goals, on a cadence, not whenever someone remembers to look. Adaptation means the plan, process, or product changes the moment inspection reveals it should; adaptation gets harder, not easier, when the people involved aren't empowered to act on what they've seen.Put a harness next to that, and you can see exactly what it's missing. A harness can be transparent to the developer who configured it. It has no native mechanism for being transparent to the product manager, the compliance officer, or the customer whose refund policy the agent just implemented. That's not a technical gap you close with better observability tooling. It's a structural gap you close by putting a team with named, distributed accountabilities around the harness (requirements, development, testing, deployment, model orchestration, etc.), rather than just around the model.This is precisely the argument we're building into The Agile Product Operating Model’s (APOM) governance principles: define governance as outcomes, not checkpoints; shift it left into the discovery and delivery workflow instead of bolting it on at the end; and, this is the part the Google paper skips entirely, inspect the effectiveness of governance itself frequently, and adapt the operating model when the evidence says it's failing. Governance isn't a separate process bolted onto delivery. It's discovery and delivery, described in terms of impact and outcome instead of implementation.The accountabilities the harness can't replaceHere's where it gets concrete. AI doesn't just change how code gets written; it changes what the existing Scrum accountabilities need to do.The Product Owner's job gets harder, not easier, because AI can produce output at a speed no human could match, and something will sit in that gap: someone has to judge what's actually worth producing. That's a strategic accountability, not a backlog-refinement task, and it's the accountability that answers the question the Google paper's architecture section raises but doesn't resolve: who decides, and on what authority.The Scrum Master's job changes, too. AI introduces a new category of impediments: tool friction, skill gaps, governance gaps, and transparency failures. Someone has to remove them, and someone has to coach the team to question AI output rather than trust it uncritically. That coaching function is the human-facing half of "harness engineering." A well-designed AGENTS.md file is necessary. It is not sufficient if no one on the team has the standing or psychological safety to say that the agent's output looks wrong.And the Retrospective doesn't disappear; it has to evolve to hold a conversation that the current SDLC framing has no room for: what slowed us down, where AI helped, where it misled, and whether our junior engineers are still building the judgment they'll need once the easy execution work is gone. Prompt libraries and AI working agreements are legitimate Retrospective outputs. That's not process theater. It's the inspect-and-adapt loop operating on the harness itself, owned by the team, not just by whoever wrote the system prompt.The through-lineNone of this argues against harness engineering. Build the AGENTS.md file. Write the evals before the code. Route the deterministic tasks to cheaper models. All of that is real, and Google's paper provides a great overview of this approach. But a harness answers questions about a model's behavior. It doesn't answer questions about an organization's judgment. AI accelerates what an individual developer or agent can produce; it doesn't, on its own, accelerate a team's ability to agree on what's worth producing, notice when it's gone wrong, or change course. That's the coordination problem Scrum has always existed to solve, and it won't go away just because the code is being written faster. If anything, the faster the generation gets, the more the coordination layer is the whole ballgame.Generation is solved, as the Google paper puts it. Verification, judgment, and direction are the new craft. I'd add one line to that: judgment and direction aren't individual skills you bolt onto a harness. They're team accountabilities, and they need a framework built for exactly that, which is the argument my next post in this series is going to make in more detail.
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | AI Changed the Bottleneck. Your WIP Limits Should Change With It. | 0 | 10.22 | 08-09-2026 |
| 2 | Does Your AI Know the Scrum Guide? Twelve Questions to Find Out | 0 | 9.71 | 21-09-2026 |
| 3 | What Happens to Your Scaled Agile Ways of Working When You Adopt an Agentic SDLC? | 0 | 6.49 | 04-09-2026 |
| 4 | The AI Fluency Gap. Why Most Product Teams Are Stuck | 0 | 16.51 | 10-09-2026 |
| 5 | AI on Top of a Dysfunctional System (1): The Product Backlog | 0 | 5.29 | 20-09-2026 |
| 6 | AI Transformations And Agile Transformations Rhyme | 0 | 7.34 | 06-09-2026 |
| 7 | Can Your Team Name the Work It Already Runs With AI? | 0 | 6.08 | 14-09-2026 |
| 8 | 5 Things the Product Owner Shouldn’t Be Doing | 0 | 16.4 | 29-09-2026 |
| 9 | Do We Need A New Scrum Guide?! | 0 | 12.09 | 11-09-2026 |
| 10 | 🎉 Launched: Scrum Team Magazine | 0 | 15.76 | 09-09-2026 |