One software engineer spends a four-hour train commute building a browser game one line at a time, without artificial intelligence. His paid work has moved away from coding, problem solving and architecture and toward reviewing code generated by machines. The personal project is not nostalgia. It is practice for abilities he fears the job may no longer exercise. [1]

That choice gives a human answer to the paper's July 11 account of entry tasks disappearing before professions. The earlier article argued that automating forms, records and first drafts could remove the work through which junior employees learned judgment. The Guardian's July 12 interviews show some software engineers trying to rebuild that missing practice for themselves. They do not establish how common the response is. [1]

The distinction matters because software companies can count generated lines, completed tickets or shorter delivery times far more easily than they can measure whether an engineer is becoming better at tracing a fault, designing a system or recognizing a dangerous shortcut. Output appears on a dashboard. Judgment usually appears only when something goes wrong.

Practice becomes the scarce input

The engineer on the train is identified by the Guardian only as Matt, to protect his employment. He describes writing and designing his game from scratch as a way to keep his skills intact after six months in which his job increasingly became a review function. His fear is specific: if the machine performs the construction, the worker may lose fluency in the construction decisions that make review possible. [1]

That is not proof of skill atrophy. The Guardian interviewed more than a dozen engineers and experts, not a representative sample of the profession. It did not administer the same test to frequent AI users and non-users over time. It did not measure debugging accuracy, security findings, design quality or unaided performance before and after adoption. The interviews establish behavior and concern, not prevalence or causation. [1]

Still, the behavior exposes a neglected input. Expertise does not arrive merely from knowing what good work looks like. It is built through attempts, mistakes, revisions and the slow accumulation of patterns. A developer learns why an abstraction is wrong by living with it, why a database choice fails by watching it strain, and why a clean-looking patch is dangerous by tracing what it touches. A tool that removes routine construction may free time. It may also remove repetitions that once made harder judgment possible.

The productivity case and the learning case can both be true. An experienced engineer may use an agent to produce a first draft, then spend the saved time on architecture or testing. A novice may receive the same draft without enough prior practice to know what is missing. The same generated code can therefore be leverage for one worker and a concealed lesson for another. A company percentage saying how much code came from AI cannot resolve that difference.

The relevant comparison is not hand work against modern work. It is one learning environment against another. If an agent removes repetitive syntax but leaves the engineer responsible for hypotheses, tests and consequences, practice may improve. If it removes the decisions as well as the typing, the worker may become faster while seeing less of the system. Firms need to identify which version they have built instead of treating tool adoption as a single activity.

Review is a different craft

Another engineer in the Guardian's feature used AI to build websites and then inspected the output for errors, redundancies, unusual decisions, bugs and visual failures. That is active work, not passive acceptance. It also shows why the phrase "AI wrote the code" says little about the labor required to make the result usable. [1]

Review can be demanding. An evaluator must understand the intended behavior, inspect the implementation, test edge cases and recognize when a plausible solution violates a constraint that the prompt never expressed. Bouke Klein Teeselink, an economics professor quoted by the Guardian, said validation also requires finding vulnerabilities, understanding errors and checking security. Those are not clerical tasks. They are forms of engineering judgment. [1]

The problem is how that judgment is acquired. A senior engineer who has designed and repaired systems for years can interrogate generated work against a library of lived failures. A junior engineer may see a polished answer with no memory of the alternatives. If companies move entry-level workers directly into supervision of agents, they need a new account of how supervisors become competent before they are asked to supervise.

Experts in the feature disagree over the continuing value of writing code by hand. Ethan Mollick, a management professor, argues that value is moving toward defining problems, designing systems and directing tools. Other participants describe the creative pleasure and technical ownership lost when their work becomes review. The disagreement is useful because it prevents a false choice between preserving every old task and abandoning the underlying craft. [1]

Writing syntax is not identical to understanding a system. Nor is directing an agent identical to understanding one. The practical question is which activities teach decomposition, causality, performance, security and maintenance, and whether a faster workflow still contains enough of them. Without controlled assessments, neither the hand-coding advocate nor the automation advocate can claim the full answer.

The ladder cannot end at review

Software has long used junior work as both production and apprenticeship. Small features, tests, bug fixes and maintenance tasks supplied useful output while exposing newer employees to larger systems. Senior colleagues reviewed the work, explained tradeoffs and gradually delegated greater responsibility. The arrangement was imperfect, but it joined learning to paid production.

