Why LLMs Amplify the Output Gap Between Senior and Junior Engineers

The Experiment: Copying a Website with Cursor

Sean Goedecke, a senior engineer, ran a revealing experiment. The task was straightforward on its face: replicate a specific website using Cursor, an AI-powered IDE. He didn't just fire off a prompt and accept the first output. He approached it like any serious engineering problem—specifying the stack, reviewing the generated code, catching architectural flaws, and iterating on the design.

The result? A functional, well-structured replica built in a fraction of the time it would take manually. But the critical finding wasn't the speed. It was the realization that the LLM didn't replace his expertise; it consumed it as fuel. Every effective prompt, every bug he caught, every architectural correction he made was a direct injection of his years of accumulated judgment.

This isn't a story about AI making coding obsolete. It's a story about AI making taste and judgment the primary bottlenecks. The source material for this analysis is based on Sean Goedecke's direct experience, which mirrors what we observe daily in the field.

Why Expertise is the Unlock for LLM Performance

To understand why seniors pull ahead, you have to look at what an LLM actually does. It predicts statistically plausible text. It has no internal model of correctness, no architectural taste, and no understanding of your specific non-functional requirements. It will confidently generate code that looks right but contains subtle concurrency bugs, O(n²) complexity hidden in a nested loop, or a database schema that will melt down under any real load.

The value an engineer brings to this interaction is a real-time filter for bullshit. Let's break down the specific cognitive moves a senior makes that a junior cannot yet reliably execute:

1. Prompt Decomposition

A junior might ask: "Build me a website that looks like this." A senior asks: "Generate the HTML structure first. Use CSS Grid for the main layout. We'll handle the responsive breakpoints in the next step. Do not use JavaScript for the navigation—we'll do that server-side." The senior is decomposing the problem into LLM-digestible, verifiable chunks. This isn't a generic skill; it's a direct function of having built enough frontends to know what the chunks should be.

2. Architectural Skepticism

When the LLM generates a solution, the senior isn't looking at syntax. They're pattern-matching against a mental library of past failures. They see a proposed data flow and think: "That's going to cause a race condition when two users hit this endpoint." They see a class hierarchy and think: "We're going to regret that abstraction in three sprints." The LLM doesn't know your team's future. The senior engineer does.

3. Contextual Debugging

When the generated code fails, the junior gets stuck in a conversation loop with the LLM, pasting error messages back and forth. The senior looks at the error, recognizes the class of failure, and either fixes it manually or crafts a precise prompt that addresses the root cause. They're not debugging the code; they're debugging the generation process.

The Amplification Effect: Seniors Pull Away

This is where the gap becomes a chasm. Before LLMs, a senior engineer might be 3-5x more productive than a junior on raw code output. With LLMs, that multiplier jumps to 10x or more. Why? Because the LLM eliminates the part of the job where the junior could previously keep pace: the mechanical act of writing code.

The diagram above illustrates the divergent workflows. The junior engineer gets trapped in a re-prompting loop, generating plausible but incorrect code and feeding errors back into the LLM without understanding the underlying issue. The senior engineer decomposes the problem upfront, feeds precise specifications to the LLM, and applies architectural review to the output, shortcutting directly to production-ready code.

This isn't about intelligence. It's about the size and quality of the mental model. The senior has a detailed, runnable simulation of the system in their head. The LLM becomes a peripheral device attached to that simulation—a fast but dumb I/O channel. The junior, lacking that simulation, is trying to use the LLM as the brain itself, which it fundamentally is not.

What This Means for Forward Deployed Engineers

For a Forward Deployed Engineer (FDE), this dynamic is even more pronounced. An FDE's job is to operate in high-ambiguity customer environments, integrate disparate systems, and ship working solutions on compressed timelines. You're not just writing code; you're reverse-engineering a customer's broken data pipeline at 9 AM, building a demo scaffold by noon, and debugging a production auth issue by 3 PM.

In this context, an LLM is either your jetpack or your anchor.

The Jetpack Scenario: You have deep enough expertise to recognize that the customer's "simple API integration" actually requires handling a Byzantine pagination scheme with inconsistent error codes. You prompt the LLM to generate a robust client that handles these edge cases, review the output critically, and ship it in an hour. You just compressed a two-day task into a morning. This is the kind of leverage we break down in our guide on the highest-leverage skills for an FDE in the AI era.

