74% of companies listed in Europe use American email providers. 89% of German enterprises consider themselves technologically dependent on foreign providers. The AI Act exists in this context. Reading it only as a compliance problem means missing the picture.

TL;DR: The AI Act is industrial policy. Europe is in structural technological dependence and regulation is the only lever where it still has global weight. The “Brussels Effect” (ability to export standards) is contested but likely for high-risk AI systems. In November 2025 the Digital Omnibus delayed implementation by 16 months, but the direction remains the same. Those reading the AI Act only as a regulatory checklist are looking at the tree and missing the forest.

The numbers on Europe’s technological position are known to insiders. They rarely enter the AI Act debate.

A Proton report from October 2025 analyzed DNS records of European listed companies: 74% use American email providers. Not startups: companies listed on stock exchanges, with governance and security obligations. A Bitkom survey of German companies with over 20 employees reveals that 89% consider themselves technologically dependent on foreign providers.

The EPRS report from the European Parliament completes the picture. Of the 100 largest global digital platforms by market cap, only 2% of the combined value is European. In cloud computing, hyperscalers, foundation AI models, Europe is a net importer.

This context changes how you read the AI Act. It’s not just about protecting European citizens from algorithms. It’s about using the only lever Europe has left to negotiate its position in a market dominated by others.

The Mechanism

The term “Brussels Effect” was coined by Anu Bradford in 2012 and developed in her 2020 book. The thesis is direct: the EU, thanks to its market size and institutional quality, manages to export its standards globally.

The mechanism works two ways. The de facto effect: companies wanting access to the European market adopt EU standards elsewhere, because maintaining two versions costs more than one. The de jure effect: other governments copy European rules because they work and reduce the cost of designing regulation from scratch.

GDPR is the canonical example. Privacy laws inspired by European regulation have been adopted in Brazil, Japan, California. Tech companies extended many GDPR protections to non-European users to simplify operations. The form of European regulation spread beyond the Union’s borders.

On the AI Act, academic literature is more nuanced.

A 2022 GovAI paper analyzed the conditions for Brussels Effect applied to artificial intelligence. The conclusion: de facto and de jure effects are likely, especially for high-risk systems from large American tech companies. Microsoft, Google, Meta operate in Europe with recruiting, credit, and content moderation systems. They’ll need to comply. And for many of these companies, it’s more economical to apply one global standard than to segment products by market.

The paper also identifies limits. The Brussels Effect works best when the EU market is unavoidable (it is for big tech), when regulation is perceived as high-quality (contested), and when credible alternatives don’t exist (China offers a different model). For low-risk AI systems or companies not operating in Europe, the effect will be smaller or absent.

An article on Policy Review proposes a complementary frame: the AI Act as “experimentalist governance”. Not a model to export wholesale, but one approach among many in a context of technological uncertainty. Interaction with other regulatory models (United States, United Kingdom, China) will be more cooperative and less unidirectional than the Brussels Effect frame suggests.

The synthesis: the Brussels Effect on AI exists but is contested and uncertain. It’s not guaranteed that European rules become global standard. It’s not guaranteed they remain irrelevant. The game is open.

The Tactical Adjustment

In November 2025, the European Commission proposed the Digital Omnibus. The package includes AI Act modifications that generated headlines about “Europe backing down”.

The facts: requirements for high-risk AI systems now apply later, about 16 months later. The new deadline is December 2027 for Annex III systems (recruiting, credit, healthcare), August 2028 for those embedded in regulated products. It’s a significant delay.

But the AI Act’s structure remains intact. Risk categories remain the same. Obligations remain the same. What changes is the calendar, not the destination.

The Digital Omnibus is a tactical adjustment, not a strategic reversal. Europe is calibrating timing, not abandoning direction. Those reading the delay as “backing down” are confusing speed with trajectory.

The Missing Frame

Conversation on the AI Act in Italy revolves almost entirely around compliance. Which systems fall into high-risk categories. How much conformity costs. What sanctions you risk. These are legitimate questions, but incomplete.

The missing context is the numbers from the start. 74% dependence on email. 89% perception of technological dependence. 2% of value in European digital platforms. In this frame, the AI Act is not a regulatory conformity problem. It’s a tool in a larger game about Europe’s position in the global technology market.

Europe has few levers. It has no hyperscalers. It doesn’t have the dominant foundation models. It doesn’t have the venture capital base of the United States or the deployment scale of China. What it has is a 450-million-person market and institutional capacity to regulate that other blocs don’t.

Using this lever to influence global standards is industrial policy. Calling it just “consumer protection” is an incomplete description. Treating it only as “compliance” is missing the picture.

Microsoft has made alignment with European regulation an element of positioning. Meta chose the opposite path, delaying model releases in Europe and pressuring for weaker rules. They’re different strategies reflecting different readings of where the market is going. Neither treats the AI Act as a simple checklist.

Maybe we should ask why we do.

Sources

Bradford, A. (2020). The Brussels Effect: How the European Union Rules the World. Oxford University Press.

Siegmann, C. & Anderljung, M. (2022). The Brussels Effect and Artificial Intelligence: How EU regulation will impact the global AI market. GovAI, arXiv:2208.12645.

Policy Review. (2025). Brussels effect or experimentalism? The EU AI Act and global standard-setting.

European Commission. (2025). Digital Omnibus on AI Regulation Proposal.

European Parliamentary Research Service. (2025). European Software and Cyber Dependencies.

TechReport. (2025). Europe’s Digital Dependence: The Risks of the EU’s Reliance on US Tech.

42% of companies have already abandoned most of their AI projects. The data suggests the worst may not be over.

TL;DR: 42% of companies abandoned AI projects in 2025, double the previous year. Stanford HAI predicts 2026 will be the year of reckoning: less hype, more demand for concrete proof. Brynjolfsson’s employment data shows the impact already: -20% for junior developers, +8% for senior. For investors, the implications are clear: metrics defined before launch, not after; vendor solutions (67% success rate) vs internal development (33%); attention to go-live timelines, which kill projects more than technology.

In mid-December 2025, nine faculty members from Stanford Human-Centered Artificial Intelligence published their predictions for 2026. This is not the usual academic futurology exercise, but a collective statement with a clear message: the party is over.

James Landay, co-director of HAI, opens with a phrase that sounds almost provocative in an era of triumphalist announcements: “There will be no AGI this year.” The point, though, is what he adds immediately after: companies will begin publicly admitting that AI has not yet delivered the promised productivity increases, except in specific niches like programming and call centers. And we’ll finally hear about failed projects.

This is not a prediction about the future. It’s a snapshot of something already happening.

The Numbers No One Wants to Look At

In July 2025, the MIT Project NANDA published a report that generated considerable debate for a single statistic: 95% of enterprise AI projects generate no measurable return. The number has been contested, the methodology has its limitations, the definition of “success” is debatable. But it’s not an isolated data point.

During the same period, S&P Global found that 42% of companies abandoned most of their AI initiatives in 2025. In 2024, the percentage was 17%. The abandonment rate has more than doubled in a year. On average, the surveyed organizations threw out 46% of proof-of-concepts before they reached production.

According to the RAND Corporation, over 80% of AI projects fail, double the failure rate of traditional IT projects. Gartner reports that only 48% of AI projects reach production, and over 30% of GenAI projects will be abandoned after the proof of concept by end of 2025.

The causes are always the same: insufficient data quality (43% according to Informatica), lack of technical maturity (43%), skills shortage (35%). But beneath these numbers lies a deeper pattern. Companies are discovering that AI works in demos but not in production, generates enthusiasm in pilots but not ROI in balance sheets.

It’s these numbers that explain why Stanford HAI, an institution hardly known for technological pessimism, is shifting the conversation. No longer “can AI do this?” but “how well, at what cost, for whom?”.

Canaries in the Coal Mine

If failure rates are the symptom, Erik Brynjolfsson’s work offers a more precise diagnosis. “Canaries in the Coal Mine”, published in August 2025 by Stanford’s Digital Economy Lab, is among the most rigorous studies currently available on AI’s impact on the job market.

The paper uses ADP payroll data, the largest payroll service provider in the United States, covering over 25 million workers. The goal is to track employment changes in AI-exposed professions.

What emerges is clear. Employment for software developers ages 22-25 has declined 20% from the peak of late 2022, roughly since the launch of ChatGPT, through July 2025. This is not an isolated data point: early-career workers in the most AI-exposed occupations show a relative decline of 13% compared to colleagues in less exposed roles.

The most interesting finding, though, is the age divergence. While young workers lose ground, workers over 30 in the same high-exposure categories have seen employment growth between 6% and 12%. Brynjolfsson puts it this way: “It appears that what young workers know overlaps with what LLMs can replace.”

It’s not a uniform effect, but a realignment: AI is eroding entry-level positions faster than it creates new roles. The “canaries in the coal mine”—young developers and customer support staff—are already showing symptoms of a larger change.

When Brynjolfsson predicts the emergence of “AI economic dashboards” that track these shifts in near-real-time, he’s not speculating. He’s describing the infrastructure needed to understand what’s happening, infrastructure that doesn’t exist today but could become urgent in 2026.

The Divergence Between Adoption and Results

There’s a paradox in 2025 data that deserves attention. AI adoption is accelerating: according to McKinsey, the percentage of companies claiming to use AI rose from 55% in 2023 to 78% in 2024. Use of GenAI in at least one business function more than doubled, from 33% to 71%.

Yet, in parallel, project abandonment rates are growing instead of declining. S&P Global shows a jump from 17% to 42% in a single year. The MIT NANDA report speaks of a “GenAI Divide”, a clear division between the 5% extracting real value and the 95% that remain stalled.

Many companies have gone through the phases of enthusiasm, pilots, impressive demos, and then crashed against the wall of real production. They discovered that the model works in a sandbox but not with their data; that integration into existing workflows is more complex than expected; that the ROI promised by vendors doesn’t materialize.

