Form factors for your new AI coworkers

When v0 can generate a usable interface and Claude Code can help build more complicated software locally, why should designers, product people, and engineers evaluate an idea only through mock-ups? They can build it together. The immediate opportunity is to reduce the distance between proposing an experience and discovering whether it works—and with it, some of the uncertainty about whether an idea deserves engineering effort.

For Craig Wattrus, that changes how to design AI products. A click-through prototype can represent a planned interaction, but working software lets you encounter the model’s actual behavior. Before settling on the interface, get the model into an environment where you can try things and see what emerges.

Flatfile provides a concrete setting: moving substantial amounts of data between systems repeatedly. In Wattrus’s informal view of its stack, customer applications run on Flatfile infrastructure. The data and its validation outcomes—errors, warnings, and other signs of dirty data—provide real-time context. Agents operate on that context through tools and jobs, and the interface determines how their work reaches the user. Because this is a developer platform, a model’s ability to write code fits directly into the work the platform already performs.

These are different ways to expose agent activity, rather than a requirement to put every capability inside a conversation.

The invisible example begins at signup. Flatfile uses an email address to identify and research the user’s company; agents then write a Flatfile application in the background. Someone from an HR company gets an HR-oriented demo. The useful result is a relevant starting point, and the user does not need to know that AI is preparing it.

The ambient example moves closer to the work. An agent analyzes a dataset in the background, and small sparkles appear on columns where it finds opportunities to fix the data. The analysis becomes visible at the location where its result matters, without requiring the user to begin a chat.

Inline transformation goes one step further: while working in the data, the user can invoke AI directly to repair it. The agent writes code, and that code runs over the dataset. Wattrus uses a million rows and 50 columns as an illustrative scale for this approach, not as a measured runtime benchmark. The mechanism matters: generated transformation code performs the dataset-wide work.

Finally, conversational Build Mode writes Flatfile applications through a no-code or low-code interaction. Work that previously required an engineer to build the application can begin with a conversation. This is a suitable surface for constructing the application, alongside the less conversational surfaces used within it.

Listening to Amanda Askell discuss Claude’s character with Lex Fridman changed how Wattrus approached agent feedback. He had been treating responses like interface copy: objecting to particular words, openings, or phrases. Instead, he began thinking of the job as character coaching—establishing the behavioral nature he wanted the agent to have. Askell’s character-training work supplied the inspiration; the application experiment that followed operated through a system prompt.

He built a chat tuner in v0 and loaded the system prompt for Build Mode’s orchestrator into it. That made it possible to change instructions and explore how Claude interpreted different qualities: friendliness, balance, concision, or caution. What does asking for more caution actually do to the interaction? A working tuner lets a designer investigate that question instead of assuming an adjective has a predictable effect.

The tuner was visually modest because its appearance was not the point. It was an instrument for designing another product. Generative development tools make it practical to build both the final interface and the smaller tools needed to understand its behavior.

Wattrus’s woodworking analogy starts with a practical requirement: to design with a material, you need to understand its properties. Mock-ups and prototypes can place layers between the designer and those properties. Direct experimentation with a model reveals what an interface must accommodate. The goal becomes creating an environment where the model can complete its assignment, stay aligned, and benefit as models improve.

Every form factor imposes constraints. If an LLM is an intern with a PhD, as the familiar analogy goes, putting it inside an application is putting that intern in a box. The design of the box deserves attention: it determines which abilities the model can use.

That question led to a concrete experiment: what tools should an AI coworker receive when it arrives for work? Wattrus tried giving one mouse-like control. He created a canvas in v0, moved the prototype into Cursor, and gave the agent instructions inside a design environment he knew well. The first moments were exciting, but the limitation quickly became apparent: the agent could move only one object at a time. It felt like putting a Formula One driver in a Prius.

A subsequent prototype, developed with v0 and eventually Claude Code, applied Flatfile’s data migration experience to a consumer workspace. Here the AI had a visible presence without being restricted to a single cursor action: it could read multiple files while writing into another. The displayed workspace holds tabular and JSON sources, procurement suggestions, and a populated unified medical supplies table together. The interaction makes room for activity broader than a person’s one-at-a-time focus.

