LLMs Change the Training Loop

The essay about LLMs eroding a software engineering career resonated because it named a tension many engineers feel but struggle to place. AI coding tools make work faster. They also remove the small struggles that used to teach engineers how systems behave.

The moral argument about whether engineers should use AI wastes time. Teams will use AI because it saves time on boilerplate, test scaffolding, code search, migration drafts, and error explanation. The practical question is which parts of engineering judgment grow through friction, and how teams preserve those learning loops after AI removes the old ones.

The Old Training Loop

Junior engineers used to learn through small, bounded tasks:

• Add a field to an API response.
• Fix a failing test.
• Update a form validation path.
• Read a stack trace.
• Follow a code path across three files.
• Write a migration and rollback.
• Ask for review and absorb comments.

These tickets looked mundane, but they taught several skills at once. A junior engineer learned the repo layout, naming conventions, test style, dependency boundaries, review culture, deployment process, and failure modes. The output was small; the learning surface was large.

AI tools can compress the output path. A model can find the file, draft the change, update a test, and explain the stack trace. That helps the team ship. It also lets the engineer skip parts of the route where judgment used to form.

Skill Loss Does Not Look Like Incompetence

The risk is subtle. Engineers using AI may produce code that passes tests and reviews. Skill loss shows up later, in the work that cannot be delegated cleanly:

Skill	How It Weakens
Debugging	The engineer waits for generated hypotheses instead of forming a fault tree
System modeling	The engineer edits local code without understanding upstream and downstream effects
API design	The engineer accepts plausible shapes that age poorly
Performance reasoning	The engineer trusts code that works on sample input
Security judgment	The engineer misses data flow, authority boundaries, or injection surfaces
Taste	The engineer loses sensitivity to names, seams, and unnecessary abstraction

The engineer may still look productive. That makes the problem harder to detect. Throughput and growth can move in different directions.

AI Is Best at the Middle of the Task

AI coding tools are often strongest after a human frames the problem and before a human makes the final judgment. They can generate alternatives, produce tests, explain APIs, draft migrations, and search unfamiliar code. They are weaker as the sole owner of problem selection, boundary setting, and risk assessment.

A healthy workflow gives the human the first and last move:

1. Human writes the problem statement.
2. Human sketches the data flow, state changes, and failure cases.
3. AI proposes an implementation or alternatives.
4. Human reads the diff as if reviewing another engineer.
5. Human runs targeted tests and adds missing cases.
6. AI helps with cleanup, comments, or documentation.
7. Human owns the merge decision.

This pattern preserves the parts of work that teach judgment. The model accelerates the middle, but the engineer still practices framing and evaluation.

Teams Need New Apprenticeship Patterns

If AI absorbs the easy tickets, managers need to redesign training. Teams cannot assume juniors will learn by osmosis from low-risk work if agents now handle that work.

Useful patterns include:

Review the prompt and the diff. Code review should ask what the engineer asked the model, what constraints they supplied, and what they rejected. The prompt is part of the work product when it shaped the solution.

Pair on debugging and implementation. Debugging reveals mental models. A senior engineer should narrate how they form hypotheses, reduce the search space, inspect logs, and decide which signal to trust.

Assign ownership of small production surfaces. A junior engineer should own a limited feature end to end: code, tests, dashboards, alerts, deployment, and support notes. Ownership teaches consequences better than isolated tasks.

Run no-AI drills. Teams can require occasional exercises without AI: trace a request, explain a flaky test, write a small parser, or perform a rollback. The exercise keeps baseline muscles alive.

Promote incident reviews as training. Incidents show how real systems fail. Juniors should see bad deploys, partial outages, confusing alerts, and rollback decisions. AI-generated summaries of incidents are useful only after engineers inspect the raw timeline.

Evaluation Should Include Reasoning Artifacts

Teams tend to evaluate AI-assisted work by the final diff. That misses the main risk. The final diff might pass while the engineer lacks a model of the system.

