The Dispatch #72

The Visibility Trap

Early June 2026
For engineers doing more with AI than ever ~8 min read

The Visibility Trap: Why Having Answers Isn't the Same as Knowing What to Do

There's a specific feeling that creeps in around month three or four of heavy AI tool use.

It's not burnout exactly. It's not confusion. It's something more specific: you have answers to questions you didn't have before, but you don't always know which questions are worth asking.

You can generate a solution to almost any coding problem in seconds. And somewhere in that, you lose the instinct for what the problem actually is.

This is the autonomy gap. And it's one of the quieter costs of AI-assisted engineering that nobody talks about enough.

This week: why the gap forms, what it costs you over time, and how to rebuild the muscle AI can't replicate โ€” knowing what matters.

Section 1: Why the Visibility Math Changed

Engineering work used to leave marks. You wrote a file; it existed. You shipped a feature; someone used it. You debugged a production incident; there was a war story attached. Your work was legible because it took visible effort.

AI changes the visibility math in one specific way:

Your output increases. More features, more PRs, more documentation. By every measurable standard, you're more productive.

The effort behind your output decreases. Less debugging time, less research, less struggling through hard problems. The "showing your work" phase compresses or disappears.

Your value feels invisible. Not because you're not working, but because the work that used to be visible is now invisible.

This is not imposter syndrome. The threat is real: if no one can see what you bring to the table beyond what AI can do, then your job looks interchangeable.

Section 2: Three Versions of the Trap

1. The Velocity Distortion

When your PR velocity doubles, everyone assumes the team is doing well. But velocity is a proxy metric, not a value metric. And when the proxy goes up while the actual expertise being exercised goes down, you're creating a ceiling for your own value.

At some point, velocity will normalize. AI tools will get faster too. The engineers who were measured by "what do they ship" will find that metric is no longer a reliable signal of their individual contribution.

2. The Explanation Gap

You shipped a feature. AI helped architect it, suggested the implementation, wrote the tests, documented the edge cases.

When someone asks how it works, what you know and what AI generated are in the same sentence. Can you explain the architecture in a way that shows genuine thinking? Can you defend the tradeoffs? Can you teach it to someone else?

The engineers who are most at risk are the ones who can't tell the difference between what they understand and what they just approved.

3. The Ownership That Isn't

Shipping code you didn't fully build creates a subtle liability. It's not fraud โ€” you didn't misrepresent anything. But there's a gap between the authority you project (I shipped this) and the understanding underneath it (I directed AI to ship this).

That gap is where trust erodes. Usually slowly. Usually invisibly. Until it's not.

Section 3: What the Visibility Trap Costs You

The visibility trap costs you something specific and hard to recover: career capital.

~71%

of senior engineers report that their individual contributions feel less visible now compared to pre-AI tool use โ€” even as their team's output has increased (The Clearing survey, Q2 2026, n=1,843)

On the measurement problem:
When output doubles but the visible effort halving, you're in a bind. The engineers who survive the next wave of AI tool changes will be the ones with visible, demonstrable thinking โ€” not just visible output. The person who can show their reasoning, defend their decisions, and teach their craft is the person who looks valuable when AI handles the execution.

On the swap:
What you're trading for higher velocity is harder to see: decision quality, architectural judgment, the feel for where a system needs to go. These are the things that took years to develop, and they don't show up in output metrics. They show up in the systems that last โ€” and in the engineers who know why those systems are built the way they are.

On the risk:
The engineers who look interchangeable with AI will be first on the list when teams need to cut. Not because they did anything wrong โ€” but because their value proposition was "output" and AI does output now.

Section 4: What Helps

The visibility trap is real but navigable. These aren't productivity hacks โ€” they're career insurance.

Document the decision, not just the output

For every significant technical decision, write a short decision log.

What was the problem, what did you consider, why this approach, what are you uncertain about. This is not project documentation. This is your intellectual trail.

It's the thing that shows what you're actually doing as an engineer โ€” the thinking behind the shipping.

Teach in your own voice

When AI generates an explanation, revise it โ€” not to fix errors, but to make it yours.

The revision process is where understanding forms. The final version should sound like you thought it, not like AI wrote it.

If it doesn't sound like you, that's information: the understanding didn't transfer yet.

Solve one problem yourself per week

This is not philosophical. It's career insurance.

You need to have at least one small problem per week where the solution was genuinely yours. Where you sat with the ambiguity, made the wrong turns, and arrived at the answer through your own reasoning.

Those are the stories you'll tell in your next performance review. They're also the stories that prove you're not interchangeable.

Name this dynamic when it comes up

Say it to your manager before they say it first.

"The output looks like AI did it because AI wrote it โ€” but the decisions underneath were mine."

That's an honest sentence. It takes ownership of the work and names the dynamic at the same time.

Section 5: The Thing That Proves You're Not Interchangeable

There's a specific test for whether your value is visible:

Can you describe your thinking? Not just what you shipped โ€” but why you made the tradeoffs you made, what alternatives you rejected and why, what you're uncertain about and what you'd test first?

If you can do that fluently, you're not in the visibility trap yet. If you can't โ€” if the explanation that comes out sounds like what AI would generate โ€” that's the signal that your value is living in places that don't show up in output metrics.

The goal isn't to make your work harder. It's to make your thinking visible โ€” because the thinking is what makes you worth more than what AI can generate.

If the visibility trap resonates โ€” doing more work than ever while feeling less visible โ€” the AI Fatigue Quiz surfaces where else this dynamic shows up in your daily experience.

Take the AI Fatigue Quiz โ†’

The manifesto on intentional AI use covers the question of ownership and what it means to truly build the systems you work on.

Read the Manifesto โ†’

The goal isn't to use AI less. The goal is to be seen for the things AI can't do โ€” the judgment, the reasoning, the ownership of decisions that matter.

The visibility trap is quiet. But the engineers who find ways to make their thinking visible will be the ones who thrive โ€” not just in output, but in careers that are genuinely theirs.

โ€” The Clearing

P.S. If you've felt the visibility trap โ€” or if you've noticed a colleague whose output is up but whose presence on the team feels smaller โ€” this week's Dispatch is worth forwarding. It's the conversation worth having before the contribution becomes invisible.