AI changed how we build. Now it's shaping what we build next.
It started with the work itself—research, specifications, code, tests. It's now part of what we choose to build. Not every product needs AI inside it. Some of them should, and those are the ones we're paying closest attention to.
Where it actually shows up
Building across several domains at once used to require a large team. It doesn't anymore. These are the parts of our work where AI is already the default—and where it isn't yet, we don't claim it.
Research and specification
Working through a problem space, drafting system designs, and writing the specification before engineering time is committed to it.
Writing and reviewing code
Drafting implementations, refactoring older work, and reviewing changes across the repositories we maintain.
Testing and quality
Generating test cases and hunting edge cases—the coverage that is first to be cut when a deadline gets close.
Documentation and knowledge
Keeping codebase documentation, system design records, and internal technical references from going stale.
Internal automation
Taking routine engineering chores and back-office work off the team, so the hours go to product decisions instead.
Content and web
Technical writing, product copy, and the web work that surrounds our products—including this website.
Where the responsibility stays
AI drafts, writes, suggests and tests. It doesn't decide. An engineer reviews everything that ships, and the judgement calls—what to build, what to cut, what is good enough—stay with people. We have no interest in a version of this where nobody on the team can explain the code.
Where this goes next
Agents are the next place this leads—not as a category to enter, but as a way to build software that carries out real multi-step work instead of just displaying it. The kind of work people currently do by hand, across five different tools, every week.
We're building toward that with the same standard we apply to everything else: it has to work reliably, and someone has to stay in control of it.
Working with organizations
We build our own products first. Where an organization's problem overlaps with work we already do—increasingly, that means agents—there may be a reason to take it on together. We haven't done that for an outside organization yet. We'd rather say so than imply otherwise.