AI has spent the last two years collecting a familiar prophecy: that coding assistants, copilots, and increasingly capable foundation models would hollow out software engineering. SignalFire’s 2025 hiring data points in a different direction.
Engineering was the most resilient function in tech last year. SignalFire says engineering hires fell 11% in 2025, far less than the broader 25% drop in total tech hiring since 2019, and engineers made up 55% of all new hires at major tech companies, up from 46% previously. If the market was expecting AI to make engineering a shrinking back office, the hiring mix suggests the opposite: as AI products move from demos to deployments, engineering remains the center of gravity.
That does not mean AI has no effect on labor demand. It means the effect is more conditional, and more organizational, than the simplest automation narratives assume. Hiring data measures one slice of the labor market, not the full footprint of work. It captures employees tracked across millions of careers and more than 80 million companies, but not all contractor labor, not all non-tech functions that support product delivery, and not every regional hiring pattern with the same fidelity. It also cannot isolate causality cleanly. AI tooling may change team structure, planning horizons, or output expectations without immediately reducing headcount. In other words, hiring trends are a signal, not a verdict.
Still, the signal matters because it maps closely to how AI products are actually shipped.
Most AI deployments do not fail because a model cannot generate text or code. They fail because the surrounding system is brittle. The hard parts are data quality, retrieval pipelines, permissioning, observability, evals, rollback paths, and the mundane but crucial work of fitting model behavior into production constraints. That is why the recent resilience of engineering hiring should be read less as a rejection of AI automation and more as evidence that AI shifts the engineering burden upstream and sideways.
A team rolling out an LLM feature now needs more than prompt design. It needs data governance to control what the model can see, ML Ops to version and monitor model behavior, platform engineering to standardize deployment and reduce integration drag, and reliability practices that treat AI components as volatile dependencies rather than deterministic services. The more a company tries to scale AI across products, the more it needs engineering discipline around testing, feature flags, evaluation harnesses, and incident response. In practical terms, AI adoption tends to increase the value of engineers who can build the scaffolding around models, not reduce it.
That also helps explain why engineering’s share of hiring rose to 55% of all new hires in major tech companies. If AI work were simply substituting away engineering labor, you would expect the mix to tilt toward fewer technical roles and more generalized product or operations roles. Instead, the share suggests concentration: AI-enabled product development is still being absorbed into core engineering teams, often alongside SRE, infrastructure, applied ML, and data roles.
For product leaders, the implication is straightforward. Do not treat AI rollout as a lightweight feature exercise that can be layered onto existing systems without meaningful platform investment. If anything, the opposite is true. The first wave of AI features can be built quickly; the second wave, the one that survives contact with customers, requires durable interfaces between models, product logic, and enterprise controls. That is where ML Ops and platform engineering become strategic rather than merely supportive.
It also changes the talent strategy. In a tighter hiring environment, companies are likely to preserve core engineering capacity while using tooling and internal automation to amplify it. That means fewer bets on blanket headcount reduction and more emphasis on cross-functional AI squads, targeted upskilling, and reusable infrastructure that makes each engineer more productive without assuming the work itself disappears. SignalFire’s data does not say every engineer is equally insulated. It would be a mistake to generalize from a single function to all specialties, geographies, or business models. But it does suggest that software engineers, infrastructure engineers, and SREs remain in demand where AI is being operationalized rather than merely discussed.
The risk, of course, is complacency. If AI tools mature enough to handle more of the coordination work around code generation, test creation, or routine maintenance, the role mix could shift again. Regulatory pressure could also slow deployment in some verticals while accelerating the need for governance specialists in others. Regional hiring patterns may diverge as companies in one market automate aggressively while another continues to staff for implementation and compliance. The right conclusion is not that engineering is permanently safe. It is that the path from model capability to headcount reduction is neither direct nor universal.
For now, the hiring data says something more interesting: AI may be changing what engineers do faster than it is changing whether companies need them. The implication for AI product teams is not to cut engineering and hope the tooling fills the gap. It is to build the platform, data, and operating model that let engineering scale with the product.
