From Writing Code to Directing It

The Manual Era# Section titled The Manual Era

Now to provide some immediate clarity, I've never been a professional Software Engineer, nor do I consider myself one at all. My web development skills stem from learning HTML/CSS in my Grade 8 (1999) Film & TV class, so so many animated skulls and fire banners. That led to learning vanilla PHP and then eventually using that to build out some WordPress themes and sites for fun. Eventually upgraded to learning the Laravel Framework and thats been kind of my focus ever since, sorry JavaScript legends, I genuinely suck at it haha. Working for Halfbrick helped me learn the Software Development Lifecycle and things like pipelines and continuous automation (Jenkins!) and all the things around that. But I was never a Software Engineer, I was the SysAdmin! I just loved learning the stuff for fun. Definitely doesn't make me an author on the subject by any means, I did do a Diploma though at one point.

My biggest takeaway from all those learnings over the years was that I really enjoy Object-oriented programming and the Model, View Controller framework. A whole lot of that thought process is pretty much directly related to the Identity work I do every day. Hell, half of what we play with are objects and we've got PowerShell to scratch the code boy itch. Truthfully, I've built korthcore.com probably 4 times now? The first was a vanilla PHP abomination that I made as a Halo related website. The second was the first business site, a custom WordPress Web Developer business site (original huh?). The third an unreleased Laravel (+ Vue.js) Web App that sat as a companion site for when I recorded Minecraft videos (it's not a phase mum!) with it's own little blog and achievement system. And today, this!

The Experiment# Section titled The Experiment

I'm writing about it because I thought it would be a neat personal experiment to rebuild the thing I've done many times prior, but use Claude Code to do it. Now the reason I wanked on about my (at best) tenuous experience in doing this for the last ~25 years is because this isn't a:

Hey Claude! Chris here. You are a Software Engineer, full stack developer! Today I'd like you to help me build my korthcore.com website again! I want you to use purple and teal. I want a blog. I want an admin panel. Oh yeah, better make it secure too please. And don't forget, follow best practices!

I wanted to see if I could go about it via a pretty typical Project delivery way, properly breaking things into Epics and Stories / Tasks like I usually do. I'd been playing with Claude Code for a couple months, nothing crazy, mostly learning the structure and different aspects around its use (Plugins, Skills, MCP etc) and fooled around making a few fun little things (I'll be doing a series on that part too because why not), so had a pretty solid grasp of the basics now, more than generic chatbot use anyway. Given the raging hype machine about how it's gonna take our jobs, figured I'd see just how much and learn how relevant it is in my day to day, see if I can find any efficiencies or things to watch out for as I go.

I'd seen some online posts and random YouTube personalities start talking about things like orchestation and human-in-the-loop and agentic workflows and a whole bunch more different buzzwords coupled with everyone making their own AI built Kanban boards to help with organisation. This just felt like pretty generic Project Management but with extra steps. So started to research options and ways to attack what I wanted to achieve.

The Vibe Code Starter Kit# Section titled The Vibe Code Starter Kit

Now, since I wanted to genuinely guide this entire project / experiment through Claude Code, like entirely (that is the experiment, start to finish, human gated sign off points etc.), I came at this initially from a few angles. I genuinely spent a couple of weeks in these first sessions, including the research and project planning aspects (ahead) and getting a bunch of input structure and data to start with that I refined until I was happy.

I already had the stack I wanted to use to provide up front, it's the thing I know so at least I can validate most of what goes on and direct towards things I do know. I already knew I'd be hosting this on my own internal Azure Infrastructure via Infra as Code (IaC) deployment. I had my Logo and colour scheme that I've had for at least the last 10 years, put together by a good friend of mine during the YouTube days. And I had a vague idea on the direction I wanted to go for the site itself. I knew of other emerging supposed all in one, end-to-end, agentic workflow solutions people would talk about, but I wanted to intentionally guide through this whole thing, not give it full agency.

Now this is all pre repository existing, no local code. Nothing. Just an idea. So I started out initially in the Claude App, using Opus 4.6, I set up a standalone KXC.Website Claude Project to contain my thoughts and fired up my first few rounds of research and validation. These first few rounds I used to help lock in my stack, it's been a few years since I've touched Laravel and co. so wanted to check what's the go nowadays. Did some baseline planning on what Infrastructure I wanted to use and a few different cost options for how it'd go. Locked down my theming, I gave it the human drawn logo and asked it to pull out a colour palette of hex values I could use as the style theming, this gave me a pretty sexy .jsx rendered output with the palette put together for visualisation, definitely appreciated that. And one big chunk of time was asking it to look through what other people are doing around project management and web development specifically with Claude Code to help me dig through some skills or MCP tools or other Plugins to help drive the whole thing.

