Enterprises are increasingly investing copious amounts of cash in AI without a lot to show for it. This could be, in part, because the wrong people are leading the change.

As I’ve argued before⁠, AI isn’t likely to eliminate developers so much as change what we need from them. For example, we keep asking whether junior developers are needed in a world where large language models can write code faster and cheaper. What this overlooks is the reality that these younger developers and their relative inexperience may be exactly what we need to rewrite the rules of software development.

This thought hit me while reading James Governor’s riff on something Ben Griffiths⁠ wrote about our industry’s habit of confusing age with authority. Griffiths remembered sitting through a conference talk in which a speaker tried to shame a young audience for not recognizing some of the older men who had shaped computing. The irony, Ben noted, was that many of those “old men” had done their world-changing work when they were younger than the people being lectured. Bill Joy wrote vi when he was 22, John Carmack created Doom at 23, Linus Torvalds launched Linux at 22, etc. Many of our industry’s titans made their biggest contributions before they had decades of experience.

The point isn’t that young people are smarter. They’re not. The point isn’t that the key to AI success is to ignore more experienced developers. That’s dumb. Rather, it’s a suggestion that Griffiths’ larger point is right: At the beginning of big shifts, experience can be a mixed blessing. It can help you see risk, but it can also make you overconfident in old ways. The most successful enterprises will find ways to balance youthful innovation with experienced guardrails.

The factory doesn’t redesign itself

Zara Zhang recently pointed to Paul David’s classic 1990 paper, “The Dynamo and the Computer,”⁠ as a way to understand why so many companies have “adopted” AI without much to show for it. David’s argument, simplified, is that electricity didn’t immediately transform factories. For a long time, factories simply swapped out the central steam engine for an electric motor while keeping the same layout, the same workflows, and the same assumptions.

Electricity was new, but we largely stifled its potential by force-fitting it into old factory systems.

The big productivity gains came later, when factories stopped treating electricity as a cleaner steam engine and started redesigning work around smaller motors distributed throughout the factory. Once each machine could have its own motor, the factory no longer had to organize itself around a single driveshaft. Work could instead be reorganized around the flow of production.

That’s a decent description of where many enterprises are with AI. Enterprises today are buying copilot licenses by the thousands, wiring agents into existing applications, etc., and then wondering why the results are so uneven, as I’ve written⁠. This is the equivalent of swapping the steam engine for an electric one and declaring that the AI modernization work is done. It’s not. Not even close.

The real payoff won’t come from asking AI to write the same tickets a bit faster. It will instead come from changing how teams define work and how (and what) developers build. The “factory” has to change.

So here’s the uncomfortable question: Who is most likely to build the new factory?

Experience cuts both ways

There’s an obvious danger in romanticizing youth. Plenty of bad software has been written by people with unlimited confidence and limited context. Enterprises need software that works, yes, but “works” also means it complies, scales, respects security boundaries, and more.

This is where experienced developers matter. A lot.

As I pointed out recently, the agent era makes engineering judgment more important than ever. After all, AI makes it easier to generate code, but easier code generation can become easier technical debt generation. Hence, the limiting factor becomes less of “Can we create something?” and more of “Can we create the right thing, in the right place, with the right constraints?” Taste is required, in other words.

Senior engineers are often better at seeing those constraints because their experience gives them “taste.” They know why the weird validation rule exists, and they remember the customer who depended on the undocumented behavior. They understand why a simple schema change can turn into a multi-week migration.

But experience also has a shadow side, because it can make the current process feel inevitable. A senior engineer may see an AI assistant as a faster autocomplete because that’s the easiest way to fit AI into their existing mental model. A junior developer, less invested in the old workflow, may ask the more interesting questions: Why are we doing this ticket at all? Why isn’t the spec executable? Why can’t the agent generate the test harness first?

It’s not that the more experienced developers don’t know these questions. Rather, they may simply not have the energy to rage against the machine, as it were.

The value of inexperience

The worst way to use junior developers in the AI era is to treat them as cheaper versions of senior developers. That was always a bad idea, but AI makes it worse. If the job is “take this ticket, generate some code, and send it to a senior person for review,” the junior developer becomes a human wrapper around a coding assistant. That helps no one. The junior doesn’t learn much, the senior gets buried in review, and the enterprise ends up with more code, which, as I’ve said, is hardly a good thing.