Angèle Christin, a communication sociologist and HAI senior fellow, puts it plainly: “San Francisco billboards saying ‘AI everywhere!!! For everything!!! All the time!!!’ betray a slightly manic tone.” Her prediction: we’ll see more realism about what we can expect from AI. Not necessarily the bubble bursting, but the bubble might stop inflating.

The Measurement Problem

One of the most concrete, and potentially most significant, predictions comes again from Brynjolfsson. He proposes the emergence of high-frequency “AI economic dashboards”: tools that track, at the task and employment level, where AI is increasing productivity, where it’s displacing workers, where it’s creating new roles.

Today we have nothing like that. Labor market data arrives months late. Companies measure AI adoption but rarely its impact. Industry reports capture hype but not results.

If these dashboards do emerge in 2026, they’ll change how we talk about AI. The debate will shift from the generic “does AI have an impact?” to more precise questions: how fast is this impact spreading, who’s being left behind, which complementary investments work.

It’s an optimistic vision: better data leads to better decisions. But it’s also an implicit admission: today we’re navigating blind.

Healthcare and Legal: The Test Sectors

Two sectors emerge from Stanford predictions as particularly relevant testbeds.

Nigam Shah, Chief Data Scientist at Stanford Health Care, describes a problem that anyone in the sector will recognize. Hospitals are flooded with startups wanting to sell AI solutions. “Every single proposal can be reasonable, but in aggregate they’re a tsunami of noise.”

According to Shah, 2026 will see systematic frameworks emerge for evaluating these solutions: technical impact, the population the model was trained on, ROI on hospital workflow, patient satisfaction, quality of clinical decisions. This is work Stanford is already doing internally, but it will need to extend to institutions with fewer technical resources.

Shah also signals a risk. Vendors, frustrated by hospitals’ long decision cycles, might start going directly to end users. “Free” applications for doctors and patients that bypass institutional controls. This is already happening: OpenEvidence for literature summaries, AtroposHealth for on-demand answers to clinical questions.

In the legal sector, Julian Nyarko predicts a similar shift. The focus will move from “does this model know how to write?” to more operational questions: accuracy, citation integrity, exposure to privilege violations. The sector is already working on specific benchmarks, like those based on “LLM-as-judge”, frameworks where one model evaluates another model’s output for complex tasks like multi-document summarization.

Healthcare and legal share a characteristic: they’re highly regulated, with severe consequences for error. If AI must prove its value anywhere, it’s where the test will be hardest. And most significant.

Track Record: How Reliable Are These Predictions?

Stanford HAI publishes annual predictions going back several years. It’s worth asking how accurate they’ve been.

At the end of 2022, Russ Altman predicted for 2023 a “shocking rollout of AI way before it’s mature or ready to go”. It’s hard to find a more accurate description of what happened: ChatGPT, Bing Chat, Bard launched in rapid succession, with accuracy problems, hallucinations, embarrassing incidents. Altman had also predicted a “hit parade of AI that’s not ready for prime time but launches because driven by an industry too zealous.” Exactly right.

Percy Liang, also at the end of 2022, predicted that video would be a focus of 2023 and that “we might reach the point where we can’t tell if a human or computer generated a video”. He was a year early (Sora arrived in February 2024) but the direction was correct.

For 2024, Altman predicted a “rise of agents” and steps toward multimedia systems. Both came true, though agents are still more promise than production reality.

Not all predictions came true. Expectations of U.S. Congressional action were disappointed: Biden’s Executive Order happened, but the new administration changed direction. Overall, though, Stanford HAI’s track record is reasonable: they tend to be cautious rather than enthusiastic, and technical predictions are generally well-founded.

This doesn’t guarantee that 2026 predictions will come true. But it means they’re worth taking seriously.

What It Means for Decision-Makers

If Stanford predictions and failure rate data converge on anything, it’s this: 2026 will be the year when enterprise AI must show results, not demos.

For those managing tech budgets, the implications are concrete.

On the metrics front, AI projects must have success criteria defined before launch, not after. Not “let’s explore AI for customer service” but “reduce average ticket resolution time by 15% within 6 months, with cost-per-interaction below X”. Projects without clear metrics have a disproportionate likelihood of ending up in the 42% of abandonments.

On the make-or-buy front, the MIT NANDA report indicates that solutions bought from specialized vendors have a 67% success rate, against 33% for internal development. This doesn’t mean internal development is always wrong, but it requires skills, data, and infrastructure that many organizations overestimate having.

On timing, mid-market enterprises move from pilot to production in about 90 days, according to the same report. Large enterprises take nine months or more. Bureaucracy kills AI projects more than technology does.

Finally, a matter of honesty. The shadow economy of AI (90% of employees use personal tools like ChatGPT for work, according to MIT NANDA) indicates that individuals already know where AI works better than official enterprise initiatives. Instead of fighting it, organizations could learn from this spontaneous adoption.

What’s Missing

Stanford predictions have clear blind spots.

None of the experts mention energy consumption and AI’s environmental impact. Christin hints at it (“tremendous environmental costs of the current build-out”) but the topic isn’t developed. Yet AI data centers are becoming one of the world’s biggest energy consumers, and this will eventually factor into ROI calculations.

There’s also a lack of serious discussion about market concentration. Frontier models are developed by a handful of companies. This creates dependencies, influences pricing, determines who can compete. It’s a strategic factor that anyone planning AI investments should consider.

Landay alludes to “AI sovereignty”, countries wanting independence from American providers, but the topic remains superficial. This is rapidly evolving, with significant geopolitical implications, that deserves deeper analysis.

A Shift in Tone

More than individual predictions, what strikes you about the Stanford article is the tone. There’s no industry-typical enthusiasm. No promises of imminent transformation. There’s caution, demand for proof, emphasis on measurement.

When the co-director of a Stanford AI institute opens by saying “there will be no AGI this year,” he’s taking a stand against a dominant narrative. When economists like Brynjolfsson publish data on young workers losing employment, they’re documenting costs, not just benefits.

This doesn’t mean AI is overvalued or that projects should stop. It means the phase of uncritical adoption is ending. Whoever continues to invest will need to do so with calibrated expectations, defined metrics, ability to admit failure when it occurs.

2026, if these predictions are correct, will be the year when we discover which AI projects were sound and which were built on hype. For many organizations it will be a painful discovery. For others, an opportunity: whoever has already learned to measure, iterate, and distinguish value from promise will have a competitive advantage that generic enthusiasm cannot buy.

Sources

Brynjolfsson, E., Chandar, B., & Chen, R. (2025). Canaries in the Coal Mine: Six Facts about the Recent Employment Effects of AI. Stanford Digital Economy Lab.

McKinsey & Company. (2024). The State of AI in 2024: Gen AI adoption spikes and starts to generate value. McKinsey Global Institute.

MIT Project NANDA. (2025). The GenAI Divide 2025. Massachusetts Institute of Technology.

RAND Corporation. (2024). The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed. RAND Research Reports.

S&P Global Market Intelligence. (2025, October). Generative AI Shows Rapid Growth but Yields Mixed Results. S&P Global.

Stanford HAI. (2025, December). Stanford AI Experts Predict What Will Happen in 2026. Stanford Human-Centered Artificial Intelligence.

60% of managers admit they need better KPIs for AI. Only 34% are doing anything about it. Meanwhile, the data that actually matters already exists, but nobody’s looking at it.

TL;DR: Companies measure activity (hours saved, tasks automated) instead of impact. A Stanford paper analyzing 25 million workers shows what to do instead: segment by role and seniority, distinguish substitutive from augmentative use, use control groups, monitor in real time. Those who adopt these principles will have an information advantage over those still tracking vanity metrics.

The 2025 AI adoption reports tell a strange story. On one hand, companies claim to measure everything: completed deployments, hours saved, tickets handled, costs reduced. On the other, 42% are abandoning most of their AI projects, more than double the previous year. According to MIT NANDA, 95% of pilot projects generate no measurable impact on the bottom line.

If we measure so much, why do we fail so often?

The problem is we’re measuring the wrong things. Typical enterprise AI metrics (time saved per task, volume of automated interactions, cost per query) capture activity, not impact. They tell you whether the system works technically, not whether it’s creating or destroying value.

A paper published in August 2025 by Stanford’s Digital Economy Lab offers a different approach to what it means to truly measure AI. And the implications for those managing technology investments are concrete.

The vanity metrics problem

Most corporate AI dashboards track variants of the same metrics: how many requests processed, how much time saved per interaction, what percentage of tasks automated. These are numbers that grow easily and look good in slides. Their flaw is fundamental: they say nothing about real business impact.

A chatbot handling 10,000 tickets per month looks like a success. But if those tickets still require human escalation 40% of the time, if customer satisfaction has dropped, if your most profitable customers are migrating to competitors, the number of tickets handled captures none of this.

The S&P Global 2025 report documents exactly this pattern: companies that accumulated “deployments” and “completed experiments” only to discover, months later, that ROI wasn’t materializing. Costs were real and immediate; benefits were vague and perpetually deferred to next quarter.

According to an MIT Sloan analysis, 60% of managers recognize they need better KPIs for AI. But only 34% are actually using AI to create new performance indicators. The majority continues using the same metrics they used for traditional IT projects, metrics designed for deterministic software, not for probabilistic systems interacting with complex human processes.

What serious measurement looks like

“Canaries in the Coal Mine”, the paper by Erik Brynjolfsson, Bharat Chandar, and Ruyu Chen published by Stanford’s Digital Economy Lab, isn’t about how companies should measure AI. It’s about how AI is changing the labor market. But the method it uses is exactly what’s missing from most enterprise evaluations.

