Software engineering looked like a safe bet in 2022. Then AI hit, and the story changed fast, with layoffs and underemployment reported across the sector. For engineers still employed, “building” is not what it used to be. It is increasingly “checking,” and sometimes that shift is so direct it changes what your day even feels like.

Every weekday, Matt, a software engineer commuting from Pawling, New York by train, spends four hours on the ride to work on his own project. It is a browser-based video game, and he writes every line of code himself. He says he is “actively trying to keep [his] axe sharp” and asked to not use his actual name to protect his employment. In the last six months, he says his job has increasingly shifted away from coding, problem solving, and software architecture toward reviewing code generated by artificial intelligence. His worry is skill weakening, so he is doing the opposite of what many teams are tempted to do. “I am trying not to leverage AI where I can.”

That one sentence captures the tension now gripping software teams: AI can produce code quickly, but speed is not the same thing as craftsmanship, and review-heavy work can quietly train a different muscle. In Matt’s case, the “front line” task is no longer the same as writing code from scratch or owning architecture decisions. Instead, it is evaluating what AI suggests, deciding whether it is correct, and catching edge cases the model may miss. That can still be valuable work. The problem is time allocation. If the core of your day becomes review, you spend less time practicing design and implementation. Skill decay is not always dramatic. Sometimes it just looks like a gradual erosion of comfort and depth.

The source also ties this to broader labor outcomes: the advent of AI has disrupted software engineering, leading to several layoffs and underemployment. That matters for decision-makers because it changes what “productivity” means inside engineering orgs. If teams are under pressure to do more with less, AI-generated output can become a lever for cutting cost, compressing timelines, and reducing headcount. But when organizations do that without a deliberate plan to preserve developer capability, they risk creating a system that is optimized for short-term throughput and less resilient when requirements shift.

Now layer in incentives and board dynamics. When executives face layoffs and underemployment in the labor market, they have a strong temptation to treat AI as a replacement engine rather than a co-pilot that also forces upskilling. Boards, meanwhile, are often asked to balance cost control with long-term execution risk. The second-order effect is that “cheaper code” can become “fragile code,” if engineers are no longer sharpening the foundational skills needed for maintainability, performance tuning, secure design, and architecture work. Matt’s commute is a micro example of what happens when employees try to protect themselves. At scale, you get a workforce that is both hurried and anxious, using personal time to keep skills alive.

There is also a regulatory and governance angle, even if the source does not name specific agencies or rules. In software work, AI review introduces new questions around accountability: who is responsible for correctness, for security posture, and for compliance when AI-assisted code enters production. That becomes harder when the job description shifts away from architecture and toward inspection. For executives, the practical takeaway is not just “use AI responsibly,” it is to define clear ownership. Teams need processes that map the decision points: what must be reviewed, what standards apply, and how engineers demonstrate competence beyond trusting that output is “probably fine.”

Collective action enters the picture because individual coping strategies do not scale. Matt is protecting himself by not naming his real identity and by using his time for independent coding. But many engineers cannot carve out that kind of buffer. If layoffs and underemployment continue, employees have less freedom to experiment and upskill on their own schedule. That is where collective approaches become strategically important: shared training programs, internal coding standards, mentorship for architecture fundamentals, and coordinated career development can reduce the risk that AI turns engineering into a narrower job category.

Ultimately, Matt’s four-hour train ritual is not just a personal productivity hack. It is a signal of what is happening inside software organizations: work is shifting from building to reviewing AI-generated code, and that can weaken skills if teams do not intentionally design for skill preservation. For founders, engineering leaders, and investors, the stake is simple. If engineering talent becomes review-heavy without maintaining depth, the company may get faster outputs while quietly losing the capability to adapt. The disruption is real. The only question is whether leadership treats it as a temporary efficiency win or a long-term capability rebuild.