Neel Shah, VP of Software Development
May 22, 2026
There is a growing belief that because people are now using Claude, Copilot, Cursor, Codex, and other AI coding tools to build applications, the future must be that AI will also write complete software systems.
I understand why people think that. The progress is real. Modern AI coding tools are no longer just autocomplete engines. Claude Code can work inside a developer’s environment, understand a codebase, make edits, run commands, and assist with software development workflows. GitHub Copilot’s coding agent can research a repository, create an implementation plan, make code changes on a branch, and prepare work for developer review. OpenAI’s Codex is also positioned as a coding agent that can help with software development tasks.
So yes, AI is absolutely changing how software gets built.
But I do not think the right conclusion is: “AI can build apps, therefore AI will write systems.”
That conclusion skips over an important distinction.
Building an application is not the same as building a system.
And in an enterprise, that distinction becomes even more important.
Applications are visible. Systems are responsible.
An application is often what the user sees: screens, forms, workflows, APIs, dashboards, reports, and features. AI is increasingly good at helping build these. Given a prompt, a mockup, an existing repository, or a clear requirement, AI can produce working code very quickly.
That is valuable. It can reduce boilerplate. It can accelerate prototyping. It can help developers explore ideas faster. It can turn intent into a first draft of implementation.
But a system is much broader than the application surface.
A system includes architecture, data ownership, service boundaries, security, permissions, deployment strategy, observability, failure handling, scalability, cost control, compliance, supportability, and long-term maintainability.
In an enterprise, a system is rarely just one application. It is usually a set of connected capabilities. A single business process may involve a user interface, backend services, databases, message queues, APIs, identity providers, reporting systems, third-party integrations, batch jobs, and operational workflows. It may involve multiple teams, multiple repositories, multiple deployment pipelines, and multiple sources of truth.
An application asks: “Does this feature work?”
A system asks: “Will this business capability continue to work correctly, securely, predictably, and economically when real users, real data, real failures, and real organizational complexity are introduced?”
That is a very different problem.
Enterprise systems are connected, not isolated.
This is where the conversation about AI needs more nuance.
A team may use AI to generate an application or a feature quickly. That does not automatically mean AI has understood the enterprise system around it.
In a real enterprise, software does not live in isolation. One application depends on another. One service publishes data that another system consumes. One workflow may trigger a downstream process. One database may be treated as the source of truth by multiple business functions. One API change may affect several teams. One performance issue may cascade across multiple systems.
So when we build software in an enterprise, we are not only asking, “Can this code be generated?”
We are also asking:
Where does this capability belong?
Which system should own this data?
Which team owns this business process?
What are the upstream and downstream dependencies?
What contract are other systems relying on?
What happens if this integration fails?
How will we detect and recover from partial failure?
How do we avoid duplicate processing?
How do we protect the rest of the enterprise from a bad change?
How will this evolve over time?
These are system questions. They are not simply coding questions.
AI can help with them. It can propose options, summarize dependencies, draft integration contracts, generate diagrams, and identify risks. But it still needs human direction and accountability. Someone has to understand the enterprise context. Someone has to make the trade-offs. Someone has to decide whether the design fits the broader system.
AI can write code. That does not mean AI owns the consequences.
The mistake is assuming that because AI can produce code, it can own the full engineering outcome.
Code is only one artifact of a system.
A system also depends on decisions that are not always obvious in the code:
Should this operation be synchronous or asynchronous?
Where should state live?
What is the source of truth?
What happens if this message is delivered twice?
What happens if the database write succeeds, but the event publish fails?
What happens if an upstream service is unavailable?
What happens when two systems disagree?
What happens when a future team changes a contract they do not fully understand?
What telemetry will tell us that the system is failing?
How do we roll back safely?
How do we prevent one feature from creating risk for the entire platform?
AI can help reason through these questions. It can suggest designs, identify risks, create test plans, generate diagrams, and challenge assumptions. But the judgment still matters. Someone still needs to decide which trade-offs are acceptable, which risks are tolerable, and which design best fits the business and operational reality.
That is engineering.
Working software is not the same as production-grade software.
AI is very good at producing something that appears to work.
That is useful, especially for demos, prototypes, internal tools, and isolated feature work. It can create a form, generate an API, connect to a database, add validation, and write tests.
But production-grade systems require more than happy-path correctness.
They require resilience. They require observability. They require safe deployments. They require secure defaults. They require clear ownership. They require predictable behavior under failure. They require maintainability after the original author has moved on.
A generated app may work in a local environment.
A real system must survive production.
And in an enterprise, production does not mean only one app running correctly. It means the broader business process continues to work across multiple connected systems. It means failures are contained. It means dependencies are understood. It means data remains consistent enough for the business. It means the support team can diagnose issues. It means future changes do not break hidden downstream consumers.
That is the difference.
The future is not “AI writes systems.” The future is “AI raises the leverage of system builders.”
The better framing is not that AI replaces system design.
The better framing is that AI increases the leverage of people who understand systems.
A strong engineer using AI can move faster. They can generate scaffolding, explore alternatives, refactor code, write tests, summarize unfamiliar areas, create migration plans, and review edge cases. AI becomes a force multiplier.
But AI also amplifies weak thinking.
If the architecture is unclear, AI may generate more unclear code.
If the domain model is wrong, AI may confidently build on the wrong abstraction.
If the integration boundary is poorly understood, AI may produce code that works locally but creates enterprise-level coupling.
If the team has no standards, AI may create inconsistency faster.
If the prompt asks for the wrong thing, AI may deliver the wrong thing beautifully.
This is why AI adoption should not be confused with engineering maturity. A team can generate more code and still create a worse system. A team can move faster and still increase long-term complexity.
Speed is not the same as quality.
Building apps is becoming easier. Building systems may become more important.
As AI makes application development easier, the bottleneck shifts.
The hard part becomes less about typing code and more about knowing what should be built, where it belongs, how it should interact with the rest of the enterprise, and how it should behave under real-world conditions.
That means architecture matters more, not less.
Engineering leadership matters more, not less.
Good boundaries matter more, not less.
Clear ownership matters more, not less.
Testing, deployment, monitoring, and operational discipline matter more, not less.
When anyone can generate code quickly, the differentiator becomes the quality of the system thinking behind the code.
AI changes the role of engineers.
The role of the engineer is shifting.
Engineers will spend less time manually producing every line of code and more time shaping, directing, reviewing, validating, and operating AI-assisted work.
That requires engineers to become better at:
describing intent clearly,
breaking work into safe units,
setting architectural constraints,
reviewing AI-generated changes,
thinking through failure modes,
testing assumptions,
understanding system boundaries,
understanding enterprise dependencies,
and making trade-offs explicit.
This is not a downgrade of engineering. It is a higher bar.
AI can help create the implementation, but engineers remain accountable for the correctness, safety, and maintainability of the system.
The real risk is confusing application generation with system ownership.
The most dangerous mindset is not “AI is useless.” That is clearly wrong.
The most dangerous mindset is: “AI generated the app, so the system is solved.”
That is also wrong.
AI can generate a lot of the visible application layer. It can accelerate feature delivery. It can reduce friction. It can help teams build faster.
But systems are not just generated. They are designed, connected, governed, operated, evolved, and owned.
A serious system has memory. It has history. It has dependencies. It has users. It has incidents. It has costs. It has compliance requirements. It has organizational consequences.
In an enterprise, the system also has relationships with other systems. That is what makes the problem harder. A change in one place can create risk somewhere else. A local optimization can create global complexity. A feature that looks simple inside one application may be complicated because of the systems it touches.
AI can assist with all of that, but it does not eliminate the need for engineering accountability.
So, are they right?
They are right that AI will write more application code.
They are right that AI will become more agentic.
They are right that future tools will be able to complete larger and more complex software tasks.
They are right that the productivity impact will be significant.
But I do not think they are right if they mean AI will simply replace the need to design, connect, operate, and own enterprise systems.
The future is not: “AI writes everything, so engineers are unnecessary.”
The future is: “Engineers who understand systems will use AI to build better systems faster.”
That distinction is important.
Because building an app is about making something work.
Building a system is about making sure it keeps working.
And building an enterprise system is about ensuring many connected components keep working together.
References
Anthropic. “Claude Code.” Anthropic describes Claude Code as an agentic coding tool for software development that can work with codebases, edit files, run commands, and support developer workflows.
GitHub Docs. “About GitHub Copilot coding agent.” GitHub explains that Copilot’s coding agent can research a repository, create an implementation plan, make code changes on a branch, and prepare work for developer review.
OpenAI Developers. “Codex.” OpenAI describes Codex as a coding agent that can help with software development tasks.
OpenAI. “Unrolling the Codex agent loop.” OpenAI describes Codex’s agent loop as coordinating the user, model, and tools used to perform software work.