“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”

Martin Fowler

Code review has been important my entire career, and AI-generated code makes it even more important now. When the volume of code can increase without the same increase in time spent writing it, the review process starts carrying more of the burden.

Historically, code review was a relatively small amount of effort at the tail end of the work. Not a rubber stamp, but proportional to the effort invested and the size of the change. If a feature took a week to design, build, and self-test, the review might take a few hours. Even on a larger milestone, a well-sized pull request was usually something reviewers could understand in a focused pass.

I am setting aside the obvious outliers here: enormous pull requests, someone disappearing for weeks, or a pile of unrelated changes dropped into one review. Those were already bad practices. With agentic coding, we have entered an era where it can be significantly faster to produce code than it is to read, understand, and review it.

Writing Code Was Part Of The Review

Before AI coding tools became part of the normal workflow, writing code had a built-in form of review. An engineer might start with a good technical design, but the act of writing the code brought them closer to every line, every branch, and every assumption. Edge cases often appeared in implementation that had not been obvious at the level of the technical design.

That feedback loop felt natural, not like extra process, but it made a real difference in the quality of the final product. A lot of good code is not good because the first idea was perfect. It is good because the engineer kept tightening the idea while implementing it. They paused halfway through a function and noticed a race condition. They wrote a test and realized the interface was awkward. They saw that the happy path was simple, but the retry path was going to leak complexity into three other places.

Those small corrections often happen mentally, in the seconds between one line and the next. By the time the code reaches review, the pull request may look like one clean pass, but the engineer has already made several passes through the problem.

AI Changes The Ratio

AI changes that rhythm. It can produce code that is syntactically correct, compiles, follows the apparent shape of the request, and looks 95% right with relatively little effort. That is useful, and it is also where the risk lives.

Typing a function might take a minute or two. Reading the same function can take ten seconds. If the edge case is obvious, the reader catches it. If the bug sits in an assumption about ordering, permissions, concurrency, retries, stale data, or how another part of the system behaves, it is much easier to slide past it.

The first reviewer of AI-generated code is often the same person who prompted it. That person may understand the goal, but they may not have spent the same amount of time wrestling with each line. The code arrived faster than the mental model. The second reviewer then inherits a harder job: they are supposed to protect the quality bar, but now they may be reviewing code that neither human fully built up from first principles.

That is the human review bottleneck. The team can create more code, faster, while the human work of understanding intent, correctness, maintainability, and system fit does not compress at the same rate.

Start With The Plan

The answer is not to treat reviewers as rubber stamps. It is also not to ask every reviewer to become a heroic last line of defense for an ever-growing pile of plausible-looking code. A better workflow moves more of the thinking before the pull request exists.

One technique I like is iterating over the plan with the agent before asking it to write the code. Talk through the approach, the assumptions behind it, and the edge cases that could break the design. This is also a good time to explore failure modes, tests, rollback, data shape, permissions, race conditions, and integration points. The code is usually the easy part for the tool. The plan is where the human judgment belongs.

This takes more investment up front, but it changes the review. Instead of handing someone a pull request and expecting them to infer the entire design, the author can attach the plan to the ticket or pull request: what the change is intended to do, what options were considered, what risks were discussed, what tests matter, and where the reviewer should pay closest attention.

Test Cases Are High Leverage

I have found iterating on test cases especially useful. Writing tests is often tedious, but agentic coding can accelerate that part of the work without removing the need for judgment. Asking the agent to list test cases and expected outputs can reveal tests you missed, or places where the agent misunderstood the intended behavior.

Correcting those test cases and expected outcomes gives you a stronger foundation of unit tests going forward, while also feeding directly into the behavior the agent is about to implement. Instead of discovering the misunderstanding after reading the generated code, you can catch some of it while the work is still a plan.

Context Is Part Of The Code Review

The act of planning, and attaching that plan to the ticket or pull request, does not guarantee the output is correct. It does, however, give the reviewer an overview of the changes, the intent behind them, and the broader context around the work.

It can also provide value for future maintenance, assuming the code has not changed too much by then. Even when the plan is a little stale, it can still explain what the author believed they were solving, which tradeoffs were intentional, and where the important edges in the implementation were supposed to be.

This is where AI can improve engineering work rather than simply accelerate typing. Used well, it can help engineers pressure-test the design earlier, generate a better test plan, and make the intent easier to share. Used casually, it can create a lot of code that looks finished before the team has done the human work of understanding it.

I do not want teams to slow down just to preserve the old way of working. I want the faster workflow to carry enough context that reviewers can do their job well. As AI makes code faster to produce, I want engineering teams to remain responsible for understanding what was built and shipped, and for making sure the generated code is still high quality.

