CAVEAT: There is a follow-up correction to this post regarding the work-permit rules and exempted occupations that you may want to read first here: pkt.systems/posts/038-swe-not-exempted/.
Sweden’s new work-permit compromise is being debated as immigration policy. For software and engineering, it is also a labor-market signal.
The government’s new model raises the general salary threshold for labor migration to 90 percent of the Swedish median salary, reported as 33,390 SEK per month, but exempts 27 occupations from that level. For the exempted occupations, the threshold is reported as 75 percent of median salary, roughly 27,000 SEK per month. The exempted list includes care roles, but also engineers, IT operations technicians, and system administrators. The rules are reported to take effect on 1 June 2026, with transition rules (Omni).
Sweden has been tightening migration policy for several years, including stricter salary requirements for work permits. The political argument has been that very low thresholds enabled exploitation, wage dumping, and forms of shadow employment. Employers and industry groups have objected that blunt thresholds can also remove workers from sectors that genuinely struggle to recruit. Svenska Dagbladet reported the earlier government compromise that moved the planned floor from 100 percent of median salary to 90 percent, while noting business concerns that higher salary floors could make international recruitment harder (Svenska Dagbladet). The later exemption list is the sharper signal: engineering and IT operations roles are reported to sit below that general floor (Omni).
That may be defensible in some sectors. It is more delicate in software and engineering, because the same occupational labels cover very different labor-market realities.
An AI researcher training models in-house is not the same labor-market object as a backend engineer, platform engineer, DevOps engineer, operations specialist, systems administrator, or full-stack consultant. A company may genuinely struggle to hire one machine-learning specialist while still maintaining a large ordinary engineering organization. The shortage of a narrow specialist role does not prove a shortage of general engineering capacity. It certainly does not justify treating the whole software labor market as one undifferentiated shortage category.
The exposed part of the market is not the tiny number of specialist AI hires. It is the broad capacity layer: the engineers who build, integrate, operate, maintain, deploy, refactor, support, and extend the systems that already run the business.
That is the layer now under pressure.
Shortage is not one thing
Software demand in Sweden is real. Borg, Wernberg, Olsson, Franke, and Andersson found that three out of ten Swedish firms develop software in-house, and four out of ten Swedish government agencies do the same; many private firms reported that the limited supply of software developers affected their expansion plans (Borg et al.). Software is no longer merely a sector. It is a production capability spread across the economy.
But "software shortage" is too blunt a category. It hides different problems that require different instruments.
One problem is genuine specialist scarcity. Some companies need people who understand machine learning, data pipelines, advanced security, embedded systems, distributed systems, or regulated-domain engineering at a level that is rare in the domestic market. Skilled migration can be useful and necessary in those cases.
Another problem is stack mismatch. Employers ask for specific combinations of tools, platforms, languages, frameworks, and cloud environments. A Swedish study of software job ads found rising demand for cloud and automation technologies such as Kubernetes and Docker, and observed that job ads emphasize specific technologies while higher education emphasizes concepts (Dobslaw et al.). That does not prove employers are wrong to care about tools. It does show that hiring increasingly expresses capability needs as technology inventories.
A third problem is role inflation. What used to be several roles is compressed into one requisition: backend development, cloud, Linux, Kubernetes, CI/CD, observability, microservices, architecture, operations, stakeholder communication, frontend development, and now AI-assisted delivery. A few people can cover much of that territory. Their existence does not make the requisition normal. It means the labor market has learned to ask for a collapsed team and call the absence of one person a shortage.
These problems require different responses. Specialist scarcity may justify international hiring. Stack mismatch may justify better training, better selection, and less literal filtering. Role inflation requires organizational redesign.
Conflating them is how policy becomes dangerous.
AI-specialist scarcity is not the capacity market
The current AI labor-market discussion makes the confusion worse. Svenska Dagbladet, reporting on Techsverige’s analysis, described AI knowledge as a growing labor-market requirement, with AI appearing in far more job ads and demand for IT specialists and AI/data-science competence expected to grow strongly between 2024 and 2028. But the same article also contains the crucial distinction: Techsverige’s Ana Andric says the point is not that everyone should build AI models, but that people need a basic understanding of what AI can and cannot do in their work (Svenska Dagbladet).
This is the point the capacity debate keeps losing.
Hiring one in-house model-training expert is a specialist search. It may be difficult, expensive, and internationally competitive. But that is not the same problem as hiring or sourcing fifty ordinary engineers who work on internal business systems, platforms, APIs, integrations, cloud operations, CI/CD, observability, frontend surfaces, data plumbing, and production maintenance.
The broad capacity market is affected by AI in a different way. It is not primarily that every company suddenly needs a small army of AI researchers. It is that ordinary engineering work is becoming AI-assisted. That changes the economics of stack acquisition, implementation, testing, refactoring, documentation, and local adaptation.
A controlled GitHub Copilot experiment found that developers completed a programming task 55.8 percent faster with the tool than without it (Peng et al.). A later open-source study found project-level and individual productivity gains from Copilot, but also a 41.6 percent increase in integration time; core developers benefited more than peripheral developers, plausibly because they understood the project context better (Song, Agarwal & Wen). Another real-world study reported large reductions in repetitive coding, documentation, test generation, debugging, and pair-programming effort, while also noting that Copilot struggled with complex tasks, large functions, multiple files, and proprietary context (Pandey et al.).
The evidence is not one-directional. METR’s 2025 study, reported by Reuters, found that AI tools slowed down some experienced developers when working on familiar codebases, because review and correction overhead outweighed the expected speedup (Reuters). That result does not refute AI-assisted engineering. It refines the argument. AI does not remove the need for context. It makes context more visible as the constraint.
The conclusion is not that AI replaces engineers. The conclusion is that the value boundary moves. Local stack familiarity becomes less defensible as a hard hiring filter. Context, verification, system ownership, and integration judgment become more important.
This is the argument developed in The Coordination Shift: when execution gets cheaper, the bottleneck moves to coordination, verification, architecture, ownership, and coherence over time.
Resource consulting misprices seniority
Resource consulting is the part of the market most exposed to this shift because it sells engineers through the wrong abstraction.
A client wants a person. The consultancy presents a CV. Procurement compares rates. The buyer searches for the closest match against the current stack. The consultant is not primarily bought as a compounding institutional asset. The consultant is bought as external capacity.
This can work when the assignment is narrow, temporary, and honestly scoped. It becomes toxic when it pretends to be capability building.
Resource consulting is not the problem by itself. The problem is that the resource interface is now being used to buy work whose real value is not resource-like. A senior consultant may be brought in through a stack-filtered request, but the actual assignment often becomes architecture, operational recovery, production hardening, delivery-flow repair, incident reduction, technical leadership, or organizational translation. The work is capability-oriented, but the purchasing mechanism treats it as capacity.
This is a structural claim about the interface between buying and work, not a measured statistic. The evidence above supports the premises: Sweden has broad software demand; job ads increasingly express capability as technologies; AI changes the cost of local implementation and stack acquisition; integration and context remain hard. The inference is that a purchasing model based on stack-matched capacity becomes less suitable as the value of senior work moves toward production judgment.
That mismatch becomes worse under AI. If the buyer believes the consultant is mainly a stack bundle, AI makes that bundle look cheaper. If the buyer believes the consultant is ordinary technical capacity, global labor markets can price that capacity. If the buyer understands the consultant as someone who can diagnose, stabilize, verify, and improve the production system, the comparison changes entirely.
That is why resource consulting is in a worse position than consulting in general.
A senior engineer should not be sold as an expensive checklist match. Seniority is not the accumulation of tool names. Seniority is the ability to reduce ambiguity, identify failure modes, design seams, verify systems, stabilize production, improve flow, make architecture legible, and make future work cheaper. Those capabilities are valuable precisely because they are not interchangeable.
Resource consulting makes them look interchangeable anyway.
For juniors, the damage is the missing ladder. For mid-level engineers, it is checklist inflation. For seniors, it is abstraction failure. The senior is no longer understood as someone who can improve the production system. The senior is packaged as a high-rate human adapter between too many technologies.
That is a terrible position to occupy when AI is making implementation surface cheaper and global labor markets are making stack-matched capacity easier to source.
The migration precedent is not abstract
The issue is not skilled migration itself. Skilled migration can be productive, complementary, and necessary. Broad reviews of the economic literature usually find that advanced economies can absorb migration better than popular debate assumes, with long-run average effects that are often neutral or positive, while also producing distributional effects among workers who compete most directly with new arrivals (Roodman).
The problem is when a state creates a lower-threshold channel at the same time as employers inflate roles, reject adjacent competence, and describe their own overconstrained hiring model as a shortage.
Sweden has seen the weakness of employer-declared shortage before. The 2008 reform made Sweden’s labor-migration system unusually employer-driven by OECD standards. Frödin and Kjellberg’s study of third-country labor migration into Swedish low-wage jobs found that the liberal employer-driven model brought migrants into sectors such as restaurants and cleaning, including workplaces without collective agreements and cases where recruitment appeared to follow ethnic or nationality-linked employer networks rather than a transparent shortage mechanism (Frödin & Kjellberg).
Software is not restaurant work, and engineers are not cleaners. The relevant similarity is institutional: once employers define shortage too loosely, the system starts measuring employer preference rather than social need.
The international precedents point in the same direction. The United Kingdom moved away from broad shortage-occupation salary discounts and toward higher salary thresholds tied more closely to occupation-specific earnings, with the government arguing that the system should not be used as a low-cost labor route (Financial Times). The United States has spent years debating the H-1B program because its most controversial use has not been rare expert hiring, but staffing and outsourcing channels. Vox summarized a Bloomberg investigation finding that IT staffing and outsourcing firms accounted for 40 percent of H-1B visas in 2023, and Reuters reported that the 2026 wage-weighted H-1B selection system specifically disadvantages staffing and IT consulting firms that had filed large volumes of lower-wage registrations (Vox, Reuters).
The lesson is not that Sweden will reproduce the American system. The institutions differ. The lesson is that technical migration channels can be used in two very different ways: to import rare capability, or to arbitrage capacity.
Resource consulting is where that distinction becomes most fragile.
The advisory gap in Swedish tech
The obvious escape route is explicit specialist advisory consulting. In many markets, this is where senior judgment belongs: diagnosis, operating-model design, architecture review, recovery programs, platform strategy, technical due diligence, engineering-management support, and delivery-system redesign.
Sweden has some of this, but not enough of it in software. Classical consultancy exists, but much of it sits in the management-consulting, audit, sourcing, and transformation world. Those firms can sell transformation, governance, risk, sourcing, and operating-model programs. That is not the same as a mature market for deep software-production advisory: work that understands code, architecture, infrastructure, delivery flow, verification, operations, and organizational design as one system.
This is not a market-size claim. It is a category claim. The visible categories are talent supply, managed workforce, systems integration, IT consulting, management consulting, and internal technology leadership. There is no equally visible category for software-production architecture as an advisory discipline. The absence of that category pushes serious seniors into awkward positions.
Sometimes the gap is filled by permanent technology leaders: CTOs, heads of engineering, principal engineers, staff engineers, engineering managers, platform leads, and architects who repair the production system from inside the company. That can work, but it is difficult. These roles are often trapped between executive expectations, delivery pressure, legacy architecture, underpowered governance, and teams that were never given the mandate to own outcomes properly.
Sometimes the gap is filled by a shadow form of consulting. The request for quotation looks like resource procurement. The CV must pass the stack filter. The assignment is formally a capacity assignment. But once the person starts, the real work is capability work: untangling architecture, repairing delivery flow, making operations credible, setting engineering standards, reducing incident load, improving deployment, and explaining to management why the system behaves the way it does.
That shadow model is unstable because it hides the actual value of the work behind the wrong purchasing mechanism. It forces seniors to smuggle advisory value through a resource-consulting contract. It also means the market cannot price the work correctly, because the buyer pretends to buy capacity while receiving judgment.
This is where software production architecture should exist as an explicit category. Not architecture as diagram ownership. Not enterprise architecture as governance theatre. Not resource consulting with a better title. Software production architecture is the architecture of the production system itself: how software is conceived, built, verified, deployed, operated, changed, governed, and made coherent over time.
That is the work serious seniors should move toward.
Permanent positions now have a stronger argument
Permanent employment has become more attractive not because employment is morally superior to consulting, but because context now compounds faster than stack familiarity.
A permanent role is not automatically better. Many permanent jobs are bureaucratic, politically constrained, or trapped in fake-agile matrix structures. But for a strong engineer, a real permanent position has one advantage that resource consulting cannot match: context compounds.
A permanent hire learns the domain, the failure history, the informal architecture, the customers, the operations, the political constraints, the previous bad decisions, the deployment scars, and the actual decision system. With AI, that person can absorb missing stack surface quickly. What cannot be downloaded in a week is the lived understanding of how the company really works.
That changes the hiring logic. If the company expects the person to stay, exact local stack match should matter less. The rational hiring question is not whether the candidate has already used the same frontend library, CI tool, or cloud wrapper. The rational question is whether the candidate can learn quickly, operate safely, verify output, communicate across boundaries, and reduce coordination cost.
That is capability hiring, not consultancy procurement.
Consultancy procurement asks what the person already knows. Capability hiring asks what the person will make possible.
The difference becomes larger under AI. When implementation surface becomes easier to traverse, the scarcer assets are judgment, context, ownership, and the ability to keep systems coherent over time. A senior person who joins a company permanently can turn those assets into institutional memory. A resource consultant often turns them into billable hours that disappear when the assignment ends.
This does not mean every senior should become an employee in the old sense. It means seniors should exit the commodity resource market. The destination can be a permanent role with real mandate, a managerial technology role, a staff-plus engineering role, a platform leadership role, a software-production architecture role, or a specialist advisory practice. What matters is that the work is sold and understood as capability, not capacity.
Consulting is not dead. Capacity consulting is the weak form.
The conclusion is not that senior engineers should never consult. The conclusion is that senior engineers should stop selling themselves as capacity.
There is still a future for specialist consultancy, classical advisory, and high-trust intervention work. That market is different. It does not sell a CV against a keyword list. It sells diagnosis, recovery, architecture, verification, operating-model design, platform strategy, workflow redesign, incident reduction, technical due diligence, engineering leadership support, or AI-assisted delivery-system design.
The consultant should leave behind a better production system, not merely consumed hours.
That is a different economic object. A resource consultant is compared against another resource consultant, an offshore engineer, an internal transfer, a visa-sponsored worker, or an AI-assisted mid-level developer. A specialist advisor is compared against the cost of continued confusion.
Senior engineers should be explicit about which market they intend to occupy.
The middle is becoming dangerous. It is the place where the person is broad enough to be useful everywhere, but still packaged narrowly enough to be compared by stack keywords and hourly rate. It is the place where clients want senior judgment but buy through junior procurement mechanisms. It is the place where AI compresses ordinary implementation, migration policy may widen labor arbitrage, and employers continue to demand total-stack profiles while avoiding the harder work of building technical capability.
That is not a stable middle. It is the layer that gets priced and squeezed first.
The line for senior engineers
The Swedish work-permit dispute is not only a migration story. It is a warning about the technical labor market.
If an engineer is genuinely rare, hire globally. If a society lacks a capability, recruit it. If a company needs specialist expertise, pay for it. There is no serious future in protecting mediocrity behind borders.
But there is also no serious future in letting employers inflate one job into four, refuse to train, reject adjacent competence, invoke shortage, and then use policy to bypass the wage and development signals that their own hiring model created.
For senior engineers, the implication is direct.
Do not let yourself be sold as a total-stack resource.
Go permanent where your context can compound. Or go specialist enough that the client buys judgment rather than capacity. Sell production capability, not stack familiarity.
For Sweden, this matters because many senior technical assignments are still entered through resource-oriented mechanisms: CV matching, framework agreements, hourly rates, stack filters, and start-date availability. That purchasing model can hide the real value of senior work once the assignment begins. Under AI-assisted engineering, global sourcing, and lower-threshold technical labor migration, the mismatch becomes harder to defend. Seniors who create production capability should avoid being positioned as stack-matched capacity.
If the competence is merely stack acquisition, AI is already eating it.
If the competence is ordinary capacity, global labor markets will price it.
If the competence is judgment under uncertainty, production ownership, verification, architecture, and operational coherence, it should not be sold as a body on a timesheet.