Most of what you read about generative AI in software is written by people selling it. This is from the other side of the table — engineers who use these tools every day to ship customer software, with a working list of where they earn their keep and where they don't.
The short version: AI assistance is real, it's compounding, and it has changed the shape of senior engineering work more than any tool since version control. Below is what we use, what we put in the product, and what stays in the human's hands.
§ 01Where we use it every day
Auto-completing the obvious is where it pays. Boilerplate, fixtures, schemas, migration shells, table types, regex with five edge cases, SQL across three joins. Anything with a clearly correct shape that just needs typing out.
The tooling has to know the project. A model in a chat window two tabs away is fast for prose, useless for code. Most of the daily work in our shop runs through an editor-integrated assistant that reads the open file and the surrounding repo.
A small example from this week:
type Post = { slug: string; publishedAt: string };
export function bySlug(posts: Post[]): Map<string, Post> {
return new Map(posts.map((p) => [p.slug, p]));
}Twelve seconds of typing. The model wrote it in one. The wins look mundane in isolation; they add up across a week.
§ 02Where it does the heavier work
Beyond completion, three places consistently pay:
- Exploring an unfamiliar codebase. "Where does this state get mutated?" "List every place we call this function." A model with repo access answers in seconds what used to be twenty minutes of grep-and-read.
- Test scaffolding. Reading a function and producing a first-draft test file — with realistic inputs, edge cases a tired engineer might miss, and the right shape of mocks — is now a one-step operation. The senior engineer still owns what gets kept.
- Migration and refactor proposals. The first cut at "rename this concept across forty files" or "rewrite this component as a server component" lands ninety percent right. The remaining ten percent is where the engineer earns the bill.
The pattern across all three: the model drafts, the engineer decides. That ordering is load-bearing. Reverse it and you get a brittle codebase faster.
§ 03Where it earns its keep inside the product
A different question: when does AI belong inside the product itself, not just the team building it?
Two checks decide it.
First, is it load-bearing for the user, or decoration? A chat panel bolted onto a dashboard is decoration. A natural-language interface that lets a support agent close a case in one sentence instead of seven clicks is load-bearing. We've built both. Only the load-bearing kind stays in the product after launch.
Second, does the cost shape work? Tokens are a real line item. At low scale they round to zero; at real scale they're a fixed cost per active user. We model the spend before we ship the feature, not after.
When both checks pass, AI inside a product is some of the most leverage a small team can buy. AuraMind, our own product, is built on this principle — the AI doesn't decorate, it answers.
§ 04What we won't say
You won't see us quote a percentage on how much faster these tools make our team. Anyone quoting a universal multiplier — forty percent, two-x, ten-x — is selling you something. It depends on the codebase, the team's seniority, the kind of feature, and the day.
What we will say: every senior engineer in our shop uses AI tooling all day, every one of them ships more than they did two years ago, and none of them want to go back. That's the honest version.
The right question isn't "how much faster does AI make us?" It's "where does it let a senior engineer do work that wasn't worth doing before?"
A lot of the compounding wins fall into that second category. Documentation that previously was never going to get written, now gets written. Migrations that used to be scheduled for "Q3, probably" happen in an afternoon. Edge-case tests that everyone agreed mattered but nobody had time for now ship with the feature.
§ 05How we work with it
Our working approach in a sentence: write fewer lines, lean on judgement, automate the parts that don't need any.
Inside customer projects we treat AI tools as a productivity multiplier, not a substitute for the engineering work. The senior engineer is still on the keyboard. They review what the model writes the same way they'd review a junior pull request — looking for correctness, for things the model didn't know about, for the kind of decisions that don't show up in the diff.
If you're building a product where AI either helps your team ship or helps your users get work done, we should talk.