Blog

Reading the AI-Native SDLC Playbook against my own git log.

Anthropic published a piece called “The AI-Native SDLC Playbook” recently, and its core argument stuck with me: the software development lifecycle was designed for an era when writing code was the slow part. That is no longer true. An agent can implement a feature in minutes. What is still human-speed is everything around the code: deciding what to build, reviewing what came back, and deciding whether it is safe to ship.

I read it the way I read most engineering frameworks now, with a second tab open to one of my own repos. Outr, the outbound sales pipeline I have been building, is a good test case, because almost none of it was written by hand. Of its most recent 157 commits, 149 carry a Claude co-author line. That is not a stat I calculated for this post. It is just what git log says when you grep it.

So I went stage by stage.

Plan and Design. The playbook wants an intent.md, then a spec.md, each a committed artifact a human approves before work starts. I do not have that ritual. What I have instead is a docs/decisions/ folder with three architecture decision records, each dated, each with a Context, a Decision, and a Consequences section that admits what the choice does not solve. One of them, on why the agent pipeline runs as BullMQ queues instead of something fancier, ends by naming the exact debugging capability we gave up (distributed tracing across stages) and the condition under which we would revisit it. That is not the playbook's format, but it is the same instinct: write down the reasoning before you write the code, so the audit trail exists whether or not anyone reads it again.

Build. This is where the playbook and my actual practice line up almost exactly. Work starts in plan mode, Claude reads the codebase, proposes a plan, and only then touches anything. The 149-of-157 number is what that looks like at scale over two months. What I did not expect, going in, is how well this maps onto Outr's own product: it is a pipeline of agents (Vyasa scoping the target profile, Narad scoring fit, Sanjay gathering evidence, Scribe drafting, a human approving, Apollo sending, Hephaestus learning from the edits). I am running an AI-native SDLC to build a tool whose entire value proposition is running an AI-native pipeline for someone else's sales team. The recursion was not intentional. It just happened, because it is the same shape of problem: break work into stages, let an agent own each stage, keep a human gate where judgment actually matters.

Test. The playbook's line is that “every session checks its own work before a human sees it.” My CI runs a disposable Postgres container so a real integration test can prove tenant isolation, not a mocked one, then lints, builds (which type-checks both workspaces), and runs a dependency vulnerability scan scoped to production packages only. That last part has a comment in the workflow file explaining why: a dev-only tool has a known high-severity advisory that would block every single build if the scan were not scoped, so the gate checks what actually ships, not what sits in node_modules during development. That is a human decision encoded into an automated gate, which is the whole idea. The gate does not think. It enforces a thing a person already decided.

Deploy and Maintain. Here is where I am furthest from the prescription. The playbook describes named release authorization, managed MCP servers, sandboxed non-interactive Claude runs in the pipeline itself. I do not have that yet. Deploys are still a person running a command. I do not think that is wrong at Outr's current size, but I noticed the gap plainly once I had the playbook's language for it, and it is the part I am most likely to build next.

What I liked most about reading it this way, stage against stage, is that it is honest about where the two other things I have shipped this year also land on the same spectrum without me having named it that way at the time. Book writing agents has a Noesis policy check that runs before the LLM-based quality checker, deliberately, because a deterministic gate catches a banned pattern with 100% consistency and a model-based one does not. unslop-text is built the same way on purpose: a regex pass that runs entirely in the browser first, and only then an optional model pass for the structural problems no pattern can see. Different projects, same rule showing up again: put the deterministic check in front of the subjective one, every time you can.

None of this makes the playbook a checklist I am now trying to complete. It is closer to a vocabulary. I already had most of these practices before I had the words for them, and the gaps it surfaced (no formal skills or hooks, deploy still manual, intent.md replaced by something more ad hoc) are real and worth closing. That is the actual use of a framework like this: not to tell you what to build, but to hand you a clean enough map that you can see exactly where your own system stops matching it.

Back in the first post of this series I wrote that the bottleneck was no longer typing code, it was knowing what should be built and how humans stay in control of increasingly capable digital workers. Reading this playbook against my own repo is the closest I have come to seeing that sentence turn into a checklist I can actually audit myself against.

Read this post on Substack

I am writing a series of four posts about the evolution of software development, told through the career of a developer named Maya. This is the first part, where we look at the mainframe era.

In the 1980s, programming was a chore. You spent your time trying to get work into a machine that was not designed for your convenience. Maya worked in a company where the computer was a mainframe. It was big and expensive and it lived in a room with special air conditioning.

You did not type code on a screen. You wrote it on paper forms. Then you gave the forms to a keypunch operator. They would turn your code into a stack of cards with holes in them. You gave the cards to the computer operator. They would run the job overnight. If you made a mistake in your logic, the machine would tell you the next morning. You would fix the error and try again the following day.

