When you start a coding project with an AI agent, tell it the scaling plans immediately. Don't hold back the moonshot vision. Don't drip-feed context. This isn't human management where you motivate people with incremental goals.
The common instinct is wrong. People think: "Let me get the MVP working first, then I'll tell it about the enterprise scaling requirements." This produces code that works today and breaks tomorrow.
AI agents don't get overwhelmed by big pictures. They don't lose motivation when faced with complex requirements. They don't need incremental confidence building. These are human problems that don't apply to statistical pattern matchers.
The Rewrite Tax
Here's what actually happens when you hide scaling plans. The AI builds exactly what you asked for. It works. You're happy. Then you mention "by the way, this needs to handle 10,000 concurrent users and we're adding microservices architecture next quarter."
The AI looks at the code it just wrote. Nothing in that codebase was structured for scale. The database calls are synchronous. The architecture is monolithic. The error handling assumes single-user context. You just paid for code you're about to throw away.
This isn't a minor refactor. This is starting over with different fundamental assumptions. You wasted a week building a prototype that taught you nothing about the actual system you need to build.
Why AI Needs The Full Picture
LLMs make architectural decisions based on the context you provide. Give it a small problem, it produces small-problem solutions. Give it a scaling problem, it produces different code from the start.
Tell it you need to handle millions of requests, it considers caching strategies from the first function. Tell it you're building microservices eventually, it structures modules with clear boundaries from day one. Tell it you need multi-region deployment, it thinks about data consistency and latency from the beginning.
These aren't things you bolt on later. They're fundamental architectural assumptions that shape every line of code. The earlier the AI knows them, the less you rebuild.
The Short-Term Focus Trap
"But I just need something working right now." Fine. That's a valid requirement. Tell the AI that too. Say: "Build this to eventually handle enterprise scale, but optimize for getting a working demo up today."
The AI can do both. It can write code that works immediately but won't require complete rewrites later. It can make architectural choices that support both current simplicity and future complexity. It can document which parts need to scale and which don't.
What it can't do is read your mind. If you don't tell it about future requirements, it optimizes for what you did tell it. Then you blame the AI when the code doesn't scale, but you never asked for scalable code.
The trap is thinking short-term focus means hiding long-term plans. Short-term focus means "deliver value now." Long-term awareness means "don't make choices now that will cost us later." These aren't contradictory. They're both requirements you should specify.
What To Actually Tell It
Be specific about scale expectations. Not vague "this might get big someday" statements. Actual numbers. Expected user counts, data volumes, request rates, geographic distribution.
Tell it about architecture plans. Not just "we might do microservices" but "we're splitting user auth, payment processing, and content delivery into separate services within six months."
Explain deployment requirements. Cloud providers, regions, compliance needs, availability targets. These affect code structure from the beginning.
Describe data access patterns. Read-heavy or write-heavy, real-time or batch, relational or document-based. These determine architectural choices that are hard to change later.
The AI doesn't need motivation or confidence building. It needs technical requirements. All of them. Upfront. So it can make informed architectural decisions instead of guessing what you might need later.
The Moonshot Problem
"But what if the moonshot never happens? Won't I have over-engineered code?"
This question misunderstands the issue. Telling the AI about scale requirements doesn't mean building for scale immediately. It means making architectural choices compatible with scale.
You don't need to implement caching for millions of users on day one. But you should structure your code so adding caching doesn't require rewriting the entire data layer. You don't need microservices immediately. But you should organize code with clear service boundaries so splitting them later is straightforward.
When To Hold Back
There's one exception. If you genuinely don't know what you're building yet, tell the AI that. "We're experimenting with this concept. The requirements will change dramatically. Optimize for changeability over everything else."
That's a valid technical requirement. The AI can optimize for flexibility instead of scale or performance. It makes different tradeoffs when it knows requirements are fluid versus when it thinks you want production code.
But if you know you're building something real that needs to scale eventually, tell it immediately. The default should be full context, not incremental disclosure.
The pattern that works: dump all your requirements, constraints, and future plans in the first conversation. Let the AI see the full problem space. Then work iteratively on implementation while the AI makes decisions aligned with where you're actually going.
The pattern that fails: treat the AI like a junior developer who needs careful motivation management. Hide complexity to avoid overwhelming it. Reveal requirements incrementally. Then wonder why you're constantly rewriting code.
AI agents don't have impostor syndrome. Give them the full picture.
AI Attribution: This article was written with assistance from Claude, an AI assistant created by Anthropic.