Blog

Two things crossed my feed recently, which caught my attention and were related to a few of my recent posts. The first was Fata, a spaced-repetition app with a blunt pitch: fight “skill rot from AI coding.” I’m not promoting Fata (or similar tools) necessarily but I found the concept interesting. The second was a Hacker News thread with more than 1,000 points where developers were asking, half-seriously, whether they should go back to a local model for daily coding because the friction might keep them sharper. The underpinning of both is the same. We can all feel certain skills quietly atrophying… ...

I switch between coding assistants from time to time. Sometimes it’s Claude Code, sometimes it’s GitHub Copilot CLI, or occasionally I’m playing with OpenCode on a side project. Each one is good at different things, and I like having the option to switch between them. What I don’t like is the tax I pay every time I move my own plugins between them. The annoying part My plugins aren’t anything fancy. A handful of skills and agents, plus a few MCP servers here and there. Stuff I’ve built up over time and want available wherever I happen to be typing that day. ...

Mark Russinovich and Scott Hanselman recently published a paper in Communications of the ACM called “Redefining the Software Engineering Profession for AI.” Their central question is what happens to early-in-career engineers when AI changes the shape of the job? Their thesis is straightforward. Generative AI acts as what they call “seniority-biased technological change.” It gives a massive boost to engineers who already know where to draw boundaries, what to watch for in production, and how to tell good output from plausible output. Engineers who haven’t built that intuition yet are left trying to steer something they don’t fully understand. ...

AI has made engineers more productive. There’s no doubt about that. What’s changed is where the time goes. The hands-on coding that used to dominate our day is shrinking, and everything around it, such as planning, design, and review, is expanding to fill the gap. The role is completely shifting. I’ve been thinking about what specifically separates the engineers who are thriving from the ones still finding their footing in this new era of software development. It’s not the tools they use. It’s the skills they develop. Here are five that I believe matter most right now. ...

Most of the conversation around AI-assisted development focuses on individual productivity. How can one engineer ship faster, write fewer bugs, automate more of the tedious stuff? But I’ve been thinking more about the team-level question: when coding speed stops being the constraint, what do you actually change about how a project is structured? My team has been running a project this way recently, and we’ve learned some things. Not all of them obvious. ...

The tooling for AI-assisted development is moving fast. Coding assistants ship new features every week, each with their own spin on agents, planning mode, and various levels of customization. It’s a lot to keep up with, and most of the discourse focuses on the tools themselves. I think that’s the wrong level to optimize at. The tools will keep changing. What’s more durable are the patterns and knowing which level of AI assistance to reach for based on the size and ambiguity of the task in front of you. ...

Conductor is a CLI my team built for orchestrating multi-agent AI workflows. We’ve been using it on a recent project and building it in the open from the start. I kept putting off this post because I wanted to get the framing right, but at this point I’d rather just get it out there and iterate. What it is Conductor is a CLI for running multi-agent AI workflows defined in YAML. You describe your agents, how they connect, and what conditions determine the next step… then you run it. ...

Welcome to my corner of the internet. I’m Jason, a Principal Software Engineer at Microsoft. Lately, a lot of my work has been taking ambiguous problems, building something real, proving it works, and handing it off to a product team to scale. That kind of work tends to live behind corporate walls: design documents, architecture reviews, prototype repos. But the thinking behind it is universally useful, and I’d rather share it in the open. The patterns, the trade-offs, the lessons from failures. That’s what this site is for. ...