My AI Writing Roadmap: Four Tracks From Infra to Agents
I write about AI on this blog. Not "AI in general" — that's too big to write coherently about as a single topic. You end up writing platitudes. Instead, I write across four tracks, each anchored to a place where I've actually paid the cost of learning.
Since the start of the year, I've accumulated enough AI-related posts that it's time to step back and lay out the structure they fit into. This post is the map: what the four tracks are, why they hang together, what's already published in each, and what's coming next. If you've ever landed on the blog from one post and wondered whether the rest is worth your time, this is the index.
Why Four Tracks
Most AI blogs I read pick one lane and stay in it. Researchers write about model architecture. Tutorial writers write about prompts. Pundits write about jobs. Each is useful, and each is partial.
The thing I keep wanting to read — and don't find enough of — is the perspective of someone who has to make all of it work at once. The platform engineer who has to land GPU clusters and also manage the team that uses them. The senior dev whose IDE now writes 70% of the typing and who also has to decide what to even type. The architect who has to design systems that include non-deterministic agents and also evaluate whether the junior pipeline still feeds them.
That's the seat I write from. Four tracks fall out naturally:
- AI Native Infrastructure and DevOps — what changes underneath when GPUs and agents become first-class workloads, and how the operating practices that keep them alive have to evolve.
- Dev Methodology in the AI Era — how the discipline of writing software evolves when AI does most of the keystroke work.
- Engineering Roles in the AI Era — how every seat at the engineering table is being rewritten, asymmetrically.
- Agent Engineering — three-layer coverage of building agents: platform, patterns, hands-on code.
Each track maps to a place where I've actually done the work. I ran one of the larger Kubernetes deployments I know of — 200+ clusters, 5,000+ applications, 50,000 nodes, 2 million instances — so I have something to say about what does and doesn't transfer to AI Native infra. I've shipped real features using Vibe Coding, OpenSpec, and Superpowers, so the methodology track is reported, not theorized. I've sat in IC, senior dev, architect, and engineering manager chairs at different points, which is why the roles track tries to cover the whole table rather than one seat. And the agents I write about are the ones running my own finance knowledge base and stock analysis pipeline — not hypothetical demos.
The tracks don't try to be exhaustive. They try to be honest about where I have a perspective worth reading.
Looked at together, the four tracks close a loop. Track 4 is the thing you're building — an agent. Track 3 is the people who build it. Track 2 is the discipline they use. Track 1 is the platform that has to host the result. Each one feeds the next: a harder agent forces methodology to bend, which forces roles to absorb new work, which forces infra to host a different shape of workload. I write across all four because they only make sense as a system.
Track 1 — AI Native Infrastructure and DevOps
The angle: Cloud Native taught us how to run stateless, elastic, predictable workloads. AI Native breaks several of those assumptions — GPUs can't be overcommitted the way CPUs can, models have minute-scale cold starts instead of second-scale, and the failure modes are stochastic rather than crash-or-not. About 70% of what we built for Cloud Native — at the infrastructure, platform, and DevOps layers — transfers. The other 30% has to be rebuilt. This track is the practitioner's account of what's in each bucket, including how operating practices themselves have to evolve.
Published
| Post | What it covers |
|---|---|
| Cloud Native → AI Native Infrastructure | GPU clusters, schedulers, hardware platform management |
| Cloud Native → AI Native App Platform | Application platform layer for model and agent workloads |
| IaC and Kubernetes as a Two-Layer Control Plane | Why the IaC + K8s split survives the transition |
| DevOps at Scale | How DevOps practices hold up at hundreds of clusters and tens of thousands of nodes |
Coming next
| Post | Why it matters |
|---|---|
| Agent Runtime on AI Native Platform | Bridges this track and the Agent Engineering track. Agents need a different runtime profile from both stateless web apps and batch ML training, and the platform implications are real. |
| Agent DevOps | When the workload is an agent that calls tools, spawns subagents, and produces non-deterministic output, the DevOps playbook — observability, rollouts, runbooks, incident response — has to be redesigned. |
The reason this track exists at all is that I find most AI infrastructure writing either too high level ("GPU compute is different!") or too narrow (a single inference optimization technique). The interesting writing happens at the platform level — where a few dozen architectural choices end up determining what tens of thousands of users can actually do.
Track 2 — Dev Methodology in the AI Era
The angle: The biggest change isn't what we build with AI — it's how the work gets done. Vibe Coding is real, and it's neither hype nor a productivity miracle. Spec-Driven Development is what comes after Vibe Coding burns the people who try to scale it. There's a methodology arc here, and most of the noise online conflates the stages.
Published
| Post | What it covers |
|---|---|
| Claude Code Series (Overview) | Entry point to a seven-part series — introduction, walkthrough, methodology evolution, use cases, and conclusions |
| 10x Productivity — An Honest Take | Where the 10x claim is real, where it's marketing, and what actually changes |
| From Vibe Coding to Spec-Driven Development | The arc most teams have to traverse — and why Vibe Coding alone breaks at the team boundary |
| Agile Development in AI Coding | How sprint, story, and review practices have to bend |
| Stacking OpenSpec and Superpowers | A combined SDD workflow that shipped a real refactor in 3 hours with 86 new tests |
| Stacking OpenSpec and Superpowers, Three Weeks Later | Five friction points from running the stack across multiple projects, and the plugin that packages the evolved workflow |
Coming next
| Post | Why it matters |
|---|---|
| SDD at Team Scale | Everything published so far covers an individual contributor's workflow. The team-scale version — shared specs, review handoffs, drift across people — is where SDD either works or doesn't. |
This track is reported, not researched. Every post in it describes work I actually shipped using the tool described, with the rework rate, defect rate, and time-to-merge attached. That's the reading promise: no methodology I haven't run myself.
Track 3 — Engineering Roles in the AI Era
The angle: AI doesn't change every engineering role by the same amount. Some seats compress hard (the junior IC pipeline). Some seats get more important (the senior who can decompose ambiguous problems for AI). Some seats become harder to fill (the architect who has to design around non-deterministic components). I want the full map, not the one-role takes.
Published
| Post | What it covers |
|---|---|
| No More Junior Engineers? What AI Really Means for Early-Career Developers | The most controversial seat — what happens to the entry-level IC role when AI does the work a junior used to do |
| How Ops Engineers Can Stay Relevant in the Age of AI: Becoming a Platform Engineer | Ops thinking is fixing problems; platform thinking is making classes of problems impossible. AI accelerates that shift. |
| The AI-Augmented Engineering Manager: How I Run a Team in 2026 | What the EM role looks like when your team's output is 3x but your team size stays the same |
| The Senior Engineer's AI Trap: Why Experience Works Against You | Why technically strong engineers fall into specific AI adoption traps — and what the third career transition actually looks like |
Coming next
| Post | Why it matters |
|---|---|
| Architect in the AI Era | Designing systems that include agents as first-class components is a different discipline. |
| PM in the AI Era | What product management looks like when the build cost of a prototype collapsed by an order of magnitude. |
The seats compress asymmetrically. That's the thesis the track exists to defend.
Track 4 — Agent Engineering
The angle: Three-layer coverage. Bottom: the platform infrastructure that hosts agents. Middle: the design patterns that recur across agent systems. Top: hands-on code, the actual building of an agent end-to-end. Most agent writing online sits at one layer. I want to write at all three because the layers inform each other.
Published
| Post | What it covers |
|---|---|
| Taming AI Agent Uncertainty | The design pattern problem at the heart of agent engineering — how to engineer around stochastic behavior |
| Building a Personal Finance Knowledge Base with LLM Wiki | A complete walkthrough of building an investment knowledge base that an LLM can reason over — the data layer for a real agent |
| Building an AI Agent: From Claude Skills to Production | A retrospective on extending an open-source LLM wiki into a production-grade personal agent — the engineering reality of turning a working tool into a real agent |
| Building an Agent from Scratch: LangGraph, Qdrant, and the Gaps Between the Docs | The A-layer. End-to-end walkthrough of python-agent — architecture decisions, LangGraph ingest pipeline and ReAct QA agent, SQLite-first data layer, and four specific failures the tutorials don't cover |
Coming next
| Post | Why it matters |
|---|---|
| Comparing Mainstream Agent Frameworks | A practitioner's read on the frameworks I've actually used to build agents — what each is good at, where it leaks, and which I'd pick again. |
| Agent Platform — Infrastructure Layer | The C-layer view. Bridges Track 1. Where do agent runtimes actually live, and what does the platform have to provide? Still in research mode — I want a thicker case-study base before writing. |
| Agent Design Patterns | The B-layer. The methodology backbone for the series — the recurring patterns I keep seeing across agent systems. Also still in research mode; the goal is enough patterns from real systems before generalizing. |
This track is also where I learn the most, and where I'm most cautious about writing ahead of my evidence. The hands-on piece is now done. The framework-comparison piece is close. The platform and patterns pieces will land when the case-study base is thick enough to generalize from.
How I Pick Topics and Write
The short version: topics come from real work friction. If something cost me a weekend to figure out and isn't well-written about elsewhere, that's a candidate. I keep a case-study library of every project I've shipped, with the failure modes, numbers, and decisions logged — so when a topic surfaces, the raw material is already there. The actual writing is a collaboration with AI: I draft an outline, AI helps me find weak structure and dead sentences, and I rewrite the parts that matter. AI is a faster editor than I am alone, but it can't tell you what's worth writing about. That part is still entirely on me.
What I deliberately don't write about: things I haven't done. There's no shortage of speculation on AI online. The contribution I can make is to write only what's reported.
How to Read This Blog
Pick a track and start. The dates are roughly chronological within each track, so the earliest post in any track is usually a fine entry point. If you want only one piece per track:
- Infrastructure: Cloud Native → AI Native App Platform
- Methodology: Stacking OpenSpec and Superpowers
- Roles: The Senior Engineer's AI Trap: Why Experience Works Against You
- Agents: Building an AI Agent: From Claude Skills to Production
This roadmap will get updated as the "coming next" entries become "published." If you want to be notified when the next batch lands, the RSS feed is the most reliable channel — I post inconsistently across other platforms but every post lands in the feed.
The map exists because the writing is going somewhere. Four tracks, one practitioner trying to make sense of a moving target. Thanks for reading along.