yeah we're seeing the same thing from the infrastructure side. small opinionated api surface means less code and you can actually read what the agent wrote.
yeah totally. an example from the article is that when when you're reviewing 31 lines of business logic instead of 150 lines of boilerplate it's a lot easier to catch bad error handling or security issues - which kinda goes hand in hand with what you're saying.
This is close to what we're doing with [Encore](https://encore.cloud). The framework parses your application code through static analysis at compile time to build a full graph of services, APIs, databases, queues, cron jobs, and their dependencies. It uses that graph to provision infrastructure, generate architecture diagrams, API docs, and wire up observability automatically.
The interesting side effect is that AI tools get this traversability for free. When business logic and infrastructure declarations live in the same code, an AI agent doesn't need a separate graph database or MCP tool to understand what a service depends on or what infrastructure it needs. It's all in the type signatures. The agent generates standard TypeScript or Go, and the framework handles everything from there to running in production.
Our users see this work really well with AI agents as the agent can scaffold a complete service with databases and pub/sub, and it's deployable immediately because the framework already understands what the code needs.
We've had a bunch of people migrate over from Heroku in the last couple years, especially after they killed the free tier.
The main difference from other alternatives is that you don't write any infrastructure config - you just declare what you need in your code (databases, cron jobs, pubsub, etc) and Encore handles provisioning it in your AWS/GCP account (works locally as well where local is 1:1 to your prod env). So there's no Terraform to maintain or Docker setup to mess with.
If you're looking to move off Heroku it's pretty straightforward, most folks get their app running in an afternoon. Happy to help if you run into anything: https://encore.cloud
Haha. We're not trying to replace Ops, just prevent teams from needing to build internal platforms before they can ship product. You can still modify all the provisioned infra directly in AWS/GCP console, or layer Terraform on top. We work alongside you, not against you.
We provide client abstractions for infrastructure primitives (databases, pub/sub, object storage, etc.). Your application code uses these abstractions, and the actual infrastructure configuration is injected at runtime based on the environment.
For example, your code references "a Postgres database" and Encore provisions Cloud SQL on GCP or RDS on AWS, handling the provider-specific config automatically. The cloud-specific details stay out of your application code.
And if you prefer Kubernetes, we can provision and configure GKE or EKS instead of serverless compute. The point is your application code stays the same regardless.
Encore (the framework and CLI) is fully open source and free to use. You can deploy anywhere by generating Docker images with `encore build docker`.
Encore Cloud (optional managed platform) has a generous free tier and paid plans for production teams that want automatic infrastructure provisioning in their own AWS/GCP accounts. You can find more details at encore.cloud/pricing
You can just use the resource as you'd normally would and then use e.g. secrets to define the connection settings per environment. You would however need to provision the resource yourself for all your envs. We have a terraform plugin to help you automate it.
I'd argue it's the opposite of coupling. Your application code references logical resources (database connection, pub/sub topic, bucket) without knowing anything about the underlying infrastructure. Encore extracts these needs and a configurable planner transforms them into actual infrastructure.
The same application code can run locally (Docker), on AWS (RDS, SQS, Lambda), or GCP (Cloud SQL, Pub/Sub, Cloud Run) without changes. That's less coupling than explicitly configuring cloud-specific resources in Terraform or even using cloud SDKs directly.
Re: Chalice - similar idea but Chalice is AWS-only and focused on serverless functions. Encore is cloud-agnostic and works for any backend architecture (monoliths, microservices, containers, functions).
But you're inverting the dependency-injection pattern (dependency-extraction?) rather than feeding your app the things it needs to run, you're encoding the dependencies directly into the application code. Maybe it works great in practice, I haven't tried it, but it looks brittle and hard to test.
[0]: https://encore.dev
reply