For mentorship, ask for artifacts:

• A short design note for nontrivial changes.
• A risk list with tests mapped to each risk.
• A trace of the relevant code path.
• A rollback plan for migrations or external behavior changes.
• A note on which AI suggestions were rejected and why.

These artifacts do not need ceremony. A few lines in a PR can reveal whether the engineer understands the change. They also make AI-assisted work easier to review because the human decision points become visible.

The New Baseline Skill Set

AI tools raise the minimum expected output. They also raise the importance of meta-skills:

Skill	Why It Matters More
Problem framing	The model follows the shape of the request
Context selection	Too much context confuses, too little context misleads
Diff reading	Generated code can look more coherent than it is
Test design	Models often test the happy path they just wrote
Tool skepticism	The engineer must notice plausible nonsense
Operational thinking	Shipping code remains a human responsibility

The engineer who thrives with AI will not be the one who accepts the most generated code. It will be the one who can turn vague work into crisp constraints, then judge outputs against those constraints.

A Personal Workflow

For my own coding, I would preserve these habits:

1. Read the relevant code before asking for a change.
2. Write the failure case in plain language.
3. Ask the model for two approaches when the design is uncertain.
4. Keep generated diffs small enough to review.
5. Run tests before editing generated code, then run them again after edits.
6. Explain the merged solution without quoting the model.

That last test is useful. If you cannot explain the code without leaning on the assistant's phrasing, you have not absorbed the change.

LLMs remove friction from software work. Teams should welcome the useful friction loss and preserve the friction that trains judgment. The future engineering apprenticeship will be more explicit, more trace-based, and less dependent on the accidental curriculum of small tickets.

A Training Plan for AI-Native Teams

Teams can turn this into a concrete training plan instead of a vague warning.

For the first month on a codebase, a new engineer should keep an "assumption log" for nontrivial tasks. The log can be short:

• Files I think own the behavior.
• Data flow I think matters.
• Tests I expect to fail if I am wrong.
• AI suggestions I rejected.
• The reviewer feedback that changed my model.

The log teaches engineers to externalize judgment. It also gives mentors a way to spot shallow understanding before it ships.

During the second month, the engineer should own a small production surface. Not a toy ticket. A real feature slice with dashboards, alerts, tests, and support notes. AI can help implement the work, but the engineer should explain the operational path: what happens when the feature fails, which metric moves, who gets paged, and how to roll it back.

During the third month, the engineer should lead a small incident or bug review. The goal is not blame. The goal is to practice reconstructing causality from logs, code, deploy history, and user reports. AI can summarize the timeline after the engineer builds it by hand. That ordering matters because the skill lives in choosing which evidence to trust.

The Review Rubric Changes

AI-assisted pull requests need a different review rubric.

Reviewers should ask:

Review Question	What It Detects
Can the author explain the change without the assistant?	Shallow acceptance
Does the PR name the risky path?	Missing system model
Are tests mapped to risks?	Happy-path generated tests
Did the author inspect generated code before review?	Delegated attention
Does the diff cross ownership boundaries?	Architecture drift
Is rollback described for behavior changes?	Operational immaturity

This rubric helps seniors review faster. It also teaches juniors what the team values. A generated diff can be fine. An unexamined generated diff should not pass review.

Protecting Taste

Taste sounds vague, but in engineering it shows up in small decisions: naming, module boundaries, error messages, API shape, test structure, migration sequencing. AI tools can imitate local style when the context is strong. They can also produce plausible code that adds one more helper, one more abstraction, one more flag, one more branch.

Teams can protect taste through examples. Keep a small set of "good changes" in the repo: a clean migration, a well-scoped refactor, a strong incident writeup, a careful API addition. Point new engineers and agents at those examples. Make the taste inspectable.

AI tools learn from context. Humans do too. If the repo only contains code and no examples of judgment, both will copy surface patterns.

Sources

• human-in-the-loop: LLMs are eroding my software engineering career