The AI-native software program I'd build if I started over

Take a program away. Imagine it doesn't exist yet at the company you're at, no incumbent team, no half-built tooling, no political memory of an earlier attempt that went sideways. Just you, a real product, and the question of how you'd build the program from a blank page. Here's mine for an AI-native software design and development program, by which I mean a team building products that use AI and using AI in how they build them.

The first move is to make evaluation a first-class practice before anyone ships an AI feature. Not a layer of tests bolted on top of model output, but the artifact a designer or engineer produces before they're allowed to call a model from the product code. A prompt without an eval set is a feature without a definition of success, and a feature without a definition of success ships either too soon or not at all. Eval first. Code second. Always.

The second move is to organize the team around the work as it exists now. The unit of useful output isn't the ticket anymore. It's the prompt and the eval set it points at, sometimes a skill or an agent on top of those. The team's tooling, review process, and the way work is tracked all need to start there. Treating an AI feature like a regular feature with a model call inside it is how programs end up shipping prompts they can't reason about, evaluated against vibes by whoever wrote them.

The third move is to give designers and engineers the same tools. Claude Code, Cursor, a shared evals platform, the same model access tier. Designers prototype real working features and engineers learn to taste model output. The traditional roles still exist, but the gap between them shrinks in practice. The handoff that consumes most of a feature's calendar time at a normal company has half the surface area on a team where the designer ships a working prototype with a passing eval and the engineer hardens it for production.

What I'd refuse to do

I'd refuse to set up a separate "AI team" with a slack channel and a roadmap. The structure says AI is a department; the work says it's a capability that lives in every team. The separate-team version optimizes for the early thrill of having shipped an AI feature and pays the price for it in year two, when the AI team is a bottleneck and the rest of the org has forgotten how to make decisions about model behavior. Every product team is an AI team. The center of gravity is shared infrastructure (evals, gateway, the model interface), not a roster.

I'd refuse to lock the program to a single model or provider. Standardize the interface; let the model swap. The AI gateway pattern is right for the same reason a database adapter is right: the abstraction lets you move when the underlying technology moves, and the underlying technology in this case moves on a quarterly cadence. A program that wrote import claude six months ago and is wedged into one provider's API surface today is the cautionary tale.

I'd refuse to treat the codebase as something only humans read. The convention of dense in-tree documentation, a CLAUDE.md per project, clear naming, and a layout that an agent can navigate without grep gymnastics: that's an investment that compounds every week and is nearly free to pay forward. Codebases that are illegible to AI agents are usually also illegible to new hires, and the discipline of writing for an agent often improves the codebase for everyone.

What I'd front-load

A real internal tools practice. The team's own productivity comes from the customizations: slash commands for the common workflows, hooks that catch the easy mistakes, scheduled agents that handle the bookkeeping nobody wants to do. The pattern that distinguishes the teams shipping fast from the teams that aren't is which ones treat tooling as part of the work and which ones treat it as a hobby for the engineers who like that kind of thing. Half a day a week per person on tooling, on the calendar, pays for itself within a quarter and keeps paying.

A culture of eval-driven development. Before a prompt is changed, the eval set runs. After it's changed, it runs again. The eval set itself is a living artifact with its own change log, reviewed the same way code is reviewed. Most teams discover this after their second production regression caused by a model swap or a prompt tweak that "seemed safer." The clean-page version starts here.

A library of small reusable agents and skills, built and shared the way components are shared on a design system team. Each one has a name, an owner, a description of what it's for, and tests. People reach for them by default. The same logic that made shared components win over copy-pasted ones applies here, and the same failure modes apply too: shared agents only work if someone owns the trust and quality of the library.

What I'd hire for

Two roles I'd hire for early that look different from a normal engineering or design hire. The first is someone who thinks rigorously about evaluation: how to write eval sets that distinguish a model that works from a model that mostly works, how to read a failure log, how to design rubrics that don't drift, how to keep the eval set honest as the product changes. This skill is rare and load-bearing and shows up nowhere in a standard job description.

The second is someone who can teach an engineer to see what's wrong with a piece of design. Closing the design-engineering gap on an AI team isn't a process problem. It's a literacy problem, and someone has to do the teaching. The role looks like a design ops person crossed with a teacher, and the teams that have one ship features that feel intentional. The teams that don't ship features that feel like a working demo, which is most teams.

Most of what I've described above is borrowed from how good engineering and design programs already work, applied to a stack that's three years old and still rearranging itself weekly. The bet is that the principles transfer and the cadences need to be tighter, because the underlying technology is moving on a different clock. The clean-page version isn't an exotic new program. It's a normal program, started with the right shape for the work that exists today.