Will AI agents really replace software engineers and developers?
AI agents already build, deploy, and maintain working software, so the real question is not whether they replace the typing but what you own when they finish. Most hosted AI builders give you code that only runs in their cloud, and the runtime, database, environment, and build pipeline all stay behind when you leave.
Last updated
AI agents already build, deploy, and maintain working software, so the real question is not whether they replace the typing but what you own when they finish. Most hosted AI builders give you code that only runs in their cloud, and the runtime, database, environment, and build pipeline all stay behind when you leave. That is where "replaced" turns into "trapped," and it is the part of the conversation that matters more than any benchmark.
What do you actually own when an AI agent builds your app?
The honest answer depends entirely on which tool built it. Lovable, Bolt, and similar platforms generate real source code. React components, API routes, database schemas, package manifests. That code is genuinely yours. You can download it, sync it to GitHub, and read it. But an application is more than its source. The code is a blueprint and the runtime is the building. When you export from a hosted builder, you get the blueprint and none of the building.
What comes with you: the source repository, usually as a Git export or a GitHub sync. What does NOT come with you: the runtime that served it, the database and its data, the environment variables that wired API keys and service connections, the domain and its TLS certificate, the build pipeline that turned pushes into deploys, the CDN that cached your assets, the preview environments, and the credit-based billing model that priced your usage. Every one of those is something you rebuild or re-host somewhere else. If you are coming from Lovable specifically, there is a page on what happens after your Lovable plan that covers the specifics of that export.
What breaks the moment your code is somewhere else?
Everything that was a managed service becomes your problem on the same day. The database connection string that was injected by the platform is now a string you have to set yourself, pointing at a database you have to provision. The OAuth redirect URIs that pointed at your hosted domain now point at a domain that does not exist yet. The serverless functions that ran on the platform's edge network now need a server. The build pipeline that watched for pushes and deployed automatically is gone, and npm run build on your laptop is not a substitute.
The thing that breaks first is usually the database. If your app used Supabase through Lovable's managed connection, the connection string and the service role key were injected at deploy time. You have the code that calls Supabase, but the keys, the project, and the data live in someone else's account. You either point the code at your own Supabase project, which means migrating the schema and the data, or you swap the database layer for something else. Both are real work. There is a separate guide on connecting your own Supabase project instead of Lovable cloud that walks through the first option.
The thing that breaks second is the domain. Your app answered on a subdomain of the builder's domain, with a TLS certificate they managed. Moving it means pointing a new domain at a new runtime, provisioning a new certificate, and updating every hardcoded reference to the old URL.
Where does this go now?
If you are holding source code from a hosted builder and asking where it runs next, the options are a PaaS like Vercel or Railway, which is closest to what you had but still someone else's infrastructure, a cloud VM where you run Docker and manage the runtime yourself, or your own cluster. Most people stop at the first option because the second two feel like more than they signed up for. That is a reasonable position. The reasons people churn from hosted builders are covered in more detail here, and they almost all come back to the same wall: the app works, the bill grows, and the infrastructure is not yours.
Running it on my-app.engineer looks like this. You describe the application in chat or point the platform at the repository you exported. A manager agent produces a build plan, a builder agent writes or adapts the source, and the deploy lands on a K3s cluster as a Helm release. The app answers on <app>.<user>.my-app.engineer immediately, and a custom domain can be pointed at it through the routing layer, which handles the certificate. A QA agent opens the deployed app in a real browser and verifies it does what the blueprint said. If it does not pass, it does not get called done.
The cluster is K3s, deployed through Helm, running Postgres and Docker. Nothing about the runtime is invented here. You can join your own hardware to it: a machine at home becomes a node over a private network, and pods schedule onto it like any other node. That is the path that makes the running cost approach zero, because the compute is yours.
The deploy itself is a push to the repository. The pipeline compares paths against the previous commit, rebuilds only the services that changed, and rolls out with helm upgrade --atomic, which is a zero-downtime rolling update on K3s. A release that fails its health checks rolls back rather than half-landing.
Who should NOT move?
If you want a landing page and never want to see infrastructure again, stay where you are. A hosted builder that manages the runtime, the database, the domain, and the build pipeline is the right answer for that job, and a Kubernetes cluster you own is more machinery than a landing page needs. The freedom of owning the cluster only matters if you plan to run something that outgrows the hosted tier: a real product with a database, payments, and users who expect it to stay up.
If your app is a demo that shows something works and nothing more, the same applies. my-app.engineer has a demo build type that runs with memory only and no payments, but if that is all you need, the hosted builder you are already paying for does it too. Moving for the sake of moving is not the point.
The point where moving makes sense is when you are paying $25 to $100 a month to a hosted builder plus $20 to $59 a month to Vercel or Supabase, your app has users, and you have hit the ceiling of what the hosted tier lets you control. That is the deployment wall, and the way through it is not a bigger plan on the same platform. It is owning the runtime.
Do the agents actually replace the developer's judgment?
They replace the part where a developer types code into an editor, and they are getting better at the part where a developer reasons about architecture. What they do not replace is judgment about what to build and why. The research gate on this platform has rejected products where the demand was real but the product was human expertise rather than software. A UK-based support service for legal practice management users was rejected because the validated demand was for knowledgeable people answering calls and doing migrations, not a software product. A billing support service for independent fitness studio owners was rejected for the same reason: the core product was manual intervention inside third-party platforms, not a build. The agents ship code. They do not ship support teams.
What went wrong here is also worth knowing. A Postgres major version bump from 15 to 16 crash-looped a database because Postgres does not upgrade its data directory across major versions on start. The container came up, refused the existing data, and restarted forever. The database is now pinned to its major version, and a major upgrade is a deliberate migration, never a tag change. That is the kind of thing an agent does not catch on its own, and the kind of thing that owning the runtime forces you to think about. That is the trade.
my-app.engineer builds the app and puts it on a Kubernetes cluster you own, with Helm releases, a real repository, and a path to join your own hardware. The agents design, build, deploy, and verify. The cluster is yours from the first deploy, which means leaving here is the same operation as arriving: you take the Helm release and the source and you run them on any Kubernetes cluster.