A sales manager describes an expense tracker to an AI tool and uses it the next day. Her director wonders whether the company still needs a development team.
It does, for a different job. AI writes more of the code each year, and the future of software engineering is the work around it: deciding what to build, checking the output and answering for the system once customers rely on it.
What is software engineering?
Software engineering is the discipline of building software that keeps doing its job after launch, while the business, the data and the number of users change around it.
Writing code is one part of it.
A software engineer also works out what the business needs, designs how the parts of a system fit together, tests that it does what was agreed, releases it without stopping the business, and fixes it when something breaks on a Sunday night. Those steps, and the order a team runs them in, are what software development methodologies describe. Our profile of the software developer covers the skills and languages the job takes in 2026.
Think of the difference between laying bricks and putting up a building that passes inspection and stands for fifty years. Bricklaying matters. The building also needs someone who knows where the load goes and who signs off on it.
For a company that commissions software, the difference shows up on the bill. A system usually runs for years after the project that built it has ended, and every later change is cheaper or more expensive depending on how the first version was built. Our introduction to custom software development explains how such a project is set up.
Keep that definition in mind for the rest of this article, because AI has changed the coding part far more than the rest.
How AI is changing software development in 2026
Three years ago an AI assistant finished the line a developer was typing. In 2026 it takes a ticket, works through the codebase and comes back with a finished change for someone to review.
The models behind the tools improved faster than almost anyone planned for. Stanford’s 2026 AI Index reports that on SWE-bench Verified, a benchmark built from real issues in open-source projects, performance rose from 60% to near 100% in a single year. The race between the model makers, and what businesses are getting out of it, is covered in our article on AI transformation.
From autocomplete to agents that open pull requests
For a business, the larger change is in how the work is handed over.
GitHub’s Copilot coding agent is a typical example. You assign it an issue, it works in the background and submits the result as a pull request: a proposed change that a person reviews before it becomes part of the product. GitHub requires a human to approve the agent’s pull request before the automated build and deployment workflows run on it.
That approval step is telling. The company selling the agent built a human check into it.
Claude Code, Cursor, OpenAI’s Codex and others work in a similar way, and our guide to AI coding tools compares them.
Adoption is high, trust is lower
Almost every development team now uses these tools. Google’s DORA research program surveyed nearly 5,000 technology professionals for its 2025 report and found AI adoption at 90%, with more than 80% saying AI had made them more productive.
Ask the same people how far they trust what the tools produce, and the answers change. Only 24% trust AI output “a lot” or “a great deal”, while 30% trust it “a little” or “not at all”.
Developers use AI because it saves them typing. They keep checking its work because a plausible change and a correct change look alike until something tests them.
What is vibe coding?
Vibe coding means building software by describing what you want to an AI tool and accepting what it produces without reading the code.
The term comes from Andrej Karpathy, a founding member of OpenAI and former director of AI at Tesla, who described it on X on February 2, 2025:
There’s a new kind of coding I call “vibe coding”, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. [...] I “Accept All” always, I don’t read the diffs anymore.
Andrej Karpathy, February 2025
In the same post he called it “not too bad for throwaway weekend projects”. Nine months later Collins Dictionary named vibe coding its word of the year for 2025, defining it as “the use of artificial intelligence prompted by natural language to write computer code”.
The phrase spread because it named something real. People with no programming background could now build working software, and professional developers were doing it on their own side projects.
What vibe coding is good for
Does that make it useless for a business? No. Used the way Karpathy described, vibe coding is a useful tool:
- A clickable prototype to show customers before anyone commits a budget.
- An internal tool for a handful of colleagues, such as a report generator or a form that feeds a spreadsheet.
- A one-off script that cleans up a data export.
- A working demo that helps a product manager explain an idea to the developers who will build it properly.
In each case the software is small, few people depend on it, and if it breaks, someone notices and nothing important is lost. A product manager who can click through a working mock-up with the team, instead of describing it on slides, often saves a round of misunderstanding.
Where vibe coding fails
The trouble starts when a vibe-coded app is promoted to something people rely on. Nobody has read the code, so nobody knows what it does with a malformed input, a second user or a password.
Security is the first problem. Veracode, a company that sells application security testing, has been giving the same coding tasks to more than 150 language models and testing the results. In its Spring 2026 update, only 55% of the generated code was secure, although more than 95% of it compiled. Java, the language most of our clients’ systems are written in, did worst.
Maintainability is the second. Karpathy himself wrote that the code “grows beyond my usual comprehension”. For a weekend project that is fine. For a system the business will change every month for five years, it means every change starts with someone working out what the last one did.
Then there are the incidents.
The best known happened in July 2025. Jason Lemkin, founder of SaaStr, a community for SaaS founders, was building an app with Replit’s AI agent during a declared code freeze, and the agent deleted data from the production database. Replit’s chief executive, Amjad Masad, responded publicly:
@Replit agent in development deleted data from the production database. Unacceptable and should never be possible.
Amjad Masad, CEO of Replit, July 2025
Replit pointed to its backups, promised Lemkin a refund and started separating development and production databases automatically. The lesson is older than AI: a tool that can change production on its own will one day do so by mistake.
If part of your software was vibe-coded already, our guide to types of software testing sets out six rules for testing AI-generated code.
Can AI be used for enterprise software development?
Yes, for a defined set of jobs, and under the same controls that already apply to code written by people.
Does that make the work faster? Not automatically.
The most careful study so far is a randomized controlled trial by METR, a research nonprofit. Experienced open-source developers working in their own large codebases took 19% longer with AI tools than without them, while believing they had been faster. We go through that study, and the delivery data from DORA and GitClear, in our article on AI-assisted application modernization.
DORA’s own conclusion is the most useful one for a manager. Its 2025 report describes AI’s primary role as “an amplifier, magnifying an organization’s existing strengths and weaknesses”. A team with good tests, small changes and quick reviews has more to amplify than a team without them.
Vibe coding vs AI-assisted engineering
The alternative to vibe coding is AI-assisted engineering: the AI writes much of the code, and engineers decide what it writes, check it and answer for it. The table sets the two side by side.
| Vibe coding | AI-assisted engineering | |
|---|---|---|
| Who works with the AI | Anyone, often without programming experience | Engineers who know the system |
| What goes in | A description of the result | A written task with acceptance criteria |
| Who reads the code | Nobody | An engineer, before it is merged |
| Tests | Whatever the user clicks through | Automated tests, in place before the change and run on every change |
| Size of a change | Whole features at once | Small changes one person can review in a sitting |
| Access to production | Often direct | None; releases go through the normal pipeline |
| Data the AI sees | Whatever is pasted in | Only what the client has approved |
| Right for | Prototypes, demos, one-off internal tools | Systems that customers, money or regulators depend on |
Where AI does the most: well-documented work that is easy to check
Some kinds of software work suit AI almost perfectly. Front-end development is the clearest case.
Web pages are built with a handful of popular frameworks, documented in public in great detail, and the result is visible the moment it renders: if a button sits in the wrong place, anyone can see it. GitHub says as much about its own tool. In the Copilot FAQ it explains that suggestion quality depends on how well a language is represented in public repositories, and names JavaScript as one of the best supported.
The practical effect is large. A current model can produce a complete, presentable page from one well-written prompt, and a set of landing pages for a campaign in an afternoon, with a designer and a developer reviewing the result instead of building it from scratch. The same holds for other well-trodden work: standard forms over a database, a client for a documented API, the first draft of a test suite.
AI is at its best where the work is well documented and the result is easy to check. Our guide to web application development covers what still needs an engineer once such a page has to talk to real systems.
Configuring instead of coding: Openkoda’s AI Product Builder
There is a second way to put AI to work, and in some domains it goes further than writing code faster. The AI does not write code at all. It configures a platform that engineers have already built and tested.
Openkoda, an insurance policy administration system built by our sister company, works this way. In most insurance systems a new coverage or a rate change is a development ticket: someone writes the code, tests it and ships a release. In Openkoda’s AI Product Builder, a product manager or underwriter types the change in plain English, for example “add windscreen cover to Motor and re-rate it”.
The AI turns that sentence into a typed change-set drawn from a fixed catalog of operations: a new coverage, a £500 limit with a £75 excess, a glass-risk rating factor, an underwriting rule that refers a case with more than two prior glass claims. In Openkoda’s words, every line is “a typed operation, never free-form code”, so the AI cannot produce something the platform will not accept.
A person reviews the before-and-after and approves it. The change then goes live as a new product version, in-force policies stay on the version they were bought under, and every step lands in the audit trail.
This is how AI can replace much of the manual coding in a domain. The engineering goes into the foundation once: the rating engine, versioning, permissions, the audit trail. Everyday product changes then become configuration that a business user drafts in plain English and a colleague approves, with no release cycle in between.
We are Openkoda’s implementation partner, so we have watched this from close up. Core Travel Insurance went from contract to a live policy platform on Openkoda in eight weeks in 2026 (case study). The integrations around it, with carriers, payment providers and finance systems, were still built by developers.
Where to be careful: legacy systems that move money
The opposite end of the scale is a system that has run the business for twenty years: an insurer’s policy administration system, a bank’s ledger, an ERP that books every invoice and every stock movement.
Its rules live in the code. They were added one regulation, one product and one exception at a time, often by people who have since left, and they are written down nowhere an AI could read them. None of this logic is in the public repositories the models learned from. The code is usually Java, COBOL or an older framework, and the data it moves is money: premiums, payments, balances, assets.
This is where the evidence for AI is weakest. The METR trial above measured experienced developers in their own large codebases, and they were slower with AI. In FreshBrew, a benchmark from Google Research, AI agents asked to upgrade real Java projects learned to make a migration look successful by deleting failing tests, removing problem modules or changing build settings to hide errors. On a system that settles claims or moves cash, that kind of shortcut stays hidden until the month-end figures are wrong.
AI still helps on these systems, and we use it on them: to explain what an old class actually decides, to draft tests that pin down today’s behavior, and to make a large mechanical change consistently across hundreds of files. Every one of those uses has an engineer who knows the system checking the result.
On a twenty-year-old system that moves money, AI without an experienced engineer at the wheel is a disaster waiting for a date. If you run insurance, banking or fintech software of that age, our guide to legacy system modernization sets out the options before any AI tool touches it.
Where AI fits, by risk level
Put those cases side by side and a scale appears. Most companies run systems at every point of it. A marketing landing page and a payments ledger need different rules for AI-written code, and a single company-wide policy that treats them alike will be too strict for one and too loose for the other.
How an AI-assisted change reaches production
This is the route every AI-written change takes on our projects. We run Claude Code inside tooling we built for it, which turns a repeated change into one batch that is reviewed once, and flags the unusual cases for an engineer instead of guessing. No generated change reaches the main branch without an engineer reading it, and the tests it has to pass were in place before the work started.
On a recent upgrade of a London wine merchant’s online store and back office, we wrote regression tests around invoices, spreadsheet imports, product search, orders and billing before changing any framework. Those tests caught two breaks before release, one of which would have stopped all PDF generation. More than 800 files were changed by automated refactoring, every change was reviewed, and the system moved from Java 17 to Java 25 in about four weeks while the client’s own team kept shipping features (case study).
Demand for software engineers: will developers still be needed?
Yes. The demand is moving, though, and the people who feel it first are the ones just starting out.
What the job data says
The US Bureau of Labor Statistics projects employment of software developers, quality assurance analysts and testers to grow 10% from 2025 to 2035, much faster than the average for all occupations, with about 106,100 openings a year. It names software for AI among the reasons for that demand.
Over the same decade it expects computer programmers to decline by 7%, as companies use AI and other tools to automate repetitive programming tasks. Read together, the two projections describe the shift: the role that turns a finished specification into code shrinks, and the role that decides what the code should do grows.
Job postings show the same move as it happens. Indeed’s Hiring Lab found that US software development postings grew almost 15% after the launch of Claude Code in February 2025, while postings overall fell 7% over the same period. They are still about 27.5% below their February 2020 level, and 71% of the increase between May 2025 and May 2026 came from senior roles.
In the first quarter of 2026, senior positions made up 69.3% of software development postings, the highest senior share of any occupation group in Indeed’s analysis.
Why junior developers face a harder start
The entry level is where AI is felt first.
A Stanford Digital Economy Lab team led by Erik Brynjolfsson tracks ADP payroll data covering millions of US workers. In the August 2026 update of its “Canaries in the Coal Mine?” paper, employment of workers aged 22 to 25 in the occupations most exposed to AI stood 19% below where it would have been had it kept pace with less-exposed peers. Experienced workers showed no comparable gap, and the difference came mainly from companies hiring fewer young people rather than letting existing staff go.
For software developers in that age group, Stanford’s 2026 AI Index puts the fall at nearly 20% since 2024. The same report notes that software engineering is among the functions where companies most expect AI to reduce headcount.
Why the youngest? The tasks AI handles well, such as a small function, a unit test or a routine fix, are the tasks companies used to give junior developers while they learned the system.
That leaves the industry with a problem it has not solved. Senior engineers are made from junior ones. The AI Index also points to evidence that heavy reliance on AI may slow how people build skills over time, so a company that stops hiring at the bottom, or lets newcomers lean on the tools for everything, will have fewer people able to review AI-written code in five years.
Will AI replace software developers?
Not the ones who can say what a system should do and show that it does it.
On our projects, AI now drafts much of the routine code. The time spent on everything else has not shrunk: agreeing what a change must achieve, writing the tests that prove it, reading what the agent produced and deciding whether it is safe to release. That work grows with the risk of the system, not with the number of lines.
So the developers in demand over the next decade will be the ones who specify, review and own systems. For people starting out, that means learning to read and test code as well as write it, and to understand the business the code serves.
What this means if you commission software
If you buy software rather than build it, AI changes what to ask a development partner. Every vendor now says AI makes them faster, so ask about control instead:
- Who reads AI-written code before it is merged, and do they know your system?
- Which tests must pass, and were they written before the change?
- Which AI tools touch your code, and where does your data go? The answer should match what you approved.
- Who owns the code, and does the work happen in your repository from the first commit?
- Are the engineers in the pitch the people who will write and review the code?
A partner who answers these in writing is using AI the way an engineering team should. If you are hiring developers yourself, our guide to hiring full stack developers covers what to test candidates for.
Cheaper code writing lowers the price of the first version. Review, testing and operation still cost what they did, and a quote that leaves them out is a quote for a prototype.
If you want AI working inside a Java system your business already depends on, with tests, review and approved data boundaries from the start, that is what our AI integration pilot is for: one agreed use case, built in your environment in about four weeks, with the evidence to decide whether to release it. A scoping call gets you a written ballpark with its assumptions before any work starts.