Engineering leadership is full of invisible work. You make ambiguous calls. You translate between strategy and implementation. You protect focus. You coach people through messy growth. You decide when to push, when to pause, and when to let a team learn the hard way.

The strongest engineers are not always the fastest coders. They are the ones who make the fewest expensive decisions.

An engineering principle should still work when its author is absent. Name the situation, default, legitimate exceptions, and evidence that would change it. A real tradeoff is the test.

The best engineering leaders don’t optimise for faster decisions. They optimise for decision quality. Speed only matters when the decision creates meaningful progress.

Before turning an AI productivity estimate into a staffing decision, run a bounded capacity experiment. Keep the team intact, spend the claimed capacity on work previously out of reach, and measure the downstream result before deciding. newsletter.thelongcommit.com/p/ai-gave-e...

Before rescuing a reasonable, reversible decision, clarify the goal, constraints, and review point. Then let the call differ from yours. Leadership should build decision capacity, not a queue for approval.

The best engineering leaders don’t optimise for faster decisions. They optimise for decision quality. Speed only matters when the decision creates meaningful progress.

You don’t need to chase every new tool to stay relevant. But you do need to keep learning before the market forces you to.

Before accepting a senior engineering role, inspect the learning environment. Which decisions will you observe? What tradeoffs will your manager explain? Where will you have room to make calls and examine the outcome?

Before a polished demo gets mistaken for a product decision, define what the prototype is allowed to prove, which shortcuts limit the answer, and when the experiment ends. I wrote about treating prototypes as expiring questions, not early products: newsletter.thelongcommit.com/p/the-proto...

AI can make you faster. It can also make you passive. Don’t outsource the parts that build judgment: • Understanding the problem • Thinking through tradeoffs • Reviewing carefully • Learning from mistakes • Explaining your decisions Use AI to increase leverage. Not to avoid thinking.

A team can spend three years working around a bad decision to avoid a three-month rewrite. The rewrite has a project plan, a deadline, and an estimate. The workaround is paid off quietly: one exception, one incident, a slower change at a time. Visible costs get debated. Hidden costs become normal.

AI can make you faster. It can also make you passive. Don’t outsource the parts that build judgment: • Understanding the problem • Thinking through tradeoffs • Reviewing carefully • Learning from mistakes • Explaining your decisions Use AI to increase leverage. Not to avoid thinking.

A prototype should answer a question, not win an argument through polish. Define the evidence, shortcuts, expiry, and disposition before the demo exists.

I write about AI, engineering judgment, seniority, leadership, career growth, and how software work is changing. Subscribe if you want fewer hacks and more durable thinking. newsletter.thelongcommit.com/

AI will make coding faster. That makes engineering judgment more valuable, not less.

A team that never lets attention land eventually weakens the judgment the work depends on. Recovery is maintenance for decision-making, not a perk added after delivery.

Ownership does not mean doing everything yourself. It means making sure the important thing does not get dropped. That includes: • Clarifying the goal • Finding the gaps • Pulling in the right people • Communicating progress • Managing risks • Following through • Learning from the outcome

Give agents only the autonomy their verification can support. If failure is slow to detect, rollback is painful, or proof is just the agent’s summary, narrow the task.

New leads rarely need a more optimized calendar. They need to notice where the team is still waiting for their judgment, permission, context, or courage. That is the allocation problem hiding inside time management.

Good work does not always speak for itself. Sometimes it needs a clear explanation from the person who did it.

Want to become known for good judgment? Do this consistently: • Explain the tradeoffs • Separate reversible from irreversible decisions • Ask what problem you are really solving • Document why a decision was made • Revisit the decision when reality changes Good judgment is not magic.

AI coding adoption should start with task boundaries. A bounded docs, CI, or build update is not the same risk as a performance fix across a messy system. Decide which work is agent-shaped before arguing about which agent won the benchmark.

AI did not make my work faster. It made starting easier. That is useful when I point it at work I already chose. It is dangerous when the tool starts setting the agenda because it can always produce something. newsletter.thelongcommit.com/p/everythin...

You don’t become valuable by hoarding knowledge. You become valuable by making the whole team smarter.

I’ve never seen a developer burn out from “too much coding.” I’ve seen them burn out from: • unclear priorities • constant interruptions • politics Protecting focus isn’t selfish. It’s survival. What drains you more: code complexity or context chaos?

Some work disappears the moment it ships. Some work keeps creating value. Aim for the second kind. Examples: 👇

