Issue #75 | Late June 2026 | Forwarded by 460+ engineers
The Thing Worth Naming This Week
There's a problem emerging in performance reviews, promotion decisions, and hiring conversations that nobody has named clearly yet.
It's not that AI is making engineers less capable.
It's that AI is making individual engineers less legible — the judgment, context, and decisions that constitute real expertise are increasingly invisible in the artifacts that get reviewed.
What the Visibility Trap Is
The visibility trap is the gap between what an engineer knows and what their work shows.
When you write code from scratch, your thinking is embedded in the artifact. The design decisions, the edge cases you anticipated, the tradeoff you resolved in favor of maintainability over speed — all of it is legible in the result. Your manager can read your judgment through your code.
When AI writes 40% of your code, that 40% is the model's judgment, not yours. The artifact is correct. The thinking is invisible.
Over time, this creates an evaluation problem: your output looks like it includes work that isn't yours. Your manager sees code you shipped but can't tell which parts reflect your thinking and which parts reflect the model's. Your actual expertise becomes undetectable from the outside.
The trap is this: the better AI you use, the less visible your contribution becomes — even when your contribution (the decisions, the judgment, the direction) was more valuable than the code itself.
How It Shows Up in Practice
The visibility trap manifests in specific, recognizable ways that engineers have started noticing but haven't had the vocabulary for.
The code review that tells you nothing:
You get feedback on a PR. The reviewer comments on the AI-generated portions — things that were reasonable defaults, not decisions you made. Your actual decision — the tradeoff you resolved, the architecture you chose, the constraint you worked within — goes unmentioned. Not because it was unremarkable. Because it didn't appear as code.
Your evaluation is based on the surface of your work, not the thinking underneath it.
The promotion packet with no story:
You're up for senior. Your manager needs to write a promotion case. She has your output — features shipped, metrics improved, code merged. What she doesn't have is the narrative of your thinking. The problems you solved before they became visible. The calls you made that the AI didn't make for you. The judgment you exercised in the AI-assisted work.
She can write about what you shipped. She can't fully write about what you decided.
The reference check that can't go deep:
A reference calls to discuss you. They say you shipped a lot of code. They ask what problems you solved that AI couldn't have solved. The honest answer requires explaining which judgments were yours and which were the model's — and that distinction is genuinely hard to articulate from the outside.
The hiring signal that misfires:
A company is evaluating you for a senior role. They can see you shipped extensively with AI tools. They can't see the decisions that shaped what shipped. Are you someone whose judgment scaled the output? Or are you someone whose output replaced their judgment? The code looks identical.
Why This Falls on Individual Engineers
The visibility trap is not a systemic failure — it's a structural feature of AI-assisted work that falls hardest on the individual.
Companies haven't built frameworks for evaluating the judgment underneath AI-assisted code. Performance processes are still organized around output: features shipped, PRs merged, bugs resolved. AI assistance increases output and decreases the legibility of the judgment behind it.
This means the burden of visibility falls on you.
The engineers who navigate this well do a specific thing: they make their thinking legible even when the code isn't fully theirs.
This shows up as: explaining their decisions in code review comments, writing architecture decision records, verbally walking through tradeoffs they resolved, documenting the "why" in PR descriptions, pairing on the design before the AI writes the implementation.
They're not showing their work. They're showing their thinking — and their thinking is what distinguishes them from the AI.
Specific Tactics for Making Your Judgment Visible
1. Write the decision before you write the code.
Before any significant implementation, write 3-5 sentences on what you're about to build, why you chose this approach, and what you decided against. Paste that into the PR description or a comment in the code. This is your thinking becoming legible — it shows the judgment that preceded the AI's output.
2. Name what AI did in code review.
When a reviewer asks about a specific piece of code, a useful answer is "I made this decision; the AI implemented it." Or: "This was a default from the AI; I reviewed and accepted it." Neither is better or worse. Both are honest. Both make your role clear.
3. Use architecture decision records.
For any significant system design, write a short ADR (Architecture Decision Record): what you decided, why, what alternatives you considered, and what you decided against. This is pure judgment documentation — exactly the thing AI doesn't produce.
4. Narrate your tradeoffs in 1:1s.
Don't assume your manager sees the judgment in your work. Tell them. "In this sprint I made the call to optimize for maintainability over velocity — the AI would have gone the other way. Here's why I overrode it." This is not bragging. This is making your expertise legible.
5. Document the AI's contribution honestly.
In code comments or PR descriptions, note what was AI-generated and what you directed. "AI-generated implementation of the approach we discussed in the design doc" is more useful than it sounds — it shows the human direction that shaped the output.
The Longer View
The visibility trap is a real problem that will get more pronounced, not less.
As AI coding tools become more capable, the output gap between AI-assisted and non-AI-assisted engineers will widen. The code will be better. The thinking will be harder to see. The engineers whose judgment is most valuable will be the least legible if they don't actively work to make it visible.
Companies don't know how to evaluate AI-era engineers. Performance frameworks are built for a world where output maps to individual contribution. That mapping is broken — and it won't be fixed by HR processes in the next 12-24 months.
The engineers who navigate this well will be the ones who made their thinking visible before they needed it to be visible.
The engineers who don't will find themselves in promotion conversations, hiring processes, and performance reviews where the work looks good and the story is hard to tell.
The key shift: you're not managing your output anymore. You're managing the legibility of your judgment. The output is the artifact. Your thinking is what gets evaluated.
From the Clearing
This week on the site:
- The AI Skill Stack — maps which specific skills depreciate fastest with heavy AI use and what to do about each one — useful for engineers who want to protect the capabilities that are hardest to make visible
- The Manager Guide — updated with new sections on evaluating AI-era engineers and making promotion cases for engineers whose judgment is visible in ways traditional frameworks don't capture
- The Judgment Tax — last week's Dispatch, the companion piece on the other side of this dynamic: what you lose when you let AI make decisions you should have made
That's it for this week. Forwarded to 460+ engineers navigating the space between doing good work and being able to show it.
The best engineers are not the most productive. They're the most legible.
Missed an issue? The full archive is at clearing-ai.com/newsletter-archive
Want to share your story? Share your experience — anonymous, always.
Managing a team? Team Manager Guide
If this was forwarded to you and you'd like to subscribe directly: clearing-ai.com/newsletter
Forward this to an engineer who needs it.
Subscribe to The Dispatch → Free every Tuesday. 460+ engineers already subscribed.