The authors obtained access to ADP payroll data, the largest payroll processor in the United States, with monthly records of over 25 million workers. Not surveys, not self-reports, not estimates: granular administrative data on who gets hired, who leaves, how much they earn, in which role, at which company.

They then cross-referenced this data with two AI exposure metrics: one based on theoretical task analysis (which jobs are technically automatable) and one based on actual usage data (how people actually use Claude, Anthropic’s model, in daily work).

The result is an X-ray of AI’s impact with unprecedented granularity. Not the generic “AI is changing work” but precise numbers: employment for software developers aged 22-25 dropped 20% from the late 2022 peak, while for those over 35 in the same roles it grew 8%. In professions where AI use is predominantly substitutive, young workers lose employment; where it’s predominantly augmentative, there’s no decline.

This type of measurement should inform corporate AI decisions. Not because companies need to replicate this exact study, but because it illustrates three principles that most enterprise metrics ignore entirely.

Measure differential effects, not averages

Aggregate data hides more than it reveals. If you only measure “hours saved by AI,” you don’t see who’s saving those hours and who’s losing their job. If you only measure “tickets automated,” you don’t see which customers are receiving worse service.

The Stanford paper shows that AI’s impact differs radically by age group. Workers aged 22-25 in exposed professions saw a 13% employment decline relative to colleagues in less exposed roles. Workers over 30 in the same professions saw growth. The average effect is nearly zero, but the real effect is massive redistribution.

For a CFO, aggregate productivity metrics can mask hidden costs. If AI is increasing output from the senior team while making it impossible to hire and train juniors, the short-term gain could transform into a talent pipeline problem in the medium term. The paper calls it the “apprenticeship paradox”: companies stop hiring entry-level workers because AI handles those tasks better, but without entry-level today there won’t be seniors tomorrow.

The operational consequence is that every AI dashboard should segment impact by role, seniority, team, and customer type. A single “productivity” number is almost always misleading.

Distinguish substitutive from augmentative use

One of the paper’s most relevant findings concerns the difference between substitutive and augmentative AI use. The authors used Anthropic’s data to classify how people actually use language models: to generate final outputs (substitution) or to iterate, learn, and validate (augmentation).

In professions where use is predominantly substitutive, youth employment has collapsed. Where use is predominantly augmentative, there’s no decline; in fact, some of these categories show above-average growth.

Not all “deployments” are equal. A system that automatically generates financial reports substitutes human labor differently from one that helps analysts explore scenarios. Metrics should capture this distinction: classify each AI application as predominantly substitutive or augmentative, separately track impact on headcount, skill mix, and internal training capacity. Augmentative systems might have less immediate ROI but more sustainable effects.

Control for external shocks

One of the Stanford paper’s most sophisticated methodological aspects is its use of firm-time fixed effects. In practice, the authors compare workers within the same company in the same month, thus isolating the AI exposure effect from any other factor affecting the company: budget cuts, sector slowdown, strategy changes.

The result: even controlling for all these factors, young workers in AI-exposed roles show a relative decline of 16% compared to colleagues in non-exposed roles at the same company.

This kind of rigor is rare in corporate evaluations. When an AI project launches and costs drop, it’s easy to credit the AI. But maybe costs would have dropped anyway due to seasonal factors. Maybe the team was already optimizing before the launch. Maybe the comparison is with an anomalous period.

The solution is to define baselines and control groups before launch. Don’t compare “before vs after” but “treated vs untreated” in the same period. Use A/B tests where possible, or at least comparisons with teams, regions, or segments that haven’t adopted AI.

Toward high-frequency economic dashboards

In his predictions for 2026, Brynjolfsson proposed the idea of “AI economic dashboards”, tools that track AI’s economic impact in near real-time, updated monthly instead of with the typical delays of official statistics.

It’s an ambitious proposal at the macro level. But the underlying logic is applicable at the company level: stop waiting for quarterly reports to understand if AI is working and instead build continuous monitoring systems that capture effects as they emerge.

Most AI projects are evaluated like traditional investments: ex-ante business case, periodic reviews, final post-mortem. But AI doesn’t behave like a traditional asset. Its effects are distributed, emergent, often unexpected. A continuous monitoring system can catch drift before it becomes a problem.

In practice, this means working with real-time data instead of retrospective data. If the payroll system can tell you today how many people were hired yesterday in each role, you can track AI’s effect on headcount with a lag of days, not months. The same applies to tickets handled, sales closed, errors detected.

Another key principle: favor leading metrics over lagging ones. The actual utilization rate (how many employees actually use the AI tool every day) is a leading indicator. If it drops, there are problems before they show up in productivity numbers.

As the Stanford paper segments by age, corporate dashboards should segment by role, tenure, and prior performance. AI might help top performers while harming others, or vice versa.

Internal comparisons are also essential: teams that adopted AI vs teams that didn’t, periods with the feature active vs periods with it deactivated. These comparisons are more informative than pure time trends.

The cost of not measuring

There’s a direct economic argument for investing in better measurement. The 42% of companies that abandoned AI projects in 2025 spent budget, time, and management attention only to get nothing. With better metrics, some of those projects would have been stopped earlier. Others would have been corrected mid-course. Others still would never have started.

The MIT NANDA report estimates that companies are spending $30-40 billion per year on generative AI. If 95% generates no measurable ROI, we’re talking about tens of billions burned. Not because the technology doesn’t work, but because it’s applied poorly, measured worse, and therefore never corrected.

The Brynjolfsson paper offers a model of what AI measurement could be. Administrative data instead of surveys. Demographic granularity instead of aggregate averages. Rigorous controls instead of naive comparisons. Continuous monitoring instead of point-in-time evaluations.

No company has Stanford’s resources or access to ADP’s data. But the principles are transferable: segment, distinguish substitutive from augmentative use, control for confounding factors, monitor in real time. Those who adopt these principles will have an information advantage over those who continue tracking deployments and hours saved.

Sources

Brynjolfsson, E., Chandar, B., & Chen, R. (2025). Canaries in the Coal Mine: Six Facts about the Recent Employment Effects of AI. Stanford Digital Economy Lab.

Deloitte AI Institute. (2025). State of Generative AI in the Enterprise. Deloitte.

MIT Project NANDA. (2025). The GenAI Divide 2025. Massachusetts Institute of Technology.

MIT Sloan Management Review. (2024). The Future of Strategic Measurement: Enhancing KPIs With AI. MIT Sloan.

S&P Global Market Intelligence. (2025, October). Generative AI Shows Rapid Growth but Yields Mixed Results. S&P Global.

This comprehensive analysis of AI sovereignty, European choices, and geopolitical implications will be fully translated soon.

The article covers:

• Four definitions of AI sovereignty (legality, economic competitiveness, national security, value alignment)
• Two operational models for achieving sovereignty
• Gulf states’ AI infrastructure investments
• Europe’s position between American providers and sovereign models
• GAIA-X and EU cloud sovereignty initiatives

For now, please refer to the Italian version for the complete content.

Three months later, Marco is gone. Luca replaced him. The team still isn’t working.

The scene keeps repeating because the diagnosis is wrong. Not wrong in an obvious way — wrong in a plausible way, which is worse. “Marco isn’t motivated” sounds reasonable. Everyone nods. Too bad the problem isn’t Marco.

Social psychology has a name for this: fundamental attribution error. Ross described it in 1977: when we observe behavior, we tend to attribute it to personal traits (laziness, poor collaboration) while underestimating the weight of the situation the person is in.

J. Richard Hackman spent forty years studying teams: flight crews, orchestras, intelligence squads. The bottom line of his research: structural conditions explain up to 80% of variance in team effectiveness (Wageman, Hackman & Lehman, 2005). When a team isn’t working, the most likely problem isn’t who’s in it. It’s how it was designed.

Before replacing people, check the conditions.

The five conditions: a checklist, not a theory

Hackman didn’t produce an abstract model. He produced a checklist. Five conditions that, when present, make it likely a team will work. When absent, make it likely it won’t. He validated them empirically across hundreds of teams in different contexts. They work as a diagnostic tool long before they work as theory.

Here’s a quick translation into software context. For the full picture, start with the previous piece on Hackman’s team vs. working group distinction.

1. Being a real team. Clear boundaries, stable composition, real interdependence. If even one of these three is missing, you don’t have a team. You have a group of people with a shared manager.

2. A compelling direction. A clear, challenging, meaningful objective. Not “close the sprint stories” — that’s a unit of measurement, not a direction. A compelling direction answers the question: why does this work matter?

3. An enabling structure. Roles, norms, skills. The minimum infrastructure so people don’t have to renegotiate everything from scratch every week.

4. A supportive organizational context. Does the team have the information it needs? The resources? Does the reward system incentivize group outcomes or individual performance? This is the condition the team can’t give itself. It depends on the organization around it.

5. Competent process coaching. Not technical mentoring: someone who helps the team work better together. How they make decisions, handle disagreements, distribute work. It’s the condition that matters least of the five (the 10% in Hackman’s 60/30/10), but it’s the one everyone focuses on.

The instinct when managing teams is to start at the bottom: coaching, facilitation, interpersonal dynamics. Hackman says: start at the top.

The table that flips the diagnosis

This is the core of the argument. Six phrases I hear repeated constantly. For each one: the usual diagnosis, the most likely structural cause, and where to look instead.

Some of these mappings are directly anchored to Hackman’s research. Others are my translation into the software context, and I flag them as such.

“Marco isn’t motivated”

It’s Marco’s problem, people say. He lacks drive, ownership. Maybe he’s not right for the role.

More likely, the team lacks a compelling direction (condition 2). If the team’s objective is vague, purely administrative, or changes every two weeks, motivation isn’t a trait of Marco’s. It’s a rational response to a context that gives no reason to invest energy. I’ve seen brilliant developers seem disengaged because their team’s mandate was “support the product” — which in practice meant answering tickets endlessly with no vision of where things were heading.

