2.2free~6 min

What AI types now

1. The expanding keyboard, on the other side

Everything the human used to type, and didn't want to, the model now types. That's most of the code.

Implementation bodies. Test scaffolds. Boilerplate setup. Database migrations. CRUD endpoints. Form validation. Type definitions for an API response. Wrapper functions. Glue code. Conversions between three slightly different shapes of the same data. The hundred lines around the ten lines that actually matter.

The model is fast at this because the model has seen a million examples of each pattern. It produces the seventy-fifth-percentile version of any common pattern without thinking. That used to be most of a workday.

2. The pair: what you write, what the model writes

Here's the pair. Top block: what the human types. Bottom block: what the model fills in.

tsThe human writes the spec and signature
/**
* Parse an ISO 8601 duration string into total seconds.
*
* Supports the subset commonly used in calendar APIs:
*   PT15M       -> 900
*   PT1H30M     -> 5400
*   P1DT2H      -> 93600
*
* Years and months are NOT supported (variable length).
* Throws on malformed input. Returns an integer.
*/
export function isoDurationToSeconds(input: string): number {
// model fills this in
}
tsThe model writes the implementation
export function isoDurationToSeconds(input: string): number {
const match = input.match(
  /^P(?:(\d+)D)?(?:T(?:(\d+)H)?(?:(\d+)M)?(?:(\d+)S)?)?$/
);
if (!match) {
  throw new Error(`Invalid ISO 8601 duration: ${input}`);
}
const [, days, hours, minutes, seconds] = match;
return (
  (Number(days) || 0) * 86400 +
  (Number(hours) || 0) * 3600 +
  (Number(minutes) || 0) * 60 +
  (Number(seconds) || 0)
);
}

You'd have written something close to that yourself. It might've taken twenty minutes to remember the exact regex, look up the date math, and double-check the unit conversions. The model produced it in under a second. The implementation isn't interesting. The spec was.

3. The categories of code the model now owns

Implementation bodies. Whatever the function signature promises, the model can usually deliver.

Test scaffolds. "Write tests for this function covering happy path, empty input, malformed input, and the integer-overflow edge." You'll add the ones the model missed. Most you won't have to write.

Boilerplate. Express route handlers, React component skeletons, dependency injection plumbing, retry wrappers. The shape is so standard the model nails it.

Migrations. Schema diffs, up/down SQL, backfill scripts. The model knows the patterns and the gotchas.

Common patterns. Repository pattern, observer, debounce, retry-with-backoff, rate limiter, LRU cache. The model has seen each one a thousand times in real production code.

4. The categories the model doesn't own

Some code the model is bad at. Worth naming, so you know where your typing time is still well spent.

Anything that depends on knowledge only your codebase has — internal conventions, what the team agreed to last quarter, which utility lives where. The model can guess and will guess wrong.

Anything where the failure mode is silent and the cost is large. Financial calculations. Auth checks. Anything irreversible. The model will write code that compiles and looks right and rounds the wrong way.

Anything genuinely novel. If you're inventing a new algorithm or pattern, the model can't paste it from memory. It has to reason from first principles, which is where it's weakest.

5. The split, in one sentence

The model types the code you would've typed if you'd had infinite patience and no boredom. You type the parts that need you to be there — the spec, the unusual cases, the decisions about what to ship.

It's a good trade. The boring parts were the parts that gave you RSI.