Why This Blog
I’ve been a software engineer for 12 years. I just had my work anniversary in early March. I’ve worked in a startup, I had my own consulting company, I bootstrapped a startup, I worked in large enterprises. I’ve built a lot of things and I have little to show for, in terms of artifacts. I can give you a resume but I’ve forgotten more than what’s on that resume.
I want to start writing this blog to keep a record of what I’ve done and what I am thinking about at the time of writing. It’s not going to be your millionth tutorial on how to set up Claude Code (ok, maybe a little for one specific thing I did). But I want to show what worked for me and what didn’t. If it helps someone, great. If it doesn’t, also great.
I’m not here to tell you AI is going to change the world or take your job. I don’t know if it will. What I do know is that I’ve been using it to ship real software, and some of it has been genuinely impressive and some of it has been garbage. Like any tool. The internet opened up the world to millions of people and it also has some very dark corners. AI is no different. It’s not magic and it’s not the apocalypse.
What it is, for me, is practical. I built a media monitoring platform called Marquis. A full production system with DynamoDB, Lambda, EventBridge, Slack integration, the whole stack. I built Gilbert, a Rust CLI that talks to that platform. I coded half of both of them from my phone.
The phone thing
I have a family. Young kids. Anyone with small children knows the math: if something requires pulling out a laptop, finding a quiet spot, and getting into a flow state for two hours, it’s not getting done. Not on a weeknight. Probably not on a weekend either.
But I can write a spec on my phone during a lunch break. I can refine it at night after the kids are down. And with spec-driven development, where the spec is the source of truth and the AI implements against it, that’s enough. I write the what and the why. The AI handles the typing.
I set up Claude Code running remotely on an AWS instance and controlled it from my phone. I’d write a spec, send it over, review what came back, refine, iterate. Marquis and Gilbert got built in the cracks of my day. Ten minutes here, twenty minutes there.
What I think about AI, honestly
I’m not scared of it. If AI takes my job someday, so be it. Me refusing to learn it won’t slow it down. I’d rather be at the front of this wave than scrambling to catch up when it’s too late.
But I’m also not a true believer. I’ve seen AI write clean, correct infrastructure code in minutes. I’ve also seen it confidently generate something that would have taken down a production service. The skill isn’t in using the AI. The skill is in knowing what to ask for, knowing how to validate what comes back, and making the design decisions that the AI can’t make for you.
The developer is still the one in charge. You’re the architect, the decision-maker, the person who says “make this config-driven so other teams can use it.” The AI writes the code. You make the calls.
What’s coming
I’m going to write about the things I’ve actually built and operated. For now, I am committing to write about these three things (I claim to have expertise in):
- AI-assisted development in practice
- Distributed systems and cloud architecture
- Career engineering
I recently built a disaster recovery framework during an operational crisis. A full IaC solution for exporting DynamoDB data to safe regions. Spec-driven, built in one hour, and the entire org adopted it by noon the same day. That’s a story I want to tell. There are more like it.
There’s one more reason I’m writing this, and it has nothing to do with tech. I know very little about some of the people in my family who came before me. They’re not here to tell their story anymore. I don’t want that to happen to mine. Someday my kids/grand kids might want to know what their papa was building and thinking about during these years. This is that record too.