The PR Shipped. Did the Engineer Grow?
AI can improve engineering output while weakening the signals managers use to evaluate growth.
The project is a success. The pull request is clean, the design document is thorough, and the change shipped faster than expected. Yet at the six-month review, the manager still cannot answer the question that matters: what can this engineer decide now that they could not decide six months ago?
Consider a project to add automatic retries to an event-processing service. An LLM proposes a plausible design: exponential backoff, capped attempts, sensible alerts, and clean tests. The engineer turns it into a polished pull request.
During review, a staff engineer asks whether the downstream handler is idempotent. It is not. Under the wrong failure conditions, the proposed design could create duplicate side effects. The team revises the approach, and the change ships safely.
The review worked: the system is safe, and the team can operate it. What the merged pull request does not reveal is whether the engineer learned to recognize the risk, or whether the relevant judgment remained with the reviewer.
A recent discussion on X framed this as managing engineers who “don’t want to think anymore” because they delegate judgment to LLMs. The replies described polished documents with shallow reasoning, entirely AI-written pull requests with obvious flaws, and engineers appealing to model authority during disagreement: “Cursor thinks you’re wrong.”
These are practitioner anecdotes, not evidence that engineers everywhere are losing the ability or desire to think. That framing mistakes a measurement problem for a motivation problem. The same tool that removes boilerplate can recommend an architecture, weigh a tradeoff, and produce a persuasive explanation of why the decision makes sense. It never announces when assistance has become substitution.
AI may also accelerate learning by exposing engineers to alternatives and feedback they would not otherwise encounter. The management problem is not that growth cannot happen. It is that a polished artifact can hide how much of the underlying judgment developed in the engineer who submitted it.
A manager now needs to separate three outcomes:
Did the work deliver?
Is the decision understood and safely owned?
Did the engineer’s judgment develop?
AI can improve the first. Review and senior oversight can protect the second. The third can remain unresolved even when the project looks entirely successful.
Output is becoming a weaker signal of growth
This problem is not entirely new. Reviewers have always corrected one another, and finished artifacts have never revealed every step of the reasoning behind them. Engineers have always borrowed judgment from colleagues, documentation, previous designs, and Stack Overflow.
AI changes the signal. It can generate both the proposed decision and a convincing account of how that decision was reached. Borrowed judgment can now arrive with the polish of independent reasoning.
If AI can help you deliver more is out of question now. Randomized field experiments involving 4,867 software developers estimated that access to GitHub Copilot increased completed tasks by 26.1 percent. The experiments did not measure understanding, code quality, or long-term capability, but they provide strong evidence that AI assistance can create real leverage.
Other research suggests that the cognitive work is moving. A Microsoft Research and Carnegie Mellon study asked 319 knowledge workers about 936 examples of using generative AI at work. Participants described critical thinking shifting toward verification, integration, and oversight. A 2026 longitudinal preprint about professional software engineers similarly describes a shift from creation toward directing, evaluating, and correcting AI output.
None of these studies shows that engineers are learning less. They measured completed work or workers’ descriptions of how their work was changing, not long-term judgment. Together, they explain why completed work is becoming a weaker proxy for individual development.
A correct answer does not, by itself, demonstrate engineering growth. Growth becomes visible when someone forms a view, encounters evidence or disagreement, updates that view, and carries the lesson into a different problem. If a model proposes the approach and a senior reviewer repairs its weak assumptions, the system may be safe while the author’s mental model remains unchanged.
A model can also produce the design rationale, the rejected alternatives, and the explanation for why the eventual decision was correct. The work may look thoughtful without showing whether the engineer can reproduce the thinking when the conditions change.
Managers cannot inspect their way out
Prompt logs can answer compliance questions. They cannot answer growth questions. They show how something was produced, but not whether the author can adapt when the generated answer stops matching reality.
An unaided presentation has a different weakness. It may reveal local understanding, but it also rewards verbal confidence and can become a ritual in which engineers perform comprehension for senior reviewers. Applied to every meaningful change, it turns the most experienced people on the team into permanent approval gates.
Strong engineers can delegate large amounts of implementation while retaining a clear model of the system, its constraints, and its failure modes. Another engineer can write every line manually and still exercise poor judgment. How much AI someone used is not a useful substitute for evaluating what they can decide.
Even “Cursor thinks you’re wrong” is not a problem because Cursor must be wrong. The model may have surfaced a valuable objection. The problem is that the objection has not been converted into inspectable evidence and an owned recommendation.
The immediate coaching questions should be straightforward:
What do you recommend?
What evidence can we verify?
What would change your mind?
The engineer can use the model while answering. The manager is looking for ownership of the decision, not proof that the engineer worked alone.
Organizational incentives complicate this further. If a company demands visible AI adoption, rewards throughput, and treats hesitation as resistance, engineers will reasonably reach for a model before forming their own view. Management cannot punish the pause and then blame people for skipping the thinking that might have happened inside it.
Managers need evidence of development without creating surveillance. That evidence appears across time, not inside a prompt transcript.
Review one decision twice
A better way to evaluate growth is to revisit one consequential decision twice: once while it is open and once after the outcome is visible.
The first review can happen inside an existing design discussion. The engineer captures:
their recommendation;
the key uncertainty;
the evidence that would cause them to change direction.
A staff engineer or teammate familiar with the system then challenges the premise. The point is not to pre-approve the decision. It is to expose the assumption the decision depends on.
The second review can happen in an existing retrospective or one-on-one. Ask:
What surprised you?
Which assumption failed?
What will you investigate earlier next time?
Return to the retry example. The useful evidence is not that the engineer can now define idempotency. It appears later, when another project involves message reprocessing and they raise the duplicate-effects risk before somebody else has to ask. The lesson has moved from one corrected pull request into the engineer’s judgment.
An LLM can help write the initial decision note. That does not undermine the exercise because the note is only a marker. The evidence arrives afterward: the engineer notices a related risk sooner, changes direction when the facts change, adapts the lesson to a different system, or helps another person reason through the same tradeoff.
This should be selective. Reviewing every ticket would create another approval process and concentrate an invisible coaching tax on the same senior engineers. Managers should reserve the practice for consequential, uncertain, or difficult-to-reverse decisions.
They should also protect time for the coaching involved and ensure that useful technical challenges become developmental feedback rather than disappearing inside pull-request comments.
For a growth conversation, a few examples of transferred judgment are more diagnostic than a complete inventory of AI-assisted tickets.
What should be visible six months later
The useful question is not whether if engineers “want to think.” It is how to manage when thinking can be skipped without making the output look unfinished—and when the organization may reward the output before anyone notices.
Preserving every manual step would confuse effort with learning and discard genuine leverage. The management responsibility is to preserve the parts of engineering work where people form a view, encounter disagreement, revise their assumptions, and transfer what they learned.
That changes what counts as evidence in a performance conversation. Completed work still matters. So does recognizing a failure mode earlier, changing a recommendation when the facts change, applying a lesson in a new context, and helping somebody else make a better decision.
These signals are less convenient than counting pull requests. They are also closer to the capability a team will need when the next problem no longer resembles the last one.
A growth review should not ask how much of the engineer’s work was generated. It should ask what this engineer can now decide that they could not decide six months ago, and what evidence shows they can carry that judgment into the next problem.