How to Let Non-Engineers Vibe-Code Internal Apps Without Losing Control of AWS

The operations lead who built a refund queue with Claude Code over a weekend is not going to file a ticket to get it hosted. If the engineering team has no supported path, the app ends up on a personal account or a laptop, with a copy of customer data next to it.

This is the shadow IT problem the UK NCSC describes, with a faster build step, and a sanctioned way to ship is the more realistic control.

This guide describes that path on plain AWS and with Encore.

The controls at a glance

Plain AWS: accounts, branches and a pipeline

Start with a dedicated AWS account for internal apps, so a mistake cannot reach production data directly. AWS's guidance on organizing your AWS environment treats accounts as the main isolation boundary for this reason. Put the apps in a repository with protected branches that require an engineer's review before merge, and have CI deploy with a role assumed through OIDC.

The gap is in infrastructure, because a non-engineer's agent will add a database or a queue by writing infrastructure code, and the reviewer has to read IAM policies and security groups written by a model for someone who cannot judge them. A generated policy that grants * on a resource type looks fine at a glance and is the kind of detail that slips through.

Encore: a reviewed path from prompt to AWS

Encore combines an open source SDK for TypeScript and Go with a platform that provisions and deploys what the code declares into your own AWS account, under rules the engineering team sets. The builder's agent writes services with the SDK, and infrastructure shows up in the code as declarations such as new SQLDatabase("refunds", ...) rather than as IAM and networking. That keeps the review about what the app needs, while Encore generates the AWS setup with private subnets and per-service roles.

The workflow for a non-engineer looks like this:

1. Run encore run locally, which starts Postgres and the app, and iterate with the agent until it works. Rules from encore llm-rules init keep the agent on Encore's conventions, as described in the AI integration docs.
2. Push a branch and open a pull request. On the Encore Pro plan, Encore creates a preview environment with its own database, so the reviewer clicks through the working app.
3. An engineer reviews and merges. If the change adds infrastructure and the environment has manual approval turned on, an Admin approves it before it is created.

Access is set with roles. The builder can be a Member who deploys through branches, while Admins keep cloud connections and approvals. Cloud access sits with Encore's IAM role, not the agent, which makes it more reasonable to let people outside engineering ship.

Good to know

Encore covers the backend and the deploy. A non-engineer still needs a frontend, which can be served from the app with api.static. Review is still required, since Encore makes infrastructure changes visible and approvable but someone has to read the code.

How to choose

• Encore when you want non-engineers to ship apps with a backend into your AWS with preview environments and approvals, without anyone reviewing generated IAM.
• Plain AWS when internal apps must follow the same infrastructure pipeline and review as your production systems.

Related guides

• Building internal tools with AI agents without giving them your AWS keys
• Encore vs Void for AI-built internal apps
• Preview environments
• How to give AI coding agents access to cloud infrastructure safely
• What to put in CLAUDE.md or AGENTS.md so your agent deploys to AWS correctly
• How to test AI agent pull requests in a preview environment