This is what working with the material reveals. Building and playing with the interface exposes both the model’s capabilities and the constraints the designer has placed around them. Moving from deterministic interactions toward inference requires observing that relationship directly.

Once the broad properties are familiar, the next task is to find the grain: where this particular material is strong, weak, smooth, or rough. That requires humility about the durability of a design. As models change, the interfaces built around their strengths and weaknesses may need rebuilding.

One Build Mode request made the problem tangible. Wattrus asked the agent to enable the Automap plugin, which maps source data to target data. It produced the code, but also a wall of text. Wattrus estimates that this particular request saved probably a week of work across product specification, roadmap coordination, engineering, and QA. That is his estimate for the request, not a measured general productivity gain. The useful work was substantial; the explanation still got in the way.

A separate v0 prototype explored a better interaction for splitting personal details. Its reference point was how a thoughtful coworker communicates complicated work: choose words carefully, show what is happening, and stop to check understanding. The proposed flow made control explicit:

1. Show the operation visually and ask whether it is right.
2. Confirm alignment and the user’s approval.
3. Indicate that a snapshot has been taken and rollback is available.
4. Preserve the fact that the user approved the operation.

These controls turn a long explanation into an interaction where the user can inspect and authorize the work.

The prototype then offers next actions. If something goes wrong, the agent can express the failure—even with a small head shake—and, when appropriate, back off and return control to the user. The important behavior is the handoff: the agent does not have to keep pushing after it has made a mistake.

As the team implemented the design, they found that it could fit beyond a conversational flow. The same visual interaction could sit inside inline transformation. That inline version was still forthcoming at the time of the talk; the reusable idea was a way to explain, approve, and recover from an operation wherever it appeared.

Automating tedious tasks is an obvious use for a new technology, but experimentation can uncover interactions that were not previously possible. Wattrus connects this renewed appetite for playing with software to the earlier excitement around CSS3 and HTML5. A prototype need not begin with a fully specified feature to reveal something useful.

In one experiment, the target was an agent with initiative: curious, enthusiastic, and focused on getting work done, without taking an assignment too far. Wattrus dropped a JSON file and a CSV file into a workspace. The agent noticed that the data looked similar and combined the files without being explicitly asked to merge them. It then wrote a report describing its work.

The report identified duplicates and suggested what to do next, building context from the work already completed. The displayed medical supply integration report also includes price discrepancies, date coverage, and recommendations. Wattrus had been experimenting with Claude 4 to understand its behavior; this sequence exposed the kind of focused initiative he had been looking for.

The agent made further suggestions and generated a slide deck, but the deck was explicitly requested. That distinction matters: the initial file combination emerged from the agent’s interpretation of the inputs, while the presentation followed a user instruction. The team was incorporating the discovered behavior into a new product called Obvious, described at the time as coming soon.

Another experiment gave agents a knowledge base containing recorded and transcribed customer calls alongside customer documentation. When the agents analyzed customer data, they could use that context to generate suggestions. Wattrus expected more and better suggestions, and reports getting both. The surprise was a suggestion for a repair the agent could not perform itself.

For missing employee IDs, the agent advised the user to go to HR and have the IDs generated. It could identify how to resolve the problem even though it could not supply the missing information. An execution limit can become an actionable human handoff. The useful output was a next step outside the software, rather than an attempted automatic repair. Wattrus credits curiosity and experimentation with exposing that behavior.

Keeping an eye on future models becomes more concrete when there is a task you can return to—a personal pelican-on-a-bicycle test. Wattrus’s example is LLM-backed autocomplete. He wants to explore whether a model can support that interaction, while acknowledging that an LLM may not be a good fit for it.

His autocomplete experiment contains 100 suggestions for fixing data. The displayed bake-off places GPT 4o-mini beside Llama 3.1 8b instant, running on Groq, with command inputs and suggestion lists in both panes. At the time of the talk, he had not found a model that was both very fast and very good at this task. This is a personal test of an interaction, not a standardized evaluation with published latency or quality scores.

That test application gives future model improvements a specific place to prove useful. Start with an interaction you care about, design toward the form factor you want, and build an application that can test whether the available models support it. The design practice then has something tangible to revisit as the material changes.