The Four Pillars of Modern Software Development in the AI Era

Harvard Business Review Analytic Services just dropped a white paper, sponsored by AWS, titled Embracing Modern Software Development Practices in the AI Era. It is a polished, executive-friendly read aimed at Fortune-1000 CIOs. It is also, quietly, one of the cleanest summaries of where engineering culture is heading in 2025 — and most of it applies just as forcefully to a fifteen-person startup as it does to AT&T.

I read it so you don't have to. Then I translated it for the only audience I really care about: founders and operators who have to ship software, hire engineers, and not run out of money before any of that pays off.

The white paper opens with a line every founder should write on their whiteboard: "In the AI era, software is the business." It is no longer a back-office cost center, a vendor dependency, or a project you ship once and forget. It is the product, the moat, the hiring magnet, and the audit trail — all at once. Which means the way you build it has to evolve.

<>Pillar 1: Speed & agility (and the death of the quarterly release)

The first pillar is the one founders already feel in their bones: ship faster, ship smaller, ship continuously. HBR cites the Continuous Delivery Foundation finding that 83% of developers are now involved in DevOps activities, up from 78% the year before. CI/CD pipelines, microservices, and Agile rituals are no longer the avant-garde — they are the floor.

The data point that should embarrass anyone still on a six-month release cadence is buried mid-paper. AT&T, with the help of a custom developer platform, now ships 60 to 70 new applications per quarter. Sixty. Per quarter. That is what "speed and agility" actually means in 2025.

The quote that nails the cultural shift comes from Saxon Burden, an AWS engineering leader: "Software is no longer just supporting the business. It is the business. That's pushing a need to be able to deliver software quickly." If you are a founder and your dev cycle is measured in months, you are not slow — you are misaligned with the entire decade.

<>What this looks like in a startup-sized org

You do not need AT&T's platform team to get here. You need three things:

1. A trunk-based git workflow with feature flags, not long-lived release branches.
2. A CI pipeline that runs in under 10 minutes and deploys to a staging URL on every PR.
3. A weekly release ritual — even if "release" just means "merge to main and let the pipeline ship it."

We see this pattern over and over with our clients at SAMO: the moment a startup stops batching changes into Friday afternoon "deploys," velocity roughly doubles within a quarter. Not because the engineers got better — because the system did.

<>Pillar 2: Improved visibility (or, how Capital Group went from 13,000 alerts a day to under 1,000)

The second pillar is the one most founders under-invest in until it is too late. HBR is blunt: as systems get more distributed, complexity is the enemy. You cannot ship faster if you cannot see what is breaking.

The case study here is gorgeous. Capital Group's Brian Landreth describes a transformation where his team went from roughly 13,000 alerts per day to under 1,000 — by deduplicating, correlating, and applying basic predictive analytics to their observability stack. Same systems, same engineers, one tenth the noise. That is not an observability win. That is a sanity win.

The HBR authors connect this directly to test automation: continuous testing is the only way to keep visibility honest as the system grows. Quote, lightly paraphrased: "automated testing across unit, integration, and end-to-end layers is no longer a luxury — it is the seatbelt that makes speed survivable."

<>Pillar 3: AI-powered automation (the 87% vs 50% chart you need to internalize)

This is the pillar everyone wants to talk about — and the one most often mishandled. HBR cites a McKinsey developer-productivity study from June 2023 that produced what is, in my view, the single most important chart of the year.

87% of developers using generative AI tools said they could focus on satisfying and meaningful work. Of developers not using those tools? 50%. The gap is 37 points. That is not a productivity gap — that is a retention gap. Engineers who feel like they are doing meaningful work stay. Engineers stuck shovelling boilerplate leave.

The white paper goes further. BCG executive Charles Bolt is quoted describing AI-assisted refactoring: "What used to take weeks now takes hours." And HBR's Hyperframework survey notes that 59% of leaders are seeing AI reduce infrastructure-operations workload — freeing senior engineers from toil and putting them back on product.

<>The trap most founders fall into

The trap is treating AI as a hiring substitute instead of a leverage multiplier. The data says the opposite: AI makes the engineers you already have more productive and more likely to stay. It does not let you skip the hiring conversation — it makes good hiring even more valuable, because every senior is now worth two.

This is why we paired up with our nearshore model on purpose. A senior LATAM engineer with Copilot, a clean CI pipeline, and a same-timezone standup will out-ship a junior US contractor on a six-month roadmap every time. We wrote more about that math in What Silicon Valley Gets Wrong About Nearshore Engineers.

<>Pillar 4: Embedded security & governance (the SBOM era is here)

The fourth pillar is the one that quietly separates companies that get acquired from companies that get breached. HBR cites the SANS Institute finding that 53% of organizations now report attack surfaces are exposed through their software supply chain. Half. That is not a fringe risk — that is the median.

The case study here comes from US Steel. Their CISO, Larry Airhart, describes embedding security gates directly into the developer workflow: approval checkpoints, automated policy enforcement, and SBOM (Software Bill of Materials) generation as a non-negotiable artifact of every release. Crucially, security is not a separate team blocking deploys. It is policy-as-code, running inside the same pipeline that ships features.

If you are a founder reading this and starting to sweat, the good news is that the modern tooling makes this far cheaper than it used to be. We walked through the practical starter kit in Zero Trust Security: The Startup Guide — it is not a six-month project. It is a weekend with the right priorities.

<>So what should a founder actually do with this?

Strip away the corporate language and HBR is telling you four things:

1. Ship continuously. If your release cadence is longer than a week, fix that first. Velocity compounds.
2. Make your system legible. Tests, traces, dashboards. You cannot improve what you cannot see.
3. Put AI in your engineers' hands — for them, not instead of them. Copilot, AI code review, AI test generation, AI alert triage. Treat it as leverage, not headcount substitution.
4. Bake security into the pipeline. SBOMs, dependency scanning, policy-as-code, approval gates. Make "secure" the default, not the override.

None of these are technology problems. They are leadership problems. They require someone in the room who has built this kind of org before and can sequence the changes so they actually stick. That is exactly the role we play — sometimes as a fractional CTO engagement, sometimes as a full nearshore pod that brings the pipeline, the tooling, and the engineers as a single package.

<>The bottom line

HBR's white paper is, on the surface, written for CIOs at companies with thousands of engineers and a procurement team. But the four pillars apply, almost verbatim, to a Series-A startup with twelve engineers and a CTO who hasn't slept properly since the seed round.

Software is the business. That is not hyperbole anymore — it is the operating assumption of every modern company. The pillars are how you build a business that can survive that fact: fast enough to compete, visible enough to scale, AI-augmented enough to retain talent, and secure enough to sell into the enterprise.

If you want help putting these pillars under your own engineering org — or you just want a second opinion on which one to fix first — that is what we do. Come talk to us.