“Like technical debt, management debt is incurred when you make an expedient, short-term management decision with an expensive, long-term consequence.”

Ben Horowitz, The Hard Thing About Hard Things

I recently read Ben Horowitz’s The Hard Thing About Hard Things, and one idea has stayed with me more than I expected: sometimes what looks like a one-off decision is not really one-off at all. It becomes the example people remember the next time they are trying to figure out what is allowed, what is rewarded, and what will happen if they push.

Horowitz talks about management debt: the kind of debt created when a leader chooses the expedient answer now and leaves the organization to pay the interest later. That framing resonated because decisions do not live only inside the moment where they are made. They become part of the story people tell about how the company actually works.

The Decision Becomes The Example

A leader might make an exception for one person, one project, one deadline, or one customer. In the room, it can feel practical. The context is special, the pressure is real, and the decision may even be the right call.

The hard part is that the full reasoning behind that decision may not be visible to everyone else. What people see is the outcome: someone got the exception, a team bypassed the process, a deadline moved for one group and not another, or a behavior had consequences while another did not. People learn from the visible pattern.

That does not mean every decision needs to become a rigid rule. Leadership would be impossible if every exception had to be defended forever. But a leader has to understand the teaching effect of a decision, especially when the decision is visible.

People Infer The Policy

In an organization, there are the written policies and values that people refer to. In parallel, people infer policy from the decisions leaders make, especially when the choice is visible and the tradeoff is real.

A team that cuts corners to hit a date learns something about quality. An engineer who raises a risk and gets a defensive reaction learns something about escalation. A person who goes around everyone else and still gets celebrated learns something about collaboration.

This Applies Outside Management Too

The same dynamic is present in all our professional relationships. How we handle one disagreement teaches people what future disagreements with us may feel like. How we respond to bad news teaches people whether to bring it earlier next time. How we treat a missed commitment teaches people whether commitments are real, negotiable, or mostly theater.

Over time, our behavior becomes a forecast. People decide whether to tell us the uncomfortable truth, ask for help, include us early, challenge a weak plan, or trust us with something unfinished.

A Leader’s Voice Carries Weight

The impact is broader when you have authority because your choices affect more than your own reputation. A manager’s decision can become team precedent. A director’s exception can signal something across multiple groups. A CTO’s reaction in one meeting can change what people are willing to say in the next one.

That does not mean leaders should become stiff or afraid to make exceptions. It means the exception needs to be named. Why are we doing this here? What is special about this situation? What should people not infer from it? What do we need to clean up afterward so this does not become hidden policy?

Does This Decision Set Precedent?

Before making a visible decision, it helps to pause for one extra question: if people treated this as the precedent, would I be comfortable with that?

If the answer is yes, the decision reflects the standard you want. If the answer is no but the situation still demands it, it is worth naming the context directly so people understand the exception without turning it into the new rule.

“The output of a manager is the output of the organizational units under his or her supervision or influence.”

Andy Grove, High Output Management

One of the harder leadership calls is deciding who should take on important work. The easy answer is to give the hardest project to the strongest person, and sometimes that is exactly right. If the work is urgent, company-critical, politically delicate, or on the critical path for several other teams, the business may need the highest-confidence execution you can assemble.

If that is always the answer, though, nobody else grows. Meaningful projects start collecting around the same few trusted people: the tech lead, the senior engineer, the reliable person who can rescue almost anything. The work gets done, but the organization quietly becomes more dependent on a small group. You have delivery, but not development; output, but not bench strength.

Growth Is Part Of Delivery

It is tempting to treat people development as something separate from delivery: first the team gets the work done, then people grow when things calm down. The trouble is that things rarely calm down long enough for that plan to work.

People develop through real work: projects with stakes, decisions with consequences, ambiguity they have to navigate, and feedback that arrives while the work is still alive. That does not mean every project should become a stretch assignment. It means leaders have to treat growth as part of the system.

Not Every Project Is A Good Stretch Project

Some work carries too much immediate risk to use as a learning vehicle. If a project is on the urgent critical path for multiple teams, has a narrow launch window, carries a major customer commitment, or has very little room for correction, the company may need the strongest possible lead, not the person who would benefit most from the experience.

That is not a failure to develop people; it is part of the judgment. The mistake is turning that judgment into a permanent excuse. If every project is too important for anyone new to lead, the organization has no safe way to build new leaders.

What Makes A Good Growth Opportunity

A good stretch project is not just a harder project handed to a less experienced person. It usually has a few helpful traits:

