A great deal of pre-AI software work was necessary only because computers were difficult to instruct, environments were fragmented, and translating intent into working systems was expensive.
Build systems, dependency conflicts, boilerplate integration code, API glue, framework quirks, configuration archaeology, routine migrations, test scaffolding, documentation maintenance, and much debugging are not usually the point of a product. They are transaction costs imposed by the software stack. Agents are unusually well suited to reducing them.
That does not mean the people who learned them learned nothing valuable. They developed a model of how systems fail: state, interfaces, performance, deployment, permissions, dependencies, observability, and failure recovery. But the market may pay much less for manually performing those tasks.
What “vibe coding” is actually selecting for
The fact that some people get dramatically better results than others is important. “Press Enter” is not no-skill work; it is often a compressed expression of skills that are hard to see:
- noticing that a request is underspecified;
- articulating the real goal rather than the first proposed solution;
- decomposing work into pieces that can be checked;
- providing relevant context and constraints;
- recognizing an implausible answer early;
- knowing what must be tested in the real environment;
- iterating without accidentally changing the goal;
- preserving a coherent architecture over many changes;
- deciding when an apparent success is too risky to ship.
The key sentence in your experience is:
It only really gets into trouble when I ask for something that I have not fully thought out.
That is likely to remain central. As implementation becomes easier, ambiguous thinking becomes more expensive, because an agent can rapidly build an elaborate, convincing wrong answer.
A capable “vibe coder” is less someone who writes magical prompts than someone who can conduct a tight loop:
- Form a hypothesis about the user/problem.
- Express desired behavior and constraints.
- Have agents construct a candidate solution.
- Inspect it through tests, examples, telemetry, users, and adversarial cases.
- Update the model of the problem.
- Iterate or discard.
That is engineering, even when very little code is typed by the human.
Essential versus incidental complexity
Fred Brooks’s distinction still helps: some complexity is accidental—the complexity of tools, representations, languages, and coordination machinery—and some is essential—the complexity inherent in the problem being modeled.
AI is likely to crush large amounts of accidental complexity.
A small business owner may soon be able to say: “Make a system that imports orders from these suppliers, flags likely stockouts, proposes purchase orders, lets my staff correct it, and sends me a daily summary.” The agent can build a credible version, connect services, deploy it, and repair routine failures. That is a huge expansion of who can make useful software.
But “useful” is not identical to “safe, durable, scalable, secure, maintainable, and economically worthwhile.”
The essential complexity remains in questions such as:
- What does “stockout” mean given substitutions, partial shipments, seasonal demand, and unreliable supplier data?
- Who is allowed to approve a purchase order?
- What happens when the agent is manipulated through an inbound document or email?
- How do you reconcile the system against accounting records?
- What is the rollback path after a bad automation sends 10,000 orders?
- Which local exception, known by an employee but absent from documentation, invalidates the whole workflow?
For a personal tool or a low-stakes internal workflow, those questions can be answered informally. For payroll, health, finance, identity, enterprise operations, critical infrastructure, or a product with thousands of customers, they dominate the task.
So the likely outcome is not “all complexity disappears.” It is: the cost of producing a first implementation falls toward zero, while the cost of knowing what deserves production—and governing it once deployed—becomes proportionally larger.
Will build-system and maintenance work shrink?
Probably, in its current form.
Many organizations have employed substantial engineering capacity to compensate for bad tooling, difficult migrations, legacy environments, brittle tests, inconsistent conventions, and dependency ecosystems. Agents will make one-off repairs and adaptation much cheaper. The mundane, repeated “keep the machinery moving” work will be increasingly automated or performed by a smaller number of engineers supervising fleets of agents.
But there are two countervailing forces:
-
Software volume may explode. If making software is 10–100× cheaper, organizations may create far more software, automations, integrations, and variants than before. Much of it will need operation and repair.
-
Agent-generated software creates a management problem. Code generated quickly can create a vast, poorly understood estate of services, permissions, dependencies, data flows, and latent vulnerabilities. Someone will need to impose standards, maintain evaluations, establish interfaces, contain blast radius, and decide what should be deleted rather than repaired.
The role may therefore change from “the person who hand-maintains CI configuration” to “the person who owns the delivery platform and makes a thousand agent-built changes safe, reproducible, observable, and reversible.”
That is fewer jobs doing mechanical configuration, but potentially valuable jobs in infrastructure, developer platforms, reliability, supply-chain security, software provenance, and organizational controls.
What vibe coding may look like in 2031
The term may survive, but the practice will likely split into tiers.
1. Personal and low-stakes software: nearly everyone vibes
Individuals and domain experts build:
- personal tools;
- spreadsheets-that-became-apps;
- data cleanup and reporting systems;
- small websites;
- local workflow automations;
- prototypes;
- bespoke tools for a team or client.
Most of this will not require a conventional programmer. People will work in natural language, examples, mockups, recordings, and direct manipulation of running software. The system will generate code, infrastructure, tests, and documentation as implementation details.
This will be real, useful software—and much of it will be disposable. That is fine. A large share of software should be cheap and temporary.
2. Professional product building: domain experts and engineers collaborate differently
A domain expert may create a credible working product before talking to an engineer. That changes the handoff. Instead of presenting a requirements document, they can present:
- a functioning prototype;
- examples of successful and failed cases;
- actual data and user feedback;
- an emerging workflow;
- a set of business rules.
The engineer’s role is then often to identify hidden risks, reshape the architecture, introduce security and observability, formalize critical rules, build evaluation harnesses, and turn a prototype into a system that can withstand real use.
This could be a highly productive partnership rather than a replacement story. The best engineer may be the one who makes domain experts radically more capable without pretending their first prototype is ready to run the business.
3. High-stakes systems: “vibe coding” becomes disciplined delegation
In consequential contexts, you will not simply say “make the changes” and accept the output. You may tell agents to work within a controlled environment:
- repositories and services with scoped credentials;
- written behavioral specifications;
- generated and human-curated test suites;
- simulation and staging environments;
- security scanning and adversarial agents;
- required evidence for claims;
- code/data provenance;
- canary deploys, monitoring, and automatic rollback;
- explicit human approval for irreversible actions.
The experience may still feel conversational and fast, but the underlying work is closer to directing an automated engineering organization.
The premium skill is not typing code or even writing prompts. It is building an environment where generated changes can be trusted in proportion to their consequences.
Will software engineers still be paid to do it?
Yes, but less often for “I can implement the ticket” alone.
There may be a painful squeeze in the middle: jobs whose primary value was translating clear requirements into standard application code may face lower prices, smaller teams, and higher expected output. Entry-level roles in particular are vulnerable because organizations historically used them to do bounded implementation work while they learned the system.
The better-paid roles are likely to concentrate around one or more of these:
- Owning outcomes: product-minded engineers who can identify a problem, ship a solution, and measure whether it worked.
- Deep technical constraints: performance, distributed systems, compilers, operating systems, databases, networking, graphics, embedded systems, hardware, security, and formal verification.
- AI reliability and evaluation: proving that an agentic system behaves acceptably across real edge cases, changes, and attacks.
- AI security and governance: permissions, tool isolation, prompt-injection defenses, data controls, audits, incident response, and identity/provenance.
- Domain embedding: engineers who understand healthcare operations, finance, manufacturing, logistics, legal workflows, science, government, or another difficult real-world domain.
- Infrastructure for abundance: platforms that manage the torrent of agent-generated code, tests, deployments, data, and operational signals.
- Human-facing systems: design, interaction, accessibility, workflow change, and adoption—the parts where a technically valid implementation can still fail socially.
There will still be people called software engineers. But more of them may resemble technical product owners, systems architects, reliability engineers, security engineers, domain specialists, or AI-workflow designers.
Will non-programmers take over?
They will take over a much larger share of software creation, particularly where the cost of failure is low and local knowledge matters more than engineering rigor.
That is a feature, not a bug. A lab manager, accountant, teacher, nurse, claims adjuster, or operations employee can often identify valuable problems that a remote software team would never understand well enough to prioritize. Giving them the ability to build tools is economically powerful.
But “non-programmer” does not mean “no technical competence needed.” The new baseline literacy may include:
- data models and data quality;
- access control and secrets;
- basic security skepticism;
- testing against representative cases;
- versioning and rollback;
- cost awareness;
- understanding what the system is and is not authorized to do;
- knowing when to ask for expert review.
In other words, many domain experts will become lightweight software practitioners, while many programmers become high-leverage technical governors and collaborators.
The boundary will be based less on whether one knows a programming language and more on the stakes, complexity, integration surface, and required reliability of the system.
A useful career orientation
Do not make “being good at prompting” your moat. Prompting will be absorbed into tools and training quickly.
Instead, build a combination of:
- Agent fluency — use models aggressively, understand their failure modes, and create repeatable workflows rather than one-off chats.
- Engineering judgment — testing, debugging, architecture, security, operations, and knowing how systems fail.
- A domain anchor — get close to a real class of users and workflows where correctness matters.
- Outcome ownership — learn to define success in terms of revenue, time saved, risk reduced, reliability, or user behavior.
- Trust and evaluation — become good at distinguishing a persuasive artifact from a correct one.
The optimistic case is not that every existing software job survives intact. It probably will not. It is that the ability to turn insight into a working intervention becomes far more widespread—and people who combine technical judgment with proximity to genuine problems will have much more leverage than before.
The most valuable question may shift from:
“Can I build this?”
to:
“What is true about this situation, what change would matter, and how can I safely discover whether the system actually made it better?”