Don’t look at Marco. Look at the team’s mandate. If you can’t explain in one sentence why the work matters, that’s your problem.

“Sara doesn’t communicate”

Where to look here is at work design. If everyone works on a separate feature and interactions are limited to the occasional comment on a pull request, there’s no structural reason to communicate more. Sara isn’t uncollaborative. She’s rational: why would she update others on work that doesn’t affect them?

The cause is a lack of real interdependence (condition 1). You can run all the communication workshops you want: if the work structure doesn’t create mutual dependencies, communication will remain an empty ritual.

“The team doesn’t trust each other”

The classic response: team building activities, vulnerability exercises, an offsite to get to know each other better.

Trust in a team doesn’t come from an afternoon workshop. It comes from working together long enough to predict how the other person will behave. Hackman saw this with flight crews: crews that had flown together for a while made fewer errors than newly formed ones, even with less experienced pilots. The most likely problem is unstable composition (condition 1). If you rotate people between teams every quarter, you restart from zero each time.

How many times has the team’s composition changed in the past year? If the answer is “often,” the trust deficit isn’t a relationship problem. It’s structural turnover.

“Retros don’t produce anything”

Here the question comes before the answer: is there a shared process to improve? Retrospectives assume a team that collaborates on a common outcome and wants to improve how they do it. If everyone has their own workflow, priorities, and blockers, the retro has no object. The format is irrelevant. The cause is that the group isn’t a real team (condition 1).

“The lead can’t guide the team”

The usual diagnosis: they lack soft skills. Send them to a leadership course.

The lead might be excellent. But if the team doesn’t have access to the information it needs, if resources get cut without notice, if the evaluation system rewards individual performance and ignores group outcomes, the lead is in an impossible position. It’s like asking a pilot to land well with a poorly designed airplane — you can send them to every flight course there is, but if the flaps don’t work, the problem isn’t their technique.

The cause is the organizational context (condition 4). Does the lead have the authority to make decisions? Are priorities stable enough to allow a plan? If not, the leverage is in the organization, not the person.

“Too much conflict”

Here the answer is less straightforward. Conflict in a team can be a good sign: if the team is real and negotiating norms for working together (condition 3), some friction is physiological. Hackman says it clearly: the best teams aren’t conflict-free. They’re teams that have learned to manage conflict.

But conflict can also signal unclear boundaries (condition 1): who decides what? Who has authority over which part of the system? If two people both think they’re responsible for the same area, the conflict isn’t relational. It’s structural.

The useful distinction: if the conflict is about how to do things, it’s probably healthy. If it’s about who should do what, it’s a boundary problem. And if it’s chronic despite everyone’s best intentions, it’s almost certainly not a people problem.

Why we keep getting the diagnosis wrong

If structural conditions matter this much, why does the default remain “someone’s fault”?

The first reason is that structure is invisible. You see people. You see behaviors. You don’t see the conditions in which those behaviors emerge. Hackman pressed this point in the last paper of his career, “From causes to conditions” (Hackman, 2012): research on teams has focused too much on internal causes (who does what, how they behave) and too little on external conditions (how the team is designed, what context it operates in). The same applies to people managing teams in practice.

The second is that replacing people feels easier. Giving Marco feedback, sending Sara to a workshop, swapping the lead: these are all actions a manager can take tomorrow morning. Redesigning the team’s mandate, stabilizing composition, changing the incentive system — those require time, authority, and often negotiation with someone above. The interpersonal diagnosis is attractive because it has solutions at hand. Too bad they’re the wrong solutions.

The third is more insidious, and I’ve seen it up close: the organization incentivizes individual diagnosis. Performance reviews evaluate people, not conditions. PIPs apply to people. “Cultural fit” is an attribute of people. The entire management apparatus is built around the idea that performance is an individual trait. Admitting the problem is structural means admitting the system is poorly designed — and the person who designed the system is often the one making the diagnosis.

Next time someone says “the problem is Marco,” pause for a moment. Not because Marco is necessarily innocent: sometimes the problem really is the person. But it’s less common than we think, and the interpersonal diagnosis is so intuitive we always get there first.

Try reframing. Not “who isn’t working?” but “what in the structure isn’t working?” Move from person to condition. Then ask yourself: is this condition under my control? If yes, that’s where the energy goes. If not, at least you know that no team building workshop will fix it.

It’s not a small difference. It’s the difference between debugging the code and debugging the compiler.

Sources

• Hackman, J.R. (2002). Leading Teams: Setting the Stage for Great Performances. Harvard Business School Press.
• Hackman, J.R. (2011). Collaborative Intelligence: Using Teams to Solve Hard Problems. Berrett-Koehler.
• Hackman, J.R. (2012). From causes to conditions in group research. Journal of Organizational Behavior, 33, 428-444.
• Wageman, R., Hackman, J.R. & Lehman, E.V. (2005). Team Diagnostic Survey: Development of an Instrument. Journal of Applied Behavioral Science, 41(4), 373-398.
• Ross, L. (1977). The intuitive psychologist and his shortcomings: Distortions in the attribution process. In L. Berkowitz (Ed.), Advances in Experimental Social Psychology (Vol. 10, pp. 173-220). Academic Press.

If this sounds familiar, you’re not alone. The 17th State of Agile Report by Digital.ai (2024) found that only 11% of practitioners report being “very satisfied” with Agile practices in their organization. The frustration runs deep enough that two original signatories of the Agile Manifesto have publicly turned against what Agile has become: Ron Jeffries, co-creator of Extreme Programming, wrote that developers should abandon Agile, or at least the version organizations have made of it. Dave Thomas, another signatory, declared that Agile is dead, hollowed out by marketing and mass certification.

The most common diagnosis is that Agile has become bureaucracy: too many rituals, too much process, not enough code. It makes sense. Who hasn’t thought that at least once, walking out of yet another endless planning session?

But there’s another possibility. One that has nothing to do with Agile itself, but with something more fundamental: the structure you’re applying it to.

J. Richard Hackman spent 40 years studying real teams: flight crews, orchestras, intelligence teams, surgical teams. His research, condensed in Leading Teams (2002) and Collaborative Intelligence (2011), arrives at a distinction that almost nobody in software makes: the distinction between a team and a working group. They are different things. They work differently. And they require different tools.

Agile practices are designed for teams. Apply them to a working group and you get exactly the frustration you’re feeling. The problem isn’t the method. It’s a structural mismatch.

The most overused word in software

In software, “team” is the default word for any group of people working on the same project. Five developers sharing a Jira board? Team. Two backend engineers, a frontend dev, and a designer reporting to the same manager? Team. Eight people across three time zones who meet at the 9 AM standup? Team.

Hackman would disagree. In Leading Teams he defines a “real team” through three minimum properties, all required.

The first is clear boundaries: everyone knows who is on the team and who is not. Sounds obvious, but in software practice it isn’t. The designer “shared” across three teams — in or out? The developer “on loan” for two sprints — a member? If you can’t make the list without hesitating, the boundaries aren’t clear.

The second is stable composition. People stay the same long enough to develop shared ways of working. Hackman studied flight crews: NASA data, which he reports in Leading Teams, showed that newly formed crews made more errors than those who had been flying together for a while, even when the newer crews had more experienced pilots. In software, quarterly rotation of people between teams destroys this effect. Every time, you start from zero.

The third, and most underrated, is real interdependence. The team’s output depends on collaboration between members — it’s not the sum of individual contributions. This is where most software “teams” fall apart. Five developers working on five independent features, with five cross-reviews done as a formality, are not interdependent. One person’s work doesn’t change another’s. If you removed all the meetings and put them in separate rooms, the result would be the same.

The test is brutal in its simplicity: if you eliminated standups, retros, and planning tomorrow, and everyone worked on their own, would the final product suffer? If the answer is no — if the result would be identical, maybe even faster without the interruptions — then what you have is not a team. It’s a group of individuals with a shared manager.

That’s not an insult. It’s a diagnosis. And the diagnosis is the first step toward stopping the use of the wrong tools.

Structural conditions: the 60/30/10

Hackman didn’t stop at the definition. He studied what makes a team effective, and the answer is less intuitive than you’d think.

Research by Hackman and his collaborator Ruth Wageman identifies five conditions that enable team performance: being a real team, having a compelling direction, an enabling structure, a supportive organizational context, and competent coaching. I won’t go deep on all of them here — each deserves its own article. The relevant point is different: how much do these conditions matter compared to what a leader does day to day?

Hackman’s answer, laid out in Collaborative Intelligence (2011), is the 60/30/10: 60% of a team’s effectiveness depends on design — the structural conditions put in place before the team starts working. 30% depends on launch — how the team is kicked off, the first days, the initial norms. The remaining 10% on ongoing coaching.

A clarification: Hackman presents this split as a “best estimate,” not as the result of a single study yielding those exact percentages. It’s a heuristic that synthesizes decades of research. Not a precise data point.

But the order of magnitude has solid empirical grounding. The Team Diagnostic Survey (TDS), developed by Wageman, Hackman, and Lehman and published in 2005, was administered to 2,474 people across 321 teams. The finding: structural conditions explain up to 80% of the variance in team effectiveness (Wageman, Hackman & Lehman, 2005). Not 20%. Not 50%. Eighty percent.

An earlier study by Wageman (2001) on 43 self-managing teams at Xerox had already shown the same pattern: a leader’s design activities influenced team performance. Day-to-day coaching activities did not.

The implication for software is direct. When a team isn’t working, the instinctive reaction is to work on dynamics: facilitate retros better, improve communication, do team building. Hackman’s framework suggests the most powerful lever is upstream. Who is on the team? What is the mandate? How is the work designed? Does the organizational context support it? If these conditions aren’t there, no amount of facilitation will compensate.

