How We Build at amazee.ai: Speeding Up AI Coding Agents Without Cutting Corners

AI coding tools are everywhere right now, and they’re definitely helping teams ship code at a pace we’ve never seen before. But for any engineering organization, there’s an important open question: how do we adopt these tools without quietly destroying the security and privacy standards we’ve spent years building?

That question matters more for us than most. At amazee.ai, safety and privacy are at the core of what we sell. We provide private, region-aware AI infrastructure to our customers, but we also build with AI ourselves, every day, using that same architecture. This is how we do it, and how you can, as well.

Starting with a Solid Foundation

Reliability with AI agents starts with reducing their options. If you give an agent a blank slate, it will make different architectural decisions every time. Decision fatigue is the enemy of clean output.

At amazee.ai, our internal development starts with a template we created. It’s a full-stack web app template wired for two specific things: being built with an AI agent and being deployed to Lagoon.

When you clone it and open it in your agent of choice, you just run /setup. Immediately, you’re in a working project with an opinionated stack, a Postgres database, session-based auth, and a deployment pipeline. It gives your team a path to production without requiring you to reinvent the wheel.

We decided on this stack for a reason:

• Frontend: React with Vite, Tailwind, and shadcn/ui.
• Backend: Express and PostgreSQL using TypeScript in strict mode.
• Data & Validation: Drizzle as the ORM and Zod for input validation.
• Security: Sessions in Postgres, passwords hashed with bcrypt, and .lagoon.yml and docker-compose.yml files shipped in the repo.

Opinionated stacks are sometimes framed as just “taste.” But for projects built by AI agents, they’re a huge reliability lever. Agents produce more consistent, working code when they’re working with a stack they know well and a structure they can predict.

The Non-Negotiables: Two Things We Won’t Let Agents Skip

A starter kit is only as good as its defaults. We make sure our agents follow two non-negotiable rules:

1. Private AI Calls via amazee.ai

Your proprietary code and customer data should never be used to train a public model. This is why all our AI calls route through the amazee.ai gateway, not out to public providers. Every AI feature in an app built from this kit stays within the boundary we control. The gateway is OpenAI-compatible, so our existing SDKs work unchanged, but the requests remain region-aware.

This is the same gateway that our customers use, because if it isn’t safe enough for us, it’s not safe enough for you.

2. Baked-in Security via AGENTS.md

The AGENTS.md files aren’t just documentation; they’re the core operating instructions for our Agent-Native Stack, instructions the agent loads before writing a single line of code. They spell out the rules:

• Every protected route must use a requireAuth middleware.
• Every input is validated with Zod before it touches the database.
• No any types and no hand-built SQL strings.
• Helmet and rate limiting are on by default.

The result is that safe code becomes the path of least resistance. The agent isn’t asked to “remember” security on top of building features; it’s asked to build features in a repo where the insecure shortcut simply doesn’t exist. This ensures our Agent-Native Stack remains secure from the first commit to production.

From Prototype to Production

Internally, we use this process whenever we need to spin something up quickly, whether it’s a prototype, an internal tool, or a customer proof of concept. We get a running app on our hosting infrastructure fast, with defaults that won’t trip a security review later.

We think of AI tooling, hosting, and security as one single challenge to be overcome, not three. We build with the infrastructure we sell, and we put the rules where the agent actually reads them.

This is just how we work. Every day.