The BMad Method# Section titled The BMad Method

That research led me to settling on the BMad Method as the final driver for the project. I'd looked into a few others that were popping off at the time, Superpowers was one that kept popping up, as did Get Shit Done (GSD). But in the end I decided on the BMad Method as the flow it had was more aligned to how I tend to do Project workflows anyway. Plus, this was pre Claude Design, and I had noticed this Whiteport Design Studio (WDS) plugin that integrated in the BMad workflow and figured that'd be a neat addition.

I'd set up my repo by this point and fired off my first round of brainstorming using /bmad-brainstorming, I actually did two of these, one for the Infrastructure and IaC side of things and the other for the actual website architecture and tools and structure etc. I set to run through my own variation of the BMad Method Workflow, integrating dedicated WDS Design stages prior to the architecture document being drafted, a full utilisation of the Test Engineering Architect (TEA) module items as part of the workflow as well. All wank, but that was the point, I wanted to see what comes out the other side.

I spent probably about a week or two running through the full planning stages using all the BMad and WDS tools available to me:

• A couple of design sessions, refining the UX and generating HTML/CSS prototypes that I'd tweak until I was happy with the look and feel.
• Fleshed out and structured the pipeline deployment through Azure DevOps and dedicated a whole Epic to getting this set up, with a slow staged rollout of the actual resources til they were necessary (save some $$$).
• Another Epic dedicated to setting up the local WSL development environment, ensuring all tools (including Agent tools like MCP Servers or skills) were prepped and ready.
• Generating a full architecture plan and a whole bunch of project management ceremony. epics.md, sprint-status.md and a bunch of story files fully detailed.
• Determining the test suites I wanted to use and where etc.

I wanted to try and use all these options I'd put together and see how well it would build out the end result when everything was broken down into small actionable chunks. A full site page its own Epic with multiple stories relating to different components that make up that page.

The Operating Model# Section titled The Operating Model

Once the research and project management ceremony was complete, the mext stage was to determine how to best loop through each piece of work we had following the custom BMad Workflow so we could ensure each and every work item went through the same pattern or workflow, using the same skill invocations where appropriate and following a relatively strict git cadence. This is where I created an orchestation file called story-cycle.md which, realistically, was nothing more than a guided loop I could invoke on a fresh session, pick up where we left off (due to BMads sprint tracking) and keep the same rhythm of research and enhance the story, build the tests, build the code, adversarial code review, more test shenanigans and ending with a final Pull Request (PR) to the repo to kick off the CI/CD pipeline.

I'd made sure to include a whole bunch of real specific human-in-the-loop gates so I could ensure it was me signing off after putting my own eyes on it. Like I said, no full agency, and a codebase I could actually read and at least try and validate without flying blind. These human gated stop points did genuinely work more often than not, especially when coupled with some rules.md files and a handfulof custom hooks attempting to enforce it. As in the diagram above I set these at the following checkpoints:

1. Stage 0, research and refine. The full research and refining aspect. Conversational back and forth to refine the story down even further to be precisely what I wanted.
2. Stage 1, story and design. Human-gated design discussion and sign off, as well as the final sign off to generate the full story file using bmad-create-story.
3. Stage 2, red tests first. bmad-testarch-atdd writes the acceptance tests before any code exists, deliberately failing, so the build has a fixed target to hit. Human-gated on the test count and the red split.
4. Stage 3, the build. wds-5-agentic-development in dev mode builds against the frozen story, the signed design contract, and those failing tests. Initially I kicked this off in a fresh context so the agent doing the building wasn't the one that planned it, but that was causing worse outcomes from lack of quality context. Human gates on the plan, the environment check, and the finished code.
5. Stage 4, adversarial review. Once code was written, bmad-code-review ran its full adversarial review, human-gated validation of results and remediation steps.
6. Stage 5, expand coverage. bmad-testarch-automate widens the tests past the original ATDD set. Human-gated on the new coverage.
7. Stage 6, quality score. bmad-testarch-test-review runs a quality audit and scores the work out of 100. Human-gated on the score.
8. The PR. Pint, PHPStan, the full Pest run and the build all pass locally first, then the PR goes up. CI validates, I review and approve, and a squash-merge to main fires the CD deploy. Human-gated at the PR and again confirming the deploy.