• Real importance. The work matters enough that the person can feel the impact.
• Manageable blast radius. If things go sideways, the damage is recoverable.
• Clear support. The person has access to a manager, tech lead, mentor, or experienced partner before the work is off track.
• Stable cross-functional support. Partner teams understand the goal and can engage consistently.
• Visible decision points. There are moments where the person can practice judgment, not just execute a checklist.
• Enough time to learn. The schedule has room for feedback, correction, and iteration.

You do not need every one of those conditions for a stretch assignment to work. But a project with none of them is higher risk, and that risk may not be obvious until the person is already struggling. The project should be real enough to teach something, with enough support that the person has room to learn.

Focus The Stretch

One of the best ways to calibrate growth is to notice how many dimensions are stretching at once. Someone can stretch technically, in ambiguity, in stakeholder communication, in project leadership, in planning, or in risk management. More than one may be new, but it helps to know which dimension is the primary stretch and which parts of the work need stability.

A good stretch assignment might pair technical challenge with a simple stakeholder environment, or project leadership with a familiar technical surface area. It might give someone cross-functional responsibility with a senior engineer nearby for architectural support.

The question is where discomfort will help them grow, and where stability will help them succeed.

The Strongest Person Still Has A Role

Growing someone else does not mean removing your strongest people from the system. Often the better move is not to give the whole project to the most senior person, but to use that person differently. They can review the plan, identify risks, coach the person doing the work, join key design reviews, or act as escalation support.

That kind of support lets someone else lead with real guidance nearby. The senior person is still helping protect the work, but they are also helping build the next person who can carry more responsibility.

Choose Project Leads Based On Urgency And Importance

Stephen Covey’s urgent-important distinction is useful here. When work is both urgent and important, that is often the moment for your stars. The fire is real, the timing matters, and the cost of being wrong may be high.

Non-urgent but important work can be a much better candidate for development. It still matters, but the schedule usually leaves more room for planning, feedback, correction, and support.

If development is ignored long enough, it becomes urgent in the worst way: a key person leaves, a senior engineer burns out, the same bottleneck appears every planning cycle, or a team has nobody ready to take on the next level of work.

Questions Before Assigning Stretch Work

When assigning work, “Who is the safest person to give this to?” is a fair question, but it is incomplete.

Better questions are:

• How critical is this project, really?
• What is the cost of being wrong?
• Who would grow from taking it on?
• What support would make that responsibility reasonable?
• What part of the work must be senior-led, and what part can be delegated?
• If this kind of work always goes to the same person, what capability are we failing to build?

Those questions keep delivery and development in the same conversation, even when the right answer is still to put your strongest person on the work.

Deliver And Develop

When leading a team, I try to balance what is best for the company in the short term with what builds the team for the long term. That means growing individual contributors through meaningful and challenging work while recognizing that some assignments carry more risk than others.

“Delegation without follow-through is abdication.”

Andy Grove, High Output Management

Delegation sounds simple from the outside, but it gets harder once you are the person responsible for both the work and the person doing it. Beyond simply dropping work on someone, delegation is the practice of transferring responsibility while staying accountable for the conditions around the work.

That balance is easy to miss: one end of the spectrum is micromanagement, where nothing is really delegated because every meaningful decision still routes back through the manager, and the other end is neglect, where the manager hands something over without enough support or follow-up.

Neither approach gets the real benefits of delegation: giving someone on the team room to grow while creating enough space for the leader to focus on the work that still needs their attention.

What You Can Delegate

You can delegate execution, investigation, a recommendation, a project, a decision, a process, or an outcome. What you cannot fully delegate is your accountability for whether the delegation was clear, reasonable, supported, and connected to the larger work.

When delegated work goes badly, the manager has to look at the setup. Did the person have enough context? Was success clearly defined? Were there dependencies, stakeholder risks, or decision points that needed more support? Those questions do not erase the person’s accountability, but they show whether the handoff matched the work being assigned.

The Shape Of Good Delegation

Good delegation usually answers a few questions before the work starts:

• What outcome are we trying to create?
• Why does this matter?
• What decisions can the person make independently?
• Where should the person pull the manager in?
• What constraints or risks should they know about?
• What does done look like?
• When will we check in?

That may sound formal, but it does not have to be. A five-minute conversation can be enough if it names the outcome, the person responsible, and the next checkpoint. For larger work, a short doc may be better.

Radio Silence Is Not Empowering

Radio silence can look like trust from the manager’s side, especially when the intent is to avoid micromanaging. But the person doing the work may still need context, a decision, or a quick course correction before the project drifts.

