I've been thinking about where vibe coding makes the most sense, and developer tools seem like a particularly good fit.
Agents can already turn a description into a working application with surprisingly little effort. The challenge comes when those applications need to evolve. Architecture decisions, migrations, maintainability, and operational concerns become increasingly important as software grows.
Developer tools often have a different set of constraints. A utility built to inspect an API, analyze logs, or browse database records might have one user and a fairly narrow purpose. If its requirements change significantly, rewriting it could be cheaper than maintaining an architecture designed for a much larger application.
That makes me interested in a simple idea: what if I could describe the functionality of a developer tool, let an agent implement it, and get a consistent, usable application without spending much effort on the interface?
I think a toolkit designed specifically for agent-generated developer tools could make that practical.
Why Developer Tools Are a Good Fit
Many developer tools exist to answer a specific question or make a repetitive task easier.
A database inspector lets me explore records. A log analyzer helps me find patterns in application output. An API debugger lets me construct requests and examine responses.
These applications share a few characteristics:
- They usually solve a focused problem.
- They often have a small number of users.
- Their functionality matters more than their internal architecture.
- Their requirements may remain stable for long periods.
- Replacing them can be practical when their requirements change.
The last point is particularly interesting.
A small utility with minimal persistent state can be relatively inexpensive to rebuild. That changes how much effort I want to invest in its architecture.
For this category of application, I would often prefer a working implementation today over a carefully designed system that anticipates several years of changing requirements.
Of course, a developer tool can eventually become an important piece of infrastructure. Once other systems depend on it, those architectural decisions start to matter more. The advantage here comes from keeping the scope small and understanding when that assumption stops being true.
The Application Around the Functionality
Consider a tool that scans a directory and identifies duplicate files.
The core functionality is straightforward to describe:
- Traverse a directory.
- Identify potential duplicates.
- Compare file contents.
- Return groups of matching files.
An agent can implement that logic with relatively little direction.
But I also need a way to use it.
The application needs directory selection, progress reporting, cancellation, and a results table. I probably want to inspect individual files, filter the results, and remember a few settings.
Suddenly, a fairly simple utility has acquired a collection of ordinary application requirements.
The agent has to decide how to structure the interface, manage asynchronous operations, present errors, and keep the application responsive. I then have to review those decisions and correct anything that behaves awkwardly.
These concerns appear in almost every developer tool I might want to build.
Existing UI libraries help with controls such as buttons, tables, and editors. There's still application behavior to implement around those components. A progress bar needs to reflect an operation's state. Cancellation needs to propagate to the running task. A results view needs to manage selection and navigation.
I keep coming back to the same question: how much of this could be handled by a reusable toolkit?
A Toolkit for Human Interaction
My idea is to build a toolkit that provides common interaction patterns for developer applications.
It would handle things like:
- Application layouts and navigation
- Tables, filtering, and selection
- Forms and editors
- Progress reporting and cancellation
- Logs and error presentation
- Application settings and view state
- Common data visualizations
The application would provide the functionality behind those interactions.
For example, a duplicate-file scanner would implement the scanning logic and expose its operations and results. The toolkit would provide a consistent way to start the scan, display progress, cancel the operation, and explore the results.
A database inspector could use the same table and navigation patterns. An API debugger could reuse the editors, request state, and response views.
The interesting part is the behavior surrounding those controls.
A table component is useful. A table that already handles selection, filtering, keyboard navigation, and state persistence removes considerably more work from an agent-generated application.
I want the toolkit to establish sensible defaults for those interactions so the agent has fewer decisions to make.
That would also give different utilities a consistent interface. Once I learn how one tool handles navigation, progress, and errors, the next tool should feel familiar.
Finding the Right Abstraction Boundary
The biggest risk I see is building too much framework.
Developer tools have wildly different requirements. A file browser needs hierarchical navigation. An API debugger needs editable requests. A profiler might need flame graphs or timelines.
A toolkit that tries to understand every application domain could become more complicated than the tools it supports.
I think the useful boundary is between application functionality and human interaction.
Applications Own Their Behavior
Each application should own its domain logic, integrations, data models, authorization, and external effects.
The toolkit provides controls and interaction state.
For example, the toolkit might expose an action component that understands loading, progress, cancellation, success, and failure. The application supplies the operation and determines what those states mean.
That separation would let the same interaction component work with a file scanner, database query, or API request.
It also gives the application control over important behavior. Canceling a file scan and canceling a database operation can have different consequences, even when the interface looks identical.
Standardize Repeated Interaction Patterns
I would start with patterns that appear across several kinds of tools.
Tables are an obvious candidate. So are long-running operations, editable forms, error displays, and navigation.
Each of these contains small behavioral decisions that are easy to overlook.
What happens to selected rows when a table is filtered? How does an editor handle unsaved changes during navigation? What should the interface display when cancellation has been requested but the operation is still running?
These details affect how an application feels to use. Implementing them consistently could save agents from solving the same problems repeatedly.
It could also reduce the amount of interface review I need to do after generating an application.
Leave Room for Custom Views
Some developer tools need specialized visualizations.
A profiler might need a flame graph. A log analyzer might benefit from a timeline. A database inspector could need a relationship graph.
I would want those views to participate in the toolkit's layout, navigation, and state conventions while keeping their rendering and domain behavior independent.
Composition and extension points seem important here.
The toolkit needs enough structure to make common applications easy to build, while allowing custom behavior when a tool has requirements the standard components cannot express.
Finding that balance will probably be one of the harder parts of the design.
Designing a Toolkit for Agents
There's another complication: agents already know how to use established UI frameworks.
A custom toolkit introduces unfamiliar APIs and conventions. An agent might choose the wrong component, misunderstand its lifecycle, or implement behavior that the toolkit already provides.
That could eliminate much of the benefit.
I think documentation and agent-specific instructions would be an important part of the toolkit itself.
Ideally, an agent could discover the supported application patterns and use them when generating a tool. It would know how to define actions, connect application state, display results, and introduce custom components.
This leads to a hypothesis I want to test.
A smaller set of well-defined interaction patterns might make agent-generated applications more consistent and reduce the amount of correction they require.
The tradeoff is the cost of learning and applying those patterns.
An agent working with a familiar framework has a large body of existing examples to draw from. A custom toolkit would need sufficiently clear APIs, examples, and instructions to compensate for that advantage.
It could also make certain applications harder to implement if the abstractions are too restrictive.
I don't know where that balance falls yet.
Testing the Idea
I want to evaluate the toolkit against conventional UI development using a few representative developer utilities.
Three applications seem like a useful starting point:
- Duplicate-file scanner: Directory selection, long-running operations, progress, cancellation, and structured results.
- Log analyzer: Streaming updates, filtering, large data sets, and navigation.
- API inspector: Editable inputs, request execution, response visualization, and error handling.
Each application exercises a different combination of interaction patterns.
I would have an agent implement each utility using a conventional UI stack, then implement the same utility using the proposed toolkit.
The comparison would focus on a few things:
- Implementation effort: How much agent work is needed to produce a functional application?
- Generated code: How much application-specific UI and state management code remains?
- Corrections: How often do I need to intervene to fix interface behavior?
- Consistency: Do the resulting applications behave predictably across common interactions?
- Flexibility: Which requirements become awkward or more complicated because of the toolkit?
I would also want to examine how much instruction context the toolkit requires. A framework that saves application code but requires extensive agent guidance introduces a different kind of overhead.
The most useful results might come from the cases where the toolkit gets in the way. Those failures would help identify which abstractions deserve to exist and which responsibilities should remain with the application.
Where I Want to Start
My initial instinct is to keep the toolkit small.
I'd start with actions, progress reporting, tables, navigation, and error presentation. Those patterns cover a useful portion of the duplicate-file scanner example and appear in many other developer utilities.
From there, I'd use actual application implementations to decide what belongs in the toolkit.
I'm particularly interested in whether standardizing interaction behavior improves the output of coding agents. If an agent can rely on established patterns for common application concerns, it may be able to spend more of its effort implementing the functionality I asked for.
That benefit is still a hypothesis.
The question I want to answer is how much reusable interaction infrastructure it takes before agent-generated developer tools become meaningfully easier to build, and at what point the toolkit itself starts adding more complexity than it removes.