Matt, a software engineer, spends his 4-hour commute reviewing AI code to stay sharp

Software engineering was one of the best-paying professions in the US in 2022, but AI has already started reshaping day-to-day work. For Matt, a software engineer who asked not to use his actual name to protect his employment, the disruption is not theoretical. It is happening on a train platform, for four hours a day.

Every weekday, Matt takes a four-hour commute to Pawling, New York. During that time, he works on his own project, a browser-based video game where he writes every line of code himself. His goal is direct: “I am actively trying to keep my axe sharp.” He is also explicit about how he is fighting the new workflow. In the last six months, he has increasingly watched his job shift away from coding, problem solving, and software architecture, and toward reviewing code generated by artificial intelligence.

That shift matters because the job title might still be “software engineer,” but the muscle being trained is changing. Coding, designing system architecture, and solving technical problems are not just tasks, they are feedback loops. When you write code, you learn from compiling errors, debugging loops, design tradeoffs, and performance constraints. When your workload pivots toward reviewing AI-generated code, the feedback loop gets different. You are still evaluating correctness, but you may spend less time doing the original creative and technical work that strengthens design judgment. Matt’s concern is rooted in that difference: he is convinced the change will weaken his skills.

So he does what many professionals do when the ground moves: he creates a controlled environment where he can practice the skill he fears losing. He uses his commute, one of the few predictable blocks of time in modern life, to keep building. The browser game is not just a hobby. It is deliberate training, where he can write every line himself rather than outsourcing parts of the implementation to AI. His stated approach is blunt: “I am trying not to leverage AI where I can.” That sentence is doing a lot of work. It signals that, at least for him, AI is no longer a tool on the margins. It is becoming the default mechanism, and he is trying to stop that default from training away his core competency.

From an organizational standpoint, this is where the story gets uncomfortable. If more engineers spend their days reviewing AI-generated code, companies can benefit from speed and output. But they also risk a longer-term skills gap, especially in areas like software architecture and problem solving, where senior judgment compounds. Boards and executives should notice the second-order effect: output can remain stable while expertise degrades, like a company that can ship features but loses its ability to design durable systems. That is not a prediction. It is the direct mechanism Matt describes in his own role shift.

There is also a labor-market context underneath the personal narrative. The source notes that AI’s advent has disrupted software engineering and has led to “several layoffs and underemployment.” That is the broader pressure cooker in which workers like Matt are operating. When layoffs hit and hiring requirements tighten, companies often push for higher leverage per employee. AI can look like the perfect lever: faster iteration, fewer manual steps, and a way to maintain delivery even when headcount is pressured. But when that leverage changes what engineers do day to day, it can also change what they can do next.

Regulation is not the headline driver in this specific account, but it is part of the larger governance backdrop for AI-powered software development. As AI-generated content becomes embedded in engineering workflows, the compliance questions tend to follow: how is correctness validated, what documentation exists, and how do teams demonstrate that systems behave as intended. Even without naming specific rules in the source, the underlying risk is straightforward. Reviews shift, accountability must still land somewhere, and the people doing the review need enough technical depth to catch subtle errors, security issues, and architectural mismatches.

For executives, the strategic stake is simple: AI can change the tasks, but companies still need engineers who can design, reason, and build. Matt’s strategy is personal, but it highlights a managerial problem that does not go away if you ignore it. If your engineering org relies on AI to generate code while staff spend more time reviewing than building, you may be buying short-term velocity at the expense of long-term capability. Matt is trying to prevent that erosion in his own skill set. Leaders should assume talented people will respond the same way, quietly, by carving out their own practice time, and that can either become a workforce advantage or a signal of growing discontent.

The most important thing to take from Matt’s story is that the disruption is already in motion. In the last six months, his work shifted toward reviewing AI-generated code. He is actively countertraining by writing every line himself during his commute. That is a real-time snapshot of how software engineering can evolve from building to adjudicating. The question for decision-makers is what your organization is training instead, and whether you are comfortable with the future skill profile you are outsourcing to AI.