AI made me a better engineering leader

Estimated reading time: 7 minutes

Key takeaways:

• AI didn’t speed up her coding. It sharpened the design reviews and judgment calls that were never about code to begin with.
• Starting an ADR used to be the hardest part. Now she explains the situation informally, lets AI draft something flawed, and sharpens her thinking by disagreeing with it.
• A METR study found developers took 19% longer with AI but felt 20% faster. Her response: don’t trust that feeling. Measure what actually improves, not how fast it feels.

---

AI made me a better engineering leader, not by writing my code faster, but by sharpening the parts of the job that were never about code in the first place.

When I first started using AI, I evaluated it like a coding tool. Could it finish a function? Could it save me enough keystrokes to justify another open window? The results were mixed. Sometimes it was impressive, and sometimes it confidently invented an API. I treated it as unpredictable autocomplete and assumed that was the extent of it. I was measuring the wrong work.

Most of my job is not writing code. I review designs, plan infrastructure, document decisions, and help teams reach conclusions that hold up six months later. The important output is rarely a commit with my name on it. It is a decision that prevents the wrong system from being built.

That is where AI changed how I work as an engineering leader. It gets difficult ideas onto the page sooner, makes my review preparation more rigorous, and sometimes makes me spend longer on a decision because I can now challenge my first answer before the organization commits to it. Those are leadership improvements, not coding ones.

I stopped waiting for the perfect first paragraph

For years, the hardest part of writing an architecture decision record (ADR) was opening the document. An ADR captures a significant technical choice: what we decided, what else we considered, and which tradeoffs we accepted. That makes the first sentence feel expensive, as if starting were declaring that your thinking is finished when you know it is not.

The problem was never a lack of knowledge. It was the pressure to turn incomplete thinking directly into polished writing. ADRs are the sharpest case, but technical proposals and capacity plans produce the same delay.

AI gave me an intermediate step. Now I start by explaining the situation informally: the decision, the constraints, the alternatives, and whatever still bothers me.

What comes back is rarely good enough to keep. It gives too much weight to the wrong concern, understates a risk, or reaches a conclusion I disagree with. That is useful. A flawed draft gives me something concrete to resist, and every disagreement forces me to make my own reasoning clearer.

The important outcome is not the time saved. It is that the decision becomes visible while it can still be influenced, so engineers can challenge an assumption before it hardens into implementation. A leader whose reasoning stays in their head is a bottleneck.

I arrive at design reviews with a real line of inquiry

There is an uncomfortable transition as you become more senior: you are responsible for more systems while personally touching less of their code.

Your understanding comes increasingly through diagrams, documents, and explanations from the engineers closest to the code. That creates a risk. You can sense that a design feels fragile without understanding the mechanism well enough to explain why.

I used to compensate by asking broad questions in reviews. How does this fail? What happens during a rollout? Those questions were reasonable, but they put the analysis on the presenter in real time, and if nobody connected them to a specific failure path, the discussion moved on.

My preparation is different now. Before an important review, I choose the part of the design I understand least and work through it until I can form a precise question. With an unfamiliar framework or protocol, that means working through it interactively until I can reason about it, rather than losing a weekend to documentation.

One multi-region proposal made the value of that approach obvious. The service was going to run in several cloud regions, and on paper the design was coherent: replicate the necessary identity and configuration data, bring up the new regional deployment, and begin routing requests to it.

I kept returning to the moment between those steps. What would happen if customer traffic reached a region that was technically available but had not yet received all of the replicated identity data?

That was not a theoretical edge case. Replication takes time. The original rollout path treated “the region is running” and “the region has a complete enough view of shared state” as though they were the same condition. They were not. During that interval, some legitimate requests could be evaluated against incomplete data and rejected, causing authorization failures for a subset of customers immediately after traffic shifted into the new region.

We changed the rollout approach. Traffic enablement could no longer depend only on the service being healthy; it needed explicit validation that the required replicated state was present. The tool did not hand me the answer. Its contribution was less dramatic: it let me explore the design’s assumptions until I understood where to press.

The useful question also survived the meeting. Afterward, partial synchronization became something we looked for deliberately in regional rollouts, and I began asking authors to attack those assumptions themselves before presenting a design. That is the leadership outcome I care about. Finding one issue is useful. Turning the reasoning that found it into a repeatable team habit is better.

Sometimes AI makes the work take longer

A July 2025 study from METR, an AI research nonprofit, captured a contradiction I recognize in my work. The researchers ran a randomized controlled trial with 16 experienced open-source developers completing 246 real tasks in repositories they already knew. When they were allowed to use AI, they took 19% longer. Yet afterward they believed AI had made them about 20% faster.

That gap between measured time and perceived time matters. AI can make work feel fluid: less staring at an empty editor, a constant stream of plausible next steps. Activity feels like progress, even when reviewing and integrating those suggestions consumes more time overall. Speed cannot be assumed because the experience feels fast.

For the decisions I own, producing a possible answer is not the hard part. The hard part is determining whether the answer survives contact with operational reality, organizational constraints, and the failure modes nobody drew on the diagram. So I deliberately use AI for work that may add time.

I ask it to argue against my preferred option, to name what a skeptical security or operations reviewer would question, and to surface the assumptions a proposal depends on. Then I investigate the ones with the highest consequences. That usually sends me back to documentation, metrics, or the engineer who owns the system, but it happens while changing direction is still cheap.

One caveat. METR now describes its early-2025 finding as historical, and a February 2026 update found signals that newer tools may produce real speedups, though selection effects make the size hard to pin down. So I do not treat “AI makes developers slower” as a universal rule. The narrower lesson holds: our intuition about our own productivity is unreliable, especially when a tool makes the work feel easier.

What engineering leaders should measure instead

The most common AI metrics are easy to count: code generated, pull requests completed, and minutes saved. They have value, but they mostly describe individual throughput. 

Leadership is accountable for what happens between people: the quality of a shared decision, the clarity of a tradeoff, the timing of a risk discovery, and a team’s ability to challenge its own assumptions.

The 2025 Stack Overflow Developer Survey shows that divide clearly. Among developers using AI agents, about 70% said the tools reduced time spent on particular tasks and 69% reported higher productivity, but only 17% said the agents had improved collaboration within their teams. That is the gap leaders should watch. Faster individual work does not automatically create better collective judgment.

I now use three questions to judge whether these tools are improving my leadership:

1. Is important reasoning becoming visible earlier, while disagreement can still change it?
2. Are reviews exposing consequential assumptions sooner, especially in failure, migration, and partial-state scenarios?
3. Is critical thinking spreading? The senior person should not always be the one who finds the weakness, and progress looks like authors breaking their own designs before anyone asks.

If you want somewhere concrete to start, take the next design that reaches you, identify three assumptions it depends on, and ask AI to construct a situation in which each one is false. Pick the failure with the highest cost and verify it yourself, by reading the implementation or talking to the engineer who owns that part of the system.

Do not treat generated analysis as evidence. Bring one precise question into the review, then ask the author to run the same exercise before the next one.

Over time this compounds. Reviews get sharper, documents get more honest about uncertainty, and risks show up while they are still design choices rather than incidents. The differentiating skill is not knowing the perfect words to type into a prompt. It is knowing when an answer is superficial, which claim requires proof, and where a design relies on hope.

That was already the work of engineering leadership. AI has given me more chances to practice it.

Get articles like this in your inbox

Choose your LeadDev newsletters to subscribe to.