Instead, junior developers should be given room to explore new workflows, with just enough oversight from experienced colleagues. That might mean giving these newer developers interesting questions to answer, such as:

• How would we redesign onboarding if every internal API had an AI-readable contract and examples that actually worked?
• How would we change code review if the agent produced a change summary, test evidence, dependency risk, and rollback plan with every pull request?
• How would we build features if product requirements were written as executable acceptance tests rather than vague prose?
• How would we reduce toil if agents could safely perform routine migrations, dependency updates, or incident triage within clearly defined boundaries?

These are not toy problems. They’re not “junior work.” They’re exactly the sort of process redesign that enterprises need but generally avoid because everyone is too busy running on the existing hamster wheel.

Finding the balance

So what should engineering leaders do? First, stop treating AI adoption as an individual productivity contest. We seem to be moving quickly away from the idea that “lots of tokens” equals “great engineer,” but the fact that we even flirted with it is damning. I love how Santiago Valdarrama eviscerates this vanity metric: “Measuring AI productivity in number of lines written is a stupid mistake. One day, everyone will have always been against this.” Instead we should be asking questions like, “What part of our software delivery process no longer makes sense?” AI’s biggest gains will come when we change how we specify, test, review, and ship software.

Second, mix up your AI workflow teams. No, not committees or PowerPoint-producing centers of excellence. I’m talking about combining two or three newer developers who are already fluent in AI-native tools with two or three senior engineers who understand production, security, architecture, and organizational constraints. Then give them a real workflow to redesign, such as dependency upgrades or test creation.

Third, make the senior engineer’s job less about saying no and more about defining the guardrails within which others can say yes. I’ve argued that golden paths are key to using AI effectively. Good senior engineers should define the paved roads: approved patterns, test requirements, observability standards, etc. Then let junior developers and agents move quickly inside those boundaries.

Fourth, reward deletion. This may be the most important point. Going back to the factory electricity metaphor, we’ll fail with AI modernization if we simply add AI without removing outdated processes.

Bring everyone to the table

The future of software development won’t belong to the young. It won’t belong to the old, either. It will belong to teams that combine the talents of both.

Newer developers often bring impatience. They’re less likely to accept the existing workflow as sacred. They’re more likely to try weird tools, compose them in unexpected ways, and wonder why enterprise software development feels like a ritualized exercise in waiting for permission.

Experienced developers bring judgment. They know that software has users, auditors, attackers, budgets, latency, history, and consequences. They know that the right answer is often boring, and boring is good.

Enterprises need both. They need the developer who asks why the factory is still organized around the old drive shaft, and they need the developer who knows which machines will kill someone if moved casually. In sum, every development team needs people who know why the old system exists… as well as those who don’t.

Microsoft’s president, Brad Smith, has reacted to student discontent with AI, telling today’s graduates that there is still a place for human creativity.

Students across the US have booed speakers who talked up AI at their graduation ceremonies in recent months, including Google’s former CEO Eric Schmidt, the CEO of a record label, and a real estate executive.

Smith hasn’t ventured out onto a podium to share his views, but in a lengthy blog post, AI, Jobs and the Next Generation, acknowledged students’ concerns about their futures.

He said that, just as painting survived the arrival of photography, so will the job market survive the arrival of AI. “While it may feel unfair that the job market is so uncertain, you were made for this moment. Technology is second nature to your generation. Constant change has taught you how to adapt quickly,” he wrote.

He also used the blog to promote a book written by his colleagues Ryan Roslansky and Aneesh Raman on how to get ahead at work in the age of AI.

The corporate world will see massive changes, he said: “This includes AI automation of tasks in current entry-level positions and, especially in the tech sector, corporate pressure to reduce headcount to help pay for AI’s enormous capital expenditures.”

Some of those changes are already here. In the past six months, we have seen massive job losses at Oracle, at Meta and at AWS. There are no signs of any let-up: Last month saw the tech industry shed more than 38,000 jobs. Students contemplating their future will find little comfort in Smith’s optimistic words, particularly as his essay shows that Microsoft is not making any changes to its AI program going forward.

Technology companies announced 38,242 job cuts in the US in May 2026, the highest monthly total for the sector since August 2024, according to research by employment placement company Challenger, Gray & Christmas. So far this year the company has observed 123,653 US technology job cuts, a rise of 66 percent from the same period in 2025.