This was a bad way to work. But it forced you to be careful. You could not run the code to see if it worked. You had to read it until you understood it perfectly. You had to trace the logic in your head. People today think this was a limitation. In some ways it was. But it also meant that when you wrote code, you knew exactly what it was going to do before it ran.

The environment was very formal. The language most people used was COBOL. It was designed to look like English but it was not natural to write. It was verbose. You wrote a lot of lines to do simple things. The office was hierarchical. The people who ran the mainframe were like the high priests of the company. They decided who got access and when.

Then computers started to change. People began talking about machines you could keep on your desk. The people running the mainframes laughed at this. They said these little computers were toys. They were not powerful enough to run a business. They were not serious machines.

Maya did not know who was right. The mainframe was reliable. It did what it was told. But it was also slow and hard to use. She looked at the desk computers and thought they looked like a distraction. But she also noticed that the people using them were getting things done faster. They were not waiting for the overnight batch. They were changing the software whenever they wanted.

That is the real difference. Access. The people who owned the mainframes owned the bottleneck. When the computer moved to the desk, the bottleneck moved to the person. Maya realized that the office structure was built for a world that was disappearing. The authority of the mainframe operator came from control. But the power in the new world would come from speed. She was still using the old tools but she was already looking for a way to use the new ones.

Read this post on Substack

This is the second part of a four-part series on how the tools of software development have evolved. In the previous post, we looked at the mainframe era. Here, we move into the web-based application era.

The shift to the web was not just about better hardware. It was about changing the rules of who gets to see the work. When Maya started building web applications, the central mainframe was still there in the basement. But nobody cared about it anymore. The energy had moved to the web server.

We moved from a world of batch processing to a world of request and response. You clicked a button and the screen updated. It sounds simple now. At the time, it felt like magic. We were using Java and HTML and we were trying to make these things behave like the desktop software people were used to. It was hard. The browser was a terrible environment for building complex logic. It was not designed for it.

The office changed along with the tools. The mainframe people had been isolated. They were in the basement and they did not talk to the business users. Now, we had to work in teams. You had designers and product people and developers all working on the same thing. This was efficient. It was also stressful. People were constantly arguing about how to structure the code. We had three-tier architectures. We had middle layers that existed only to pass data from the database to the browser.

I think the biggest change was the speed of failure. You could deploy a change in the morning and see it break in the afternoon. Some people were terrified of this. They wanted the stability of the old way. But the people who were willing to break things were the ones who moved ahead. They learned that if you can fail fast, you can learn fast.

Maya spent a lot of time in these meetings. People were worried that the web was a passing fad. They thought it was just for showing documents. They did not see that it was a new kind of operating system. By the end of this phase, people were talking about the cloud. They said it was just someone else’s computer. Most people thought this was a joke. Maya started to think that if you could run your code on someone else’s hardware, you did not need to be a large company to do large things. She was not sure what this meant for her job. She just knew that the walls of the company were getting thinner.

Read this post on Substack

This is the third part of a four-part series on the shifting landscape of software engineering. Having covered the mainframe and web eras, we now look at the transition to the cloud, microservices, and the rise of infrastructure management.

Once we accepted that we could run our software on someone else’s machines, everything changed. We stopped worrying about hardware. We started worrying about complexity.

This was the era of microservices. We took the big, single applications we had built for the web and we broke them into pieces. We put each piece in a container. We used tools like Kubernetes to manage them. This was supposed to make things easier. It was supposed to make it so that if one part failed, the rest would keep working.

It did do that. But it also created a new problem. We had so many moving parts that nobody could hold the whole system in their head. We had CI/CD pipelines that were running tests every few minutes. We were shipping code all the time. This was what everyone wanted. But it meant the job of a developer became less about writing code and more about managing the infrastructure.

Maya spent her time mentoring younger developers. She had to teach them how to handle the new tools. They were smart, but they had never seen a system that was down because of a configuration error in a cloud provider. They expected the system to be up. They did not understand that the more parts you have, the more ways there are for the system to break.

Privacy and security became the main thing we talked about. We were putting everything online. We were storing data in places we did not own. The risk was no longer just about the code. It was about how the data moved. We were building platforms that were very powerful but also very fragile.

Maya was comfortable with this. She liked the challenge. But she also noticed that we were spending a lot of time maintaining the system. We were not building new things. We were just keeping the pipes clean. She heard people talking about quantum computing and edge AI. She wondered if we were just building more complex systems that we would eventually have to replace. She wondered if the next jump would be about intelligence, not just connectivity.

Read this post on Substack

We are at the point where the software is starting to think for us. This is the era of the digital coworker. Maya is not writing code as much as she is defining problems for agents to solve.

