The Agentic Shift: How AI Is Changing Software and the Future of Work

We keep asking whether AI will replace developers.

I think there’s a more useful question: what becomes valuable when software gets easier to build?

Writing code is only part of the answer. The bigger story involves how teams work, what clients pay for, and who takes responsibility when something goes wrong.

For freelancers, founders, and software teams, that’s the shift worth paying attention to.

From suggesting code to taking on tasks

There’s an important difference between an AI tool that suggests your next line of code and an agent that can work through a task.

Instead of asking, “How do I fix this bug?” you can assign a goal: “Investigate the bug, implement a fix, and test the result.”

In a February 2026 engineering account, OpenAI described a Codex workflow where agents could reproduce bugs, change code, validate fixes, and open pull requests. Crucially, this happened inside an environment deliberately built to support that work.

That last detail matters.

Useful autonomy depends on clear instructions, accessible documentation, appropriate tools, and reliable checks. Anthropic’s guidance also makes an important distinction: some jobs benefit from flexible agents, while others are better served by simpler, predictable workflows.

My takeaway is that learning to delegate well is becoming part of learning to build well. The work includes defining the goal, setting boundaries, and deciding whether the result is good enough.

The developer’s value is changing

I’m skeptical of tidy predictions that junior developers will suddenly outperform everyone, mid-level roles will disappear, and senior engineers will just supervise agents.

The evidence is more interesting than that.

A study covering 4,867 developers across three company experiments found that access to an AI coding assistant increased completed tasks by about 26% in the combined analysis. Less experienced developers showed higher adoption and larger productivity gains. The results also varied across the experiments.

That is encouraging. It does not prove that a new developer becomes equivalent to an experienced engineer within weeks.

Producing code and understanding a system are different capabilities.

My practical takeaway is to use AI to expand what you can do without skipping the learning that helps you judge its work. Ask why an approach works. Inspect the changes. Understand the tradeoffs.

Clear specifications matter too. Being able to explain the intended behavior, constraints, and failure cases is a technical skill, not just a prompting trick.

The goal should be greater capability, not greater dependence.

Faster development is real, but context matters

The productivity gains are worth taking seriously. So are the conditions behind them.

In its 2023 study, McKinsey found that developers could document code in roughly half the time, write new code in nearly half the time, and refactor existing code in about two-thirds of the time. Savings were much smaller on highly complex tasks.

Those are meaningful improvements. They are not a universal promise that every project will ship dramatically faster.

Measuring the impact is difficult, too. In February 2026, METR reported that selection effects and measurement challenges made its newer developer-productivity results an unreliable estimate of the current overall benefit.

For a team or an independent builder, I’d focus on practical questions.

Are we delivering useful features sooner? Are we creating fewer defects? Is the finished product easier to maintain? How much review and rework does it need?

The same thinking applies to technical debt. AI can help explain unfamiliar code and accelerate refactoring, but that is different from proving that a rewritten system preserves the behavior a business depends on.

A faster first draft is valuable. A reliable release is the outcome that matters.

The economics are shifting toward outcomes

If routine implementation becomes cheaper, businesses need a stronger reason to choose one provider over another.

My view is that this puts more weight on domain knowledge, thoughtful design, useful integrations, and trust.

Proprietary data can be part of that advantage, but I wouldn’t treat ownership alone as a guarantee. The important question is whether the data helps solve a problem better.

Pricing offers a concrete example of this broader shift.

Intercom’s Fin uses outcome-based billing, with billable outcomes including defined resolutions and certain completed workflows. That ties part of the price to what the agent accomplishes, rather than access alone.

At the same time, more automation does not automatically mean lower operating costs. Anthropic notes that agentic systems can trade higher cost and latency for better task performance.

For freelancers and consultants, I see an opportunity here: make the value of your work easier to understand.

Instead of presenting only the hours spent building an integration, explain what it improves. Does it reduce repetitive work? Make a handoff more reliable? Help the client respond faster?

Faster tools should make us rethink how we demonstrate value, not just how quickly we produce deliverables.

Privacy needs to be part of the design

More capable systems deserve more careful boundaries.

Synthetic data is one useful approach. It creates artificial records intended to preserve useful characteristics of the original data.

But “synthetic” does not automatically mean private.

NIST explicitly warns that many synthetic-data generation techniques do not provide formal privacy guarantees. It also explains that preserving useful statistical relationships while protecting privacy can be difficult.

That is why I’d treat privacy as an engineering requirement from the beginning.

What information does the system actually need? Who can access it? What should be retained? How will sensitive information be kept out of logs and inappropriate outputs?

Encryption, access controls, and suitable privacy techniques can contribute to the design. None should be treated as a shortcut around testing or a blanket guarantee of compliance.

A convincing demo is not enough when real people’s information is involved.

What this means for independent builders

I don’t think the opportunity is simply to become the person who generates the most code.

It is to become better at turning an unclear problem into a useful, dependable result.

Use AI to explore options, reduce repetitive work, and test ideas. Keep developing the judgment to challenge an output, explain a decision, and recognize when a system should not be given more autonomy.

We do not need to pretend the employment impact is settled to see the opportunity.

My view is simple: faster execution raises the importance of choosing the right work and taking responsibility for the result.

For those building with AI, where are you seeing the biggest change: delivery speed, the scope of projects you can take on, or what clients expect?

Sources and further reading

[1] OpenAI: Harness engineering: leveraging Codex in an agent-first world https://openai.com/index/harness-engineering/

[2] Anthropic: Building effective agents https://www.anthropic.com/engineering/building-effective-agents

[3] Cuiet al Management Science: The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers https://doi.org/10.1287/mnsc.2025.00535

[4] McKinsey: Unleashing developer productivity with generative AI https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/unleashing-developer-productivity-with-generative-ai

[5] METR: We are Changing our Developer Productivity Experiment Design https://metr.org/blog/2026-02-24-uplift-update/

[6] Intercom: Fin AI Agent outcomes https://www.intercom.com/help/en/articles/8205718-fin-ai-agent-outcomes

[7] NIST: Differentially Private Synthetic Data https://www.nist.gov/blogs/cybersecurity-insights/differentially-private-synthetic-data

Perfect