Beyond prototypes: shipping trustworthy AI
Three stories about getting AI features into production—from Veriff, NFTPort, and Pactum—drawn from my Nordic Testing Days keynote.
Products
What to build, how to prototype and ship it, whether it works, and what users experience.
A thinking partner is a medium, not a source
A thinking partner's value is in what it pulls out of you, not the text it writes. Five things stock Claude gets wrong, and the 800 words of instructions that fix them.
Great ideas are incubated dumb ones
Many ideas look weak or dumb when they are born. If you shoot them down before incubating them, you will never get anything new.
Agentic UX ruins the coaching
One more thing that's annoying when using AI as a coach: any amount of reasoning tokens will make me switch away. Latency actually matters here. Two seconds is okay; twenty ruins the flow. There is also something more subtle. I don't take as much responsibility for my thoughts, am not as critical. I don't
AI coach
Can you build an AI coach? The obvious answer is yes: AI is great at spotting patterns in what you say, and you can ask it to use any style of coaching, any framework. An exec coach I used to work with thinks you can't build an AI coach, because true change happens in relation to another human.
Places to put the AI
Every product team building with AI faces the same question: where does the AI interaction go? Not the model or the prompt, but the affordance: the surface the user sees and interacts with. For my own reference and discussions I wanted to capture these. Even though the chat box is where this all got started, these are not stages of
Vibe coding a music learning app
Reading Shipping at Inference-Speed and with the Christmas holiday on my hands, I again felt a deep desire to ship a side project while getting a feel for state of the art AI coding tools. Usually I temper my enthusiasm for side projects and discard ideas immediately: rarely do I have significant free time on my laptop. But with
Subtractive changes
When solving a problem with an existing system, most people tend to add. But often, removing makes a design better. * Dieter Rams's famous principle is "Less, but better." * Strunk & White tell you to "Omit needless words." In fact, the paper People systematically overlook subtractive changes explores this concept. From the abstract: Improving objects,
Skills, not agents
I used to think shipping an agent product meant building: 1. The core LLM loop. 2. Skills: describing to the LLM how to do particular things (including building API connectors etc). But it seems that Claude Code and Codex are strong enough general-purpose agents that you can just outsource (1) to one of those generic ones, and focus just
Principal
I recently noticed that it's a bit clunky to talk about "users" of our agents. Building complex enterprise software, we have multiple types of users, from operations teams making daily decisions to executives looking at high level dashboards, and of course suppliers. But often none of these people can make important judgement calls, like "will