These figures represent the third successive month that there has been an increase in job layoffs across all sectors, the company said.

“The labor market is being reshaped by technology in real time. AI is now the leading reason companies give for cutting jobs and the primary industry citing it is technology,” said Andy Challenger, chief revenue office at Challenger, Gray and Christmas.”

AI was blamed for 38,579 of the 97,006 job cuts announced across all industries tracked by the company. It accounted for 40% of the cuts observed in May, up from 7% in January.

This year has already seen some major layoffs in technology. In March, HPE slashed 2,500 jobs from its wage bill, while Oracle announced plans to shed an unspecified number of developers. And the cuts keep on coming, just last month, Meta shed 8,000 employees.

Microsoft has announced Coreutils, a new Windows 11 feature that allows developers to run many popular Linux command line utilities natively on Windows from a single binary.

Revealed at this week’s Build 2026 developer conference in Seattle, Coreutils is about reducing what Microsoft terms the “cognitive load” faced by developers when moving between Windows and other platforms.

Currently, accessing the Linux command line utilities that are considered essential in many CI/CD development environments on Windows requires a kludge that involves either opening an emulation such as Git Bash, or a virtualized Windows Linux Subsystem (WSL) terminal.

Both are time-consuming and inefficient. As Microsoft’s announcement puts it: “Developers constantly move between platforms, but familiar commands don’t work consistently, forcing workarounds, lost speed and context switching.”

Coreutils removes the need for this back and forth, allowing developers to run most Linux commands straight from the Windows CMD command prompt, PowerShell, or Windows Terminal.

“Whether you’re moving between Linux, macOS, WSL, containers or cloud environments, the commands and workflows you’ve built over years just work in your Windows environment,” Microsoft said.

Most utilities, but not all

Installed as a single executable (via WinGet: install Microsoft.Coreutils), Coreutils for Windows itself is a Rust rewrite of the GNU uutils/coreutils project that provides commands that are universal across Linux distros.

Fundamental to making Coreutils efficient to manage is the fact that individual Linux commands run from a multi-call executable which maps via NTFS hardlinks pointing to each command. The advantage of this approach is that there’s only one binary to install, one binary to sign, and one binary to patch or update.

Microsoft lists 75 Linux utilities supported by Coreutils, including commonly-used commands such as ls, cp, find, grep, find, rm, du, hostname, and uptime.

However, some Coreutils commands clash with existing CMD or Powershell commands, or are otherwise not possible to execute; Microsoft provides a compatibility table listing conflicts. This means that some commands are not available, specifically: dir, expand, kill, more, timeout, and whoami.

There are also some commands omitted from Coreutils because a command relies on a POSIX Unix/Linux feature that Windows doesn’t implement in a compatible way; some examples are chmod, chown, id, stty, and chroot.

In other cases, the command will execute in one context, CMD, but not in PowerShell. Microsoft explained the complex order of precedence:  “Whether the Coreutils version runs depends on the shell, the PATH order, and (for PowerShell) the alias table.”

As well as Coreutils, the Build 2026 developer conference also saw Microsoft announce WSL containers CLI and API to deploy Linux containers on Windows, a new framework for autonomous agents with open source governance tools, and Microsoft Scout, an AI agent designed to automate tasks in Microsoft 365.

This article originally appeared on InfoWorld.

For years, software developers on H-1B visas benefited from steady demand among US technology employers. That market is becoming more selective as companies redirect spending toward AI and rely more heavily on coding assistants.

Recent layoffs at companies including Meta and Amazon have added to the uncertainty, with engineering and software roles affected even as major technology companies continue to deepen investments in AI.

Developers and analysts say traditional engineering roles are becoming harder to land, recruiters are asking more often for AI-related experience, and workers are being pushed to keep pace with tools such as GitHub Copilot, Claude, and ChatGPT.

The shift is being driven by both AI investment and broader economic uncertainty, according to Pareekh Jain, CEO of Pareekh Consulting. Companies are changing the profile of the developers they want, hiring fewer people in some areas while paying more for AI talent.

“AI investments are changing company hiring strategy,” Jain said. “They require a different profile, fewer numbers, and also across geographies.”