A Markdown instruction file can be a product change. If it changes how an agent escalates, cites sources, reviews work, or hands off output, it needs ownership and review. Code should enforce boundaries. Markdown can carry behavior. Treat both as part of the system.

Good work does not always speak for itself. Sometimes it needs context. Before you assume people noticed your impact, ask: 👇

Building what you’re told to build is good. But it’s rarely enough to become truly valuable. Here’s a simple playbook: 👇

One underrated reason management is useful training: it forces you to explain intent, not just assign tasks. That maps straight onto AI-assisted coding. Agents are very good at completing the wrong task when the goal is unclear.

AI can generate code. It cannot decide what is worth building.

AI coding opinions often track accountability. If you own exploration, speed feels like leverage. If you own review, incidents, hiring, or skill growth, the same speed creates different costs. That is a better split than believers vs skeptics.

Hard production bugs are not always solved by a better theory. Sometimes they are solved by better population data. OpenAI's June 30 Rockset writeup is a useful reminder: the breakthrough was separating two crash populations that had been treated as one bug.

AI is changing software. Teams are changing. Career ladders are changing. But the hard parts still come down to judgment: what to build, what to ignore, how to lead, how to grow, and how to stay useful when the ground moves. That’s what I write about. 👇

Building it is not enough, here’s a simple playbook to make yourself more valuable: • Propose a new initiative • Implement it • Write a blog post about how you did it • Speak about it at a conference or meetup Do this a few times, and you’ll see your reputation skyrocket 🚀

AI-era interviews need realistic work, but not unpaid product work. The signal is how a candidate reviews AI output, spots risk, explains tradeoffs, and chooses tests. Bound the task, ask comparable questions, and keep your roadmap out of it.

Some friction in engineering is waste. Some is training. I am fine using AI to remove boilerplate, but careful when it removes the debugging and modeling work that built my judgment. If I own the production behavior, I need to explain it without reopening the chat.

Building it is not enough, here’s a simple playbook to make yourself more valuable: 1. Propose a new initiative 2. Implement it 3. Write a blog post about how you did it 4. Speak about it at a conference or meetup Do this a few times, and you’ll see your reputation skyrocket 🚀

If the first dev-tool evaluation happens inside an AI assistant, docs and SDK ergonomics become distribution. The agent may build the shortlist before anyone visits your site, so the product has to be legible in code, examples, errors, limits, and tradeoffs.

Token budgets are becoming engineering policy. The useful question is what kind of work deserves expensive context, stronger models, and autonomy. If engineering does not define good AI spend, finance will define cheap AI spend.

AI may make developers write less code without making the work lighter. A May 2026 longitudinal study found work shifting toward directing, evaluating, and correcting AI output. I would watch cognitive load and review concentration before celebrating time saved. arxiv.org/abs/2605.23135

I published a new Long Commit piece yesterday: AI productivity should be measured after the merge. PR count and cycle time are too early. The useful question is whether review, production, maintenance, and users absorbed the change cleanly. Code got cheaper. Ownership did not.

Agent coding has a team-learning problem. If pairing, review, debugging, and watching judgment happen move into private agent loops, a team can get faster while losing shared practice. The fix is visibility: review plans, preserve prompt and failure trails, and pair on high-risk sessions.

A June 2026 paper had Claude Code and Codex build chess engines in 17 languages. They got working systems everywhere, but language still shaped strength, cost, and supervision. AI lowers the floor. It does not erase architecture tradeoffs. arxiv.org/abs/2606.13763

A vague ticket used to fail slowly. With AI, it can become a plausible diff before anyone agrees what the change should do. For risky work, review intent before code exists: scope, non-goals, acceptance criteria, assumptions, validation plan.

AI can compress implementation without compressing accountability. That is why "% of code written by AI" is such a weak management metric. The value is moving toward deciding what should exist, verifying it, and owning what ships.

Addy Osmani's 70% problem is a management problem too. AI makes the prototype visible fast. Production work still moves into review, edge cases, security, performance, and integration. Budget for it instead of calling it cleanup. addyo.substack.com/p/the-70-pr...

DeepMind's June 18 AI Control Roadmap reads like an operations warning. If agents can touch code, data, credentials, or CI, give them scoped permissions, logs, approval gates, and rollback paths. This is production hygiene. deepmind.google/blog/securi...

AI made generation cheaper. It did not make ownership cheaper. For meaningful AI-assisted work, sign-off needs more than "the agent made it": what changed, what validation exists, what could break, and who owns it after merge.