These frontier coding models are incredibly good at writing code. You can build some really impressive, fully functional applications with the new coding language, English. Vibe coding has brought both excitement and fear to the software engineers I know. On the one hand, the potential of an individual is astronomical. On the other hand, who will need software engineers in a few years? My take on that topic will be in an upcoming Steelman blog entry. For now, though, I'm left thinking about where the industry is headed as the bar for building keeps getting lower and lower.

Between OpenClaw, Claude Code, Codex, etc., there is a clear trend toward an enormous amount of applications being written. This is trending toward individuals/companies building and managing their own niche software, specifically for their needs. This brings up two thoughts:

1. How do you build the right thing well?
2. How do you build that thing so that it can be managed?

The answer is a software factory. People and companies will need software factories at their disposal that let them build quickly, trash the things that don't work, and build the ones that do. A few companies are building software factories. Some have released them as products like (https://www.8090.ai/), and some are building them to use internally to build better and faster than others.

Where do we start with this? There are a lot of good PRD generation companies out there, I think that's probably the place I'd start. Moving from idea to asking the right questions and understanding what to build are key. So let's start there.

So where do we start? The goal is to build something that can define requirements for an idea. The frontier models are good at this with a generic prompt that asks the LLM to go through the questions one by one until there's enough information to start building. So, can we improve on that? I think so.

We can improve it by not focusing on what the person THINKS they want to build, but by guiding the user to the actual problem they are trying to solve. This isn't to say that an LLM will know the domain better than the person; however, most people don't think about the root problem they are trying to solve and work from there. Instead, people take what they know for granted and start from way higher up the decision tree when they think about what they want to build. Can we structure the conversation so the model steers it toward the foundational problem and then directs the user to the requirements from there? I think that's probably a good place to start.