This shift is colliding with a tougher sponsorship environment for H-1B developers.

Jain said companies are more selective about hiring visa-dependent workers than they were two or three years ago, especially when permanent residents and US citizens are more available in the market.

“Companies are not looking for H-1B now,” Jain said. “They are building a local workforce and preferring green card holders and citizens.”

Employers may now be more likely to consider H-1B candidates only when they have immediate project needs, rather than building a longer-term bench of visa-dependent workers.

Concerns are visible in public forums used by technology workers. In one January post on Blind, an anonymous senior software engineer with seven years of experience said she had been laid off while on an H-1B visa and was “not interview-ready,” highlighting how quickly job loss can become a visa problem for H-1B workers in the US.

Junior developers face the squeeze

The combination of AI tools and tighter hiring is hitting early-career developers hardest, said Adarsh ML, a product engineer at Ather Energy who tracks global engineering hiring trends.

“Companies are increasingly looking for specialized engineers with machine learning and data science skills,” Adarsh said. “Job opportunities for people with zero to three or four years of experience are not really there anymore.”

The shift is also changing team structures, Adarsh said. Earlier, one manager may have had two or three interns and several freshers reporting to them. Now, many of those roles are being replaced by AI agents.

“Companies now want people who understand software well enough to catch the mistakes these AI agents make,” Adarsh said.

That creates a longer-term risk for the software talent pipeline.

“If companies only want people with five years of experience to manage AI agents today, who will have that experience five years from now?” he said. “There may not be enough experienced developers left.”

AI literacy becomes baseline

The impact is not the same for every role. Sophia James, an Indian software professional based in the US who works in database monitoring, said AI has not significantly changed her team’s daily workflow. But AI literacy is becoming a management expectation.

“Managers are trying to understand whether we are keeping up with the changes happening in the market,” James said. “Recently graduated students, whether BS or MS, are finding it difficult to get jobs. But people who already have jobs, like us, are not facing that much of an issue in terms of projects continuing.”

Jain also stressed that AI literacy is now becoming a baseline expectation for software developers, even outside AI-focused roles.

“Being AI-literate is a must now, even if the role is not directly in AI development,” he said. “This is like knowing Excel even if you are not from finance in the earlier era.”

Fewer developers required

Jain said AI coding tools are likely to reduce the number of developers companies need for similar tasks, making the technology deflationary for some software work.  

But Jain added the impact may not be entirely negative. Enterprises will need to invest in data, cloud, and modernization to become AI-ready, creating new work. AI could also encourage companies to build more applications internally instead of buying from SaaS providers, potentially creating opportunities for IT services firms.

The effect is already visible in hiring decisions. Nikhil Dhiman, head of engineering at CarInfo, said AI is changing the economics of early-stage software development, particularly when companies are building proofs of concept or testing new ideas.

“Some companies are very cautious now,” he said. “They want to leverage AI more and hire less. They just want to see the impact first.”

Navigating the new hiring market

Familiarity with tools such as ChatGPT and GitHub Copilot is now a baseline requirement for developers, said Sanchit Vir Gogia, chief analyst at Greyhound Research.

Developers need deeper expertise in areas such as cloud infrastructure and data engineering, as well as security and AI governance, he said. Those skills are closer to the systems enterprises need to validate and scale, rather than the routine coding work AI tools are starting to compress.

“The engineer who only produces output grows easier to replace as the output grows easier to generate,” Gogia said. “The engineer who can validate it, secure it, situate it in a real business, and stand behind the result becomes harder to replace.” For H-1B developers, he said, adaptation also requires visa planning. Developers should understand portability rules and employer sponsorship timelines before a job loss forces urgent decisions.

“A high-skilled worker has up to 60 days after a role ends, and the right to begin new employment the moment a valid portability petition is filed,” Gogia added. “The strategic error is treating that window as a safety net rather than a planning horizon.”

The article originally appeared on InfoWorld.

Tech companies seem to be falling over each other these days in firing people to either replace them with AI or to pay to build AI infrastructure. Wouldn’t it be nice if they at least waited until AI actually worked for business?

On the one hand, top tech businesses such as Amazon, Block, Cisco, Cloudflare, and Meta have all announced that they’re slashing payrolls — either because AI can do the same work as people or they need the cash to build out their AI infrastructure. Isn’t that great? All together, of the 37,638 tech job cuts so far this year, 47.9% — almost half —  can be tracked back to AI. 

