If you’ve read some of my previous posts, you’d be forgiven for thinking I am not a fan of AI. The truth is, while there are some downsides, most of the changes I’ve experienced have been for the better.
I used to argue that leaders of teams beyond a certain size can increase their leverage by maximizing the time they spend managing, rather than doing any IC work. I still think good management, especially with teams of more than a few people, should be the core mission of a leader, but AI has given me renewed appreciation for the value of being “hands-on”.
For example, our team recently released a broken feature that took much too long to revert. Most companies have some kind of feature-flagging system that allows for new features to be quickly turned on and off without a redeploy. We did not.
After a few hours researching and coding with my agent, I built a simple feature-flagging system. It was nothing fancy, but it worked. I could have used a third-party product, but I wanted something that was idiomatic to our system and worked the way our team would expect it to work. I knew they didn’t want another login to a third-party dashboard – they wanted to control it via command-line arguments, with appropriate documentation so Claude could understand it. The team immediately embraced the tools I made and has used them for all our critical deployments with almost no prompting from me.
This was a small win, but a significant one because it immediately improved the quality of our deploys across teams, and reduced overall risks.
Spending some time coding here and there not only solves the immediate problem like a missing development tool, but it also helps keep me in the loop on our systems, and helps me build trust with the team. Making directly impactful contributions also makes my job just a bit more fun.
Why am I able to contribute now, when I wasn’t before? It’s not just because Claude is doing a lot of the code-writing. It’s also because I can learn and understand new areas of the system very quickly. I can ask Claude to explain how things work. I can even ask Claude to suggest other ways of solving a problem that I hadn’t considered. I can dig in with deep questions about things I understand but am not an expert in, like PostgreSQL performance.
The same applies to onboarding anyone to anything. Our team has been organically improving all our READMEs and CLAUDE.md files and the results are far better than we would have gotten from the documentation improvement project I was considering not long ago. It’s now much easier for a new team member (whether recently hired or new to a particular team) to find the relevant code and understand it in context. When in doubt, it’s also easy for them to figure out who to talk to.
While I stand by the principle that adding new technology like languages and microservices can complicate systems rather than simplify them, the changes in AI over the last two years have softened my position considerably. Because developers can onboard to new systems and languages more quickly, I have less of a knee-jerk reaction against adding new tech and new services, and feel less inclined to enforce the monolithic model when my team is pushing against it. Many of the downsides of prematurely moving to microservices remain, but they are less significant than they once were.
Having only one or two people who deeply understand a critical system used to be a major concern. It’s still not a great situation, but because people can onboard themselves faster, and information can be gathered so quickly, I worry about it less. AI tools can deeply understand not just what code is supposed to do, but what it actually does, and they can do this without depending on perpetually outdated documentation.
Even though most people in engineering have been using AI full-time for a while now, we’re still building our intuitions about what can be done with it. Outside of engineering, the intuitions people have are even worse: many CEOs and product managers I’ve talked to view AI as a magic wand for getting work done, but still lack vision about how the products we’re building can be changed, and what whole new categories of problems we can solve with AI-based products. I believe the best ideas will come from people using the tools every day, and developing intuitions about what they can build, and I’m excited to see where that leads.