But the first of those five conditions — “being a real team” — opens a question that almost nobody in software asks.

Team or working group: the distinction that changes everything

A point Hackman makes often, and that gets misunderstood just as often: the distinction between team and working group is not a value judgment. It’s not “team = good, working group = bad.” They are two different organizational modes, each with its own strengths.

A working group is a set of people reporting to the same manager who may coordinate, but whose output is primarily individual. Everyone has their own goals, responsibilities, deliverables. The manager coordinates, assigns, removes obstacles. Deep interdependence is not required.

A team produces collective output. The result cannot be decomposed into the sum of individual contributions: it requires continuous collaboration, shared decisions, mutual adjustment. The cost is higher — you need stable boundaries, shared norms, time to develop ways of working together. But for certain kinds of problems, it’s the only configuration that works.

The damage comes from confusing the two.

A working group managed as a team generates overhead without benefit. Coordination meetings exist, but there’s nothing substantial to coordinate. Retrospectives don’t produce actions because there’s no shared process to improve: everyone has their own workflow, priorities, blockers. The Agile ceremony becomes a fixed cost on work that doesn’t require it.

The damage goes both ways, though. A real team managed as a working group is equally dysfunctional. If you have people who need to collaborate on a complex problem and treat them as individual contributors — assigning separate tasks, evaluating them individually, without protecting time for joint work — you’re undermining the one thing that makes that team effective: interdependence.

I’ve seen both scenarios. The first is more common in software, because the default organization tends to be the working group (developers assigned to individual features), while the process infrastructure is almost always that of a team (Scrum, Kanban with standups, retros, planning).

The operational question isn’t “how do I improve my team?” It’s more fundamental: is what I’m leading a team or a working group? The answer changes everything that follows.

The Agile mismatch: right tools, wrong structure

Back to the frustration we started with. Agile practices — Scrum in particular — didn’t emerge in a vacuum. They’re designed around a specific assumption: that a small group of people works interdependently toward a shared goal, iterating together. The sprint assumes a common goal. The standup assumes that knowing what others are doing changes your work. The retro assumes a shared process to inspect. Planning assumes collective prioritization decisions.

These are all tools that assume interdependence. Without it, they lose their point.

Now look at the typical “team” setup in many software organizations. People are assigned — often rotated — to a “team” that is really an organizational container. Everyone works on their own user story, with interactions limited to code review and the occasional Slack question. The “sprint goal” is the sum of individual stories. Interdependence is minimal or absent.

Apply team tools to this structure and the result is predictable. The standup becomes a round of updates nobody listens to. The retro produces generic complaints. Planning becomes bureaucracy. Not because Scrum is bureaucracy — but because you’re using it on a structure it wasn’t designed for.

The Manifesto signatories say as much, in different words. Jeffries talks about “Dark Scrum” — organizations using Agile rituals as control mechanisms, draining them of collaboration. Thomas says “Agile” was turned into a commercial noun when it was meant to be an adjective describing a way of working. Their critique is legitimate. But the diagnosis they offer — “organizations have corrupted Agile” — is incomplete. Hackman’s framework provides a more structural one: many organizations haven’t corrupted Agile. They’ve applied it to structures that aren’t teams.

I bring this up because I’ve seen it happen more times than I’d like to admit, including in contexts with competent people and good intentions. The standard response to the malaise was always the same: change the facilitator, try a different retro format, add a ceremony. Hackman’s framework gave me the vocabulary for what I felt but couldn’t articulate: the problem wasn’t the execution. It was the premise.

This changes the diagnosis and the solutions. If the problem is “Agile has become bureaucracy,” the answer is less process, fewer rituals, more autonomy. Sometimes that’s right. But if the problem is a structural mismatch, the answer is different: either transform the structure into a real team — with the costs that entails — or accept that you have a working group and adopt tools consistent with that reality. Both options are legitimate. What doesn’t work is staying in the middle.

Back to the twelve-minute standup we started with. Five people, five updates, no interaction. The obvious diagnosis is that the standup is poorly facilitated, or that Scrum doesn’t work, or that the team needs to “work on communication.” These are all responses that address the symptom.

Hackman’s question is different, and it comes first: do those five people need to talk to each other every morning to do their work? If each person’s work doesn’t depend on the others’, the standup isn’t poorly facilitated. It’s useless by design. The retro doesn’t produce actions because there’s no shared process to improve. Planning is bureaucracy because there are no collective decisions to make.

It’s not a question of execution. It’s a question of structure.

Next time you think “Agile doesn’t work,” try reframing. Don’t ask how to improve the process. Ask whether what you’re leading is a team or a working group. The answer isn’t a judgment. It’s a diagnosis. And from the diagnosis, everything else follows.

Sources

• Hackman, J.R. (2002). Leading Teams: Setting the Stage for Great Performances. Harvard Business School Press.
• Hackman, J.R. (2011). Collaborative Intelligence: Using Teams to Solve Hard Problems. Berrett-Koehler.
• Wageman, R. (2001). How Leaders Foster Self-Managing Team Effectiveness: Design Choices Versus Hands-on Coaching. Organization Science, 12(5), 559-577.
• Wageman, R., Hackman, J.R. & Lehman, E.V. (2005). Team Diagnostic Survey: Development of an Instrument. Journal of Applied Behavioral Science, 41(4), 373-398.
• Digital.ai (2024). 17th State of Agile Report.
• Jeffries, R. (2018). Developers Should Abandon Agile.
• Thomas, D. (2014). Agile is Dead (Long Live Agility).

Companies don’t hire juniors because AI does those tasks better. But without junior developers today, who will lead teams in ten years?

There’s a question that rarely appears in quarterly reports: if we stop hiring people who are learning, who will know how to do this job a decade from now?

The numbers tell a story that should concern anyone managing technical teams. Employment for software developers between ages 22 and 25 has dropped 20% from the peak in late 2022, according to a paper from Stanford’s Digital Economy Lab based on payroll data from 25 million workers. It’s not a uniform decline: in the same period, employment for those over 35 in the same roles grew 8%.

The mechanism is what we might call the apprenticeship paradox: companies stop hiring entry-level because AI does those tasks better than a recent graduate. But without entry-level workers today, they won’t have senior engineers tomorrow.

The numbers of collapse

The contraction is not an impression. It’s documented by multiple independent sources.

Entry-level hiring at the top 15 tech companies dropped 25% between 2023 and 2024, according to SignalFire. Since 2021, the average age of technical hires has increased by three years. Companies aren’t just hiring less: they’re hiring differently, preferring senior profiles who can be productive from day one.

Tech internships have collapsed 30% since 2023, according to Handshake. Meanwhile, applications have increased 7%. More people competing for fewer positions, and the remaining positions require increasingly prior experience.

A Harvard study of 285,000 American companies found that when firms adopt generative AI, junior employment drops 9-10% within six quarters. Senior employment remains stable. These aren’t mass layoffs: it’s a silent hiring freeze. Companies simply stop opening entry-level positions.

The pattern repeats in Europe. Junior tech positions have dropped 35% in major EU countries during 2024, based on aggregated data from LinkedIn, Indeed, and Eures. In the UK, the Big Four consulting firms cut graduate hiring between 6% and 29% in two years. In India, IT companies have reduced entry-level roles by 20-25%, according to an EY report.

The World Economic Forum, in its Future of Jobs Report 2025, warns that 40% of employers expect to reduce staffing where AI can automate tasks. And automatable tasks are, almost by definition, the ones junior developers used to do.

The logic of the short term

The rationale behind these choices is understandable. A senior engineer with AI tools can do what previously required two or three juniors, at least for certain tasks. GitHub Copilot, Cursor, and similar tools promise productivity gains of 20-50% according to their vendors. For a CFO looking at the next quarter, hiring a junior who will need six months of training before being productive seems like a difficult investment to justify.

James O’Brien, a computer science professor at Berkeley who works with startups, describes the shift: “Previously, startups would hire one senior person and two or three early-career coders to assist. Now they ask: why hire a recent graduate when AI is cheaper and faster?”

It’s a reasonable question in the short term. Code generated by AI isn’t top quality, but neither is code written by a recent graduate. The difference, O’Brien notes, is that the iterative process to improve AI code takes minutes. A junior might take days for the same task.

Heather Doshay, head of talent at SignalFire, sums it up: “Nobody has the patience or time for hand-holding in this new environment, where much of the work can be done autonomously by AI.”

The problem nobody calculates

There’s a flaw in this logic, and it’s called the talent pipeline.

Matt Garman, CEO of AWS, said it explicitly: “If you don’t have a talent pipeline you’re building, if you don’t have junior people you’re mentoring and growing in the company, we often find that’s where the best ideas come from. If a company stops hiring juniors and developing them, eventually the whole system falls apart.”

It’s not rhetoric. It’s demographic mathematics applied to organizations. Every senior engineer, every tech lead, every CTO was once a junior. The path from recent graduate to technical leader requires years of experience on real projects, mistakes made and corrected, feedback received, patterns internalized. There is no shortcut.

If the industry stops hiring juniors in 2023, by 2033 it will have a structural shortage of mid-level talent. By 2038, there will be a shortage of senior engineers. By 2043, there will be no one to promote to technical leadership roles.

The problem is that this cost doesn’t appear in any quarterly balance sheet. It’s an invisible debt that accumulates silently, and when it becomes obvious, it will be too late to remedy quickly.

AI that teaches and AI that atrophies

There’s a further irony in this situation. The same AI tools that are eliminating junior roles could, in theory, accelerate learning. An AI tutor available 24/7, patient, answering every question: it sounds like every student’s dream.

The reality is more complicated.

An experiment conducted by Wharton and Penn researchers on nearly a thousand high school math students tested two versions of a GPT-4-based tutor. The group with access to a ChatGPT-like interface (GPT Base) achieved 48% better results during assisted practice sessions. The group with a tutor designed to guide without giving direct answers (GPT Tutor) achieved 127% better results.