On the other hand, despite all the AI hype and hysteria, no one has yet proven that AI is, generally speaking, really all that helpful for businesses. Oh, I know, I know. You did great things with OpenClaw vibe programming. Microsoft’s CEO, Satya Nadella, claims 20% to 30% of the company’s code was written by AI. And Nvidia assures us that 88% of its surveyed customers report AI has increased their revenues. 

But really, what else would they say? “Dear Board, we just blew half a billion bucks on Nvidia GPUs, and we’re losing money hand over fist?” I don’t think so.

The truth is, as an IDC study reports, a mind-boggling 88% of proof-of-concept AI projects never reach production. Lest we forget, MIT’s The GenAI Divide: State of AI in Business 2025 study found that 95% of AI projects fail to deliver measurable P&L impact. 

Now, I have to acknowledge that AI is finally becoming truly helpful in business. As a guy who knows a thing or two about programming, Linus Torvalds, creator of Linux and Git, said at Open Source Summit North America, “I’m personally 100% convinced that AI is changing programming.” He estimates that “AI will increase your productivity by a factor of 10.” 

But is that reason enough to slash make workforce cuts of between 10% to 40%? (Short answer: No. Longer answer: Noooo!)

It’s not just the mass firings. Workers who are either awaiting the axe, or have escaped it for the moment, are miserable. As one Meta employee told The San Francisco Standard, “I tend to cry in the shower,” and, “A lot of my feelings about my job are about the general chaos and not just the layoffs. ” 

So, explain this to me: When everyone knows AI-driven layoffs are coming, exactly how well do you expect them to work? You really think they can give their best? 

Making matters worse, it’s an open secret that IBM, Google, and Meta are having their employees train their AI replacements. As a popular meme puts it, workers are now “building your own coffin.” Is it any wonder that a lot of people — 29% of all employees and 44% among Gen Z workers —  are deliberately sabotaging work when the boss insists they train their AI replacements?

It also sure doesn’t help office morale when the CEO keeps saying AI will replace half of all employees. A particularly egregious example of this was when Standard Chartered CEO Bill Winters proclaimed his bank would slash thousands of jobs and replace “lower-value human capital” with AI.  

He’s since backed off the claim, but come on — we all know he meant it. Just like all the other CEOs who’ve said similar things, between FOMO and the knowledge that AI job news is sure to make the stock price jump, they’re eager to cut headcounts and boast about how successful AI will make them. 

What happens a few quarters down the road? Their attitude today seems to be let  tomorrow take care of tomorrow. I hate to tell them, but that really doesn’t work in the long run. (Not, mind you, that a future much farther ahead than the next quarter seems to matter much anymore to business executives.)

It should. As a recent Deloitte study stated: “Most respondents reported achieving satisfactory ROI on a typical AI use case within two to four years. This is significantly longer than the typical payback period of 7seven to 12 months expected for technology investments. Only 6% reported payback in under a year, and even among the most successful projects, just 13% saw returns within 12 months.” 

AI, in short, is not the miracle cure for what ails businesses that its fans claim. 

Will that stop businesses? I doubt it. While I appreciate that California Gov., Gavin Newsom is trying to bandage the AI job bleedout by mandating studies on subsidizing companies to keep employees rather than replace them with AI, I doubt that will do much to staunch the wound. 

At the Open Source Summit North America, Linux Foundation CEO Jim Zemlin was optimistic about AI and jobs. He pointed out that, thanks to AI becoming  “pretty damn good coders,” the number of open-source projects on GitHub has led to a “surge of new code and projects.” 

Zemlin also believes that while few developers will write code, “engineers will still design, review, secure, and integrate that code.” (He’s referring to what’s becoming  known as forward-deployed engineers.) This, in turn, will supposedly lead to tech job growth. 

I’d feel a lot better about that prediction if I believed the C-suite suits at most companies were capable of truly forward-looking thinking rather than focusing entirely on hiking the stock price by making the next quarter look good through staffing cuts. 

In the long run, sure, AI will make us more productive. But, we’re not there yet. For now, companies need to keep employees happy, not shove AI down their throats — and work out carefully and thoughtfully how AI will really work for business.