Developments in Software: What Changed and What Matters

Key Points

• Your developers are likely already using AI tools whether you’ve sanctioned them or not, so your policy decision is about process design. Permission is already decided.
• The 2025 DORA report links AI adoption to higher delivery throughput and higher instability at the same time. The constraint moved into review, testing, and QA.
• If your team is still debating whether to containerize, that meeting is about organizational readiness rather than technology at this point.
• Your codebase likely carries around 581 vulnerabilities on average and your team probably did not write most of the code containing them.

What Is Modern Software Development?

Modern software development is the practice of building and shipping software through automated, continuously deployed pipelines onto elastic cloud infrastructure. AI assists in the authoring loop, and security checks run throughout rather than only before release. Modern development goes further than Agile. Agile changed how teams plan and decide; modern development changed the mechanics of how a change reaches production and how quickly it can be reversed.

The four developments below all work the same way. Each delivered on its promise and moved the slow part somewhere else. Engineering leaders who plan for today’s bottleneck get the benefit; those who plan for last year’s bottleneck get the instability and none of the throughput.

The Four Developments in Software That Actually Changed the Work

Most software development trends collapse under a delivery schedule. These four held. They changed the daily mechanics of the software development industry enough that an engineering leader has to plan around them.

AI tools moved from experiment to default

The adoption argument is over. Stack Overflow’s 2025 survey found 84% of developers using or planning to use AI tools, and generative AI tools are now part of the default software development process. DORA’s 2025 report found 90% of respondents using AI in their work.

Adoption outpaced confidence. In that same Stack Overflow survey, fewer than a third of developers said they actually trust the accuracy of what these tools produce. The skeptics outnumber the believers, with output quality the primary driver.

Even with the widespread doubt, most teams are standardizing on AI-assisted development. The top frustration developers reported was output that is “almost right, but not quite” at 66%, which is the failure mode I watch for, because it survives a weak code review or PR validation and reaches production intact.

Cloud native development stopped being a decision

The CNCF 2025 annual survey recorded 82% of container users running Kubernetes in production, up from 80% the year before. Nearly every surveyed organization reported adopting cloud native techniques in some form.

At those numbers, cloud computing and container orchestration are no longer a strategy. They are a floor. If you’re still holding an architecture review about whether to containerize, the meeting is about organizational readiness at this point. Legacy systems complicate the timeline. The decision itself is settled.

Platform engineering became the team’s product

CNCF’s own read on its survey is that the next wave of value depends on platform engineering, on cultural adoption, and on evolving security and observability practice. That lines up with what the tooling numbers imply. Once every team can deploy independently, deployment stops being the expensive problem. The replacement was the fifty slightly different ways your teams now deploy.

Platform engineering is the response: treat the internal delivery platform as a product with users, a roadmap, and adoption metrics rather than as a shared services backlog. The distinction I care about is voluntary adoption. Platform adoption driven by policy produces compliance. Adoption driven by speed produces a product.

Dependency reuse moved the attack surface

Most of the code in your product is code your team did not write, and the risk inside it doubled last year. Black Duck’s 2026 analysis puts the mean at 581 vulnerabilities per codebase, more than double the year before, and attributes the jump in part to AI-assisted development velocity. More than nine in ten of those codebases carry a component over four years out of date.

Supply chain attacks found their easiest targets in exactly those dependencies, the ones nobody maintains any more and the ones pinned to an old version in your build. Verizon’s 2026 Data Breach Investigations Report found third parties involved in 48% of breaches. Shipping secure software now means proving what’s inside it, and the standard for doing that is settled. Enter the Software Bill of Materials (SBOM). CISA published its 2026 minimum elements in July 2026, co-authored with federal agencies and international partners. The update added component hash, component license, generation tool, and generation context to the 2021 baseline.

