This will be a photo-heavy post. I've been working on wireframes for the last two weeks and have plenty to show. I'll provide the images now and follow those with some important issues that have popped up. These wireframes are still in development and may not be perfectly consistent.
Wireframes thus far
This dashboard shows a left side panel with easy access to your library and projects. At the bottom, I've stuck placeholders for the sync summary and cost analysis shortcuts, which could open their respective panels. The middle shows files for a specific project. On the right panel, you'll work with your tools for the project you have open. Here, you can view tools' sync statuses, create tools or import existing library tools, and run chats and graphs in distinct tabs.
This simple set of wireframes shows a flow for creating a new agent. Skills and instructions are what define the "personality" and "vocation" of an agent.
The above set of wireframes shows a flow for creating a graph of agents. To align with the vernacular used in my CLI, each block in the flowchart-style graph is a "Step," and the three types of steps are the Agent Run, the Agent Chat, and the Human Checkpoint. The graph created in the flow above starts with a chat in which the human can discuss the project with a planner agent. Then, a builder agent picks up the work and executes. Next, the work is reviewed by an agent and either sent back to the builder or approved. Finally, a human reviews the work.
The user can run the graph by clicking the "Run" button at the top-right of the window and selecting "Graph" followed by the specific graph they would like to run (not shown). Here, you'll see the same graph created in the previous wireframe flow being run through each step. It starts with a chat step, which the human uses to engage with the chat agent until the human elects to complete the step. Next, the build step is run. When the build agent outputs a specific key phrase, called the "verdict" (in this case there is only one verdict), the step ends and the review step begins. In this flow, the reviewer chooses a verdict that redirects the graph back to the "Code Project" step. After that build step, the reviewer accepts and the human checkpoint begins. The human user is provided with a summary of which files have been changed since the last human checkpoint (in this case, since the beginning of the graph run). The human is also given links to important files to review and specific commands that can be run. For example, depending on the project a command like "npm run dev" can be run to show the project in a browser. Finally, the human can choose to approve the work or provide feedback for rework in another build step. This flow assumes approval and ends here.
Food for thought
Creating these wireframes has surfaced some major questions that you'll probably see addressed before the next round of wireframes, hopefully by the end of this week.
- The issue of the IDE
Originally, the application was going to be both an IDE for the files in the project as well as a GUI for operating your AInstance library, such as by creating and running graphs. These wireframes are designed with the application acting as both the code editor AND the GUI, but I'm leaning toward redesigning this to be used alongside VSCode in a separate window or as an extension. That would fit the work styles of 99.99% of the SWEs I'm designing for while relieving me of having to reinvent the wheel in making an IDE that can support anything.
2. Simple vs. complex graphs
Some of these wireframes are for the graph-creating and graph-running flows, and specifically they model a graph with one primary path. But, what about a graph that branches into different paths that never reconverge? This changes implementation. A user will want to know how many times a path has been retraced, but in some cases a path could be retraced repeatedly with no upper limit. Because of this, the wireframes shown here will need to be readjusted to provide path traversal information in a compact way that works whether a graph is simple or complex.
An important outstanding item on my to-do list for wireframing is modeling cost optimization. I'd like to continue to promote this product as a human-centered-design tool by making it something that can be used for rapid prototyping. This means users should be able to design graphs that are cost-effective enough for repeated runs. I'll be thinking about this more in the days ahead.