AI has created a tough job environment for entry-level workers and things aren’t getting better anytime soon — even those with AI capabilities now need “senior-level” skills to land a job.

“AI-exposed entry-level roles are seven times more likely to require traditionally senior-level skills such as judgement and leadership,” consulting firm PwC said in a study released this month.

That’s because AI is changing the traditional career ladder. Companies are increasingly looking for candidates that use the cutting-edge tools and services to amplify their performance and grow faster. “Organizations must rethink how they mentor and train junior staff, helping them step up to complex decision-making much earlier in their careers,” PwC said.

Entry-level job seekers with or without AI skills are already dealing with stagnant wages,  layoffs, and stalled hiring. 

(The PwC findings echo similar concerns raised late last year in McKinsey’s State of AI report. Many companies are reducing headcount by deploying AI agents to take over entry-level jobs.)

Early-career AI job postings “have flatlined in highly AI exposed sectors,” and listings for junior roles with mid-career or senior-level skills have grown 35% since 2019, PwC said.  The consulting firm largely discounted the notion that AI is taking jobs away, though other studies point in the opposite direction. 

By the end of May, AI-driven job cuts had reached 87,174 for 2026, already outpacing the total of around 54,836 in 2025, according to figures released by Challenger, Gray and Christmas earlier this month.

The AI-driven layoffs haven’t reached the “jobpocalypse” stage yet, and workers are more productive with it, said Andy Challenger, chief revenue officer at Challenger, Gray and Christmas. But companies are rethinking hiring and long-term operational strategies as AI becomes a routine component in daily workflows and processes, he said.

Businesses are “restructuring aggressively as they reposition for an AI-driven economy,” he said.

That’s putting downward pressure on entry-level hiring as AI tools absorb more routine work, said Kye Mitchell, head of Experis US, a part of ManpowerGroup. “That doesn’t remove opportunity, but it changes the expectations. Employers now expect candidates to come in with hands-on experience, AI familiarity, and the ability to contribute faster,” Mitchell said.

Compensation remains strong for specialized, in-demand skills, while more commoditized roles such as customer service, helpdesk, and some entry-level positions  are flattening. “The shift overall is toward skills-based hiring, where demonstrable capability matters more than credentials alone,” Mitchell said.

Graduates who combine technical fundamentals with practical experience, AI fluency and strong communication skills stand out quickly. Job candidates can’t rely solely on academic credentials. 

“Employers are moving away from ‘train-from-scratch’ hiring and looking for talent that can contribute earlier and continue to adapt,” Mitchell said.

The PwC study also focused on the productivity gap between companies that have invested heavily in AI and companies lagging in adoption.

Since ChatGPT showed up in 2022, AI-exposed companies have seen productivity gains of 40% versus other companies. “The companies achieving the biggest productivity gains from AI are not using it only to cut costs,” PwC said.

AI-forward firms are also raising headcounts and wages. “Far from being a job killer, AI may actually be a job expander when used to unlock growth and enter new markets,” PwC said. 

Workers who use their domain expertise to supplement AI tools can advance, with AI-exposed roles “2.5 times more likely to rely on skills like empathy, judgement, and creativity that become even more valuable as AI absorbs some routine work,” PwC said.

China’s e-commerce giant JD.com is preparing for a future where packages are delivered by robots instead of people. The company’s founder and chairman, Richard Liu, expects robots will “sooner or later” take over deliveries from the company’s roughly 700,000 couriers.

“It will definitely be robots delivering packages. But I really don’t want our 700,000 brothers to go without food and without jobs,” Liu said at the Asia-Pacific Economic Cooperation CEO Forum, according to the Financial Times.

He did not provide a more specific timeframe for the change. As part of the transition, Liu said JD.com has entered into agreements with about 120 schools to retrain couriers for new professions, including the repair and maintenance of robots.

The number of gig workers in China — including delivery drivers, chauffeurs, and factory workers on temporary contracts — is expected to reach about 320 million this year, according to Chinese researchers. At the same time, the youth unemployment rate stands at over 16%.

I was blessed with a terrific high school English teacher. Ms. Jewel was funny, kind, interesting, and tough on us. I can still spell “ecstasy” on the first try because of her. One of the more memorable lessons she taught was a “Hemingway and Fitzgerald” module. 