Coding agents disturb that bargain because they are strongest at producing the first draft that once gave a junior employee a bounded problem to solve. If a machine performs the draft and a senior performs the review, the employer may collect speed while skipping the middle step where a less experienced worker learned. The missing rung is not a sentimental attachment to typing. It is a financing question: who pays for practice when practice no longer looks like the fastest route to output?

An employer could answer with protected exercises, paired design, incident analysis, test writing, architecture reviews and rotations through maintenance work. It could require engineers to explain generated code before merging it, or compare an unaided solution with an agent-assisted one. Those are possible training designs, not findings from the Guardian's interview set. Their value would have to be measured against errors, review time, retention and later independent performance.

The engineer on the train has chosen a more fragile solution. He finances his own apprenticeship with commuting time. That may preserve his fluency, but it transfers the cost of adaptation from the firm adopting the tool to the worker worried about becoming dependent on it. A private game can teach construction. It cannot give him authority over a production system, feedback from a team or the institutional memory that comes from maintaining software after release.

The career consequence reaches beyond junior hiring. If experienced employees spend more time reviewing machine output, companies must decide what counts as advancement. The worker who catches a subtle vulnerability may create more value than the worker who accepts ten generated features, yet conventional output measures can reward the visible volume. Promotion systems built around shipped projects may need evidence about prevented failures and sound design, not merely delivery speed.

Labor statistics do not measure fluency

The Guardian places these interviews inside a difficult technology labor market. But layoffs, underemployment, job postings and generated-code shares are different measures. A layoff can reflect interest rates, pandemic over-hiring, strategy, automation or several causes at once. A company can generate more code without employing fewer engineers. A worker can keep a job while losing meaningful practice. None of those outcomes can stand in for another. [1]

The current X record is thinner. Repeated searches produced no verified status inside the edition's 60-day freshness window that addressed these July 12 interviews. An older Andrew Ng post discussed coding agents and software-team design, but its April timestamp makes it ineligible for the publication stack. That is a discovery boundary, not proof that X lacked debate.

That boundary prevents two common errors. The first is to use anxious interviews as proof that software engineering is disappearing. The second is to turn an old expert post or a failed search into a current platform consensus. The interview set shows some workers responding to a changed workflow. It does not supply a national estimate of lost skill, employment effects or generated-code quality.

Better evidence would follow tasks and careers together. Employers could report which assignments agents complete, how long review takes, what defects escape, who finds them and whether junior hiring changes. Training programs could test architecture, debugging and security before and after sustained tool use. Promotion records could show whether workers who enter through agent-heavy roles reach independent responsibility at the same rate as earlier cohorts.

Those measurements would also distinguish substitution from expansion. Easier coding may produce more custom software and create new work. It may reduce the number of people needed for some projects. It may do both across different firms and periods. Counting professions misses the sequence. The first change can occur inside a job, when the worker stops constructing and starts approving.

Keep the ability to say no

Manual practice has value beyond preserving an old technique. It gives an engineer a fallback when a model is unavailable, expensive, wrong or poorly suited to a sensitive system. It also makes consent meaningful. A worker can choose a tool intelligently only if the alternative remains within reach. Dependence turns a productivity option into infrastructure.

The fallback matters most during failure. An engineer responding to an outage cannot assume the same model, context or service remains available. Someone must reconstruct behavior from logs, code and system state under pressure. Regular unaided practice does not guarantee that competence, but an organization that lets it disappear should not discover the loss for the first time during an incident.

That does not mean serious engineers must reject AI. The Guardian's examples include people using generated code as material for rigorous testing as well as people reserving personal projects for unaided work. Both responses treat the tool as something to evaluate rather than a verdict on what engineering now is. [1]

The durable question is not how many lines a model can write. It is whether the organization retains people capable of understanding what those lines do, recognizing what they omit and teaching the next cohort to do the same. That capacity will not be preserved by slogans about inevitable replacement or inevitable abundance.

For now, the strongest receipt is modest. Some engineers are deliberately doing work a machine could do faster because speed is not the only output they value. They are buying practice with their own time while employers redesign paid work around review. Until firms publish training, error and career evidence, the browser game on a long commute remains both a craft project and an unpaid warning.

-- THEO KAPLAN, San Francisco