← Back to blog
Sep 11, 2026·12 min read

How Software Development Actually Changed in 2026

How Software Development Actually Changed in 2026

The short answer: writing code stopped being the bottleneck. Specifying what code should do, and guaranteeing what it must never do, became the bottleneck instead. That shift changed who can build software, moved the hard problems from syntax to constraints, and made the layer underneath the application matter more than the application itself.

The numbers

Three figures describe the year.

  • 60% of new code globally is now AI-generated, per Gartner. Not assisted, generated. The human role has moved from writing to directing.
  • 75% of new enterprise applications are built on low-code or no-code platforms, up from under 25% in 2020. The people building software increasingly aren't developers.
  • Gartner expects that by 2027, over 65% of engineering teams using agentic coding will treat the IDE as optional, shifting control, governance and validation to automated platforms rather than a person in an editor.

Put those together and the picture is clear: less code written by hand, more people building without engineering backgrounds, and less human review at the point of creation.

What changed

Building is no longer the expensive part

For thirty years, the cost of software was the cost of writing it. Estimates were in engineer-weeks. A feature took a sprint.

That's gone. A prototype takes an afternoon. A working application with a database and a login takes a day. The Stanford x DeepMind hackathon this year had three of its top six projects built without engineering teams.

The constraint moved. It's now judgement: knowing what to build, and knowing what must never happen once it's built.

The failure moved from syntax to constraints

When code was written by hand, errors were mostly syntactic or logical, and they surfaced in review or testing.

AI-generated code has different failure modes. 45% of it fails OWASP Top-10 benchmarks. 72% of organisations have had a production incident traced to it. A study of 200+ vibe-coded apps found 91.5% had at least one vulnerability from hallucination.

The errors aren't in syntax. The code compiles and runs. They're in constraints: what the code is allowed to reach, who it's allowed to act as, what it must refuse to do. Those were never in the prompt, and a code generator doesn't add what it wasn't asked for.

Review stopped scaling

Teams that use AI well allocate 15 to 20% of each sprint to consolidating what it produced - duplication, shallow abstractions, missing error handling.

But volume is outpacing that. When an agent generates in an hour what a team wrote in a week, review at the same standard takes the week you were trying to save. And when Gartner's 65% treat the IDE as optional, review becomes optional with it.

So the safety net that caught errors in hand-written code is thinning at exactly the moment error rates are highest.

The backend became the differentiator

This is the consequence most people haven't drawn yet.

Frontends are solved. Every AI tool produces a competent one. The difference between products is no longer how they look.

What's not solved is what's underneath. Authentication that actually gates. Permissions that hold when an agent composes queries at runtime. Audit that can reconstruct what happened. Isolation that keeps one customer's data from another's.

Those were always hard. What changed is that they're now the only hard part, and they're the part AI is worst at, because they're constraints rather than features.

This is the gap Butterbase is designed for. The application can be generated by any AI assistant, but the database, auth, permissions, multi-tenancy and audit are enforced underneath in Postgres, regardless of what was generated above them.

What didn't change

Production still needs guarantees. The bar for software that handles money, customer data or compliance obligations didn't move. What moved is how much of the code beneath that bar is now machine-generated.

Someone still has to know what they're building. Natural language programming makes it easy to describe what you want. It doesn't make you good at wanting the right thing. Specification is still the skill.

The 3-to-6 month problem still exists. Software that worked at launch still breaks when a dependency updates or a schema changes. It just breaks now in code nobody on the team wrote.

What it means for who gets to build

The optimistic reading is real. A law firm can build its own client portal. A property manager can build the tool AppFolio wouldn't sell them. A founder can ship a B2B product without a technical cofounder. All of that is happening.

The caveat is that they're building on top of something, and what that something provides determines whether the result is safe.

If the foundation is a code generator, the constraints are whatever the model happened to produce. If the foundation enforces permissions, isolation and audit in the database, the constraints hold regardless of what was generated above them.

That distinction - what's enforced underneath versus what's generated on top - is the axis that now matters. It replaced "how good is your engineering team" as the question that predicts whether software survives contact with users.

What to do with this

  • If you're technical: stop thinking of the backend as something you build per project. Think of it as the layer that holds the constraints AI won't. Pick one, put your projects on it, let the agent generate everything above it.
  • If you're not: you can build now. Genuinely. But choose the foundation before the tool, because the tool determines how fast you build and the foundation determines whether it works.
  • If you're running a company: the question isn't whether to let people build with AI. They already are. The question is whether what they build sits on something that enforces the rules you'd want enforced, or on whatever the model felt like writing that day.

Butterbase is built on this thesis. Generate the application with any AI assistant or directly in the dashboard, and the database, auth, permissions, multi-tenancy and audit are enforced underneath in Postgres, regardless of what was generated above them. Related reading: Vibe Coding vs No-Code Platforms and Backend for AI Agents.

Frequently asked questions

Around 60% of new code globally, according to Gartner.

For judgement, specification and constraints, yes. For writing standard code, increasingly no. The role shifted from author to director.

Constraint failures: authentication that doesn't gate, permissions that don't hold, data that isn't isolated. 45% of AI-generated code fails basic security benchmarks.

Because frontends are solved and backends aren't. The hard parts, auth, permissions, audit and isolation, are constraints rather than features, and constraints are what code generators are worst at.

Yes, if the platform underneath enforces the guarantees the generated code won't. With Butterbase, the database, auth, permissions, multi-tenancy and audit are handled underneath, so non-developers can generate real production applications. Without that foundation, they can build prototypes.