I loved the short stories of both, but Hemingway’s work always stuck out for me. It’s cliché to say that Hemingway was terse, but we only say it because it is true. He could pack more into a page than most writers. He didn’t waste a syllable. 

Software developers are soon going to have to take a lesson from Hemingway.

It’s not hard to be concise in code. You have to be, by design. The compiler won’t put up with any throat-clearing and jibber-jabber. You can’t meander. You have to use a very strict set of words and symbols, and you have to use them in a defined way. 

Thanks to agentic development, we don’t write code anymore. But we are writing for the agents. A lot. 

All about the spec

Let me explain. Claude Code, Codex, Copilot, and the rest all love to be “spoken” to in Markdown. We used to define our code with unit tests and specifications written for humans. Now, it’s all about the spec. And the spec needs to be both complete and concise. 

It needs to be complete in the sense that if you leave something out or forget to define something, the agent will very likely fill in the gaps for you. Forget a feature or requirement, and the agent will go off confidently and almost certainly in the wrong direction.

At the same time, you need to be concise. Because if you are too effusive, you may give the agent ideas that you don’t want it to have. If you write like Fitzgerald — lush and expansive —  the agent will be off and running in a direction you can’t be sure about. 

Our compilers will stop cold if we aren’t precise and concise. Our agents? They will proceed with confidence, diligently producing a result that looks great but isn’t what we want.

So we need to learn to write like Hemingway and pack as much meaning into as few words as possible. Or, as Paul Graham said:

Let’s be clear

For years, we’ve been writing semi-vague Jira tickets and expecting our fellow humans to fill in the gaps and “get the gist” of what we were trying to do. We don’t have that luxury anymore. Developers who aren’t able to move on from “Jira-speak” to “Agent-speak” are going to struggle. If we don’t follow Graham’s advice in writing those specs, who knows what we’ll get.

Maybe someday agents will know the ins and outs of our business well enough to “know what we mean,” but they can’t today. The time we used to spend coding now needs to be spent perfecting our new craft of writing precise specifications for our agents to execute.

Every listicle ever written on “How to be a Great Developer” says you need to be a great communicator — but that was communication with other humans. 

Ms. Jewel always taught us that our writing is only as clear as our thinking. Our compilers forced us to write clearly. Our coding agents won’t do that. I’m sure there are many developers out there now who wish they had listened more closely to their high school English teacher.

Hot AI companies can’t stop talking about forward-deployed engineers (FDEs), which are now very much in vogue. 

FDEs, in case you haven’t heard, are hired by companies looking (hoping?) to successfully deploy AI tools and services. It’s one of the hotter professions in a world still trying to understand the impact of AI on careers.

So, what exactly are FDEs — are they techy lone rangers like the ones OpenAI, Google and Microsoft are hiring? Turns out it’s not so much about individual engineers who swoop in to design and roll out AI deployments; it’s more about a team of engineers working together at customer sites.

At least, that’s the view at Amazon Web Services (AWS).

In fact, according to Taimur Rashid, managing director of the AWS Generative AI Innovation Center, the FDE concept pre-dates the current generative AI (genAI) gold rush. The same kinds of engineering teams were needed for the earlier machine-learning and cloud eras to help companies with deployments.

Rashid recently talked about how AWS sees FDEs as a profession in a conversation with Computerworld. And he weighed in on the desired job skills the company seeks in this increasingly AI-centric era.

What is an FDE? “We view it as a team. It’s a cross-functional team that has engineers, scientists, strategists, and folks that can piece technology and business together. In some cases, we do have to have security engineers in there, too. 

“I see them as anesthesiologists. They have to prep so many things, monitor things throughout. We see ourselves as a frontier deployment team helping customers adopt all forms of AI, whether it’s genAI, agentic AI, even emerging trends like physical AI. We’re helping these companies become frontier themselves.”

How does an FDE engagement begin, and how is it structured? “Where we see the forward deployed model is when customers come in — for example, we have our executive briefing center in Seattle and in Arlington, VA. When customers share what they’re trying to do, very quickly a customer’s like, “What’s the quickest way I can go and build something with you?” 

“We’ll forward deploy our people in, we’ll embed them in your business and we’ll go through these 45-day sprints that we typically design. Through those successive sprints, we’re building stuff together, we’re proving value, and then they can expand that to a much broader engagement.