The Anchor Scenario: You lack the integration experience to know what you don't know. The LLM generates a client that works perfectly in the happy path. You ship it. It fails silently on the customer's first paginated request, corrupting their data pipeline. You now spend the next two days firefighting, debugging code you didn't truly write, and eroding the customer's trust. You would have been faster writing it manually and learning the edge cases yourself.

The FDE role amplifies the expertise gap because the cost of failure isn't just a broken build—it's a broken customer relationship. When you're the face of the engineering team on site, your judgment is the product. The LLM can't fake that. For a deeper look at the day-to-day reality of this role, see our breakdown of what an FDE actually does in a week.

How to Use This Today: A Deliberate Practice Loop

If you're a junior engineer or an aspiring FDE reading this, the takeaway is not "don't use LLMs." It's "use them to accelerate your acquisition of expertise, not as a substitute for it." Here's a concrete loop you can run today.

The Retype-and-Explain Protocol

This is a practice we drill at FDE Coach. It's designed to convert LLM output from a crutch into a learning accelerator. We've covered a version of this in our piece on retyping LLM code to prevent cognitive debt.

1. Prompt for a solution to a problem you understand the shape of but can't yet code fluently.
2. Close the LLM's output. Do not copy-paste.
3. Retype the entire solution from memory, line by line. You will fail to remember parts. That failure is the signal. The parts you can't reconstruct are the parts you don't understand.
4. Annotate every line with a comment explaining why it's there, not what it does. "Increments the counter" is useless. "We increment here before the check to avoid an off-by-one error when the list is empty" is expertise being built.
5. Break it intentionally. Change a design decision. What happens if you swap this library for that one? What if you make this call synchronous? Run the broken code and understand the failure signature.

This protocol forces your brain to build the mental model the senior already has. You're not just consuming code; you're reconstructing it, which is how neural pathways actually strengthen.

Start with Constrained Domains

Don't try to learn "programming" with an LLM. That's too broad. Pick a constrained, high-value domain where the patterns are stable and the feedback loops are tight:

• Database query optimization: Ask the LLM to generate a query, then you explain the query plan.
• API client design: Generate a client for a well-known API (like GitHub's), then you critique the error handling and retry logic.
• Data transformation pipelines: Generate a script to transform a CSV, then you break it with a malformed row.

Each of these is a sandbox where you can build the pattern-matching machinery that separates seniors from juniors. These are also exactly the kinds of skills you'd showcase in an FDE portfolio built to get hired in the AI era.

The Balanced Take: Gatekeeping vs. Genuine Leverage

Is this dynamic unfair? In one sense, yes. It's another Matthew Effect—those with expertise gain more from new tools, widening the gap. But framing it as gatekeeping misses the point. The LLM isn't withholding value from juniors; juniors are simply unable to extract the value yet. This is no different from how a master woodworker extracts more value from a CNC machine than an apprentice. The tool lowers the barrier to execution but raises the premium on design and judgment.

The optimistic read is this: LLMs dramatically shorten the feedback loop for acquiring expertise. The apprentice woodworker used to spend years just learning to saw straight before they could attempt complex joinery. The junior engineer used to spend months wiring up boilerplate CRUD endpoints before touching architectural decisions. Now, the boilerplate is free. You can spend your cognitive budget on the hard stuff from day one—if you choose to.

The trap is using the free boilerplate to avoid the hard stuff entirely. That's how you arrive at year three with one year of experience repeated three times, and an LLM dependency that masks your lack of growth until a high-stakes situation rips it away.

FAQ

Q: Should junior engineers avoid using LLMs entirely? No. But they should use them as a learning tool, not a production crutch. Retype the output. Break it. Annotate it. If you're pasting code you couldn't explain to a colleague, you're building debt, not skill.

Q: How do I know if I'm actually learning or just getting faster at prompting? The test is simple: can you solve a novel problem in the same domain without the LLM? If you've been "building" React apps with an LLM for six months but can't write a functional component from scratch in a plain text editor, you haven't learned React. You've learned how to prompt for React.

Q: What's the single highest-leverage thing a junior engineer can do to close the gap? Build a complete, working system in a domain you care about without using an LLM for code generation. Use it for explanation, use it for documentation lookup, but write every line yourself. You'll discover exactly where your understanding is fuzzy, and that discomfort is where growth lives.

Q: Does this mean AI coding tools are overhyped? Not at all. They're genuinely transformative. But the hype often frames them as a replacement for skill, when they're actually a multiplier of skill. The distinction is everything.