But here’s the point: when AI was removed and students took the exam on their own, the GPT Base group achieved 17% worse results than the control group who never used AI. The GPT Tutor group, by contrast, achieved results similar to control.

Students were using AI as a crutch. They performed better with assistance but learned less. When the assistance was removed, they found themselves worse off than those who never had it.

A study from MIT Media Lab documented what researchers call “cognitive debt”: using LLMs for writing seems to reduce mental effort during the task, but at the cost of more superficial learning. Researcher Nataliya Kosmyna expressed concern about developing brains: “Developing brains are the ones at highest risk.”

It doesn’t mean AI can’t help learning. The Wharton study shows it can, if designed with the right safeguards. But “wild” AI, the kind that gives answers instead of guiding toward answers, can do damage.

The new profile of the junior

If fewer juniors will be hired, what characteristics must they have to be hired?

Market signals are clear. It’s no longer enough to know how to code. Employers expect recent graduates to be able to manage projects, communicate with clients, understand the software development lifecycle. The “grunt work” that once served as a training ground is being automated. Those entering must be operational at a higher level almost from day one.

Jamie Grant, who manages career services for engineering at the University of Pennsylvania, describes the change: “They’re not necessarily just programming. There’s much more high-level thinking and understanding of the software development lifecycle.”

David Malan of Harvard, who teaches the world’s most-followed introduction to programming course, notes that the biggest impact of AI has been on programmers, not on roles that were expected (like call centers). The reason: programming work is relatively solitary and highly structured, perfect for automation.

But Malan also notes something interesting: in the United States, employment for “programmers” dropped 27.5% between 2023 and 2025, but employment for “software developers,” a more design-oriented position, dropped only 0.3%. The difference is in the level of abstraction. Those who write code are vulnerable. Those who design systems less so.

Three scenarios for the future

Scenario 1: The collapse of the pipeline

Companies continue not to hire juniors. In five to ten years, the shortage of mid-level talent becomes acute. The remaining senior engineers command astronomical salaries. Companies that can’t afford them lose competitiveness. The industry polarizes between a few giants who can attract talent and everyone else struggling.

Scenario 2: Apprenticeship reinvented

Some companies realize the problem is coming and invest against the trend. They create intensive training programs, perhaps assisted by AI designed to teach instead of replace. They become the preferred employers for top talent, who know they can grow there. In the long term, they have a competitive advantage.

Scenario 3: Uneven democratization

AI lowers the barrier to entry for some skills (writing working code) but raises it for others (designing systems, debugging complex problems, managing AI itself). Those with access to quality training and mentorship can skip some steps. Those without remain stuck. Inequality of opportunity increases.

None of these scenarios is inevitable. They are possibilities that depend on choices companies, educational institutions, and policymakers will make in the coming years.

What those who hire can do

If you manage a team or influence hiring decisions, some questions deserve reflection.

Are you optimizing for the next quarter or the next ten years? A junior costs more in the short term. But the alternative is to depend entirely on the external market for talent, competing with everyone else who made the same choice.

Is your team still teaching? If senior people spend all their time producing and no one teaching, you’re consuming human capital without regenerating it.

How do you use AI in training? If your juniors use Copilot to get answers instead of learning to find them, you’re accelerating their short-term productivity while compromising their long-term growth.

Are you hiring for today’s skills or tomorrow’s adaptability? Specific technical skills have an increasingly short half-life. The ability to learn, to reason about new problems, to work with people—those last.

What those starting out can do

If you’re early in your career in a market that seems to close doors on you, some principles can help.

AI isn’t eliminating all junior work. It’s eliminating repetitive, isolated junior work. The roles that survive require human interaction, judgment about ambiguous problems, creativity applied to specific contexts. Look for those.

Learn to use AI as a tool, not a crutch. The difference between using ChatGPT to get answers and using it to explore problems is the difference between atrophying and growing.

Networking matters more than ever. If junior positions are scarce, competition is fierce, and often the person with a connection wins, not the person with the best CV. It’s not fair, but it’s real.

Cross-functional skills are not optional. Communication, project management, understanding the business: these are things AI can’t do and employers seek even in technical profiles.

The unanswered question

I return to the initial question: who will the senior engineers of tomorrow be?

I don’t have a certain answer. No one does. We’re conducting a real-time experiment, without a control group, on a global scale.

What I know is that every senior person I know was once a junior who someone decided to hire and train. Every tech lead made beginner mistakes that someone had the patience to correct. Every systems architect wrote embarrassing code before writing elegant code.

If we eliminate that phase, if we treat it as a cost to cut rather than an investment to protect, we’re not optimizing. We’re consuming capital that we don’t know how to regenerate.

The question isn’t whether AI can replace juniors. It can, for many tasks. The question is whether we want an industry that only knows how to consume skills or one that also knows how to produce them.

For now, the numbers suggest we’ve chosen the first option. The bill will come. Not next quarter. But it will come.

Sources

Brynjolfsson, E., Chandar, B., & Chen, R. (2025). Canaries in the Coal Mine: Six Facts about the Recent Employment Effects of AI. Stanford Digital Economy Lab.

Bastani, H., Bastani, O., Sungu, A., Ge, H., Kabakcı, Ö., & Mariman, R. (2024). Generative AI Can Harm Learning. The Wharton School Research Paper.

Stack Overflow. (2025, December). AI vs Gen Z: How AI has changed the career pathway for junior developers. Stack Overflow Blog.

IEEE Spectrum. (2025, December). AI Shifts Expectations for Entry Level Jobs.

Rest of World. (2025, December). AI is wiping out entry-level tech jobs, leaving graduates stranded.

Kosmyna, N., et al. (2025). Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task. arXiv.

World Economic Forum. (2025). Future of Jobs Report 2025.

FinalRound AI. (2025). AWS CEO Shares 3 Solid Reasons Why Companies Shouldn’t Replace Juniors with AI Agents.

GPTBot went from 5% to 30% of crawler traffic in one year. Traffic generated by user queries to AI has grown 15 times. Traditional SEO infrastructure no longer intercepts this flow.

TL;DR: Optimization for generative search engines (GEO) requires specific technical interventions: configure robots.txt for 20+ AI crawlers, implement llms.txt to guide LLMs toward priority content, extend structured data with JSON-LD including Person schema with complete E-E-A-T (73% higher selection rate). Structure content in answer blocks of 134-167 words to facilitate extraction. Multimodal content has +156% selection rate. Princeton research shows that adding citations from authoritative sources increases visibility up to 40%. Those who implement now build competitive advantages that are difficult to catch up with.

Traditional SEO optimizes for a specific goal: ranking in the sorted lists returned by search engines. The user searches, receives ten blue links, clicks. Traffic arrives.

Generative search engines work differently. ChatGPT, Perplexity, Gemini, Claude don’t return lists of links. They synthesize answers by drawing from multiple sources, citing (or not) the source. The user gets an answer, not a list of options.

According to Cloudflare data from December 2025, GPTBot reached 30% of AI crawler traffic, up from 5% the previous year. Meta-ExternalAgent entered at 19%. ChatGPT-User, the bot that accesses web pages when users ask questions, registered growth of 2,825%. Traffic related to user queries increased 15 times over the course of the year.

This is not marginal change. It’s a new acquisition channel that requires dedicated infrastructure.

robots.txt: configuration for AI crawlers

The robots.txt file communicates to crawlers which parts of the site they can access. For traditional search engines, the configuration is established. For AI crawlers, the landscape is fragmented: each provider uses different user-agents, with different purposes.

Map of major AI crawlers

OpenAI operates with three distinct crawlers:

User-agent: GPTBot
# Training foundational models. Collects data to train GPT.

User-agent: ChatGPT-User
# User browsing. Accesses pages when a user asks for information.

User-agent: OAI-SearchBot
# Search. Indexes content for ChatGPT's search function.

Anthropic uses:

User-agent: ClaudeBot
# Training and updating Claude.

User-agent: Claude-Web
# Web access for user functionality.

User-agent: anthropic-ai
# Generic Anthropic crawler.

Perplexity:

User-agent: PerplexityBot
# Indexing for AI answer engine.

User-agent: Perplexity-User
# Fetch for user queries.

Google has separated functions:

User-agent: Google-Extended
# Token for AI use. NOT a bot, it's a flag.
# Blocking this user-agent prevents use of content for AI training
# while maintaining standard indexing.

User-agent: Googlebot
# Traditional crawler for Search.

Meta:

User-agent: Meta-ExternalAgent
# Crawling for AI model training.

User-agent: Meta-ExternalFetcher
# Fetch for user requests. Can bypass robots.txt.

Other relevant crawlers:

User-agent: Amazonbot
User-agent: Bytespider      # ByteDance
User-agent: Applebot-Extended  # Apple AI (flag, not bot)
User-agent: CCBot           # Common Crawl
User-agent: cohere-ai
User-agent: cohere-training-data-crawler

Configuration strategies

Strategy 1: Full access for maximum AI visibility

# Allow all AI crawlers
User-agent: GPTBot
Allow: /

User-agent: ChatGPT-User
Allow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: anthropic-ai
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Google-Extended
Allow: /

User-agent: Meta-ExternalAgent
Allow: /

User-agent: Amazonbot
Allow: /

Strategy 2: AI search visibility, no training

This configuration allows AI systems to cite your content in responses, but prevents use for training models:

# Allow search/user crawlers
User-agent: ChatGPT-User
Allow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Perplexity-User
Allow: /

# Block training crawlers
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: Meta-ExternalAgent
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: cohere-training-data-crawler
Disallow: /

Strategy 3: Selective access by directory