The final PR gate was human-gated through the pipeline and requiring me to go review the request and approve it, assuming it passed CI (honestly, it was pretty bad at dev vs prod CI matching passes). Every commit was also human-gated for me to make sure I committed logical things together and ensured things weren't missed. There were still a lot of mishaps, even with a pretty detailed (and no, not context heavy) workflow to follow. That said, as I improved things over time, on occasion a few of these human-gated parts I would relax (mostly the commits) and refine over the length of the project.

The Core Pillars# Section titled The Core Pillars

I had more than a few funny (or frustrating) interactions during the whole project, and especially when refining a Story. The initial research and refine phase may yield changes that add complexity or additional scope and It'd raise these concerns every single time, I'd say things like "Yes please, do this." and it would come back suggesting maybe not because of the time cost involved, and would cite human work hour / effort estimates at me for different pieces of work. Appreciated for transparency, but it was some fun pushback to respond "Ignore time constraints, you're building this so human time estimates are of little consequence." and have it do what it always does, immediately agree with my suggestion telling me it's clearly a much better thought out plan. I am, after all, a genius it's the one thing each LLM agrees on! With everybody...

Do It Once. Do It Right. I held the agent to the same bar as my own standards. No shortcuts, no lazy work, foundational best practices from the outset. This included repeatedly telling the agent that we never defer work.

Build What Lasts. Docs and tests were not optional. Any story that shipped without them was not done. Arguably the best job for an agent.

Security Built with Intent. It was wholly unnecessary other than to see if we could but, Enterprise grade from the first commit. Didn't always work, but tried to instill from the get go.

Own Every Detail. The agent's gaps are my gaps. I read its reasoning, caught the work it quietly tried to defer, and signed off every gate. Directing does not mean not looking.

Trust Is Earned, Not Assumed. I did not take the agent's word that it worked, it lies so much! Human gates included required proof, screenshot validation etc. And even then some slop still gets through.

Structure Drives Scalability. Structure up front with a strong foundation ensured scaling was not an issue down the line. It also helps keep the agent with relevant context.

Now this was pre the newer discussions around having a harness or different structures for workflows or project agentic memory or insert random new fad here. I decided I'd had enough annoying repeat behaviours I was gonna set up a core pillars of sorts, effectively just a change to the CLAUDE.md but previously I'd mostly generalised that aspect and kept CLAUDE.md lean to not be too context heavy, so I added as an @reference within to a dedicated core-values.md it could at least pretend to follow for each of our sessions.

The biggest reason for creating it was explicitly just how much this mfer wants to defer work, like it's genuinely crazy how often you'll read through its reasoning, see it found a bug / issue and reason to itself "Yeah, nah, no worries. We'll defer that as its not in scope" which is inherently all well and good. But instead of communicating that at all, it decided it'd keep track in its own deferred-work.md file that it was never asked to create nor was part of our explicit workflow. Again, appreciate the fact it was at least logging them, but this was raised nowhere in discussions, only found it (early thank god) because I babysat and read all it's little back and forth self chat. The Never defer, always stop, raise the issue to discuss before continuing tenet did at least reduce that by at least 75%.

What's the Point?# Section titled What's the Point?

So what was the point of all this? Not another "AI is coming for your job" hot take, and not a sales pitch for a tool. I rebuilt a site I have already built a few times over, except this time I directed an agent to do it for me, start to finish, just to see what it could actually do and learn some stuff along the way.

I've a few more posts lined up to kind of deep dive different aspects of the build and the journey on how we got to the v1.0 release. A lot of learnings, a lot of frustrations. Claude Code absolutely carried real work, but it also went off the rails more times than I could count, where I'd only caught because reading each line of it's reasoning like a weirdo. The one constant was that the moment I trusted it blindly, it found a way to let me down, granted that was due to lack of process refinement that I'll employ for the v2.0 build (yes, I am that cool).

Each of the following posts in the series takes one phase outlined here and is expanded on further, outlining my thought process, the wins (and the failings) and what I changed ongoing to keep things on track (HINT it's been a battle). So if you're into long winded rants in an old man yells at cloud style, look no futher. New posts dropping soon!