A manager may delegate a project, avoid follow-up, and then feel surprised when the work misses the mark. The person doing the work thought they were supposed to optimize for one thing. The leader assumed another. Stakeholders expected a third. Everyone was busy. No one was aligned.

That is not empowerment. It is unclear expectations showing up late, after the work is already moving in the wrong direction.

Trust often grows from useful presence: context when it matters, space where it is earned, and timely feedback before the work is too far gone.

Micromanagement Is The Opposite Failure

Micromanagement fails in the other direction. The assignment exists, but authority does not travel with it. Plans, tradeoffs, and small decisions all wait for approval, so the person learns to ask permission instead of building judgment.

A delegated project needs boundaries, but it also needs room. If a leader wants someone to become more capable, they need enough authority to make real decisions and enough safety to learn from them.

The Balance Leaders Have To Navigate

The useful middle is more deliberate than either mistake. The person doing the work needs a clear area of responsibility, enough room to exercise judgment, and enough support that they are not trying to infer the job from silence. Context, clear roles such as with DACI or RACI, stakeholder awareness, and check-ins all help make that possible.

Delegating does not mean disappearing. It means staying responsible for the conditions around the work while letting someone else genuinely carry it forward.

“Bad news does not get better with age.”

I remember walking with a colleague as he was heading into a meeting. As we got close to the room, he said something like, “Well, I hope they don’t ask about Project X.”

I understood the feeling. Nobody enjoys walking into a room hoping to defend a messy project, and nobody wants the awkward question, the uncomfortable pause, or the moment where everyone turns toward the part of the work that is not going well.

However, this instinct is backwards: you want the hard questions so you can explain what you know, what you do not know, what is being done, and what decision is needed, because the alternative is not silence: the alternative is that people talk about the problem when you are not there.

The Conversation Will Happen Somewhere

When a project is in trouble, silence is not neutral.

• Worried stakeholders will try to make sense of the situation.
• A confused team will fill in gaps.
• Leaders without enough information will build their own story from whatever signals they can see.

Avoiding the hard question does not make the organization less concerned; it makes the organization less informed. A hard question in the room gives you a chance to replace guessing with understanding. It also gives you a chance to show what responsible leadership looks like: say what is late, name the tradeoff, identify the dependency, make the needed decision explicit, and when you do not know yet, say what you are doing to find out.

Hard Questions In One-On-Ones

With your own team, an engineer may bring you a problem, a concern, a fear, or a messy early signal: the technical direction may be shaky, a teammate may be struggling, the deadline may be less realistic than people have been saying, a partner team may be frustrated, or the engineer may be worried they are not the right person for the work.

None of that is fun to hear, and it is still much better than not hearing it. This is where Stephen Covey’s habit, “seek first to understand, then to be understood,” matters in a very practical way: before I explain, defend, or solve, I need to understand what they are seeing and why they are worried.

If the problem is real and your team does not bring it to you, you still have the problem. You just have it in the dark. By the time it surfaces, you may discover that you have two problems: the original technical or project problem, which has been sitting unaddressed, and a trust problem, because your team did not feel safe enough, clear enough, or supported enough to bring it to you earlier.

Psychological safety can sound like a buzzword until you have worked on a team that lacks it. On that kind of team, risks stay hidden, people polish status, engineers wait until they are certain before raising concerns, and problems arrive late, fully grown, and harder to fix.

On a healthier team, people can say, “I am worried about this,” before they can fully prove it. They can ask for help early, surface risk while there is still time to change the plan, and trust that the first response will be curiosity instead of blame. That is not just better for morale; it is better operationally.

Make The Questions Welcome

You cannot simply announce that hard questions are welcome and expect people to believe you, because people watch what happens after the question.

If someone raises a concern and gets punished, dismissed, mocked, buried in defensiveness, or handed the entire mess alone, the lesson is clear: do not bring problems early.

A different lesson forms when the response is curiosity, clarity, shared ownership, and action. That does not mean every concern is correct. Some hard questions are unfair, some framings are wrong, and some worries are missing context. The first move should usually still be to understand: what are they seeing, what are they worried will happen, what decision do they think is needed, and what are we missing?

The Question Is A Signal

A hard question is a warning light, an invitation, the first visible sign of a risk that has been growing quietly, and a chance to build trust by facing the truth directly.

As a leader, I want that signal while it is still useful. I want the engineer to tell me before the project is fully off the rails. I want the stakeholder to ask while there is still time to reset expectations. I want the awkward topic in the meeting before it becomes the hallway narrative.