It is a strange shift. For a long time, the goal was to write better code. We wanted languages that were more expressive. We wanted libraries that did more work for us. Now, the machine does the work. You give it a task and it generates the code. You check it. You refine it. But you are not the one who wrote it from scratch.

This changes the role of the developer. You become a conductor. You have a set of agents that can do specific tasks. Some do the testing. Some do the deployment. Some even write the documentation. Maya spends her day managing these agents. She has to decide which agent is good for which task. It feels like she is managing a team of very fast, very literal assistants.

The company gave every developer a personal AI assistant. The goal is to make us more productive. And it does. You can do in an hour what used to take a day. But it also means the bar for what is considered hard work has moved. The company expects more output.

Maya wonders about the future. If the AI can write the code and test it and deploy it, what is the value of the human? She thinks the value is in the decisions. The AI can do the work, but it cannot decide what is important. It cannot decide what a good product looks like. It does not have taste.

She sits at her desk and watches the assistant suggest a solution. It is a good solution. It is often better than what she would have written. She accepts it. She realizes that we are no longer building tools. We are building systems that can learn. And she is not sure if we are still the ones who are setting the direction. We are just making sure the agents do not get too far off track….

Read this post on Substack

There was a time when two simple words meant everything.

Hello, World.

If you learned to program at any point over the last several decades, those were likely the first words you ever made a computer display. They certainly were for me.

My first version was not written in Python or JavaScript. It was not even C. It was Assembly language. Every character mattered. Every instruction mattered. Getting those two words onto a screen felt like magic because it meant I had finally convinced a machine to do exactly what I had asked.After that came C, C++, Java, JavaScript, and almost every language I learned afterward. The ritual never changed. Before building anything meaningful, you started with Hello, World.

It was a tiny program, but it represented something much bigger. It was your introduction to a new way of thinking. Years later, when I first gained access to ChatGPT, my instincts took over. The very first thing I asked it to do was simple.

“Generate a Hello World program.”

At the time, access to large language models was limited. There were no headlines about artificial intelligence transforming every industry. Most people had not even heard of ChatGPT yet. It was something you accessed through an invitation, shared quietly among people who were curious enough to experiment. As programmers, we all have habits. Mine was testing a new technology with the simplest possible problem.

Could it write Hello World? It could.

But after only a few conversations, I realized I was asking the wrong question.

Hello World was never the point.

The real surprise was not that artificial intelligence could generate a few lines of code, I mean it was cool but there were other software that would do the same. The surprise was that it could explain the code, modify it, rewrite it in another language, debug it, and then help design an entire application around it.

The first program had quietly become the whole program. That was the moment something shifted. For decades, programming started with a blank editor and a cursor blinking patiently, waiting for us to type the first line. Today, many developers start with a conversation instead. The cursor is still there, but increasingly it is waiting for us to describe what we want rather than how to build it.

That changes more than software development. It changes the relationship between humans and computers.

We are moving away from instructing machines one command at a time. Instead, we are defining goals, setting constraints, reviewing outcomes, and collaborating with systems that can reason through increasingly complex tasks.

Writing code is becoming less about syntax and more about intent. Of course, software is not disappearing. Good engineering still matters. Architecture still matters. Security, governance, scalability, and experience matter just as much as they always have. If anything, they matter more because artificial intelligence can produce software faster than ever before.

The bottleneck is no longer typing code. The bottleneck is knowing what should be built, why it should exist, and how humans remain in control of increasingly capable digital workers.

That is where this series begins.

Over the next ten blogs, I will explore how artificial intelligence is changing the way we work, not by replacing people, but by creating a new partnership between humans and digital workers. We will look at agentic artificial intelligence, autonomous systems, orchestration, governance, and the emerging architectures that make this collaboration possible.

Hello, World was once our first conversation with a computer. Perhaps the next era of computing will not be defined by the first program we write.

It will be defined by the first digital colleague we learn to work alongside.

Read this post on Substack

I've always believed that the best way to learn is to stay open. Open to new people, new problems, and the kind of opportunities that don't fit neatly into a plan.

That mindset took me from building payment systems at Amazon to shipping voice AI on Alexa to leading AI strategy at Moderna. And now it has me as tech advisor on an enterprise agent evaluation platform, while finishing my MBA at MIT Sloan (cross-registered at Harvard Business School).

None of that was mapped out. Each step started with a conversation, a question I couldn't stop thinking about, or a problem that felt worth solving.

So this is a small corner of the internet where I'll share what I'm working on, what I'm learning, and what's on my mind. If something here sparks a thought, I'd love to hear from you.

I'm always ready to explore new opportunities. Let's talk.

shripathmit@gmail.com