User-agent: GPTBot
Allow: /blog/
Allow: /docs/
Disallow: /api/
Disallow: /internal/
Disallow: /user-data/

Limitations of robots.txt

A critical point: robots.txt is a voluntary protocol. Crawlers can ignore it.

In August 2025, Cloudflare blocked Perplexity bots after documenting protocol violations. In October 2025, Reddit deliberately trapped Perplexity crawlers, demonstrating they bypassed restrictions through third-party tools. Legal action followed.

The operational consequence: robots.txt alone is not enough. For real enforcement, you need IP verification, WAF rules, or CDN-level blocks. Cloudflare reports that over 2.5 million sites use its managed robots.txt function to block AI training.

llms.txt: the new standard for guiding LLMs

In September 2024, Jeremy Howard of Answer AI proposed llms.txt, a new standard file for communicating with Large Language Models. Unlike robots.txt, which controls access, llms.txt guides models toward the most relevant content.

What llms.txt does

The llms.txt file is a markdown document positioned at the domain root (/llms.txt). It works as a curated map that tells LLMs which pages contain the most important information and how to interpret them.

It’s not a blocking mechanism. It’s a recommendation system, like a librarian guiding a visitor to the right shelves instead of letting them wander.

File structure

# example.com

> Technical site on AI implementations for enterprise.
> Content verified, updated monthly.

## Core Documentation

- [Production RAG Guide](https://example.com/docs/rag-production):
  RAG architectures tested in production, chunking patterns,
  evaluation metrics. Updated Q4 2024.

- [API Reference](https://example.com/docs/api):
  Complete REST API documentation. Includes code examples
  in Python and cURL.

## Technical Articles

- [LLM Latency Optimization](https://example.com/blog/llm-latency):
  Strategies to reduce p95 latency below 200ms.
  Includes benchmarks on Claude, GPT-4, Mistral.

- [AI Cost Management](https://example.com/blog/ai-costs):
  Framework for estimating and optimizing inference costs.
  Real data from enterprise deployments.

## Resources

- [AI Glossary](https://example.com/glossary):
  Technical definitions of 150+ AI/ML terms.

llms-full.txt: extended version

Beyond llms.txt, the standard provides an optional llms-full.txt file containing the full site content in flattened format. It removes non-essential HTML, CSS, JavaScript and presents text only. Some sites generate files of 100K+ words.

The advantage: allows LLMs to process the entire site in a single context. The limitation: easily exceeds the context window of most models.

Adoption status

As of January 2025, OpenAI, Google, and Anthropic do not natively support llms.txt. Their crawlers don’t automatically read the file.

Current adoption is concentrated in specific niches:

• Technical documentation: Mintlify integrated llms.txt in November 2024. Documentation sites for Anthropic, Cursor, Cloudflare, Vercel use it.
• Dedicated directories: directory.llmstxt.cloud and llmstxt.site catalog sites with implementations.
• Manual use: Developers who upload the file directly to ChatGPT or Claude to provide context.

It’s an investment in future-proofing. When major providers adopt the standard, those who have already implemented will have an advantage.

Implementation

1. Create /llms.txt at the domain root
2. UTF-8 format, clean markdown
3. Include only indexable pages (no noindex, no blocked in robots.txt)
4. Add concise but informative descriptions for each URL
5. Optional: reference in robots.txt with # LLM-policy: /llms.txt

Differences with other standard files

Structured Data and JSON-LD for AI

Structured data is not new. It’s been standard SEO since 2011. But its role changes in the context of generative search engines.

Why Structured Data matters for AI

LLMs process everything as tokens. They don’t natively distinguish between a price, a name, a date. Structured data provides an explicit semantic layer that disambiguates content.

An article with JSON-LD markup communicates in a machine-readable way: this is the author, this is the publication date, this is the publishing organization, these are the sources cited. The model doesn’t have to infer this structure from the text.

Basic JSON-LD implementation

JSON-LD (JavaScript Object Notation for Linked Data) is the preferred format. It’s inserted in a <script> tag without mixing with content HTML:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "TechArticle",
  "@id": "https://example.com/rag-production-guide",
  "headline": "RAG in Production: Patterns and Anti-Patterns",
  "description": "Technical guide to enterprise RAG implementation with real metrics",
  "author": {
    "@type": "Person",
    "name": "Author Name",
    "url": "https://example.com/team/author-name",
    "jobTitle": "AI Team Leader",
    "knowsAbout": ["RAG", "LLM", "Vector Databases", "AI Engineering"]
  },
  "datePublished": "2025-01-04",
  "dateModified": "2025-01-04",
  "publisher": {
    "@type": "Organization",
    "name": "Example.com",
    "url": "https://example.com",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/rag-production-guide"
  },
  "articleSection": "Engineering",
  "keywords": ["RAG", "Production", "Enterprise AI", "Vector Search"],
  "wordCount": 3500,
  "inLanguage": "en"
}
</script>

Priority schema types for AI visibility

Article / TechArticle / NewsArticle

For editorial content. TechArticle for technical documentation.

FAQPage

Q&A structure that generative search engines can extract directly:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What is the difference between SEO and GEO?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "SEO optimizes for lists of results from traditional search engines. GEO optimizes for being cited in synthesized responses from generative search engines like ChatGPT and Perplexity."
      }
    },
    {
      "@type": "Question",
      "name": "Does llms.txt replace robots.txt?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "No. robots.txt controls crawler access. llms.txt guides LLMs toward priority content. They have complementary functions."
      }
    }
  ]
}
</script>

HowTo

For step-by-step guides:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "How to configure robots.txt for AI crawlers",
  "step": [
    {
      "@type": "HowToStep",
      "position": 1,
      "name": "Identify target AI crawlers",
      "text": "Map the user-agents of AI crawlers you want to allow or block."
    },
    {
      "@type": "HowToStep",
      "position": 2,
      "name": "Define access strategy",
      "text": "Decide whether to allow training, search-only, or block completely."
    },
    {
      "@type": "HowToStep",
      "position": 3,
      "name": "Implement directives",
      "text": "Add User-agent and Allow/Disallow rules to your robots.txt file."
    }
  ]
}
</script>

Organization and Person: E-E-A-T for AI

E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness) is no longer just a Google framework. Data shows that LLMs verify author credentials before citing: 96% of content in AI Overview comes from sources with verified authors. Content with detailed author bios has 73% higher selection probability.

The Person schema must go beyond the name. It needs to communicate credentials, affiliations, specific expertise:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Mario Rossi",
  "url": "https://example.com/team/mario-rossi",
  "image": "https://example.com/images/mario-rossi.jpg",
  "jobTitle": "Senior AI Engineer",
  "description": "10+ years of experience in ML/AI, specialized in enterprise RAG systems",
  "worksFor": {
    "@type": "Organization",
    "name": "TechCorp Italia",
    "url": "https://techcorp.it"
  },
  "alumniOf": {
    "@type": "CollegeOrUniversity",
    "name": "Politecnico di Milano"
  },
  "hasCredential": [
    {
      "@type": "EducationalOccupationalCredential",
      "credentialCategory": "certification",
      "name": "AWS Machine Learning Specialty"
    },
    {
      "@type": "EducationalOccupationalCredential",
      "credentialCategory": "certification",
      "name": "Google Cloud Professional ML Engineer"
    }
  ],
  "knowsAbout": [
    "Retrieval-Augmented Generation",
    "Large Language Models",
    "Vector Databases",
    "MLOps",
    "AI Engineering"
  ],
  "sameAs": [
    "https://linkedin.com/in/mariorossi",
    "https://github.com/mariorossi",
    "https://scholar.google.com/citations?user=xxx"
  ]
}
</script>

E-E-A-T checklist for Person schema:

• description with years of experience and specialization
• hasCredential for verifiable certifications
• knowsAbout with specific topics (not generic)
• sameAs with links to verified profiles (LinkedIn, GitHub, Google Scholar)
• alumniOf for academic affiliations
• worksFor with organization URL

Citation schema

For content that cites external sources, the Citation schema adds context:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Analysis of GEO Paper Princeton",
  "citation": [
    {
      "@type": "ScholarlyArticle",
      "name": "GEO: Generative Engine Optimization",
      "author": ["Pranjal Aggarwal", "et al."],
      "datePublished": "2024",
      "publisher": {
        "@type": "Organization",
        "name": "Princeton University"
      },
      "url": "https://arxiv.org/abs/2311.09735"
    }
  ]
}
</script>

ImageObject and VideoObject for multimodal content

Multimodal content has 156% higher probability of being selected in AI Overview compared to text-only content. Gemini and Perplexity invest heavily in multimodal search. Schema for media becomes relevant:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "ImageObject",
  "contentUrl": "https://example.com/images/architettura-rag.png",
  "name": "Enterprise RAG system architecture",
  "description": "Architectural diagram showing data flow between vector store, retriever and LLM in a production RAG system",
  "author": {
    "@type": "Person",
    "name": "Mario Rossi"
  },
  "datePublished": "2025-01-04",
  "encodingFormat": "image/png"
}
</script>

For video with transcription:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "VideoObject",
  "name": "Deploy RAG in production: walkthrough",
  "description": "Video tutorial on deploying a RAG system on AWS with monitoring",
  "thumbnailUrl": "https://example.com/video/rag-deploy-thumb.jpg",
  "uploadDate": "2025-01-04",
  "duration": "PT12M30S",
  "transcript": "https://example.com/video/rag-deploy-transcript.txt",
  "author": {
    "@type": "Person",
    "name": "Mario Rossi"
  }
}
</script>

Best practices for AI-friendly media:

• Descriptive and contextual alt text (not “image1.png”)
• Captions that explain the content, not just describe it
• Transcriptions for all videos
• Captions that contextualize the figure in surrounding text

Real impact on AI search

John Mueller of Google clarified in January 2025 that structured data is not a direct ranking factor. But the indirect impact is documented:

