Thoughts on AI SDLC

I’m blown away we’ve been able to make computers do this. I know it’s “just” algorithms predicting the next token… it could be a word, an exclamation point, or a “haha”. It’s not actually alive, Ryan, right? Right?? It sure as hell feels like someone is on the other end. But that’s the magic. The conversational back-and-forth is what sells you on the future. Of course every input will just be natural language, why wouldn’t it be? When you can speak freely to someone something that happens to know everything or is smart enough to figure it out, doors open up.

But it’s not all rainbows and ice cream. We’re still early on this journey and I have mixed feelings, at least when it comes to the software development lifecycle.


Only Programmers are Programmers

The digital age has put programmers in high demand for a couple of decades now. They were the ones who could turn your idea into something real. Entire businesses are built around teams of programmers making software to satisfy a need. I know, because I’m 25 years into this industry. The promise of AI flips all of this on its head: now anyone can be a programmer!

There’s certainly truth to that, but do we really think that AI levels the playing field so much that decades of prior experience no longer matters? I’m not so sure. Even if AI is doing the heavy lifting, wouldn’t my ideas, questions, and guidance be more effective than, say, my mom’s? Surely it would!

It can definitely deliver results in all cases, but it still feels like I’m seeing far better AI output from programmers over designers, product owners, project management, etc. And I have to think that’s because of who’s in the driver’s seat.

Code is Art

When I’m writing code, I’m also focused on the elegance of programming. Coming up with clever ways to build things is addicting. The problems often weren’t the hard part, the challenge was solving them in the cleanest, most simplistic way. Sure, I bet that led to a bit of overengineering in my day, but the point is I cared deeply about code quality and the act of producing it. It’s why programmers like to write “idiomatic” code in their language of choice. The non-idiomatic version still works, but there’s way less satisfaction.

Manually working through business logic/requirements, designing a scalable data model, writing shared modules/packages/plugins, crafting APIs… it’s a beautiful and rewarding experience. With AI, context bloat is a real problem and it makes choices based on what it can reason about within that context window. Hallucinations happen and sometimes the quality slips. Ultimately, the sad reality is that AI demands I trade productivity for the creativity, art, and joy of programming as it once was. Maybe it’s nostalgia, but I already kinda miss it.

Speed, Speed, Speed

In golf, you don’t pick up club speed from swinging as hard as you can. In fact, it’s often the opposite. Improved technique is what gets you that bump in speed. You don’t have to improve your technique and swing as hard as you can. It’s counterproductive.

Enough metaphors. In software, the speed boost is real, but it’s not enough! A 30% boost in speed could be a 50% boost in speed if we can crank out code reviews even faster! AI can write your commits! AI can create the PRs!

We need to take the gains where they come, where it makes sense and not force all things, in all ways, to adopt AI because of speed, speed, speed. Keep the best practices you’ve learned in place and utilize AI to improve your technique. Iterate your way through it.

Anyone Know How This Works?

The really good programmers know how their stuff works. What I’m seeing more and more are engineers who are a little unsure. The PRs are written with AI and code review questions are answered with AI. So who’s the expert? Maybe I’m being grumpy about this, and the actual answer is: “who cares, because Claude will fix the problems, anyway”.

As long as there are on-call rotations in software, I’m really hesitant to let that human knowledge start fading away.

Spec-Driven Development

We’ve been building features with SDD for most of 2026 now. It’s a powerful tool in the toolkit. Planning, speccing, and tasking the work into phases is exactly how you get reliable results with very limited hallucinations. Our tooling allows us to build features across many repos. We orchestrate a swarm of agents to do planning, implementation, code reviews, and testing. Certain models are good at certain things. We take advantage of that.

But.

This is a big workflow with a lot of artifacts to review before any agents do work. Not all features are big features. So we’re still hunting for the middle ground, because most of the time this feels a little heavy-handed, somewhat overengineered.


Let’s reset. That all felt a little negative… what do I like about this brave, new world?

Refactoring Made Simple

When you work on software with a lot of contributing teams it’s inevitable that you’ll end up with things that should’ve been done better. A decision deemed temporary is now baked in pretty deep. And with a handful of Product folks sorting the priorities, going back to fix it never makes the list.

But now, you can spawn a team of agents to untangle that mess. Tech debt is often ugly, but it usually comes with one benefit: you know what’s wrong with it and you know how to improve it. That’s a great recipe for steering AI toward good outcomes.

Exploration

Before AI, the ideating often happened in a proposal. It was theoretical, “here are the options”. But now? You (or “you”) can build proof-of-concepts in a matter of minutes. I’m old school, so I often like to design in the browser. It always made sense to me to explore ideas under the constraints and limitations of the stack, on-screen rendering, available components, etc.

AI makes this workflow so painless and you get to feel what customers will experience. This was always a much more effective way to explore ideas, it was just too expensive before. This is probably my favorite thing the technology affords.

Planning

A main way I use AI is to help me plan or ideate on a feature. As I mentioned above, these are those magical moments when I get lost in “conversation” and forget I’m not talking to a colleague (let’s ignore the societal impacts of what I just said, though). Tossing out ideas that push past what you’d normally consider is useful, and AI makes that really easy to do.

Of course I don’t blindly trust the output, but I do find value in sanity checking my ideas or approach against something that can look into every dark corner of the codebase and help keep me in check.

Gone is the Mundane

Easy and boring things are just gone. It started with automated tests, you get those for free now. But aside from that, there are many parts of a feature or application that you work through on your way to the good stuff. Often, you know exactly what needs to happen on those boring parts, and AI can really shine when you give it clear direction. It frees me up for the more interesting parts of my job, and I appreciate that.

MCP & SKILLs

MCP is a protocol that many services support. It expands what your AI knows and what it can do by tapping into third-party systems you use. AI interactions can be pretty great regardless, but when they can see beyond that baseline, it really is a game-changer.

SKILLs are agent instructions for specific—perhaps routine—things. You define a scoped set of context, tell the agent how to behave, describe when and why to use it, and the AI decides when the time is right during normal interactions. You can also call them explicitly, of course.

I’ve found that a solid CLI + SKILL combo is as good or better than MCP integrations, and they’re often easier on the token consumption, but that’s for another post. All of this is to say that you have to take the time to properly hone your setup for the best experience, and MCP / SKILLs are a huge part of that.

Conclusion

Admittedly, I struggle to hand full control over for AI to go crazy and build my feature. That doesn’t mean I don’t rely on AI routinely (I do), I’m just more intentional about when I bring it in. It’s AI-assisted development. I’m in control, I guide it, I determine what I don’t care to write and what I do. I still focus on small PRs, small changesets. I think many people approach it this way, but definitely there’s a camp of people whose AI trust meter is maxed out and they set it loose on their code. I’m not there yet.

I don’t know where all of this is going to go. I don’t know what it’s going to mean for the future, both in tech and for my kids, but we have a technology that’s fundamentally changing everything, and it’s improving by the day. Natural language is the future interface.

We like to complain and throw our hands up at the faults of AI, humans (engineers especially!) are hilarious in that way. But I do think it’s worth taking a moment to marvel at where we are. It really is incredible. And scary. We’ll see!

Onward.