First, a little about me

My career has been that of a QA — a Quality Assurance Engineer. The title is a bit of a misnomer: a QA isn’t an engineer, and doesn’t assure quality.

It comes from manufacturing, where a QA’s job was (simply put) to check the widget coming off the line and confirm — assure — that the machine was producing to a high standard. That doesn’t map cleanly onto modern software.

I work for a SaaS company that builds genuinely complex software, some of it processing billions of dollars in payments. Objectively, we are very good at building software.

Our teams are small: four or five developers and a QA. We’re agile, we move fast, and we break features into thin, easily validated vertical “slices” we can get in front of customers quickly — so we learn whether what we’re building actually adds value.

In a world that moves this fast, the QA’s job is to shift left, to move as far up the SDLC as possible:

Planning → Analysis → Design → Implementation → Testing & Integration → Maintenance

Historically, QAs lived in those last two phases. Modern shift-left puts us in from the very first one — assessing risk, teasing out concepts, poking holes before they become code.

Developers go deep. QAs go wide. (T-shaped people, if you’ve met the term.) No one person is both — you get depth or breadth — which is exactly why a good QA and a good developer make such a strong pair. The skills are complementary.

I’ve spent ten years as a QA: traditional software, hardware and firmware, modern agile delivery. In September 2025 I moved into leadership as a Tech Lead, running a team of developers and QAs on our Identity and Community work, augmented throughout with AI.

Building software of my own, though, had always been out of reach. Call it aptitude, time, or just the way I’m wired — I’ve never been able to write code, and not for lack of trying. But I know how software gets built. I know what good process looks like. I know a healthy CI/CD pipeline when I see one. I know how to plan and stand up cloud infrastructure. I know how to test, both exploratory and automated.

My knowledge is wide. I work across Product, UI/UX, SRE, Data, QA and Development.

I know how to build good software. I just can’t write the code myself.

Until now… sort of.

Enter AI

Large Language Models are getting genuinely good at writing code. They’ve trained on the open-source codebases of the entire internet, in every language. If there’s a process, an opinion, a language or a term that touches software engineering, they “know” it.

So the gate that used to stay shut to non-developers has swung wide open. Now anyone with access to AI can write software.

But a lot of it is, simply put… shit.

Introducing: Vibe Coding

The term was coined by Andrej Karpathy, a founding member of OpenAI. Vibe coding is when you “vibe” with an AI in a chat window: you describe the outcome, let it write all the code, and as long as what comes back looks good enough, you ship it.

Vibe-coded projects tend to be full of bugs, wide open to bad actors, and generally not fit for purpose.

Vibe coding is building a soapbox racer and merging onto the motorway.

And here’s the problem: “vibe coding” has quietly become the word for everything built with AI. The assumption now runs one way — if you used AI, you made slop.

But what happens when you don’t?

What happens when you approach building software with AI the same way you’d approach it with a team of humans? When you want production-ready software that’s properly scoped, researched, planned, tested and deployed? When AI stops being the thing that writes your software, and becomes the thing that accelerates how fast you build software you understand, software you can maintain… software that’s actually good?

Introducing: Agentic Engineering

That has a name too. It’s just newer, and the vocabulary is still settling. Some call it agentic engineering (Karpathy, Addy Osmani); others augmented coding (Kent Beck) or vibe engineering (Simon Willison). They’re all circling the same idea.

Agentic engineering is what happens when you build software the (subjectively) correct way, and use AI to go faster doing it.

Quality in = Quality out

The old warning is “garbage in, garbage out.” The inverse is just as true, and far more useful: the more rigour you put in before a single line of code exists — the research, the scoping, the risk assessment a QA does on instinct — the better what comes out the other end.

Vibe coding is low effort in. Agentic engineering is high effort in. Same tool. Opposite result.

The AI is the constant. The process is the variable.

How do I Agentically Engineer?

It starts with a scratch pad, an ideas space in my dev environment. I open a terminal, make a folder for whatever I want to build, and type claude.

Then I just talk. I bring the idea, I think out loud, I brainstorm — and Claude pushes back. My system prompt is tuned to make it play devil’s advocate: never sycophantic, always challenging me. I go in with wild ideas and half-formed thoughts, and come out with something sharp.

Like a sculptor with a block of wood: you keep cutting away everything that isn’t the thing, until what’s left is refined.

From there, a new git repo. I drop the output of that first conversation into a markdown file, open a fresh Claude session inside the repo, and feed it in as the starting point for a custom process I call Outcome Driven Agentic Design. Together we map the north star, run deep research and competitor analysis, and chart the flows through the software, the user personas, the architecture.

This is deep planning — but deliberately, it says nothing about what language it will be written in, or how the functions get built.

Once that’s done: design. Informed and constrained by everything that came before it.

Then implementation. I usually have Claude (Opus) orchestrate the build, leaning on the Superpowers plugin — subagents, TDD, the lot.

But how do you make sure it’s perfect?

I don’t.

Perfect software doesn’t exist, written by a human or an AI. Perfection is the enemy of good. Any seasoned QA or developer will tell you the same thing: you can’t write bug-free code… but you can get close.

In my experience, most of the bugs that surface in well-engineered software come from three places: a shaky understanding of customer need, ill-defined requirements, or not enough testing.

All three are solvable. The process above closes the first two by design. The last one — testing — I close by working test-first: small, easily testable slices; custom prompts and tools that let Claude run automated and browser-driven tests; and then the oldest trick there is — putting it in front of real users and iterating on what they tell me.

For a long time, I hid it

When I started building with AI, I made sure not one of my commits ever admitted it. I stripped every trace.

Because I’d watched the internet decide that “AI-assisted” and “vibe-coded” were the same thing — and that both meant bad.

I don’t do that anymore.

Now every commit I make says exactly how it was built:

Assisted-by: Claude Code (claude-opus-4-8)
Agentically-Engineered: https://nerdz.cloud/agentic-engineering

I stopped hiding the process and started proving it. Because if the work is good — and I’ve spent a career learning what good means — then the tools I used to build it aren’t something to hide.

They’re something to show.

This space won’t sit still. The models keep getting more capable, the memory systems sharper, the plugins and skills keep closing the gaps. What I do today, I’ll do differently in six months.

If you want to follow along, I write about all of it on my blog — you might be reading this there now.

Strong opinions, weakly held.

These are my opinions. They move. What I’m sure of today might not survive tomorrow’s evidence, and I’m fine with that.

Yours may differ. If they do, I’d genuinely like to hear it.

I try to be intellectually honest and aware of my own biases. If you catch one I’ve missed, please — politely — call it out.

And if you’ve read this far: thank you.