Marcus: An AI can generate the code for a brand new feature in about an hour. But it still takes your company three weeks to actually ship that feature to users.
Harper: Right, so this is about making the AI coding assistants even faster. Closing that gap.
Marcus: No, that’s what's so interesting. The coding part is essentially a solved problem now. The bottleneck isn't the code anymore. It's everything else.
Harper: Everything else like... meetings?
Marcus: Meetings, reviews, sign-offs, handoffs. All the steps we built around the assumption that writing code is the slow, expensive part. This piece from Anthropic, called the 'AI-Native SDLC Playbook', argues the whole process is backward now.
Harper: SDLC, the Software Development Lifecycle. Plan, design, build, test, deploy.
Marcus: Exactly. And traditionally, the 'build' phase—the actual coding—took weeks or months. So we created all these gates before it. Product requirement documents, estimation meetings... all designed to make sure that when you finally commit to writing code, you're writing the right thing.
Harper: Because the developers' time was the most expensive resource.
Marcus: Right. But now, an AI agent can write the code in a day. Maybe hours. And suddenly that 'build' phase collapses. But the planning still takes two weeks. The security review still takes a week. The deployment process is still manual. The bottleneck just moved.
Harper: So you have this super-fast engine, but it's stuck in traffic on either side.
Marcus: Perfect analogy. And the playbook's idea is to redesign the traffic flow. They call it the AI-native SDLC. It's not a straight line anymore; it's a loop. And every step is mediated by the AI, using these version-controlled files.
Harper: Okay, that sounds very abstract. What does that actually look like?
Marcus: So they start with the very first step: the idea. Instead of an idea living in a ticket or a meeting, they propose this thing called an `intent.md`.
Harper: A markdown file.
Marcus: Yeah, a simple text file. And here's the wild part. Anyone can create one. Someone in customer support, or sales, or claims operations, like in their example. They have an idea for a feature. They just open up a chat with an AI...
Harper: And complain to the AI.
Marcus: Basically! They describe the problem in their own words. 'Customers keep calling me to ask for their claim status. It's a third of my day.' The AI then asks them questions a product manager would. Who's affected? What does a better outcome look like? What are the constraints? And after that conversation, the AI writes up the summary into this formal `intent.md` file.
Harper: And then what? They email it to an engineer?
Marcus: No, this is the key. They commit it directly to a shared code repository, like GitHub. The idea itself becomes the first artifact in the chain, version-controlled, with an author and a timestamp.
Harper: Wait. Hold on. So a person from the claims department who doesn't know how to code can just... commit a feature request directly into the engineering team's official codebase? That sounds like absolute chaos.
Marcus: Well, they'd use a tool that commits it for them, but yes. The idea is to capture the intent directly from the source, without it getting distorted through layers of management.
Harper: But that ignores the entire function of product management! You can't just build everything everyone asks for. Someone has to prioritize, to weigh it against the company's strategy, against other requests. This doesn't sound like it's democratizing ideas, it sounds like it's creating a firehose of demands and starting a political battle inside a git repo.
Marcus: I don't think it's saying there's no product owner. The article says the product owner 'watches' this folder of intents. Their job shifts from gathering requirements to reviewing these fully-formed proto-specs. It cuts out the game of telephone.
Harper: Okay, but what happens when you have a hundred `intent.md` files committed in a week? That product owner is going to be completely buried. Does the AI then... prioritize the intents for you? Because that's an even scarier idea.
Marcus: That's... a really good question. The playbook doesn't really get into that. It focuses on how to capture the intent, not how to manage the flood of them once you open the gates. Honestly, I don't fully get how you solve that triage problem.
Harper: So you just move the bottleneck again. It's not the coding, it's not the planning, it's the poor product manager drowning in markdown files.
Marcus: Maybe. Or maybe you're just having a higher-quality problem. Instead of guessing what users want, you're dealing with an abundance of clearly-stated needs. The human's job becomes judgment and curation, not transcription and translation. That feels like a step up.
Harper: Hmm. I'm not convinced it solves the human problem of there only being so many engineers and so much time. But I see the appeal of getting the idea down clean, right from the source.
Marcus: Right. It's the first play in their playbook. The starting point. It's not a perfect, automated future. It's just a different way to begin. I'm Marcus.
Harper: I'm Harper.