We have come so far since the last post's activity where I typed out a little Python + Ollama agent. I've covered serious ground, and from my new ideation, market research, and command line experimentation, I can confidently say that I have even less of an idea of what the final result will look like. This is actually an encouraging thought. I came in not knowing anything about the industry, fully expecting to make some discoveries that would inform my project's direction. That is exactly what is happening, and it isn't over yet. No matter where we end up, the experiment is already fulfilling one of its primary goals: I am quickly becoming familiar with the world of software, the terminal, how agents really work, and what's currently out there for engineers to work with.
A GUI got me thinking...
Before last week, I was encouraged to think through an interface design besides the command-line. The real interface design will have to keep waiting until the product architecture is decided, but mapping out ideas was the perfect next step for me. I'm truly a designer, and as I began to draw an information architecture chart in FigJam, I was able to walk through what a user experience could look like. I'll attach an image from my ideation, but please know that this will - and should - change dramatically as I continue exploring what is already offered and why it succeeds or fails to meet the users' needs. My vision for the core structure of he product has already changed, and my version 0 (v0) is already being implemented differently.
As I continued thinking about architecture and how the user would interact with the software, I became increasingly concerned with how my project would differentiate itself from what's already out there. It's true that the primary goal of this project is my own hands on learning - by that logic, I can still consider it a success if I rebuild Claude Code. But my goal isn't to reproduce Claude Code - I want to create a highly customizable, easily start-able software factory that allows users to keep track of a collection of skills, agents, and agentic workflows and apply those flows to projects in sandboxed environments. I'm drafting up v0 as I write this blog. But, before we discuss v0, let me take you through some more of my research.
Exploring what's out there
One of the first subjects of my market research ended up being something a little different from market research. LangGraph is a framework that allows smoother development of agentic applications, and I approached it as a potential competitor. Little did I know, a framework in this case is just a powerful code library. After I took part in six mini-lessons at the beginning of an official LangGraph course, I realized that LangGraph is very likely a tool I'll be using in my own product alongside other helpers a programmer normally imports into a Python file. It can be compared to matplotlib, a library used for math-related scripts to perform mathematical functions and create visual charts.
But LangGraph is way better and way cooler than matplotlib for our use case. LangGraph is an expansion of LangChain. LangChain lets a programmer connect their code to LLMS from different companies and chain together custom prompts and agents. LangGraph sits on LangChain's shoulders and facilitates the building of multiagent workflows. It is a code library that lets you build graphs of agents - a perfect tool to use in my application. LangGraph's makers have a studio IDE that acts as a platform for the library, but I do not think this is a critical competitor. The LangSmith Studio lets you interact with agents in your graph and even provides a node-and-edge visualization, but it falls into a slightly different niche. LangSmith Studio seems to be about developing the agentic software rather than using custom agentic software as a "software factory" to develop projects besides the agentic graph itself.
A similar application I explored was LangFlow, cleverly named so because it is a low- or no-code platform for LangGraph. LangChain, LangGraph, and LangSmith Studio are all associated with the same group, while LangFlow belongs to IBM. I appreciated LangFlow's simple UI. No course needed for this one. After downloading and logging in, I was met with a simple AI chat input box. I carefully typed out a workflow for a multi-agent software factory and hit enter. The result was interesting.
I'll save the details for a slide deck, but I can see why commenters in online discussion boards cannot picture themselves using a no-code UI in a professional development environment. Besides the stigma of using an easy tool in a hardcore dev culture, the canvas of LangFlow gets too tangled for a complex flow. This is a great solution for a less technical, less GitHub-acclimated crowd that needs to create an AI-based process for easy automation. However it's not speaking the same language as the developers that I consider my target audience in my design. I'll be keeping LangFlow's implementation in mind for if I decide to target a more visual audience with my GUI.
The YouTube software factory that inspired me
LangSmith Studio and Langflow feature the node-and-edge-style visualizations that are associated with agentic graphs, but they aren't exactly what I'm looking to implement. Yes, my product should let people build workflows. However, the primary goal should not be to build workflows but to use them, reuse them, and refine them. I want my software to be a space for deploying agents and agentic teams/flows on real projects. A YouTube video called "My Super Simple Software Factory (For Agentic Engineers)" understands the vision. (There are so many other DIY software factories out there - I have more research on the queue.)
This "software factory" is a great example of a platform that houses a variety of agents and distinct workflows. The creator could run a workflow, such as the simple "engineer -> builder" flow or the more advanced "engineer -> planner -> builder -> [code(verify) -> code(test) -> builder(fix)] bounded -> git(commit)" flow and observe its execution in a visual timeline or a specific events log. One of the most valuable parts of this walkthrough was how the engineer stressed the need for observability. Agentic activity should be as observable as possible, and a good software factory has a transparency that lets the engineer optimize for cost. This is an excellent example for me as I consider what my audience of advanced "vibe-coders" to engineers actually needs in a software factory. I've started considering another potential differentiator as I've begun developing version 0, but that will have to wait for the next blog post.