The Trump administration is waging a culture war on science, and the latest salvo is in the form of a dry, bureaucratic proposal from the Office of Management and Budget (OMB) that could threaten the future of US science as we know it.
I keep seeing the same idea in conversations about agents: detailed specs are old-world overhead now. Give the model a rough goal, let it explore, fix what comes back, move on. It sounds efficient but it also hides the cost.
A simple prompt looks cheap and tempting because it gets implementation started right away. Then the correction loops start. You review output, clarify intent, ask for changes, rerun tests, find the next gap, and do it again. Someone still has to decide whether the result matches the real goal. That person becomes the oracle.
At the other extreme, full formal specification is obviously expensive up front. Writing acceptance criteria, contract tests, or behavior-driven development (BDD) scenarios takes real effort. But the downstream cost is different because more of the oracle is executable. A test checks the same condition every time. It does not get tired, rushed, or optimistic five minutes before lunch.
That is the actual trade-off. The question is not whether specification is good or bad. It’s where the minimum total cost sits. For most agentic work, it is somewhere in the middle: enough structure to constrain the work, enough examples to make intent concrete, and enough executable checks that review does not turn into guessing.
Zero spec is not intelligent and lean; it’s just costly vibe-coding.
The bottleneck moved, not disappeared
Software engineering was never mainly about typing or even producing code. It was about deciding what should exist, what should never happen, which trade-offs matter, and what “done” means once the problem touches the real world.
For years, teams discovered missing specification through human friction. A reviewer noticed an edge case, QA found the path nobody described, a senior engineer carried half the real requirements in his head and translated them one meeting at a time. None of that was elegant, but it did force ambiguity into the open.
Agents change that fundamentally. They make implementation much cheaper and much faster. It also means an underspecified idea can turn into a plausible system before anyone has really agreed on what the system is supposed to mean.
In the old world, vague requirements ran into human slowness. In the agent world, vague requirements run into machine speed.
That is why specification suddenly feels important again. It was always important. We just used implementation cost as a crude forcing function and called the result process.
As implementation gets cheaper, more of the difficulty moves into deciding what correct means and checking it reliably.
Writing the spec is not enough
This is the part I see people skip most often. They talk as if the sequence is simple: write the spec, then let the agent implement it. The missing step is the expensive one.
The spec itself needs review.
Even a careful spec can fail in familiar ways. It can contradict itself or cover the happy path and say nothing useful about retries, rate limits, or partial failure. It can describe behavior that sounds precise but cannot actually be verified. And sometimes it is precise in exactly the wrong way: it says what you wrote, not what you meant.
When an agent executes a flawed spec faithfully, the failure gets harder to diagnose. The implementation may look coherent. It may even pass the checks you provided. But the real problem lives upstream, in the spec, so fixing it means unwinding code and reasoning together.
That is why I think spec validation deserves its own line item. Before implementation starts, someone needs to ask a few plain questions. Is this internally consistent? Is it complete enough for this task? Which parts are testable? Where are we still depending on human judgment? Which failure modes are missing because everyone silently assumed them?
Agents can help here, but only if we use them for something more useful than “write requirements.” That prompt usually produces polished fog. A better prompt is much more specific:
Draft the smallest spec that would let another agent implement this safely. Include assumptions, non-goals, acceptance criteria, edge cases, observable outcomes, and open questions. Mark which claims can become automated tests and which still require human review.
After that, hand the draft to a different agent and tell it to attack the result:
Find contradictions, ambiguous terms, hidden dependencies, untestable claims, missing failure modes, and places where an implementation could pass the written criteria while still violating the intent.
Even that simple workflow lowers the cost of getting to a spec that is worth human judgment.
Agents do not remove the need for specs. They make it cheaper to reach a level of specificity that is actually useful.
Why multi-agent systems need stronger contracts
A single agent working on a small, bounded task can often recover from loose instructions. The loop is tight, the blast radius is local, and a human can usually steer it back on course when it drifts. Humans can even easily spot the drift to begin with.
Multi-agent systems are a very different problem. Once one agent’s output becomes another agent’s input, interpretive drift starts to compound. Agent B does not know Agent A misunderstood a requirement by 10%. It just treats the output as ground truth and keeps going. By the time a human sees the result, the original mistake may be buried under several layers of competent-looking work.
At that point, the spec is no longer just guidance but more like a contract.
That contract needs more than a paragraph of intent. It needs schemas, invariants, allowed ambiguity, validation rules, and explicit failure behavior. In many cases, it also needs contract tests, typed interfaces, and machine-checkable handoff formats. The handoff is part of the product, which is less glamorous than people hoped, but much closer to reality.
This is also where BDD and executable acceptance tests belong. Their value is not just the methodology, it’s that they move part of the human oracle into something repeatable. When behavior is stable enough to specify precisely, an executable spec is often cheaper than another round of review.
Once agents start handing work to other agents, the handoff itself needs to be specified and validated like a real interface.
A spec should have an expiration date
There is another failure that teams make here: It shows up when they keep pushing on the specification curve as if more text is always safer. It is not. At least for current models it’s not.
Chroma’s work on context rot makes the first part of the problem clear: Model performance gets less reliable as the input grows, even on simple tasks. In coding projects there is a second problem on top of that. The more design prose, examples, plans, comments, tickets, and old acceptance criteria you stuff into the context, the less obvious it becomes which parts are instructions and which parts are artifacts.
I would not call this prompt injection in the security sense. Nobody is trying to attack the model. It is closer to self-inflicted instruction drift. The context contains old design intent, current implementation, half-valid examples, generated plans from three sessions ago, and maybe a stale software design document that still describes classes that no longer exist. At that point, the model is not reading one spec, it’s averaging across competing sources of truth.
That is when over-specification stops helping and starts confusing the model. The agent can no longer tell whether a paragraph is an active requirement, a historical note, or something the code has already replaced.
A design document is useful early because the code does not exist yet. Later, it needs to shrink. Once interfaces, tests, and invariants are real, the detailed build plan should start disappearing. “Keep the parts” code is bad at expressing on its own: business rationale, non-goals, safety constraints, external contracts, and the few invariants you do not want rediscovered by trial and error. Delete the prose that just restates what classes and methods already do.
Otherwise, you end up with two specs. Humans will complain about that in review. Agents will often try to obey both.
APIs can make code behave like spec
There is also a more optimistic version of this story. Some codebases reach the “code is the spec” point faster than others, and API design is a big reason why.
If an internal API hides behavior behind conventions, weakly typed parameters, setup magic, and generic errors, an agent cannot treat the code as the spec. It has to reconstruct the rules from scattered prose and trial and error. That is slow for humans and worse for models.
The opposite is also true. An API with explicit names, task-level methods, strong types, readable validation, useful examples, and actionable errors gives the agent something concrete to stand on. If the agent can inspect the surface area, see what a method does, understand what input is legal, and recover from errors without guessing, then the code carries much more of the specification load by itself.
This is where the AI-friendly API design ideas matter in practice. Explicit discoverability beats convention. Methods should line up with real tasks instead of forcing the agent through a dozen fragile steps. Types and validation should show what legal input looks like. Error messages should point to the next fix, not just announce failure. Introspection and examples help the model learn the shape of the API from the codebase it already has. Performance transparency matters too, because an agent will happily write a correct and terrible loop around an expensive call if the API gives it no clue.
This is not only about public SDKs. It applies to internal service boundaries, library clients, repository abstractions, and even the helper classes in a large monorepo. The easier an API is to discover and inspect, the easier it is for an agent to treat the code as the authoritative spec instead of dragging more prose into the context. I have written about all this before in more depth if you are interested.
Where to invest
What I strongly believe is that there is no single right amount of specification. The answer depends on the kind of work you are doing. For a small, well-bounded task, the sweet spot is usually structured intent: the goal, a few examples, non-goals, and clear acceptance criteria. That is often enough to keep the agent productive without making setup heavier than the task.
For deterministic work such as CRUD flows, API integrations, and data transformations, the optimum moves to the right. These domains are easy to constrain and easy to test. More specification pays for itself quickly because it cuts repeated review and rework. This is where BDD, contract tests, and executable acceptance criteria help most.
For exploratory work such as architecture options, research synthesis, or novel product ideas, the optimum moves left again. Over-specification can kill the very flexibility that makes the agent useful. In that case, I would rather specify boundaries than outcomes: what must be true, what must not happen, what evidence is required, and which decisions still need a human.
For multi-agent pipelines, the optimum moves right once more. Every boundary between agents needs a contract. Without that, you are not coordinating a system. You are stacking interpretations and hoping they cancel out.
There is no universal optimum. The right amount of spec depends on whether the work is exploratory, bounded, deterministic, or multi-agent.
The common rule across all four cases is simple: validate the spec before you scale the implementation.
What survives from Agile and XP
I do not think agents make Agile or XP irrelevant. They make the useful parts easier to separate from the parts people were already tolerating.
The first casualty is the ceremony that existed mostly to coordinate human effort hour by hour. Daily status meetings, inflated backlog rituals, and estimates presented with more confidence than information do not get stronger because an agent wrote the code. If anything, they get weaker. Agents can change the shape of a task so quickly that old effort estimates become fiction even faster than before. That does not mean planning disappears. It means planning has to stop pretending it can predict implementation cost with the same comfort it had when code was the slow part.
What survives from Agile is the feedback logic. Short cycles still matter. Thin vertical slices still matter. Customer or stakeholder review still matters. Working software is still better than progress theater because agents can generate a lot of convincing wrongness very quickly. In fact, I would argue that fast feedback matters more now, not less. If a team can go from vague idea to large implementation in a morning, it also needs a way to discover by lunchtime that the idea was wrong.
XP survives even better because it was always about keeping learning close to the code. Test-first thinking still matters because executable checks get more valuable as implementation gets cheaper. Continuous integration still matters because every agent change needs a gate. Refactoring still matters because agents can happily produce code that works, passes a few tests, and still leaves you with a structure nobody wants to maintain next month. The machine has no pride here. It will generate a mess with perfect confidence.
Pair programming changes shape, but the core idea survives. I still want design judgment close to code generation. Sometimes that looks like a human working directly with one coding agent. Sometimes it looks like one model generating code while another model reviews it with a narrower brief. Either way, the useful part of pairing was never two keyboards in harmony next to each other over a coffee with their humans. It was fast design feedback before the code settled into place.
Small releases also survive, maybe for a less romantic reason. When agents can make very large changes cheaply, the temptation is to accept very large diffs cheaply too. That is a bad idea. Review, rollback, and diagnosis are easier done in small batches. A short-lived feature branch is easier to reason about than a 4,000-line monster.
What fades is methodology as reassurance. What survives is methodology as error detection. Agile and XP were at their best when they made it cheaper to discover that the team understood the problem badly. That is still the job. The agent era just removes a few excuses and adds new ways to be wrong at high speed.
The real leverage
The promise of agentic development is real. Agents can make implementation dramatically cheaper, but once code gets cheap, specification and verification become the place where projects succeed or fail.
The teams that get the most leverage will not be the teams that specify the least. They will be the teams that know when three bullets are enough, when they need a real contract, and when the contract has to become executable.
The agents are getting better. The decisions are still ours.
Welcome to the PhpStorm 2026.2 release overview. This version advances PhpStorm as a platform for your preferred coding agents, models, and AI subscriptions, improves PHP and Laravel support, and delivers productivity gains for working with Git repositories, databases, and the built-in terminal.
PhpStorm 2026.2 adds native support for more third-party AI providers and gives coding agents even greater access to the IDE’s deterministic features.
Agents skills manager
AI agents are only as useful as the context they have. When they don’t have knowledge of your frameworks, conventions, and tooling, you end up re-explaining the same setup in every new chat window.
Agent skills fix that. Install them once in PhpStorm, and your agents carry that domain knowledge across every project and session – automatically. Browse and manage skills directly from the IDE, expand the built-in library with external registries like public GitHub repositories, or let PhpStorm import skills you’ve already set up for Claude Code or Codex.
Support for third-party providers in AI-based code completion
AI сompletion is an in-editor code suggestion experience that combines inline completion and next edit suggestions that go beyond the cursor. Available to all JetBrains AI users out of the box, it’s powered by JetBrains-trained models and doesn’t use up your AI credits.
With the latest update, you can now connect your own OpenAI-compatible model providers for AI completion.
GitHub Copilot in PhpStorm
Built through a direct partnership between JetBrains and Microsoft, GitHub Copilot is now a natively integrated agent in JetBrains IDEs. Unlike in the previous ACP Registry setup, Copilot is available out of the box and provides a more cohesive experience.
You can access Copilot directly from the agent picker in the AI chat. Authentication is handled through OAuth with your GitHub account, and an active GitHub Copilot subscription is required.
Faster PhpStorm MCP server setup for terminal AI sessions
To help you get more out of AI agent workflows in the terminal, the IDE can now prompt you to configure the PhpStorm MCP server when starting a new session with your preferred coding agent. If no MCP server is configured, a notification appears automatically and takes you directly to the relevant settings.
PHP
#[FileReference] attribute for persistent file references
PhpStorm now lets you mark string literals as file or directory paths using the #[FileReference] attribute on parameters in functions, methods, and constructors. When a path is passed as a string to such a parameter, it gets first-class PhpStorm support for navigation and refactoring.
Annotated file references apply project-wide and persist across IDE restarts, making them a better alternative to manual reference injections. In addition to simple references, PhpStorm supports relative paths defined with basePath, as well as paths constructed dynamically or using variables and constants.
Trigger options for code quality tools
To further optimize the IDE’s performance, PhpStorm now allows you to configure how often third-party code quality tools like PHPStan or Laravel Pint are triggered: on the fly as you type, on idle, or on file save. You can set the Run mode setting in Settings | PHP | Quality Tools | {quality_tool_name}.
Additional language support improvements include:
Support for PER Coding Style 3.0. To configure PhpStorm’s built-in PHP formatter to use the PER Coding Style 3.0 specification on code reformatting actions, go to Settings | Editor | Code Style | PHP | Set from… and select PER-CS 3.0.0 from the list.
Arrow autocompletion after object variables. The new setting is enabled by default. To disable it, go to Settings | Editor | General | Smart Keys | PHP.
Code completion for nested arrays without explicit keys in #[ArrayShape].
Laravel
Laravel tool window
The new Laravel tool window lets you manage Laravel projects without leaving PhpStorm. Use the Dashboard tab for general project information and quick access to Artisan commands, the Errors tab to browse local or Sentry-hosted log files and explore or fix errors with AI without copy-pasting logs, and the Laravel Cloud tab to manage deployments and env variables.
Other improvements for Laravel developers include:
Support for laravel/passport and stancl/tenancy packages.
Support for PHP 8.5’s pipe operator.
ide.json options for pointing to database schema files, explicit mapping of Eloquent model classes to database tables, custom paths to Laravel Livewire locations, and new viteAsset, passportScopeId, and staticStrings (with file links) completion types.
If your TypeScript project has grown to the point where completion lags and refactorings feel sluggish, TypeScript 7 is the fix. Microsoft rewrote the compiler and language server in Go, making type-checking up to 4x faster while delivering more responsive code completion and snappier refactorings even in the large codebases.
PhpStorm 2026.2 supports TypeScript 7 as the default for projects already using it, with an opt-in upgrade path for those still on earlier versions. You get the full speed benefit immediately – no full project migration required on day one.
Version control
Enhanced Git worktree support
Version 2026.2 simplifies the management of Git worktrees in various development environments, such as WSL. Additionally, you can easily remove and clean up worktrees directly from the IDE.
These updates help streamline day-to-day worktree management while reducing the need to switch to external Git tooling.
Streamlined Git conflict resolution flow
In large projects, merges often result in dozens of file conflicts, many of which are simple import mismatches or formatting differences. PhpStorm 2026.2 improves the conflict resolution flow, allowing you to invoke the Resolve All Simple Conflicts action, which automatically resolves standard conflicts across the entire changeset instantly, instead of having to open each file one by one. With the new flow, you can also see a complete overview of resolved and unresolved files, reopen files at any time, and revert and reapply conflict chunks in any order.
Username autocompletion in code reviews
Mentioning teammates in code review comments is now easier. Simply type @ in a comment to open a list of users from the current GitHub or GitLab repository and select the person you want to mention.
Terminal
Easier file and image sharing in terminal sessions
No more copying and pasting paths from your project or external applications when working in the terminal or with CLI agents. You can now drag and drop a file or folder directly into the terminal to insert its path into the current command.
To quickly start working from a specific location, drop a file or folder onto the terminal tab area to open a new tab with its root path already set.
You can now also paste images directly from the clipboard into supported CLI agent sessions, which makes it easier to share visual information with your agent.
UI
Non-modal Settings dialog
When the Settings dialog is open, you no longer have to close it to interact with the IDE window. This makes it easy to copy project paths to set up scopes, insert values from configuration files into the settings, view code appearance adjustments immediately, or even switch to another project in the middle of the configuration process.
By default, the Settings window stays visible above the project where it was invoked. Unpin it to send it to the background.
Databases
Redesigned empty state: A faster way to begin projects
To streamline your initial setup and provide a ready-to-code experience right from the start, we’ve redesigned the empty state in the Database Explorer tool window. When you open a new project, the tool window now displays quick actions for creating data sources.
Additionally, to help you familiarize yourself with basic database features without the distraction of configuration steps, the empty state provides one-click access to PostgreSQL, MySQL, and SQLite demo databases from our Quick Start Guide.
Custom query console names: More context at a glance
You can now customize how query console names are displayed in editor tab headers, making it easier to identify open consoles and files.
Previously, only the data source name was displayed next to the file name. Now, you can use variables to include additional details such as the attached data source, database, schema, or search path. To configure the template, go to Settings | Database | Query Filesand Consoles, place the caret in the Template field, and insert the variables you need.
You can also apply the same template to query files by enabling Use this template for query files.
Database colors: v2.0
The database color system offers a refreshed, more consistent user experience and several usability improvements. This release introduces an adaptive color engine alongside several structural usability improvements:
Theme-aware custom colors. Previously, static #RRGGBB hex codes remained identical across light and dark themes, ofte1n destroying visual contrast when you switched. Now you only need to choose a hue, and the IDE automatically adjusts the shades for the active theme.
Folder color support. You can now apply custom colors to folders as well as individual database objects.
Easier access to color settings. The color submenu has been moved up a level to make it easier to find, and all color settings are now available directly in the main Settings window instead of a separate dialog.
Performance
As announced in the 2026.2 EAP blog post, PhpStorm 2026.2 focuses heavily on the overall IDE stability and performance. While not yet showing immediate results beyond an up to 10%* faster project indexing time, the latest changes lay the foundation for reduced startup time, indexing time, and freezes for both local and remote development scenarios in upcoming releases.
Share your feedback about performance in PhpStorm by taking this survey.
*Benchmarked on a pool of projects representing different PHP frameworks
Cloud
Docker Compose statuses right in the editor
Docker Compose files are now more informative and interactive. You can view the status of running containers directly inside your Docker Compose file and quickly access common actions without leaving the editor.
With the ability to jump straight to logs for a specific service, create a database connection, or open a service in your browser directly from the corresponding entry in the Compose file, it is easier to monitor and work with your application stack.
Faster Docker Compose setup with service templates
Creating dependent services in Docker Compose is now easier with ready-to-use templates for popular technologies such as PostgreSQL and Kafka.
Simply start typing the name of a service or select one from the completion list, and the IDE will generate the corresponding Docker Compose configuration for you. This helps you get common services up and running faster while reducing manual configuration work.
Terraform testing framework support
Version 2026.2 extends the IDE’s support for Terraform infrastructure-as-code capabilities by introducing native support for the Terraform test framework. This integration rounds out the IDE’s ecosystem support, allowing you to validate module behavior and enforce configuration policies early in the development lifecycle.
These additions build on out-of-the-box infrastructure tooling, ensuring your deployment configurations remain highly maintainable, predictable, and clean.
Last year, the most powerful people in technology told you, in plain language, that AI was coming for your job. Whole categories of work, gone. This year, quietly, those same companies started hiring again.
Amazon cut about 16,000 people, leaned hard into the story that AI was making it lean and efficient, and then turned around and opened 11,000 new roles for juniors and interns. The executive running its cloud business explained why he wanted all that young, green talent in the building: they come in with an energy and an excitement, a new view on things.
So which is it? Was this the robot apocalypse we were all promised, or was that always a story somebody was selling you? Both of those cannot be true at once.
I want to be useful to one person in particular here. If you run a business, or you’re about to, the whiplash is not just gossip about billionaires. The swing from everyone-is-getting-replaced to wait-we’re-hiring-again is about to cost you real money if you believe either version. I’ve spent 30 years building things, and I use these AI tools every single day. What actually happened is more interesting than either headline.
This is Part 1 of a three-part look at the AI jobs story: what’s happening, whether it was ever real, and what you should actually do about it.
The failures are real
Start with the failures, because they earned the mockery. Klarna, the buy-now-pay-later company, proudly handed something like 700 customer-service jobs to an AI chatbot. Efficiency, they said. Then satisfaction fell off a cliff, the answers came back wrong or cold, and Klarna quietly started hiring humans back into a blended model, where a real person is reachable again when the bot gets stuck.
Duolingo announced to the world that it was now “AI first” and would lean less on human contractors. The internet did not take that well. A few weeks later the public tone had shifted to, more or less, wait, please come back. IBM, Tesla’s robot-heavy factories, the fast-food drive-throughs that put bacon on a stranger’s ice cream. The same arc, over and over.
And once you’ve seen it enough times, you notice every one of these failures has the same shape. The AI walks in and genuinely does a big chunk of the job. Call it 60%: the repeatable, predictable part. Then it hits the other 40% and faceplants. Because that 40% was never the typing. It was judgment. Knowing this customer is furious and needs a manager. Knowing this invoice looks wrong even though the math adds up.
But was it ever really AI?
This is where the tidy story, the one where AI simply failed and everyone learned a lesson, starts to fall apart. There’s a bigger question underneath, and it’s uncomfortable: was it ever really about AI at all?
Rewind to 2020 and 2021. Money was nearly free, all of us were locked inside buying everything through a screen, and the tech giants hired like the party would never end. They massively over-hired. Then the world reopened, interest rates climbed, and all those extra salaries suddenly looked expensive. The layoffs that followed were, in large part, the hangover from that binge. They were coming with or without a chatbot.
So picture a CEO with two ways to explain the same 10,000 job cuts. Version one: we hired badly, we got over our skis, and now we’re cleaning up our own mess. Version two: we are riding an AI wave so powerful that we simply don’t need as many people anymore. The first tanks your stock. The second pumps it. Guess which label they reached for. Meanwhile the actual unemployment rate barely moved, from about 3.9% to 4.3%.
Watch what these companies do, not what they say. The same Amazon that framed its cuts around AI efficiency was, in that same stretch, bringing in thousands of engineers on work visas and hiring 11,000 juniors. If the machines were really doing the work, you would not need to import thousands of engineers and grow your entry-level ranks at the same time. The full forensic case for all of that is its own piece, and it’s the next one. For today, sit with this: AI was often the most flattering explanation available for a decision the company had already made.
The pivot: the same people walk it back
Then came the part that made me sit up. The very same people who spent last year warning that AI was about to flatten the workforce have, over the last few months, quietly changed their tune. Almost in unison. And the timing tells you everything.
Sam Altman, who runs OpenAI, spent a year warning that whole job categories would vanish. Recently he said he was “delighted to be wrong.” Dario Amodei, who runs Anthropic, had said as much as half of all entry-level white-collar jobs could disappear, with unemployment as high as 20%. He’s been softening that into a sunnier story about AI making everyone more productive. Elon Musk went from AI will hit jobs like lightning to, barely paraphrasing, work will soon be optional, like growing your own vegetables for fun.
So why the sudden group hug? Follow the money. Last year, doom was the product. If your AI is so powerful it could end civilization, it’s certainly powerful enough to justify a subscription and a valuation with a lot of zeros. Fear sold the software and floated the private money. But now these same companies are lining up to go public. Anthropic just filed the confidential paperwork for a stock offering.
And selling stock to the public changes the math. As one PR strategist put it, you can’t go to the public market selling societal collapse. Nobody lines up to buy shares in the apocalypse. So the story had to flip. Doom raised the private money. Optimism sells the public offering. The narrative didn’t change because the facts changed. It changed because what these people needed to sell you changed.
P.T. Barnum with a server farm
Here’s a simple test I now run on every one of these announcements, and I’d hand it to you to keep. Ask one question: who benefits if I believe this? If the answer is the company making the claim, slow down. If the answer is a company with a stock offering six months away, slow all the way down. That one question would have saved a lot of people a lot of grief, in both directions, this whole cycle.
None of this is new. We’ve just never seen it run at this scale. This is P.T. Barnum with a server farm. The same showmanship that packed circus tents a hundred years ago, the grand claim you can’t check until it’s too late to matter, now wrapped around a genuinely useful technology and pointed first at your fears and then, when convenient, at your hopes. The tool is real. The show around it is a performance.
Tasks, not jobs
Strip the show away, and the truth is boring and useful. AI is genuinely good at tasks. It is not replacing jobs. Those are completely different things. A job is a bundle of tasks, plus judgment, plus context, plus relationships. AI can take a real bite out of the tasks. It falls apart on the rest. That’s the 60/40 split, and it’s the whole lesson, hiding under a year of noise.
The leftover 40%, the judgment and the context, is almost always the exact thing you were paying that person for. It’s the veteran who knows which client disputes every invoice and which vendor always ships late in December. You can’t download that. Ford learned it the expensive way: it replaced experienced engineers with AI, became the most-recalled carmaker in America, then quietly hired about 350 of those veterans back. Same lesson, at company scale.
And Ford isn’t a fluke. Robert Half found that nearly a third of companies that cut jobs for AI have already rehired for the same roles. Gartner expects at least half of them to by 2027. A separate survey found that 55% of the executives who replaced people with AI already regret it. That’s not a technology failing. It’s a story failing, and the bill for believing it coming due.
What it means for you
For you, the person actually running something, it comes down to this. Don’t run your business on Silicon Valley’s mood swings. Last year’s panic and this year’s relief were both performances, staged by people whose incentives have nothing to do with your shop. The doom was never your operating plan, and neither is the walk-back. Your operating plan is your own numbers, and the plain reality of what this tool can and cannot do at your desk.
The rule, in one line: Hand the machine the bounded, repeatable task. Keep a human on anything that needs judgment, real context, or a relationship. Augment your people; don’t try to replace them.
The test, for any announcement: Who benefits if I believe this? If it’s the company making the claim, slow down. If it’s a company with a stock offering six months away, slow all the way down.
How to actually decide which task goes where, one by one, without setting fire to a pile of money finding out the hard way, is its own piece, and it’s coming later in this series. The deeper reason the replacement bet keeps failing is worth saying plainly, though: the thing that makes your best people valuable was never the part a machine could copy. It’s the context they carry in their heads, built up over years, that isn’t written down anywhere. A model will hand you a competent first draft of almost anything in seconds. What it can’t hand you is whether that draft is right for your situation, because it has never once been in your situation.
The short version
The AI layoff story swung hard in one direction and is now swinging hard back, and both swings were sold to you by people with something to sell. The real data barely moved. The cuts were mostly an over-hiring correction in an AI costume. Every “backfire” proves the same rule: AI replaces tasks, not jobs, and the part it can’t do is the part you were paying for. Read your own numbers, not the narrative.
The Angular ecosystem is moving incredibly fast, bringing together fully reactive architectures, smart AI agents, and robust state management. Whether you’re starting from scratch or optimizing enterprise applications, our community has you covered with exceptional resources this week!
Dive into these latest expert-led contributions:
Modern Angular from Scratch (French)
Modeste Assiongbon (@rblmdst) has launched an extensive, practical step-by-step tutorial series designed to help the French-speaking community master Modern Angular (v19+) completely from zero.
Johannes Hoppe (@johanneshoppe) explores how to integrate Claude Code into your development pipeline. Learn how this specialized command-line AI agent acts as a powerful companion for both seasoned developers and newcomers.
Arcadio Quintero (@oidacra) introduces a game-changing plugin for managing SignalStore events. Discover how to handle side effects cleanly and pass explicit event signals directly into your application state.
Sonu Kapoor (@SonuKapoor1978) breaks down how to detect and debug reactive failures. This guide shows you how to implement Signal-driven error monitoring to catch bugs gracefully across your asynchronous streams.
Angular v21 Signal Forms: FocusBoundControl (French)
Modeste Assiongbon (@rblmdst) delivers a targeted tutorial focusing on form accessibility and user experience, walking through how to seamlessly pass focus to a form control using the new FocusBoundControl primitive.
Fabio Biondi (@biondifabio) breaks down how Angular is achieving peak performance through unified reactivity. Explore this high-efficiency architectural blueprint connecting the Router to Resources and Signal Forms.
Fabio Biondi (@biondifabio) also delivers a crucial breakdown on setting up an Angular 21 project with Server-Side Rendering. Learn the distinct architectural differences between runtime Server rendering and build-time PreRender generation.
Log in