• Rich snippets from structured data increase CTR by 30% according to BrightEdge
• 72% of sites on Google’s first page use schema markup
• Google’s AI Overviews process structured data to build responses

Structured data doesn’t guarantee citations in generative search engines. But it provides the semantic context that facilitates correct interpretation of content.

Technical requirements for AI crawlers

Beyond structured data, there are technical requirements that influence LLMs’ ability to process and cite content.

Static HTML vs JavaScript rendering

AI crawlers struggle with JavaScript-rendered content. Unlike Googlebot, which executes JS, many AI crawlers prefer or require static HTML.

Operating rules:

• Critical content must be present in static HTML, not generated dynamically
• Avoid content hidden in tabs, accordions, or loaded on-scroll
• If you use JS frameworks (React, Vue, Next.js), verify that SSR or SSG produces complete HTML
• Test: view the page with JS disabled. What you see is what base AI crawlers see.

Content freshness signals

23% of content selected in AI Overview is less than 30 days old. Perplexity indexes daily. Freshness signals are prioritized over historical authority.

Implementation:

dateModified in schema must reflect actual updates:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "TechArticle",
  "headline": "Production RAG Guide",
  "datePublished": "2024-06-15",
  "dateModified": "2025-01-04"
}
</script>

Freshness checklist:

• Update dateModified only for substantial changes (not typo fixes)
• Prominently signal updates in content (“Updated: January 2025”)
• Quarterly review of evergreen content
• Update statistics and data at least annually
• Remove or mark obsolete content as archived

Citation verification and fact-checking

AI systems cross-reference with authoritative sources in real-time. Content with verifiable citations has 89% higher selection probability compared to content with unsupported claims.

Rules:

• Every statistic must have a linked source
• “According to research” without a link = unverifiable claim = penalized
• Prefer primary sources (papers, official documentation) over secondary sources
• Citations from Wikipedia, Statista, Pew Research, arXiv papers carry more weight

GEO strategies: what the research says

The “GEO: Generative Engine Optimization” paper from Princeton, Georgia Tech, Allen Institute, and IIT Delhi is the most rigorous available study on optimization for generative search engines. It tested 9 techniques on 10,000 queries.

The three most effective strategies

1. Cite Sources: +40% visibility

Adding citations from authoritative sources is the strategy with the highest overall impact. For sites with low ranking in traditional SERPs, the effect is even more pronounced: +115% for sites in fifth position.

Simply citing is not enough. The citation must be from a recognized, relevant source, verifiable.

2. Quotation Addition

Incorporating direct quotes from industry experts increases authenticity and perceived depth. Works particularly well for opinion-based content.

3. Statistics Addition

Quantitative data beats qualitative discussion. “42% of AI projects fail” has more impact than “many AI projects fail”. Works particularly well for Legal and Government domains.

Structuring content for extraction: Answer Blocks

LLMs don’t cite entire pages. They extract specific blocks. Optimizing for this pattern is critical.

Passage length optimal: 134-167 words per citable block. For direct FAQ answers: 40-60 words. Content with summary boxes at the beginning has 28-40% higher citation probability.

Practical implementation:

1. TL;DR at the beginning: Every article opens with a self-contained summary block. It’s not just for human readers: it’s the block that LLMs preferentially extract.

2. Self-contained sections: Each H2/H3 should be citable independently from the rest. An LLM should be able to extract that section and have a complete answer.

3. Heading as questions: “What is RAG?” performs better than “RAG Overview”. Direct matching with conversational queries.

4. Modular paragraphs: 75-300 words per section. No wall of text. Modular blocks are easier to extract and cite.

5. Direct answers first, context after: The answer to the heading’s implicit question should appear in the first 2-3 sentences. Elaboration comes after.

Example of optimized structure:

## What is the difference between SEO and GEO?

SEO optimizes for ranking in lists of results from traditional
search engines. GEO optimizes for being cited in synthesized
responses from generative search engines like ChatGPT, Perplexity
and Gemini. [40-60 words of direct answer]

The fundamental change concerns the objective: from ranking to
citation. In classical SEO, success is position 1 in the SERPs.
In GEO, success is being the source that the AI cites when responding.
[Elaboration and context]

Domain-specific strategies

The paper found that effectiveness varies by domain:

• History: Authoritative and persuasive tone
• Facts: Citations from primary sources
• Law/Government: Statistics and quantitative data
• Science/Health: Technical terminology + authoritativeness

Platform-specific optimization

Each LLM has different preferences. An effective GEO strategy considers these differences:

Operational implications:

• ChatGPT cites Wikipedia in 48% of responses. For topics with a Wikipedia entry, presence there matters.
• Perplexity prefers Reddit (46.7% of citations). Content discussed in relevant subreddits has an advantage.
• Gemini integrates images and video into responses. Multimodal content performs better.
• Claude verifies accuracy more rigorously. Unsupported claims are discarded.

What doesn’t work

Keyword stuffing: Adding keywords from the query to content worsens visibility by 10% compared to baseline. Generative search engines penalize over-optimization.

Generic persuasive language: Persuasive tone without substance doesn’t improve ranking.

Democratization of results

An interesting aspect: GEO levels the playing field. Sites with low ranking in traditional SERPs benefit more from GEO optimizations than dominant sites. Cite Sources brings +115% to sites in fifth position and -30% to sites in first position.

For small publishers and independent businesses, it’s an opportunity to compete with corporate giants without comparable SEO budgets.

Implementation checklist

robots.txt

• [ ] Map all AI crawlers relevant to your industry
• [ ] Define strategy: full access, search-only, selective
• [ ] Implement directives for each user-agent
• [ ] Verify syntax with Google Robots Testing Tool
• [ ] Monitor server logs for crawler activity
• [ ] Verify actual compliance (IP check for suspicious crawlers)
• [ ] Quarterly review: new crawlers emerge regularly

llms.txt

• [ ] Create markdown file at domain root
• [ ] Include site description and content type
• [ ] Organize URLs by category/priority
• [ ] Add concise descriptions for each link
• [ ] Verify that all URLs are indexable
• [ ] Consider llms-full.txt for sites with extended documentation
• [ ] Update when new priority content is published

Structured Data / JSON-LD

• [ ] Implement Organization schema for the site
• [ ] Add Person schema for authors with complete E-E-A-T:
  • [ ] description with years of experience and specialization
  • [ ] hasCredential for verifiable certifications
  • [ ] knowsAbout with specific topics
  • [ ] sameAs with LinkedIn, GitHub, Google Scholar
• [ ] Use Article/TechArticle for editorial content
• [ ] Implement FAQPage for Q&A sections
• [ ] Add Citation schema for research-based content
• [ ] Implement ImageObject/VideoObject for media
• [ ] Validate with Google Rich Results Test
• [ ] Verify parity between markup and visible content

GEO-optimized content

• [ ] TL;DR of 40-60 words at the beginning of each article
• [ ] Self-contained sections (citable independently)
• [ ] Headings formulated as questions where appropriate
• [ ] Modular paragraphs: 75-300 words per section
• [ ] Passage length: 134-167 words for key blocks
• [ ] Include citations from authoritative sources in every article
• [ ] Add statistics and quantitative data with source
• [ ] Use expert quotations where relevant
• [ ] Avoid keyword stuffing
• [ ] Calibrate tone for domain

Technical requirements

• [ ] Critical content in static HTML (not JS-only rendering)
• [ ] No content hidden in tabs/accordions/lazy-load
• [ ] Test page with JavaScript disabled
• [ ] dateModified updated for substantial changes
• [ ] Signal updates in content (“Updated: Month Year”)
• [ ] Quarterly review of evergreen content
• [ ] Every statistic with linked source

Media and Multimodal

• [ ] Descriptive and contextual alt text for images
• [ ] Captions that explain the content
• [ ] Transcriptions for all videos
• [ ] ImageObject/VideoObject schema implemented
• [ ] Captions that contextualize figures in surrounding text

Monitoring

• [ ] Track AI crawler activity in server logs
• [ ] Monitor brand mentions in ChatGPT/Perplexity/Gemini responses
• [ ] Analyze competitor citation share
• [ ] Measure referral traffic from AI platforms
• [ ] Monthly metrics review

The window of opportunity

Cloudflare data shows that crawling for AI training still dominates traffic, with volumes 8 times higher than search crawling and 32 times higher than user-action crawling. But the trend is clear: user-action traffic is growing faster than any other category.

Those who implement GEO infrastructure now build advantages that accumulate over time. Citations generate other citations. Authority recognized by models strengthens. First-mover advantage in this space isn’t just about technical positioning: it’s about building an established presence before competition intensifies.

Traditional SEO doesn’t disappear. It continues to serve 70% of search traffic that still goes through classic SERPs. But the remaining 30%, and its growth trajectory, requires new tools.

Sources

Aggarwal, P., et al. (2024). GEO: Generative Engine Optimization. arXiv:2311.09735. Princeton University, Georgia Tech, Allen Institute for AI, IIT Delhi.

AI Mode Boost. (2025). AI Overview Ranking Factors: 2025 Comprehensive Study.

Cloudflare. (2025, December). From Googlebot to GPTBot: Who’s Crawling Your Site in 2025. Cloudflare Blog.

Dataslayer. (2025). Google AI Overviews Impact 2025: CTR Down 61%.

Howard, J. (2024, September). llms.txt Proposal. Answer AI.

W3C Schema Community. (2024). Schema Vocabulary Documentation.

SEO Sherpa. (2025, October). Google AI Search Guidelines 2025.

Single Grain. (2025, October). Google AI Overviews: The Ultimate Guide to Ranking in 2025.

Yoast. (2025). Structured Data with Schema for Search and AI.

Overdrive Interactive. (2025, July). LLMs.txt: The New Standard for AI Crawling.