There’s a revolution in software development and most organizations are performing it rather than executing it. Which is totally understandable because this is all so freaking new, we’re all catching up to it and what it means. And I’m not talking about personal or even departmental productivity agents and the like. I’m talking about application software where there are end users who aren’t developers. My company builds this kind software for companies and I’m not in the advising or talking business.
Many of us have experimented and/or adopted AI coding tools. Engineers are shipping in hours what used to take days. The dizzying array of tools like Claude Code, Cursor, and Codex are a genuine step-change in what a lean team can build. Nobody’s disputing that.
Here’s what they’re missing: adopting AI development without rearchitecting the tooling & stack beneath it is productivity theater. The demos are real. The ceiling is too. And if you run long enough on the wrong foundation or take the bolt-on approach, you won’t just cap the upside — you’ll produce systems so structurally incoherent that neither your engineers nor your AI can take ownership of them. Which sounds a lot like the worst kind of technical debt, sort of like when Brundlefly was merged with the pod.
The organizations that get this right will have a durable competitive advantage. The ones that don’t are mistaking acceleration for progress.
Your Cloud Stack Was Built for Humans. That’s Now a Problem.
Let’s be honest about what AWS and Azure actually are at this point — and I do admire and appreciate them — platforms that started as something relatively coherent and spent twenty years acquiring wings, annexes, sub-basements, and load-bearing walls that everyone’s afraid to touch. Nobody has a complete map. Services bolted on in 2014 to solve a problem that no longer exists are still running, still documented, still generating support tickets. The IAM permission model alone has the structural integrity of a building where each floor was designed by a different architect who never spoke to the others.
This happened because let’s fact it — complexity, for a long time, was a feature. It created switching costs, justified enterprise contracts, and spawned certification ecosystems whose sole purpose was navigating the labyrinth and going to conferences. (Very IBM of the 80’s and 90s.) That worked when humans were doing the navigating. Sure, we’ve figured out ways to automate and script some of this but I think “Terraforming” is sort of the problem?
AI agents have no patience for accumulated institutional complexity. What AI wants and needs is a clean, deterministic, command-line-accessible surface — and a codebase it can understand without wading through seventeen years of human-friendly abstraction. Forcing AI-native workflows into legacy infrastructure doesn’t neutralize the AI — it redirects it. Instead of building, it burns its context budget navigating complexity that exists solely to serve human cognition. The AI isn’t underperforming. It’s doing exactly what you’ve architected it to do: push against a wall and figure out brute force ways around it.
What’s Also on the Way Out: Languages, Libraries, and Frameworks
The same logic applies one layer down. Frameworks built around ceremony, scaffolding, and “magic” — Spring Boot, traditional .NET, Rails-style convention-over-configuration, Angular’s original DI model — make AI reasoning harder because behavior isn’t explicit in the code. What the framework does for you invisibly is exactly what the AI has to reverse-engineer. jQuery, bloated CSS frameworks, and sprawling utility libraries exist because humans needed shortcuts. AI doesn’t need shortcuts. It needs clarity and straighforwardness.
The winners in this era share one property: what you see in the code is what the system does.
TypeScript is the dominant choice for product development — explicit, strongly typed, readable. Python retains its grip on data and AI workloads. Rust is gaining ground wherever performance and correctness matter. Next.js for full-stack TypeScript applications. Drizzle and Prisma as lightweight, explicit ORMs over Hibernate-style magic. Tailwind — styling decisions visible directly in the markup, no stylesheet archaeology required.
No magic. No hidden behavior. No framework archaeology. That’s what an AI agent needs to work confidently at speed.
What an AI-Native Stack Actually Looks Like
A few non-negotiable principles — and the specific tools that embody them.
Everything lives in the repository. Configuration, infrastructure-as-code, deployment logic, environment definitions — all of it. If it affects the system and isn’t in the repo, it’s a liability. An AI dropped into an unfamiliar codebase should reach full situational awareness without opening a browser tab.
The platform must be fully operable from code and CLI. GUIs have a legitimate role for visibility, monitoring, and human oversight. The problem isn’t consoles — it’s platforms so encrusted with additions that no one, human or AI, can confidently navigate the full surface area. Every critical operation needs a CLI path the AI can execute without a human clicking through screens.
Kill the library sprawl. Enterprise codebases are archaeological sites — layers of dependencies added to solve human ergonomic problems that no longer exist. Every package on the manifest is surface area the AI has to understand and potentially misread. Cut what doesn’t earn its place.
Write code like an AI will read it. Because one will. Consistent naming, clean module boundaries, documentation that explains why not just what — these are the difference between an AI agent that’s dangerous in twenty minutes and one that confidently misconfigures your system for three days before anyone notices.
The New Stack: What’s Actually In
The hyperscalers aren’t disappearing for enterprises with mainframe-adjacent infrastructure — and for genuinely hyperscale workloads, of course they remain the right answer. The platforms listed below have scale ceilings, and credible engineers know it. What they also have is a range that covers the overwhelming majority of applications being built today, at a fraction of the operational complexity and cost. For most teams, the ceiling is not the constraint. The complexity floor is.
Examples: Deployment & Compute
Vercel is the default for frontend and full-stack TypeScript: zero-config deploys, Git-native workflows, edge capabilities, per-branch preview environments, full CLI control. What used to require an S3 bucket, CloudFront distribution, Route 53 config, and an IAM policy now requires one command.
Railway is where your backend services live. Opinionated, CLI-first, priced for teams that don’t want a cloud billing analyst. Deployment configuration lives in the repo — the AI reads and modifies it as fluently as the application code itself.
Fly.io covers what Railway doesn’t: global distribution, low-latency edge compute, containerized workloads that need to run close to users. CLI-driven, repo-native.
Examples: Database
Neon is serverless Postgres built for AI-native teams. The headline: database branching — spin up an isolated copy per feature branch, test schema changes without touching production, merge it back. The AI can script the entire workflow. Compared to managing RDS instances and VPC configurations, it’s an almost insulting reduction in complexity.
Supabase extends Postgres with managed auth, real-time subscriptions, and file storage — all CLI-configurable, all in the repo. Easy peasy.
Upstash is serverless Redis and Kafka — pay-per-request, HTTP-accessible, zero infrastructure. Cache or message queue without standing up an ElastiCache cluster.
Example: Data & Analytics
MotherDuck is serverless DuckDB — and the cost comparison to Redshift, BigQuery, and Snowflake is genuinely damning. Analytical queries that previously required provisioning and managing a cloud data warehouse now run against Parquet files or MotherDuck’s managed layer, on demand, at a fraction of the price. CLI and API-first, SQL-native so the AI works with it as fluently as any other query layer, no infrastructure to stand up. Where Neon handles your application’s operational data, MotherDuck handles analytical workloads — reporting, aggregations, event data, anything OLAP. Two different layers, both clean.
Examples: Workflow Orchestration
Temporal Cloud for durable, long-running workflows. Write them in actual code, not JSON state machine definitions. The AI can read, reason about, and extend them. AWS Step Functions cannot make that claim.
Inngest for event-driven background jobs and scheduled functions. Workflow logic lives in your application codebase, not a separately configured console service.
Examples: Auth & Identity
Clerk instead of rolling your own or pecking away through Auth0 and Cognito. Complete user management, MFA, social login, org management — clean SDK, no IAM policy syntax PhD required. The AI implements a full auth layer in an afternoon.
And we could go on. The criterion governing every choice on this list: operable through code and CLI, configuration in files not consoles, the AI reasoning about every layer with the same fluency it brings to application code. That’s not a theme — it’s the filter.
DevOps Is Now Just Code. And That Changes Everything.
The platforms above are all truly serverless or near-serverless. They scale from zero to production without anyone tuning autoscaling groups, right-sizing instances, or babysitting pipelines at 2am. The operational surface that required specialists with deep AWS certifications and the institutional memory of a hundred past incidents is replaced by config files and self-managing platforms.
This is not an efficiency gain. It’s a role transformation — and for some organizations, a role collapse.
We’ve seen this before. In the 1990s, the DBA (the “gods” of IT) was load-bearing in every engineering org of consequence — managing query plans, tuning indexes, keeping databases alive under load. Then query optimizers matured, managed databases abstracted the operational layer, and the role contracted from team function to niche specialty. DBAs didn’t disappear — they evolved into data engineers and platform architects. But the headcount requirement collapsed.
The DevOps engineer in 2025 is at the same inflection. Some will move up the stack — architecting, governing, and overseeing AI-operated systems. That’s a real role. But the teams of specialists provisioning infrastructure, tuning autoscaling groups, and maintaining deployment pipelines? That function is shrinking, and it isn’t coming back.
Two Orders of Magnitude on Productivity. One on Cost.
The productivity case gets most of the attention. The cost case is equally compelling.
Serverless, pay-per-use platforms mean you pay for actual usage, not provisioned capacity sitting idle. Neon doesn’t charge for a database running at 3am on a Sunday. Railway doesn’t bill for headroom reserved against a traffic spike that never came. Cost tracks usage, not anxiety.
For organizations that have spent years accumulating AWS infrastructure — over-provisioned environments, underutilized reserved instances, forgotten services standing by for occasional workloads — migration to this stack can represent an order-of-magnitude reduction in platform spend. Teams already running lean on AWS will see real but more modest savings. But for most mid-market organizations, the cloud bill is carrying significant dead weight and nobody has a clean enough picture of the infrastructure to know exactly where it sits.
When your infrastructure is code, your costs are traceable. Every resource defined in the repo can be audited and attributed without a forensic accounting exercise. Contrast this with most AWS environments, where cost allocation is a discipline unto itself — tagging strategies, Cost Explorer dashboards, recommendations engines just to decipher the bill. (If are the one paying for it, you know exactly what I mean.)
The fact that “cloud cost optimization” has been a thriving consulting category for years tells you everything. When you need a specialist to read your own invoice, the platform has failed at a fundamental level.
Coding Was the Easy Part
Here’s where the vibe coder fantasy ends.
The last two years produced a charming archetype: the non-technical founder who discovered they could prompt AI into a working application. The demos are real. The conclusion — that technical depth is now optional — is not correct.
Generating code is the entry-level task. A codebase that’s never been refactored, tested at scale, audited, or tuned isn’t a product. It’s a demo with ambitions. The gap between the two is where software engineering actually lives.
AI needs to be directed across the entire engineering lifecycle — not just the part where code gets written.
QA and test coverage. AI generates test suites and executes regression passes. But someone has to define what “covered” means and know whether the tests are catching failure modes or confirming expected behavior. “Write tests” without that foundation produces tests that pass and tell you nothing.
Refactoring and technical debt. AI executes large-scale refactors faster than any human team. But you have to know what to refactor and why, and verify the output didn’t introduce regressions. That judgment comes from an engineer.
Mass changes and migrations. Dependency upgrades, schema migrations, auth provider switches — AI executes with precision inside a clean architecture. In a tangled codebase, it makes changes in the wrong places, confidently and at scale.
Security audits. AI reviews vulnerability patterns, traces data flows, audits CVEs, generates patches. High leverage — but it needs a clear threat model and a human making the call on acceptable risk. Security isn’t a scan. It’s a judgment. The AI runs the scan.
Performance tuning. AI instruments and proposes across query analysis, latency profiling, memory optimization. It cannot decide which performance characteristics matter for this product at this stage. That’s engineering judgment.
Incident response. AI triages logs, traces errors, identifies root causes faster than any human. The on-call engineer still has to know when the diagnosis is right, plausible-but-incomplete, or confidently wrong.
The pattern is consistent: AI provides leverage across every dimension of engineering work, but leverage is not autonomy. That person directing it, evaluating it, and catching its mistakes is not a vibe coder. They are an engineer using AI as a force multiplier across their full professional scope.
Teams treating AI as a code generator are capturing maybe 20% of its value. Teams treating it as a full-spectrum engineering collaborator — with the architecture and expertise to direct it properly — are building something categorically different.
The Codebase Nobody Can Read
Here’s the scenario nobody’s saying out loud, but most organizations are six to twelve months from living through.
Company adopts AI development. Keeps the same infrastructure. For a while, everything looks incredible — velocity up, features shipping, leadership thrilled.
Except the AI is generating code on top of or bolted onto complexity it can’t fully navigate. Making locally reasonable decisions that contradict choices three architectural layers down. Filling gaps with logic that sounds right but doesn’t match runtime behavior. Meanwhile the human engineers who understood this codebase are reviewing AI output rather than writing from first principles. They’re not building intuition anymore. They’re countersigning. Danger, Will Robinson!
The AI can’t orient because the codebase wasn’t structured for it. The humans can’t rescue it because they’ve lost the line-by-line familiarity that made recovery possible. It compounds every sprint. More AI won’t fix it. More engineers won’t fix it. The wall has been hit and Brundlefly is now begging for the shotgun.
The Legacy Reality — And What To Do About It
Most engineering organizations can’t just start over. Totally understand. It’s why IBM stock went down when Anthropic announced it could refactor COBOL and United Airlines just celebrated that they finally got their software off of 40 year old mainframes.
Years of accumulated infrastructure, production databases in RDS, Lambda functions woven into a dozen dependent services, enterprise contracts with real switching costs — these aren’t theoretical obstacles. For a company whose core system has been running on AWS for eight years, rebuilding on Railway and Neon is not a viable near-term path.
That doesn’t make the argument wrong. It makes the question more specific: not whether to move, but where to start and how to sequence it.
The practical answer isn’t a big-bang migration. It’s identifying the seam where new development begins and making that seam AI-native from day one. New services, new product lines, new internal tools — immediate opportunities to apply these principles without touching the legacy system. As the new architecture proves itself and the old system reaches natural replacement points, migration becomes a series of deliberate choices rather than a crisis response.
What organizations with legacy infrastructure should consider is not do is extend it further. Every new service added to the existing environment deepens the dependency. The legacy system is a known liability. The question is whether you’re managing it toward an exit or compounding it indefinitely.
This Is Not a “Later” Problem
Every engineering team on legacy infrastructure is having this conversation: “We know we need to rearchitect, but right now we’re shipping.”
There’s a legitimate version of that — responsible migration takes time. The problem is when “later” becomes permanent deferral rather than a sequenced plan.
The teams pulling ahead aren’t the ones who burned their old stack to the ground. They’re the ones who drew a clear line: here is where the old architecture ends, here is where the new one begins, and nothing new gets built on the wrong side. That discipline doesn’t require a migration, it requires a decision.
Every sprint you ship new work on the wrong foundation is a sprint you’ll pay back at a worse exchange rate.
The Honest Caveat: This Ecosystem Is Still Growing Up
The tooling is immature and moving fast. The platforms named here are genuinely excellent and also young. Neon’s branching model is innovative and a few years old. Railway has had reliability incidents. Temporal Cloud’s enterprise track record is still being written. When something breaks at 2am on AWS, you have decades of institutional knowledge, Stack Overflow threads, and battle-tested runbooks. On a newer managed platform, you may be waiting on a vendor support queue with limited visibility into the underlying infrastructure. That is a real tradeoff.
There is no established consensus on what “good” looks like. The patterns described here represent an emerging philosophy, not a ratified standard. Best practices are being developed in the open, frequently revised, and argued about by people building on rapidly shifting ground. The engineer who designed a reference architecture on AWS in 2015 had ten years of community knowledge behind them. The engineer doing this today has considerably less backstop.
Vendor concentration is a real risk. Moving away from hyperscaler complexity means moving toward a collection of specialized vendors, each excellent and each a dependency. Vercel, Railway, Neon, Clerk, Temporal — none of them are AWS in terms of longevity and stability. Designing for portability, keeping vendor-specific code thin, and maintaining clean abstractions at integration points is not optional in this stack.
The skills market hasn’t caught up. Hiring for AWS expertise is straightforward — large talent pool, standardized certifications, well-worn interview processes. Hiring for this stack means finding engineers comfortable at a frontier without textbooks, who can evaluate new tools critically and build institutional knowledge in real time. Harder hire, harder team to build.
None of this invalidates the direction. But the organizations that navigate this well will do so with clear eyes about the tradeoff: the known problems of mature-but-bloated platforms versus the different problems of powerful-but-adolescent ones. Neither is free. The question is which set you’d rather be solving three years from now.
The Reckoning is Nigh
The shift to an AI-native stack isn’t a tooling swap. It’s an architectural reckoning that touches infrastructure, codebase conventions, team workflows, and platform choices simultaneously. Getting it right means honest assessment, hard calls about what to kill, and building habits that sustain a leaner architecture over time.
The platform reckoning is coming for every organization that builds software. The question is whether you thoughtfully designed for it, or whether you will continuously hit potholes and insurmountable roadblocks along the way.
https://medium.com/@brian_carpizo/the-platform-reckoning-why-ai-powered-development-demands-a-whole-new-stack-b96242138c7ba>