This is Part 1 of a 3-part series on building AI coding workflows that don't go rogue.
I’ve been tinkering with AI, as everybody should be, especially those in the tech space.
It’s completely disrupted the industry, and I feel like we’ve got three lanes that people are putting themselves into: AI evangelists, anti-AI, and the place in-between. The latter recognises the potency of what’s available for our use, but acts with caution, especially within software development. I’m sitting in that lane.
We are seeing countless posts and adverts of people “vibe coding” and loving the fact that they can whip up a small application in a weekend. Who doesn’t love that? I think it’s fantastic that people want to play, that they want that quick hit from seeing something come to life, or they just want to prototype something. Turning that into an enterprise-level application, however, that’s where things get hairy.
Without the right frameworks, guardrails, knowledge, and plans in place, it’s the equivalent of giving a toddler a power tool. Powerful weapon, delicate hands.
I’ve spent over 10 years watching this industry evolve. From WebForms to SPAs, from IIS deployments to cloud infrastructure, through the rise and fall of countless frameworks. AI is just the latest toolset at our disposal. The difference? It’s exponentially sped up the coding stage. That could be disastrous or fantastic, depending on who’s wielding it.
I’ve recently been experimenting with the latest hype, Claude Code. Prior to this, I’ve delved into ChatGPT (who hasn’t?), OpenAI integration, Copilot, Cursor and various others, and they’ve all been useful in their own ways. Now, I’ve become interested in agentic AI flows through Claude Code’s CLI.
The Claude Code CLI is Anthropic’s agentic coding tool you run in your terminal. It reads your entire project context, takes natural language commands, and can propose changes, create commits, run tests, and handle GitHub issues. You can impose quality gates with human-in-the-loop approval or let it run wild.
I’ve made plenty of mistakes in the past, especially with Cursor – outsourcing too much development or trying to tackle humongous changes. It always ends up with the same result: me losing all empathy and shouting and cursing at the AI like it’s a disobedient apprentice for not following exactly what I’ve been saying, going completely rogue and introducing copious amounts of bullshit I didn’t ask for, or breaking everything else in the process.
I once asked it to refactor a CQRS pattern. It decided that wasn’t ambitious enough and started introducing commands and queries I’d never even thought of, let alone asked for. Cheers for that, mate.
Here’s the thing: coding itself has never been the most complex part, not after a few years in the industry anyway. Before AI, we had StackOverflow, trawling through documentation and Google Fu. The crucial bit? Understanding whatever weird fix you were about to copy into your codebase, not doing it blindly. We essentially have the same solutions now, but on steroids and faster. Understanding is still crucial.
So, when I started building with Claude Code, I knew I needed that same discipline – understand first, execute second.
My challenge here was to attempt to make a flow as autonomous as possible, following the best practices that I have set, and handling large workflows: from planning to breaking down tasks, editing files, testing and creating pull requests with a human-in-the-loop approach in order to minimise risk.
I’ve found AI most useful for scaffolding, building foundational pieces, handling the mundane tasks. Essentially using it as an assistant that I mentor – not outsourcing my thinking to it. The longer you spend designing and building software, you realise: the less code, the better. You start thinking in terms of systems, design patterns, architectural decisions. The same principles apply with AI: you’re still the engineer – it’s just doing the heavy lifting.
Claude Code operates on command files you create in plain English. You can set global standards and project-specific briefs – chain commands together – and the more detail you give it, the better it performs. The flow I built breaks work down systematically – from project brief to individual tasks. It then uses a /SHIP command with quality gates at each stage: plan, build, test, self-review and PR creation. Human-in-the-loop approval is required at every checkpoint. I’ll walk through the exact setup in Part 2.
My approach evolved to include a GLOBAL STANDARDS file: my core principles (SOLID, DRY, YAGNI, DDD, and so forth) and standards for code organisation, error handling, security, accessibility – everything I care about when designing software. It’s essentially the popular adage attributed to Abe Lincoln: “If I had six hours to chop down a tree, I would spend the first four hours sharpening the axe.”
Preparation and smart work are more efficient and effective than brute force.
In Part 2, I’ll walk through exactly how to set up this workflow: the commands, the structure, the guardrails. Then, in Part 3, we’ll use this to turn a project brief into a working MVP. Stay tuned.
About Me
I'm Mike Nash, an Independent Technical Consultant who's spent the last 10+ years building software, leading engineering teams, and watching the industry evolve from WebForms to AI-powered development.
These days I help companies solve gnarly technical problems, modernise legacy systems, and build software that doesn't fall over. I also apparently write blog posts about shouting at AI tools.
Want to chat about AI workflows, technical leadership, or swap war stories?
Connect with me on LinkedIn or drop a comment below.
Top comments (0)