I'm a designer. That's why I decided to do this project - I needed to learn how to engineer agents for programming, and I knew I would learn best not by merely coding with Claude, but by diving a layer deeper and designing a system for agentic programming from the ground up. It's like wanting to learn how to paint, and starting a paint company on the way there.
It's time to discuss how good design is implemented in what I'm doing.
One of the trickier parts of this process is that, in the past, I've learned that good UI design improves user experience by providing only the choices that a user will most likely find necessary. Narrowing a website's scope, lightening up on the heavy text content, and compacting a messy information architecture are all about lightening cognitive load. But this project has a different kind of user in mind. My software factory, currently (temporarily) named AInstance, targets software developers and agentic engineers. These people are deeply technical, to the point that they'll brag about using a CLI with zero pretty colors and zero clarifying icons, all because the shell means maximum control. That challenges my current perspective. I need to lighten cognitive load as much as possible while protecting the engineer's control. How can I implement human-centered design in my design of a tool that is meant to provide someone else total freedom in their designing?
I'll figure it out as I go. This is going to be a learning experience.
No matter what, I know that my execution of a quality solution starts with my understanding of the problem we're looking to solve.
How can we build complex software with agents while minimizing agentic error and maximizing human control?
While an entrepreneur-style AI user may prefer that an agent acts like a human - personal initiative, proactivity, good instincts, sure knowledge of the product - I see engineers who gravitate toward using agents like functions. This engineer wants something that will work in a consistent way, providing output again and again in the same style and without strange or dangerous deviations. Something programmable. This is where managing the context window and bringing in looping becomes relevant, which was the principle behind the Ralph Loop previously discussed.
Now that I've introduced the person I'm building for and the issues we're looking to solve, here are the pillars that I think make a software factory worth this engineer's time.
Control, Safety, and Obtainability. The engineer needs the capability to micromanage - that's literally the engineer's job. Safety is a must, which is why AInstance uses Docker to contain agents within a project folder and keep them away from the rest of your computer. Finally, obtainability is where so much potential lies for making AInstance something that truly fills a gap. Agentic development is expensive and time-consuming (yes, for the human). If something goes wrong at the beginning of an agentic loop/graph, it can compound into a huge waste of time if the problem isn't discovered and solved. Because this software factory is about maximizing control, the human-centered design application becomes in ensuring the engineer has tools for optimization readily available, plus the flexibility to implement changes to improve the design of his or her agentic systems.
In NNgroup's video "The Changing Role of the Designer; Practical Human-Centered Design," Don Norman discusses how, while a full double-diamond exploration of problem and solution is always ideal, the real world meets time constraints that simply don't allow for slow divergence in ideation. Norman says,
...if you build something rapidly and quickly, and give it to people, you will learn a lot from how they interact with it. And so that actually is a way of asking the questions, by giving them something that you just built...and they'll show you what's wrong or what's good. And you can build from there.
Rapid prototyping. This is something designers rely on every day, but it's difficult to implement when building out agentic graphs. I want my software factory product to make rapid prototyping, quick trial-and-error, and forward thinking easier for its users as they create and run workflows of agents on projects.
One form of visualization is already being implemented in the CLI. As you create an agentic graph in AInstance, you receive a visualization within the terminal.
AInstance also provides real cost estimates after runs, specific to the model you're using. From what I can tell so far, these estimates align with the numbers in my Claude Console.
These are the beginning of real human centered innovations in this product. What if, in the future, AInstance allows test runs of loops, estimated cost ranges in advance of running, visual explorations of run history, and efficiency comparisons between workflows? Facilitating the means for engineers to identify and adapt to problems before the problems create cost is the goal.