The Visibility Problem: Why the Engineers Doing the Most Important Work Have the Least to Show

The best engineers working with AI are often making invisible decisions: framing the right problem, identifying which questions actually matter, catching when the AI-generated solution doesn't fit the context, deciding what not to build.

None of that shows up in a pull request.

This is the visibility problem. And if you're not intentional about it, it will cost you in performance reviews, promotions, and the quiet reputation that shapes how your work gets perceived.

This week: why the best work is invisible, what that costs you in measurable ways, and how to make your judgment visible — without manufacturing false evidence of contribution.

The value in good engineering has always had two components:

The artifact: Code, systems, features — the things that get committed and shipped

The judgment: The decisions about what to build, what to skip, what problem to solve first, where to accept complexity and where to fight it

AI has made artifacts dramatically easier to produce. It has not made judgment easier — in some cases, it has made judgment harder to exercise, because the ease of generating artifacts reduces the pressure to think carefully before building.

On output metrics

If your performance review measures lines of code, features shipped, or PRs merged — AI assistance will make your numbers look better regardless of the judgment behind them. The metric doesn't know the difference between a carefully framed solution and a quickly prompted one.

This isn't hypothetical. Engineers report being evaluated on velocity metrics that AI inflates without corresponding increases in quality or thoughtfulness. The numbers go up. The work gets thinner.

On promotion decisions

Promotion committees often look for evidence of impact: the project you led, the system you designed, the problem you solved. When AI is generating the artifacts of your work, the evidence of impact is diluted.

You shipped the feature. But did you understand it deeply enough to defend the architecture? To debug it at 2am? To extend it when requirements changed? The promotion decision can't see that. It sees the feature.

On technical reputation

Over time, engineers build reputation through the quality of their decisions — the times they caught a problem early, proposed a better approach, or avoided building the wrong thing. This reputation is built through demonstrated judgment, not just demonstrated output.

When AI generates the output, your judgment is not visible in the work. Other people can't see the difference between your judgment and the AI's judgment embedded in the code you wrote.

There are specific things you do as an engineer that AI can't replace — and that evaluation systems don't see.

• Deciding what not to build The best engineering decisions are often the ones that prevented work — the feature request you talked a stakeholder out of because you understood the underlying problem well enough to propose a simpler solution. That's invisible. The PR shows nothing happened.
• Identifying the real problem You spent an hour with a product manager reframing what they were actually asking for. The solution that shipped was half the scope and twice as useful. No artifact shows that reframing happened. The feature shipped, and that's all the record shows.
• Catching AI's mistakes You reviewed an AI-generated solution and caught three subtle bugs — one a security issue, one a scaling problem, one a violation of the system's implicit contract with its users. You wrote them in the review. The AI was wrong. You were right. The PR merged. The record is a code review comment that three issues were found. The judgment isn't there.
• Choosing the right question You rejected the AI-generated approach and insisted on a different architecture because you'd seen this pattern fail in production before. You couldn't fully explain why — it was a pattern recognition from experience. The architecture held. The AI-generated approach would have caused problems six months later.

The visibility problem has a practical solution: build evidence of your thinking, not just evidence of your output.

1. Write the problem-framing document. Before you build anything, write one paragraph — in a PR description, a design doc, a comment — explaining why you're solving this problem this way, and what you considered and rejected. This is not extra work. It's the record that shows the judgment happened. If you're using AI to generate the solution, the problem-framing document becomes the evidence of your thinking.
2. Comment your non-obvious decisions. When you make a judgment call that isn't immediately obvious — this naming convention, this error handling approach, this way of structuring the config — write a brief comment explaining why. Not for the AI. For the human who will inherit this code in two years and need to understand what was in your head when you made that decision. This comment is also evidence of your thinking. It demonstrates judgment, not just output.
3. Document the alternatives you rejected. The PR that shipped is evidence of what you built. The design doc that shows what you considered and why you rejected it is evidence of how you think. Keep that record. When you make a decision about architecture, scope, or approach, note in the PR or design doc what alternatives you considered and why you chose the path you chose. This is not vanity. It's the documentation that shows you exercised judgment.
4. Make your code review comments a portfolio. Your code review comments — the catches, the questions, the architectural pushback — are evidence of technical judgment. If you review other people's AI-assisted code and catch problems they missed, that judgment is valuable. Make sure your review comments are visible and acknowledged.

The visibility problem is not just about performance reviews. It's about something more fundamental: if your judgment is invisible, you're not building the reputation that will sustain your career.

The engineers who will be trusted with the highest-leverage problems five years from now are the ones whose judgment has been tested and observed. If your work with AI is invisible, your judgment isn't being observed, even if it's being exercised.

The solution isn't to manufacture evidence. It's to make your actual thinking visible in the natural artifacts of your work — the PRs, the design docs, the code reviews, the architectural discussions.