Where do FDEs actually sit? Client side, internally, or in-between? “It’s mixed, and it largely depends on what the customer’s preference is. We’ve seen models where the customer has been very adamant that, ‘We want your teams with us in our business.’  In those cases, we forward deploy the majority of the teams on site. 

“We have models where customers are fine with you being wherever you’re based, as long as you’re still embedded virtually. And then there’s a hybrid. We deploy anywhere from five to seven people. Sometimes, the baseline is actually three.”

Will cost savings be the job of an FDE, or someone else on the team? “I expect these teams to be able to architect systems that have those cost requirements in mind, whether it’s use a different model for a different use case that doesn’t increase the per-token cost…or think about ways where you can use semantic caching. I personally think you may have a high spend in token consumption, but if you’re generating revenue, as long as the economics work out, then you’re at peace.”

What challenges have you gone through deploying FDEs in the real world? “One of the challenges worth highlighting is when customers get really excited about us forward deploying resources, what they end up realizing is [that] they’re not set up to absorb that right away. They realize they have to go through … process-related things, security access — all those operational things. 

“One very good example is the Commonwealth Bank of Australia. They said: “Prioritization’s a big thing, and if you forward deploy and you’re 100% dedicated, how do we ensure that our teams are also equally 100% dedicated?’ When you’re sitting in your office, you’re distracted by your day-to-day. So they said, ‘Why don’t we create a neutral ground in Seattle? You fly your people, we’ll fly our people. We’ll give them three weeks of dedicated time so they have no distractions.’”

Have you gone into projects where they want AI but have no security or governance ready? “I’ve been through this before, certainly. We do see customers that have security processes and capabilities, but it’s not as tight as it should be in the age of AI. Governance is the biggest area where customers right now have the biggest gap. I’m talking governance around agents. In the past two months, almost 100% of the conversation around agents is not about capability. It’s all about governance. 

“That is a big area right now where forward deploy teams are helping with governance education, and building the scaffolding for that.”

How does software engineering fit into the FDE model? “One of the greatest learnings is that as we forward deploy resources and get customers to take AI and integrate it into their systems, the knowledge of software engineering is so important. Today, a customer can use one of the Claude models and scan their code base and look at vulnerabilities. 

“The tough part is not assessing those vulnerabilities, it’s remediating [them]. Remediating [them] requires software engineering experience, because you have got to merge code, test it, deploy it. We largely see that the frontier software development teams are smaller and they’re managing agents that are doing various tasks across the software development lifecycle.”

AWS has many models at your scale, open source, closed — it’s more complex than what other AI vendors offer.  How do you nail down the talent? “It’s massive, and when you look at not only scale, it’s the complexity of the stack. We take an approach where we fundamentally do three important things: No. 1, we want to ensure people understand concepts; they have to understand pre-training, post-training, reinforcement, fine-tuning. 

“Secondly, we make sure that our teams are well versed in their first-party services. The third thing is that by design, AWS has always been about choice. We say, ‘Let’s do 80-20 here. What is 20% of those specialties that we need to have, which can cover 80% of what most customers are trying to do?’”

What skills should software developers learn to move into FDE work — the top three or four things? “We look at three categories. First category is entirely functional. Are they more engineering specific? Are they science specific? Are they security specific? Our litmus test is not only knowledge of the function, but the actual hands-on work that they can do with it. Secondly is around domain. I focus on what is their domain understanding across the whole AI lifecycle? The third thing is cultural. We are looking for folks that are okay at dealing with ambiguity, being good at stakeholder management, and having that startup mindset. 

“This AI transformation’s not for the faint of heart.”

There’s a rush for FDEs from OpenAI, Google, and others. What’s different about what you look for? “I don’t know entirely what the others are looking for, but I’ll tell you what we have been looking for in the past. When we hired solution architects, it was about systems level understanding. But what I see more and more is hands-on experience, cultural mindset, all these things are very important. If I had to pick one thing that is going to be very important in the talent that we either upskill or future talent that we hire, it has to be the application of AI towards software engineering and system integration tasks.

You’re upskilling AWS talent as well? “We do. You will see some publications coming out in the next couple of weeks around how do we do this across our software teams and how does that translate to customer-facing roles.”

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.