How I Use AI to Write Platform-Specific Code (Without Getting Generic Output)

D Jaya Vardhan Reddy — Thu, 11 Jun 2026 07:07:03 +0000

If you've used AI to write code for more than a week, you've hit this wall:

You ask for a component. It gives you something that works — technically — but looks nothing like your actual codebase. Wrong naming conventions. Wrong library usage. Wrong patterns. You spend 20 minutes rewriting the thing you asked it to write.

The output isn't bad. It's just generic. And generic doesn't ship.

Here's how I stopped getting boilerplate and started getting code I can actually use.

The Root Cause: AI Doesn't Know Your Stack

When you ask an AI to "create a data table component," it has no idea:

What UI library you're using (or its version)
How you structure your types and interfaces
What naming conventions your team follows
What patterns already exist in your codebase
What not to do (the footguns you've already learned)

So it reaches for the most statistically common answer. That's why you get generic useState hooks, default any types, and className="container" everywhere.

The fix isn't a better AI. It's better context.

The Context Stack That Actually Works

I work on Optix, a cloud asset management and cost intelligence platform. We deal with things like utilization tables, multi-account cloud inventory, and real-time cost dashboards — none of which an AI has seen before. Getting useful output required being intentional about what I feed in.

Here's the stack of context I now always include:

1. Your Types and Interfaces First

Before anything else, paste in the relevant types.

// Bad prompt:
"Create a table component for reservation data"

// Good prompt:
interface ReservationItem {
  id: string;
  service: 'EC2' | 'RDS' | 'ElastiCache';
  utilizationPct: number;
  coveragePct: number;
  monthlySavings: number;
  expiryDate: string;
}

"Create a table component for ReservationItem[]"

The moment you give it real types, the output transforms. Column names match your fields. The logic handles your actual data shape. You stop getting item.name when your field is item.service.

2. Specify Library + Version

This is the one people skip and then wonder why the code doesn't work.

// Instead of:
"using styled-components"

// Say:
"using styled-components v6 — note that .attrs() syntax changed, don't use the old form"

Or for a table:

"using TanStack Table v8 (not v7) — use useReactTable, not useTable"

Version context collapses the output to the right API surface. Without it, you'll get a mix of v7 and v8 patterns stitched together — which compiles and immediately breaks at runtime.

3. Show an Existing Pattern

This is the highest-leverage thing you can do. Paste one example of something that already works in your codebase and say "follow this pattern."

// Here's how we currently build column definitions in Optix.
// Follow this exact pattern for the new component:

const getColWidth = (key: ColKey): ColWidth => ({
  width: COL_WIDTHS[key],
  minWidth: COL_WIDTHS[key],
  maxWidth: COL_WIDTHS[key],
});

Now the AI isn't guessing your conventions. It's extending them. The output slots in like it was written by a teammate.

4. Tell It What NOT to Do

Negative constraints are underrated. Explicitly excluding bad patterns saves a round of corrections.

Don't use index as key. Don't use `any`. Don't add inline styles.
Don't use gap for column spacing — we had alignment bugs with that, use the width strategy above.

The last one is real. We had a Table component where column headers and body rows were misaligned because of mixed flex sizing strategies. Once I added "don't use gap for column spacing" to my prompts, the AI stopped suggesting the broken pattern.

5. Name Your Domain Terms

AI hallucinates less when you establish the vocabulary upfront.

In our codebase:
- "MTD" = month-to-date spend
- "EOM forecast" = projected end-of-month cost
- "commitment" = Reserved Instances or Savings Plans
- "coverage" = % of on-demand usage covered by commitments

Now when you ask it to "add an EOM forecast tooltip to the commitment panel," it doesn't invent a definition. It uses yours.

Putting It All Together: A Real Prompt

Here's an actual prompt structure I use for Optix components:

Context:
- Stack: React 18, TypeScript, styled-components v6, TanStack Table v8
- Platform: Optix (cloud cost intelligence dashboard)
- Domain: RI = Reserved Instances, SP = Savings Plans, coverage = % on-demand covered

Types:
[paste relevant interfaces]

Existing pattern to follow:
[paste one working component or utility]

Constraints:
- No `any` types
- No inline styles
- Use getColWidth() for all column sizing (not gap/flex tricks)
- Follow existing RowContainer pattern for row layout

Task:
Build a [component name] that [specific requirement].

It takes 3 extra minutes to write. It saves 30 minutes of rewriting.

The Mental Model

Think of it like onboarding a new engineer:

You wouldn't hand a new hire a Jira ticket and say "build this." You'd give them a codebase tour, show them an existing component, explain the conventions, and tell them where the bodies are buried.

AI needs the same onboarding. It's fast and capable — but it has zero context about your project unless you give it some.

The more specific your context, the less generic the output.

TL;DR

Without context	With context
Generic types (`any`, `object`)	Your exact interfaces
Wrong library version	Correct API surface
Foreign patterns	Your team's conventions
Plausible-looking bugs	Code that slots in

Paste your types before describing the task
Pin the library version and any breaking API changes
Show one existing pattern and say "follow this"
Add negative constraints for known footguns
Define your domain terms upfront

That's it. No magic prompting frameworks. Just context.
Tags: webdev react typescript ai productivity

DEV Community: D Jaya Vardhan Reddy