WHAT GM ACTUALLY DID
The cuts affected approximately 600 salaried IT employees, concentrated in GM's Austin, Texas and Warren, Michigan offices. The affected roles were not randomly distributed — they were specifically positions in areas where AI has demonstrably changed what human effort is required. Traditional software development, manual QA, legacy systems maintenance, and IT operations roles where the work is increasingly handled by AI-assisted tooling were the primary targets.
The simultaneous hiring is what distinguishes this from a straightforward cost-cutting exercise. GM was not trying to reduce the size of its IT function — it was trying to change its composition. The job postings that went live the same week as the layoff announcements specified: AI-native development, data engineering and analytics, cloud-based engineering, agent and model development, and prompt engineering for new AI workflows. These are not the same skills as the roles being eliminated, and in most cases they command significantly higher compensation. The total headcount of IT may fall, but the capability per head is intended to rise.
The context is GM's broader strategic pivot. The company retreated from autonomous vehicle development and electric vehicle investments that proved commercially difficult, and is now concentrating its technology investment on software-defined vehicles — cars and trucks where the core product differentiation is delivered through software rather than hardware. The key partnerships are with Google (Gemini for in-vehicle AI and cloud services) and Nvidia (Drive Thor for the centralised compute architecture). Building and operating those systems requires a different engineering profile than the IT department GM built over the previous two decades.
THE SKILLS BEING SHED VERSUS THE SKILLS BEING HIRED
The skills swap is specific, and the specificity matters. On the outgoing side: generalised software engineers maintaining internal enterprise systems, IT operations staff running infrastructure that is moving to cloud providers, QA testers whose work is increasingly automated, and legacy system specialists whose expertise is tied to platforms that are being retired or replaced. These are not low-skill roles — many of them require significant domain knowledge and years of institutional experience. They are roles where the economics of AI-assisted alternatives have shifted the calculation for large organisations.
On the incoming side, GM's postings were equally specific. AI-native development means engineers who design software from the ground up assuming AI assistance in the development loop — not engineers who have learned to use Copilot as an add-on, but engineers whose development practice is fundamentally structured around AI generation, evaluation, and iteration. Agent and model development means engineers who can build and deploy AI agents that operate on GM's internal systems and customer-facing products. Prompt engineering for new AI workflows means specialists who can design the instruction structures that make those agents behave reliably in production.
The compensation implications are significant. The roles being eliminated are mid-market enterprise IT salaries. The roles being opened are competing with the broader technology labour market for AI specialisation, which is at a premium. GM's total IT payroll may not decrease much even as headcount falls, and if the hiring succeeds, the capability per dollar spent should increase substantially. Whether that calculation works out in practice depends on the quality of the hiring and on how long the transition period — during which institutional knowledge walks out the door ahead of new capability arriving — lasts.
THE SOFTWARE-DEFINED VEHICLE CONTEXT
The specific nature of GM's strategic direction matters for understanding why this skills swap is happening now and in this form. A software-defined vehicle is, at its core, a platform: a centralised computing architecture (in GM's case, built around Nvidia's Drive Thor) that runs software delivering the car's behaviour, with the ability to update that software over the air after sale. The competitive differentiation is increasingly in the software layer — the AI models that power driver assistance, the voice interfaces that handle in-cabin experience, the predictive systems that manage powertrain efficiency.
Building and maintaining that software layer is different from the enterprise IT work that has historically employed most of GM's IT department. It is closer to product engineering than to infrastructure operations — it requires the skills to build AI-powered features, integrate with cloud-based model serving, manage data pipelines that train on fleet telemetry, and deploy updates reliably to millions of vehicles in the field. None of that maps neatly onto the skillset of an enterprise application developer or a legacy system administrator.
The Google Gemini partnership is particularly relevant here. GM has committed to building its in-vehicle AI experience on Gemini, which means its engineers need to work with Google's model APIs, prompt structures, and safety constraints as a core part of their development workflow. That is a specific technical capability — not generic AI familiarity but expertise with a particular platform and its operational characteristics. The roles GM is hiring for are calibrated to those specific requirements, not to a generalised sense of "AI skills."
WHAT THIS MEANS FOR IT PROFESSIONALS
The GM announcement will be read by many IT professionals as a threat, and it is appropriate to be honest about that. The specific skills being eliminated are common across large enterprise IT organisations, and GM is not the only company running this calculation. The same dynamic is playing out at financial institutions, healthcare systems, retail chains, and manufacturing conglomerates that have built substantial IT departments around capabilities that AI tooling is now partially automating. GM is the most visible example this week, not an outlier.
The honest advice for engineers in the affected skill categories is to focus on the distinction between skills that AI automates and skills that AI augments. Manual testing, routine infrastructure operations, and legacy system maintenance are areas where AI tooling is increasingly performing the core work. System design, complex debugging, security architecture, and the domain knowledge required to build software in specific verticals are areas where AI augments rather than replaces human capability. The transition from the first category to the second is not automatic — it requires deliberate investment in new skills over a multi-year period, and the time to start is earlier than the layoff announcement.
The harder truth is that "AI-native development" is not a certification or a course completion — it is a practice. Engineers who have spent the last year building real systems with AI assistance, making judgment calls about when to trust AI output and when to validate it more carefully, developing intuition about where AI-generated code is reliable and where it is subtly wrong, have a genuine advantage over engineers who have engaged with AI superficially. The skills GM is hiring for are not acquired quickly, and the organisations competing to hire them — from hyperscalers to automotive companies to financial institutions — are all in the same market simultaneously. That is good news for engineers who are already there, and a real constraint for those who are not.