Which makes the inventory the easy part. Keeping it current isn’t, and that gap is where the attack surface actually sits. The AI finding and the dependency finding compound each other, and that interaction tends to get missed. More code, authored faster, by a tool fewer than a third of developers trust, landing in a dependency graph of that size. Black Duck found only a quarter of organizations review AI-generated code for license and quality as well as security.

How Does Modern Software Development Differ From Traditional?

The differences are easier to see side by side than in prose.

The right column delivers value when the surrounding practice supports it.

Why Did Faster Delivery Make Systems Less Stable?

Faster delivery made systems less stable because AI accelerated authoring while review and testing stayed bound to the same engineers doing that work. If the AI spend has not shown up in your reliability numbers yet, this is why.

DORA’s 2025 report found, for the first time, a positive relationship between AI adoption and software delivery throughput. Faster software development is real and now measurable. In the same report, AI adoption continued to correlate with higher instability: more change failures, more rework, longer time to resolve.

Speed up, stability down, same report. Those two findings are consistent. Speeding up the fast part of a pipeline lengthens the queue in front of the slow part.

I watched this happen across engagements over the last twelve months, and the pattern held regardless of tech stack or team composition. Pull requests per sprint increased substantially across those engagements. Review capacity didn’t. Queue depth was what made it visible. What pulled it back was better specs going in, DAST and SAST running on the way through, real test suites instead of the shallow unit tests the tools default to, and pull requests scoped small enough to review properly. That combination reduced churn and the number of PRs denied after validation.

DORA’s framing is that AI is an amplifier rather than a fix. Strong teams get stronger. Struggling teams get their existing problems intensified, faster.

The teams I’ve seen come out of this well built the verification habits before they scaled AI usage, not after.

How Are Teams Actually Using These Developments?

Those four developments show up in practice as six distinct patterns, worth separating because they demand different investments and fail in different ways.

AI-assisted development with explicit guardrails

The teams getting throughput without the instability tax aren’t using AI differently. They’re reviewing differently. Generated code enters the same pipeline as written code and clears the same gates, with review effort weighted toward code quality risks like the “almost right” failure mode rather than obvious errors. The practical shape of this is a review checklist that asks different questions of generated code: does this handle the error path, does this dependency exist, is this API signature current. Those are the three places “almost right” tends to live.

Cloud native development as the substrate

Cloud native development puts containers and orchestration underneath, with the consequential decisions now about what runs on top. Treating cloud services as the default is now the conservative position rather than the aggressive one. The organizations still getting value out of this are the ones using elasticity deliberately, matching capacity to demand.

Platform engineering as a product

Platform engineering in practice means a small team, real users, and adoption measured rather than assumed. Golden paths are the usual delivery mechanism: an opinionated, supported route to production that covers the 80% case, with an explicit escape hatch for the rest. Platforms that forbid the escape hatch are bypassed.

DevSecOps focused on dependencies

DevSecOps treats scanning, SBOM generation, and update discipline as delivery work rather than audit work. With that many components and that much staleness, the update backlog is the security program. The organizations doing this well have made dependency updates a scheduled, automated, low-drama event rather than a quarterly fire drill. The limiting factor is test confidence: teams that cannot verify updates automatically are the ones running the quarterly fire drill.

Intelligent automation and automated code reviews

CI/CD automated the build and deploy stages of the software development lifecycle. What got automated next? test selection based on what actually changed, automated code reviews, and dependency upgrade pull requests raised and verified without a person opening an editor.

That automation splits in two. Before merge it belongs to the developer’s loop: scoped pull requests, static analysis and enough specification that generated code has something to be wrong against. After merge it belongs to the pipeline, which is where dynamic analysis, integration coverage, and fast feedback live.

One caution on the review half. Static analysis is a volume filter. A linter has no model of what the code was meant to do, so it cannot catch the ‘almost right’ failure mode. The tools that read a diff and reason about intent are aimed at exactly that, and I would run them on a different model than the one that wrote the code. A model grading its own output tends to confirm it.

This is the category that directly attacks the bottleneck DORA identified, which is why I would fund it first.

