Why I'm Writing About AI-First Engineering
The 17-Year Setup
I still remember the exact feeling of shipping my first real feature — a small Visual Basic form in a desktop app that probably three people used — and thinking “this is actually cool, think I can work with that”. That was 2008. Seventeen years and a lot of stack changes later, I’m a Tech Lead at Thoughtworks, I’ve shipped app features used by millions of people, and I’ve spent the last eight years obsessed with iOS in particular.
The path has been messy and non-linear: VB to .NET to mobile, enterprise to startups. iOS became the place where things clicked. I thought I knew where this was going.
And then something shifted.
The Shift
It wasn’t ChatGPT the headline. It was during a weekend when I asked Claude to translate a .NET backend I’d spent months building — into Node.js. Not summarize it. Not explain it. Fully translate it. I half-expected a broken skeleton I’d spend a weekend patching. Instead, 15 minutes later, I had working code. I deployed it to my VPS. Clients connected. Nothing broke.
I sat there for a moment not knowing what to do with that information.
I started paying attention differently after that. I noticed I was reaching for AI tools the same way I reach for the compiler — not as a novelty, but as part of the feedback loop. The questions I was asking started to change. Not “what can this do?” but “how do I design around this?” Not “is this reliable?” but “what does it mean for how I structure a project?”
The realization wasn’t “AI is impressive.” It was: AI changes how I think about building software — the process, the architecture, the team dynamics — and most of the conversations I see happening don’t go nearly that deep.
What “AI-First” Actually Means (to Me)
Let me be specific, because the phrase gets abused.
AI-first doesn’t mean “use Copilot for autocomplete and call it a day.” To me it means designing your development workflow, your architecture decisions, and your team processes around the assumption that AI is a first-class collaborator — not a shortcut, but an input you design for.
In practice that looks like: thinking about Agent Experience Design (what context does an agent need to be useful here?), building MCP servers as actual infrastructure rather than demos, and developing adaptive prompting strategies that hold up at scale. I’m working on all of this in real projects — not in theory.
Why I’m Writing This Down
Honestly? Because I can’t not.
I’m in the middle of a transition — between working full-time; building a consulting practice under my own brand; shipping indie apps, and trying to document what I’m learning as I go. Writing is an experiment I’m trying in order to process things I’d otherwise just do and forget. It forces the thinking to sharpen.
There’s also a resource I wish had existed when I started taking AI seriously as an engineering discipline. Not the hype pieces. Not the “10 prompts to 10x your productivity” lists. Something more like: here’s what I actually tried, here’s what broke, here’s what I’d do differently — from someone who’s been building production software for a long time and is approaching this with the same rigor.
That’s what I’m trying to build here.
What You’ll Find Here
Three things, one post a week:
AI workflow experiments. I’m building with agents, custom and standard, and I’ll break down what actually works. Prompt strategies that matter — like when plan mode changes everything and when it doesn’t. Skills, MCP servers wired into real pipelines (think: pulling user stories straight from your backlog into an agent’s context). The stuff that holds up in production, not in demos.
Architecture that compounds. How to structure context so AI tools stay useful as your codebase grows. The decisions that seem small now and define your system six months later.
The unfiltered reality. Balancing a full-time role, indie products, family life, and too many interests — without pretending any of it is easy.
Let’s Go
If you’re someone who wants to see what AI actually changes about how you build — agent workflows that hold up, prompt strategies that shift outcomes, architecture decisions that compound — I think we’ll have good conversations here.
See you there.