I asked an AI coding assistant to generate a DynamoDB query.

A few seconds later it confidently gave me this:

const result = await dynamo.query({
  TableName: "Orders",
  IndexName: "customerId-createdAt-index",
  KeyConditionExpression: "customerId = :customerId",
});

Looks clean.

Looks professional.

Looks like something a senior backend engineer would casually approve during code review while fighting for survival in their 14th Slack thread of the day.

Tiny issue though.

The index did not exist.

And honestly, this is becoming one of the biggest problems with AI coding tools:
they are extremely good at generating things that look correct.

The AI Wasn't Being Stupid

That’s the interesting part.

The assistant actually made a pretty reasonable guess.

It saw:

• DynamoDB usage
• query patterns
• naming conventions
• nearby code

…and predicted what probably existed.

Which is exactly what LLMs are designed to do.

The problem is:
production infrastructure is not based on probability.

Either the GSI exists or it does not.

AWS is unfortunately not very emotionally supportive about this distinction.

Infrastructure Is Not Just "More Context"

A lot of AI tooling conversations eventually turn into:

“We just need better RAG.”

Or:

“We just need larger context windows.”

That helps.

But I think there’s a deeper issue here.

Because infrastructure is not just information.

It’s relationships.

The assistant might read:

• Terraform
• schema files
• docs
• migrations
• configs

…and still not reliably understand:

• which indexes are actually deployed
• which environments differ
• which access patterns are safe
• which infrastructure assumptions are outdated

That’s not just a retrieval problem.

That’s a system understanding problem.

DynamoDB Makes This Very Obvious

DynamoDB is actually a great example here because it is brutally honest about access patterns.

With SQL databases, developers sometimes get away with questionable decisions for a while.

DynamoDB basically says:

“No index? That sounds like a you problem.”

And honestly, fair enough.

The entire database is designed around:

• partition strategy
• access patterns
• deliberate schema design
• predictable query paths

Which means an AI assistant cannot just generate random “probably correct” queries and hope reality cooperates.

The query either aligns with infrastructure design or it does not.

There’s not much middle ground.

The Dangerous Part Is Confidence

What makes these failures tricky is that the generated code often looks completely believable.

No syntax errors.
No obvious red flags.
No broken TypeScript.

Just confident infrastructure hallucinations.

And that’s much harder for engineers to detect quickly.

Especially in large systems where:

• nobody remembers every index
• environments drift over time
• schemas evolve constantly
• infrastructure knowledge is fragmented across teams

Every company has at least one cloud resource held together entirely by:

• historical accidents
• undocumented assumptions
• and collective organizational fear

AI assistants walk directly into these systems with the confidence of somebody who read half the README and decided they understand the architecture.

This Is The Gap I Keep Thinking About

Most AI coding assistants today are optimized for:

• syntax
• implementation patterns
• framework familiarity
• autocomplete quality

But production systems need something else:

• operational awareness

The assistant needs deterministic understanding of:

• infrastructure topology
• indexes
• schema relationships
• runtime dependencies
• deployment reality

Otherwise it is just making educated guesses about systems that may cost thousands of dollars per mistake.

That feels slightly important.

This Is One of the Reasons I Started Building Infrawise

This problem is one of the reasons I started working on opensource project Infrawise.

The idea is simple:

Instead of forcing AI assistants to infer infrastructure from scattered code and configs, provide deterministic infrastructure context directly.

Things like:

• DynamoDB index awareness
• schema relationships
• infrastructure mapping
• static analysis
• AI-consumable infrastructure context

Not “AI magic.”

Just explicit system understanding.

Because hallucinated code is annoying.

Hallucinated infrastructure is how people accidentally discover entirely new AWS billing experiences.

AI Needs To Understand Systems, Not Just Code

Current AI coding assistants are already very good at understanding source code.

The next generation will need to understand:

• architecture
• topology
• infrastructure relationships
• operational constraints
• deployed reality

Because software does not actually run inside VS Code.

It runs inside infrastructure.

And infrastructure is where “probably correct” stops being good enough.