2026-07-13 · 9 min read · Raw Drafts / Design / AI Tools
Software for One Afternoon
AI coding makes it reasonable to build small, temporary tools around a single creative problem, then discard them when the work is done.
I watched Y Combinator's head of design show how she works with AI, and one detail kept returning after the video ended. She would reach a point in a project where the available software was awkward, ask an AI coding tool to build a small interface around the problem, use it, and then move on.
She needed to adjust a visual effect, so she made controls for it. She needed to compare several possible directions, so she made a private gallery. She needed many event graphics that belonged to the same visual system, so she made a generator.
These tools were useful without becoming products. They did not need onboarding, a business model, a public launch, or years of maintenance. Some may only have needed to survive until the design decision was made.
That seems like a small change in workflow, but I think it changes our basic idea of what software is worth making.
Until recently, even a simple internal tool had to clear a fairly high threshold. A task had to happen often enough, involve enough people, or waste enough money before building software around it made sense. Otherwise, we adapted ourselves to the software we already had. We copied values between windows, exported the same asset repeatedly, renamed layers by hand, or kept describing tiny changes in words because asking a developer to build a proper control panel would have been absurd.
AI coding lowers that threshold. Software can now be made because it helps one person think through one problem on one afternoon.
A tool does not have to become a product
The software industry has taught us to evaluate software through scale. How many users will it have? How often will they return? Can it grow? Is the feature reusable? Who will maintain it?
Those questions remain important for software that other people depend on. They are less useful for a tool that exists inside a creative process.
A carpenter can make a jig for one unusual cut. A filmmaker can tape a mark on the floor for one shot. A designer can print twenty versions of something and pin them to a wall. Nobody asks whether the tape or the jig has a roadmap. Its purpose is to make a particular piece of work possible.
Temporary software belongs closer to that world. It can be rough, private, highly specific, and still be successful. A dashboard used for one meeting may be worth making. So may a script that cleans one dataset, a gallery that helps compare twelve concepts, or a control panel that lets someone understand how three visual variables affect each other.
This is where AI coding feels more significant than the promise that everyone can now make an app. Most people do not need another app. They may need a small piece of software that removes friction from a task they are doing today.
The difference matters because products accumulate obligations. Once other people rely on a system, the maker becomes responsible for security, accessibility, errors, documentation, updates, and the consequences of failure. Temporary personal tools can avoid some of this weight because their use is bounded and visible. The person who made the tool is often the person watching it work.
There is still responsibility, especially when private data or important decisions are involved, but the shape of the responsibility is different. The tool can remain part of the workshop instead of turning into infrastructure for strangers.
The interface can follow the problem
Professional software contains years of accumulated knowledge. I do not want to recreate Photoshop every time I need to edit an image, and I do not think designers should celebrate rebuilding basic tools badly just because an agent can generate the code.
Still, every general-purpose tool has opinions. Figma gives us frames, components, variants, and a particular way of organizing design work. Photoshop gives us layers, masks, filters, blend modes, and another way of seeing an image. These interfaces are useful, but they also decide which adjustments are easy to imagine.
When a tool gives us a slider, we begin thinking in terms of that slider. When it hides a relationship between several variables across different panels, we may never explore that relationship properly. The work starts adapting itself to the software.
A temporary custom interface can adapt itself to the question instead. If the important part of an animation is the interaction between speed, grain, and distortion, those controls can appear together. If the task is to compare sixteen directions, the interface can be designed around comparison rather than editing. If a visual identity has fixed rules and a few elements that should vary, the generator can expose exactly that distinction.
This is more interesting to me than repeatedly prompting an AI system for another version. Language is useful for direction, context, and intent, but it is clumsy for continuous adjustment. Nobody wants to describe an animation by saying that it should be slightly slower than the previous attempt, with a little less noise but more movement near the edges, then wait for another full result.
A control lets the designer feel the relationship directly.
Deciding what belongs in that control panel is already design work. Someone has to understand which variables matter, what should remain fixed, what needs to be visible at the same time, and how alternatives will be compared. The resulting interface contains a model of the problem.
This is why the designer in the video did more than ask AI for outputs. She built small environments for making decisions. The useful object was sometimes the image or animation, but sometimes it was the ability to see the space of possibilities more clearly.
Context becomes part of the material
One of the projects in the video gathered meeting transcripts, references, project ideas, and background material into a file that the AI could work from. I found this more convincing than the usual discussion about clever prompts.
A designer rarely understands a project from a short brief. The real meaning is spread across conversations, previous attempts, jokes, tensions, images people keep returning to, things that were rejected, and details that seem unimportant until they suddenly explain the whole direction.
Human teams absorb this material slowly. AI systems need it to be made available more deliberately.
This gives project documentation a different role. Notes no longer sit beside the work only as a record. They can influence what is generated, which possibilities are proposed, and how the system interprets an unclear request. A folder of references, a transcript, a list of principles, and a history of decisions can become part of the design material.
There is a danger here too. A large context file can create the appearance that the system understands a project more deeply than it does. It may repeat the language of the team while missing the emotional or political meaning underneath it. It can make a generic result sound locally informed.
The designer still has to notice the difference. Context gives the system more to work with, but it does not remove the need for judgment.
When production becomes cheap, choosing becomes harder
The video shows a designer generating many directions and building tools to compare them. This sounds like freedom, and often it is. It also creates a new kind of exhaustion.
A limitation in time or production capacity used to force decisions. If creating a direction took several days, people had to decide whether the idea deserved that effort. When sixteen directions can arrive quickly, each one can be plausible enough to delay commitment.
The work can become an endless cycle of generating, sorting, pinning, refining, and generating again. Nothing is obviously bad, but nothing is necessary either.
The designer has to bring resistance back into the process. They need to know why one direction belongs to this project, why another is merely fashionable, and when another round of variation will make the work weaker. They need to decide which inconsistency gives the work life and which inconsistency is simply unfinished.
This is where taste becomes practical rather than decorative. Taste is the ability to make a decision when many options are technically competent. It depends on context, memory, values, and a feeling for what the work is trying to become.
AI can increase the number of choices. It cannot take responsibility for caring which one survives.
The same applies to automation. In the video, one physical project remained deliberately handmade while AI was used around the digital experience. That placement of technology matters. The interesting question is not whether AI was used. The interesting question is where it was allowed to enter, what it was trusted to do, and what the designers wanted to protect from it.
Small software, real consequences
Temporary does not mean harmless. A tool used once can still expose private information, produce hundreds of public assets, distort a decision, or quietly encode a bad assumption. Vibe-coded software does not become safe because it has only one user.
There is also a familiar trap in building tools for ourselves. People can spend hours making an elaborate productivity system to avoid a task that would have taken twenty minutes. AI makes this form of procrastination faster and more seductive. Every inconvenience can begin to look like an invitation to build software.
The useful test may be simple: does the tool help us see, decide, or act in a way that the existing workflow does not? If it only moves the work into a new interface, the interface may be the distraction.
Still, I keep returning to the possibility. For most of the history of personal computing, people entered environments designed by large software companies and learned to think through the controls they were given. The spreadsheet was one of the few exceptions. It allowed millions of people to create small, strange systems around their own work without first asking whether the system deserved to become a product.
AI coding could extend that possibility beyond the grid. A teacher could make one interface for one lesson. A researcher could build a viewer for one archive. A designer could create a visual instrument for one identity. A small organization could make a tool around its own language and process instead of twisting itself around generic software.
Most of these tools will never have users in the usual sense. They will have makers. They will live inside a project, help someone understand something, and then disappear.
That is enough. Software does not always need a future. Sometimes it only needs to make one afternoon more possible.
AI authorship note
This essay began with Kris Haamer's request to connect a video about Y Combinator's AI-first design workflow to Raw Drafts. AI supported analysis of the video, drafting, editing, and implementation. Kris is responsible for the editorial direction, the emphasis on temporary software, the rejection of an earlier overly polished draft, and the decision to publish it.