Why I'm Writing 30 Days of AI Engineering
Eleven years as an engineer, and the last 18 months changed how I work more than the decade before. Here's why I'm documenting it all — and what I actually want to figure out.
Let me start with the moment that prompted all of this.
A few months ago I was knee-deep in a legacy codebase — the kind where the original author has long since left, the comments lie, and you spend three days just figuring out what a function actually does before you can safely touch it. Normal stuff. I’ve done it hundreds of times.
Except this time I opened Claude Code, described what I was staring at, and within about twenty minutes had a working mental model of the entire module, a refactoring plan, and a first draft of the changes.
Not because Claude Code is magic. It made mistakes. I corrected them. But the speed at which I could form a hypothesis, test it, and move forward — that was genuinely different from anything I’d experienced before.
That was the moment I realized: this isn’t just autocomplete with a better model. Something has actually shifted.
Eleven Years In
I’ve been writing software professionally for eleven years. I’ve seen the rise of cloud-native, containers, DevOps, microservices, low-code, serverless — every wave that was going to “change everything.” Most of them did change things, eventually. Usually slower and more unevenly than the hype suggested.
AI tooling feels different to me — not because it’s hype-free (it’s not), but because it’s already changing how I personally work, right now, in ways I can directly measure. The research-to-implementation loop is tighter. The cost of exploring an unfamiliar codebase is lower. The gap between “I have an idea” and “I have working code” has shrunk.
That doesn’t mean everything is better. There are real failure modes, real limitations, real ways you can get into trouble if you trust these tools too much or use them in the wrong contexts. That’s exactly why I want to write about them.
Why Document It Now
There are already a lot of AI tutorials on the internet. There are product docs, YouTube walkthroughs, LinkedIn posts about how ChatGPT “10x’d” someone’s productivity.
What I’m not seeing enough of is the engineer’s-eye view — someone actively using these tools in real enterprise work, writing about what actually happens when you put them in front of complex problems, legacy systems, security constraints, and team workflows.
That’s what I want to write. Not “here’s how to get started with X.” More like: here’s what I ran into when I tried to use X to solve this real problem, here’s what broke, here’s what I learned, and here’s what I’d do differently.
Eleven years of experience means I’ve built up a lot of pattern recognition for what works and what doesn’t in software engineering. I want to apply that same skepticism and rigor to AI tools — and share what I find.
What I’m Actually Working On Right Now
This isn’t a theoretical exercise. The topics I’m covering over the next 30 days map directly to things I’m doing at work:
- Claude Code for enterprise use cases — rolling it out responsibly, dealing with security and governance requirements, finding where it genuinely helps vs. where it creates noise
- Claude CoWork — experimenting with AI-assisted pair programming across async workflows
- GitHub Copilot — going beyond autocomplete, testing it in CI/CD, evaluating its test generation capabilities seriously
- Microsoft Copilot Studio multi-agent solutions — designing and building agent orchestration for real enterprise workflows, which is harder and more interesting than the demos suggest
- Coding agents — building agents that can take multi-step actions, and figuring out where the guardrails need to be
- Agent skills — the building blocks that make agents actually useful vs. just technically functional
- AI in the SDLC — where AI genuinely fits in the software development lifecycle, end to end
These aren’t topics I picked because they’re trendy. They’re what’s on my plate. Writing about them forces me to think more clearly about what I’m doing and why.
What This Series Is Not
I’m not going to:
- Pretend everything works better than it does
- Write “Top 10 prompts for GitHub Copilot” style posts
- Benchmark models against each other in ways that don’t reflect real usage
- Recommend tools I haven’t actually used in production contexts
I’m also not writing for people who are brand new to AI tools and need a gentle introduction. There are plenty of those resources already. I’m writing for engineers who are already in the trenches with this stuff and want to compare notes with someone else who is too.
What I Want to Figure Out by the End
Honestly? A few things I’m genuinely uncertain about right now:
Where is the actual ceiling for coding agents? Not the theoretical ceiling — the practical one, in the kinds of codebases and workflows most enterprise engineers actually deal with.
What does a well-governed AI toolchain look like for a large engineering team? Not just “enable GitHub Copilot” but the policies, guardrails, and workflows that make it sustainable and trustworthy.
Do multi-agent systems in Copilot Studio deliver on the promise? I’m building one right now and I have a lot of unresolved questions.
What’s the right mental model for AI in the SDLC? Not as a replacement for anything, but as a legitimate part of the process — where it belongs, where it doesn’t, and how to make that call.
Thirty days of writing should help me get some of these answers — or at least sharpen the questions.
See you tomorrow.
This is Day 1 of the 30-Day AI Engineering series. The full roadmap is in the pinned post.