# i've been building platforms first for 25 years. i think it's wrong now. > Source: > Published: 2026-07-15 03:55:40+00:00 i've been that person. standing in front of leadership with an 18-month architecture diagram, explaining why we need six months of infrastructure before a user touches a single feature. and it made sense. for 25 years it made sense. writing boilerplate was expensive. every feature came with a tax — database migrations, routing config, auth wiring. build a shared platform first, pay that tax once. the roadmap justified the investment. then i saw a stat that wouldn't leave me alone. roughly 60% of features on a six-month roadmap are obsolete by launch. not slightly off. obsolete. the customer's problem shifted. the market moved. you spent six months building a precise answer to a question nobody asks anymore. the longer you invest before showing something real, the more expensive it is to admit you were wrong. so you don't. you ship the wrong thing and call it "on schedule." i've done it. i've watched it happen. AI didn't create this problem. but agents are making it impossible to ignore. mckinsey's 2025 survey: 88% of organizations use AI. only 6% see real bottom-line impact. that 82-point gap isn't about tools. everyone has the same tools. but something shifted in their may 2026 report. they describe agents working overnight — enriching requirements, generating code, packaging outputs for morning review. they call it the "24-hour sprint." leading organizations see 3-5x productivity with 60% smaller teams. a product owner logs in at 9am and finds a feature went from requirements to tested code overnight. nobody worked late. agents did. that's not autocomplete. that's a different delivery model. and here's what most teams miss: it only works when the work is small, bounded, and complete. agents need to know where a task starts and ends. horizontal platform architectures don't give them that. jeremy d. miller built wolverine for .NET. in june 2026 he wrote: "the structure of your codebase is now, effectively, part of the prompt." think about that. when you hand an agent a task in a traditional codebase, the feature is spread across six folders. controller here. request type there. logic somewhere else. database access in another folder. the agent opens all of them, loads them into memory, figures out which parts matter. most of what it loads is irrelevant. imagine asking someone to fix a light switch, but first they have to read the wiring diagram for the entire house. now scale that to a horizontal platform build. you're asking the agent to build infrastructure that five future features will depend on. massive context, no concrete boundaries, nothing to test against. integration issues surface months later when the abstraction doesn't fit. horizontal builds give agents the worst possible working conditions. jimmy bogard came up with this. instead of organizing code by technical layer, organize by feature. one folder for "create shipment." inside: the request, validation, logic, database access, response. all of it. together. the agent opens one folder. everything it needs. nothing irrelevant. small scope, clear boundaries, complete end-to-end. you can put it in front of a real user and get feedback in days. and this gets better as models improve. i assumed larger context windows would make code organization matter less. but a 2026 guide put it bluntly: "a mid-tier model with good context outperforms a frontier model with a sloppy window." more context means more noise, not more signal. medtronic — FDA-governed medical device software — is advocating for this. their principal systems engineer wrote that a vertical slice is "structurally, exactly what an agentic model needs to operate reliably." without it, agents produce "outputs that are plausible and well-structured and wrong in ways that are genuinely difficult to detect." agents need boundaries. vertical slices are boundaries. horizontal platforms are the opposite. i've written before about how AI didn't kill the SDLC. i still believe that. planning, delivery, review — they're still the spine. what changes is the shape. planning gets tighter. you still write a spec. but instead of an 18-month platform, you spec one slice. section numbers, stable IDs, explicit non-goals. the spec becomes the contract the agent implements against. "this doesn't match §2.2" is ten seconds. "i think this is wrong" is ten minutes. delivery goes vertical. one complete slice — request to response, database to UI. the agent builds it overnight. the slice is testable end-to-end on day one. the integration test isn't a phase at the end — the slice IS the integration test. review splits in two. spec verification: does the output match the spec? mechanical, fast. and value verification: does this actually solve the user's problem? the check that used to happen months in now happens in days. anthropic's 2026 report: developers use AI in 60% of their work but can "fully delegate" only 0-20% of tasks. agents compress execution time. they don't compress ambiguity or accountability. review is where the human stays. morning. you log in. the agent finished slice A overnight — complete, tests passing, sitting in a PR. you review against the spec. section numbers. ten seconds. approve or request changes. while you review, you hand the agent slice B. same pattern. spec with non-goals. the agent starts building. you don't supervise — the spec is the briefing. afternoon. you put slice A in front of a real user. watch what they do. learn whether the feature solves the problem you thought. meanwhile the agent builds slice B. it's not blocked by your user review — slice B depends on slice A's interface, which the spec defines. not on whether the user liked it. evening. you take what you learned and write the spec for slice C. queue it up. go home. the agent starts overnight. nobody waits. the work is parallel because the handoffs are artifacts, not conversations. this doesn't work with a horizontal platform. what do you put in front of the user? an auth service? there's nothing to test. no feedback loop. the agent works alone for months. what stops a team from building slices forever and never committing to anything real? i keep thinking the answer is a budget clock. before you start, you decide: N attempts — maybe three, maybe five — and a fixed budget. at each attempt: did this prove a real user gets value? if yes, fund the next. if no, stop. it's what VC does for startups. finite runway. clear gate. prove it or stop. but i haven't tested this. i don't know what N should be. and most companies say they want fast failure but punish teams whose experiments fail. that's a culture problem, not a process one. i haven't run this playbook end to end. i'm watching it, thinking about it, starting to act on it. not pretending i've got it figured out. agents don't write production-ready code. they write plausible code. 29-46% of developers trust AI output. the SDLC processes — spec, review, checkpoints — are what keep them honest. the gains are uneven. clear wins on scaffolding, tests, migrations. complex interconnected work? mixed. you can create a mess. five features with five auth patterns = five systems to maintain. extract when you have evidence of shared need, not when you predict it. i want to hear from people who've actually tried this, not just thought about it: **have you moved from horizontal platform builds to vertical slices?** what broke? what got better? did your team resist it? **are you running anything like the 24-hour sprint?** agents building overnight, humans reviewing in the morning? or does that sound insane to you? **what stops your team from building forever without shipping?** budget clock? leadership pressure? something else? **if you're in a regulated industry — healthcare, finance, government — does vertical slicing feel possible?** or does compliance make it impractical? **does the "codebase is the prompt" framing resonate?** have you seen agents struggle with your codebase structure specifically? i don't have this figured out. i'm sharing it because i think it's the conversation engineering teams need to be having. if you've started moving this direction — or if you think i'm wrong — tell me why.