Modern delivery practices that make rollback boring

Progressive rollout, feature flags, and canary releases decouple deploying code from releasing behavior. Why does that matter? It makes a higher change failure rate survivable. If a bad change reaches 2% of traffic and reverts in ninety seconds, the failure rate matters far less than if it reaches everyone and requires a hotfix. Given that AI adoption correlates with more change failures, this is the cheapest insurance available.

Choosing among these patterns is usually a capacity problem. Platform engineering in particular asks for a dedicated team, and most engineering organizations in the 200 to 5,000 person range do not have one available. That’s the point where the build-versus-extend question gets real, and where bringing in a nearshore engineering partner becomes a genuine option rather than a cost play. Extending the team to staff a platform group is a different decision from engaging a nearshore engineering partner for custom software development, and it should be evaluated differently.

The Trade-offs Nobody Puts in the Slide Deck

Every item above carries a cost. A pitch is an argument for a yes, and the cost is the part that argues against it.

The AI trade: authoring time for review load

The trade only works if you have review capacity to spend. If your senior engineers are already the constraint, routing more code through them deepens it, and the DORA instability finding is what that looks like in the metrics. The teams who benefit most are the ones with the deepest review bench. Teams that most need the productivity boost tend to have the shallowest review capacity.

The cloud native trade: elasticity for operational surface

You now run a scheduler, a service mesh, an ingress layer, and an observability stack doing continuous monitoring, all of which need upgrading. Small teams frequently discover that the platform consumed the headcount it was meant to free up.

The platform trade: only worth the cost above a certain number of development teams

Below a certain number of delivery teams, a platform group becomes an expensive layer of indirection between developers and infrastructure they were managing adequately without it. I would want at least five or six teams hitting the same problems before funding a dedicated platform team, and evidence they’re actually the same problems.

The security trade: work that never finishes

You traded writing the code for maintaining someone else’s, forever. There is no state in which that graph is finished, so the goal worth setting is a cadence you can sustain. Zero findings is not a realistic target. Promise a board zero findings and you will lose the program in year two.

I would summarize all four the same way: each shifts effort rather than removing it. That’s still worth doing. It is only worth doing knowingly.

What Should You Do About It?

This section avoids a maturity model. Every one of those tends to justify advanced-tier spending while foundational capabilities remain broken. Concrete things, in the order I would do them.

1. Measure your change failure rate before you scale AI usage. DORA’s instability finding only matters if you can see it. If you cannot answer what percentage of your changes cause a degradation today, you will not notice the number climb.
2. Put the investment into review and test, not authoring. The queue formed downstream of the tool you already bought. Automated code reviews and faster test feedback shorten the queue downstream of the authoring tool.
3. Generate an SBOM and read it once. Treat it as a list of what’s actually in your product, not a compliance artifact. The component count tends to be a surprise the first time. Then ask the harder question: how much of that surface could you actually update this quarter if you had to?
4. Set an explicit policy for AI-generated code review. Write a rule specifying what gets extra scrutiny. ‘Use good judgment’ is not a policy.
5. If you’re considering a platform team, define what it means for it to fail. Voluntary adoption is a measurable outcome. Write the target down before you staff it.

None of these require new software development tools. Four of the five are policy and measurement. That is usually a sign the constraint is organizational rather than technical.

Key Takeaways

• Budget your next reliability investment against your current delivery rate, not last year’s. The delivery rate changed and the review capacity did not.
• Spend the AI budget on what happens after the code is written. Tool selection is close to a solved problem; review capacity is not.
• Audit whether your platform work is a product or a mandate before you fund more of it. If teams would abandon it tomorrow, you’re paying for compliance, not a working product.
• Put dependency updates on a schedule this quarter. Prioritize cadence first, findings second. The inventory is the easy half and you likely already have it.
• If I could ask for two numbers at your next review, they would be change failure rate and time to restore. Every decision above gets easier once those two numbers exist.