Generic Builder

The Bootstrap Problem

When building an intent-based generation system, we face a chicken-and-egg problem: How do we create specialized builders without first having a system to create builders? This is where the concept of a "Generic Builder" comes into play – a flexible foundation that can be configured to create other builders.

Generic Builder Design

The Generic Builder is essentially a configurable template that can be specialized for any purpose. Its design revolves around four key parameters:

name: react-functional-component
description: Create a React Functional Component
instructions: |
  Create a React Functional Component.  Using TypeScript.  Please first define the props as a type.
  If there are no props, you should skip the props type, as an empty object is not allowed.
  Then define the component as a function.
  Be sure to use a TypeScript type for the props, and not an interface.  Also export the prop type.
  Export the component as a named export, but not as the default export.
output: |
  The output should be a typescript file that should be named after the intent filename with a .tsx extension.

Bootstrapping the System

With the Generic Builder defined, we can bootstrap the entire system:

1. Start with a Single Builder: The Generic Builder itself, capable of creating other builders
2. Create Specialized Builders: Use the Generic Builder to create specific builders for different domains
3. Build Library: Gradually build a library of specialized builders
4. Compose Complex Systems: Use multiple builders together for larger tasks

This approach allows for rapid expansion of capabilities without having to manually create each builder type.

Chat Interface Design

A key challenge in implementing this framework is the user experience. While intent files are powerful, developers are accustomed to conversational interfaces. Here's how a hybrid chat interface might work:

Workflow Diagram

User Chat → Intent Parser → Builder Selection → Builder Execution → Generated Output
  ↑                                                                        ↓
  └────────────────── Refinement Loop ────────────────────────────────────┘

Implementation Approach

1. Conversational Entry Point:

   • User expresses high-level intent: "I need a NextJS app with user authentication and a dashboard"

2. Intent Recognition:

   • System identifies key intents (NextJS app, authentication, dashboard)
   • Matches these to potential builders in the registry

3. Builder Resolution:

   • System presents available builders: "I'll use the NextJS App Builder for the overall structure"
   • Additional builders are identified: "I'll need Component Builder, Auth Builder, and Data Model Builder"

4. Dynamic Builder Loading:

   • If a required builder doesn't exist locally, system can:
     • Generate it using the Generic Builder
     • Pull it from a registry/repository
     • Offer to create it on-the-fly

5. Intent Specification Generation:

   • Convert conversation into structured intent files
   • Allow user to review and adjust before execution

6. Execution and Feedback:

   • Execute builder chain
   • Present results to user
   • Allow conversational refinement

The Builder Registry

A crucial component is the builder registry, which maps high-level intents to builder implementations:

type Builder = {
  filePath: string;
  name: string;
  prompt: string;
  output: string;
  description?: string | undefined;
  namespace?: string | undefined;
};

type BuilderRegistry = {
  builders: {
    [key: string]: Builder;
  };
};

This registry can be extended dynamically as new builders are created or discovered.

Bridging the Gap: The Router Agent

The missing piece is what we might call a "Router Agent" – a specialized component that handles:

1. Intent Recognition: Parsing user requests to identify required builders
2. Builder Orchestration: Determining which builders need to work together
3. Context Preservation: Ensuring all builders have the necessary context
4. Dependency Management: Resolving builder dependencies

This Router Agent serves as the intelligent middleman between the chat interface and the builder ecosystem.

Example Conversation Flow

User: "I want to create a NextJS app with user authentication"

System: "I'll help you create a NextJS app with user authentication.
        I'll use these builders to build your application:
        - NextJS App Builder for the project structure
        - Auth Builder for user authentication
        - Component Builder for UI elements

        Is there anything specific you want in your authentication system?"

User: "Yes, I want to use JWT authentication with Google OAuth"

System: "Got it. I'll configure the Auth Builder to use JWT with Google OAuth.
        What kind of data model do you need for users?"

User: "Store user profiles with name, email, and profile picture"

System: [Generates intent files behind the scenes]
        "I've created the following structure for your app:
         - Next.js project with TypeScript
         - Authentication using JWT + Google OAuth
         - User model with profile data
         - Basic UI components

         Would you like to see the generated code?"

Conclusion

The Generic Builder concept solves the bootstrapping problem of an intent-based generation system. By starting with a flexible template that can create other builders, we can rapidly build a rich ecosystem of specialized capabilities.

The chat interface design bridges the gap between developers' preference for conversation and the structured approach of intent files. By using intelligent routing and dynamic builder loading, we can offer a seamless experience that combines the best of both worlds.

The resulting system has the potential to transform how developers interact with AI assistants, moving beyond simple code generation to true intent-based software development.