AI in the Development Workflow: Do We Still Need the Same Process?

The Tools Changed. Should the Process?

Over the previous posts I've talked about using AI for content generation, quality checking and managing the day-to-day development workflow. All of that sits within a fairly traditional software development process. Stories, backlogs, pull requests, CI/CD. The tools inside the process changed, but the process itself didn't.

That got me thinking. Should it?

There's a lot of noise at the moment about AI transforming how we build software. Vibe coding. Autonomous agents. Natural language programming. Some of it is genuinely interesting. Some of it sounds like it was written by someone who has never had to maintain a production system. I wanted to work through what I actually think about this, based on what I've seen so far rather than what the hype suggests.

The Process Still Makes Sense

Here's my current take: the fundamental shape of a good development process hasn't changed. You still need to understand what you're building before you build it. You still need to break work into manageable units. You still need quality gates. You still need to ship working software.

Let me walk through it.

What are we building and why? When To Travel didn't start with code. It started with a domain I bought years ago because travel content has profitable keywords and a huge audience. The "why" was commercial from the start: build a content site, target those searches, earn from ads. Then I sat on the domain for years without building a thing. AI didn't change any of that reasoning. It helped me pressure-test the monetisation. ChatGPT was the one that pushed me towards an email list, which was new ground for me. But the decision about whether the idea was worth my time, and what to build first, came from me and from past attempts at passive-income sites. A model can research the space and lay out options. It can't tell you whether your idea is any good.

Feature breakdown and prioritisation. Once you know what you're building, you need to break it into features, then into stories, then into a backlog with some kind of priority order. This is where AI can start to help with the thinking. Research-focused models are decent at competitive analysis, identifying gaps, and structuring ideas. I've used them for this in the early planning stages and it saves time. But the prioritisation itself, what matters most right now for this product, still requires human context that the model doesn't have.

User stories and acceptance criteria. This is your unit of work. The thing you hand to a developer. Or to an AI agent. A well-written story with clear acceptance criteria is just as important now as it ever was. Possibly more so. If you're giving work to an AI agent, the definition of what "done" looks like needs to be precise. The AI won't push back and ask clarifying questions the way a developer in a refinement session would. Well, mine does actually. I built that into the /start-story skill, which I covered in an earlier post, but only because I told it to. A vague story given to an AI produces vague output, fast.

Refinement and shared understanding. In a team, backlog refinement exists to make sure everyone has the same understanding of the work. With AI agents in the mix this becomes about making sure the AI has the same understanding. That's what CLAUDE.md does for me. It's the standing context. The refinement session that happens before every session starts.

Quality gates. Pull requests, code review, testing, CI/CD. These are your safety nets. If anything, they matter more now. When AI is writing code or generating content at speed, the gates are what prevent rubbish from reaching production. My content quality checks, the AI PR review, the test suites. These are all gates. The process didn't change. The speed at which things move through it did, which makes the gates more important, not less.

Definition of Ready. Definition of Done. These two concepts still frame the whole thing. A feature is ready when there's evidence of need and a clear scope. A story is done when it's deployable and meets the acceptance criteria. AI speeds up the middle bit but doesn't change the endpoints.

What AI Actually Touches

If I map out where AI actually helps in my workflow, it's roughly this:

• Ideation and research — faster, not transformative. Better for organising information than generating insight.

• Planning and breakdown — useful for structuring features into stories and identifying edge cases. Prioritisation still needs a human.

• Implementation — biggest gains. Well-defined stories, good documentation, clear conventions. This is where /start-story earns its keep.

• Quality and review — AI checking AI. Content gates, PR review, test generation. Essential at speed.

• Release and deploy — unchanged. A fast, reliable pipeline is a fast, reliable pipeline regardless of who wrote the code.

The interesting thing is that AI doesn't replace any stage. It accelerates the middle stages and makes the gates more important at the boundaries.

On Vibe Coding

I need to talk about this because it keeps coming up. "Vibe coding": the idea that you can just describe what you want in natural language and let AI write the whole thing. It's appealing. It's also dangerous if you don't know what you're doing.

Here's the thing: vibe coding is still coding. The output is code. It runs on infrastructure. It has bugs. It has security implications. It needs maintaining. The fact that you didn't type it character by character doesn't change any of that.

I've seen people get excited about generating an entire application in an afternoon. And yes, you can do that. But can you debug it when something breaks at 2am? Do you understand the architectural decisions that were made? Can you extend it without the whole thing falling over?

My view: use AI to write code, absolutely. I do it every day. But stay in the loop. Review what it produces. Say no when the output isn't right. Push back. Ask it to explain its reasoning. Treat it like a very fast junior developer who is good at following instructions but doesn't always understand the bigger picture. The moment you stop paying attention is the moment the quality drops.

This is not an argument against using AI for coding. It's an argument for using it well. With structure. With review. With gates.

There's even a name forming for the disciplined end of this now: spec-driven development. Write a proper spec, refine it with the AI in plan mode, then build from it. The tooling crowd treats it as a new methodology, but strip it back and the spec is just a user story with its acceptance criteria taken seriously. I've been writing those all along. The real difference is where the spec lives. SDD keeps it in a markdown file next to the code. I keep mine as a user story in the tracker, which holds the plan and the code apart and matters more the moment there's a team. Same discipline, different drawer. More on that another time.

Which brings us back to the process.

What's Genuinely New

I don't think we need to throw out the existing playbook. The fundamentals are still right: understand the problem, break it down, build it, test it, ship it. What's changing is the speed and who (or what) does each step.

A few things do feel new.

AI needs context the way a new team member needs onboarding. CLAUDE.md, auto-memory, per-locale guidance files. These are all forms of that, and it's a practice that didn't exist before. I'm still working out the right shape of it.

Quality gates need to be automated and fast. When AI can produce code and content at high velocity, manual review becomes the bottleneck. Automated checks for code quality, content tone, or security stop being a nice-to-have and become the thing holding the line.

Stories need to be more precise. A developer fills gaps with experience and common sense. An AI fills them with assumptions that might be wrong. Clear acceptance criteria and well-defined scope matter more than they ever did.

And feature flags earn their keep. If agents complete stories faster, you've got more work in flight at once. Trunk-based development with feature flags lets you merge frequently without shipping half-finished features. None of that is new, but the case for it gets stronger.

The process is the same. The rigour required at the boundaries is higher. The speed in the middle is faster. That's the shift.

A Team of One

I'm a team of one on When To Travel. The AI workflow has made me measurably more productive. I can see it in the Azure DevOps dashboards.

But I think the approach scales. The same principles apply to a team of five or fifty. You still need clear requirements. You still need quality gates. You still need someone making decisions about what to build and why.

AI handles the execution. Humans handle the direction. The process is what connects the two.

There's one piece I haven't automated yet, and it's the one whose whole job is to make everything else better. The retrospective is the next thing I'm building.

Don't throw it out. Tighten it up.