You're not taking ma job yet, AI. Domain expertise is still the differentiator in AI-assisted development

I'm all in on AI assisted development, but in order to avoid an existential crisis, I'm going to posit that domain expertise is the real differentiator in when it comes to making stuff with AI. Creating a form builder entirely with AI seemed like a good way to find out if I was right, or out of a job (also, the world was tragically short on form builders).

The difference between getting a toy and getting something real isn't in the prompts themselves, it's in knowing what to specify. Knowing what a good architecture looks like. Knowing which edge cases exist before they bite you. Knowing how to constrain the problem space so the AI implements a specification rather than guessing at every technical decision.

The declarative vs. imperative gap

Non-technical users prompt AI declaratively: "Build me a form builder with drag and drop functionality." This works for demos, but falls apart quickly because the AI has to guess at every technical decision. What's the data model? How do validation rules compose? What happens when fields depend on each other?

Technical users prompt imperatively: "Build a form builder where forms are defined as JSON schemas. Each field has a type, validation rules, and optional conditional visibility based on other field values. The schema should support nested field groups for multi-step forms."

The second approach constrains the solution space. The AI isn't guessing, it's implementing a specification.

So what did I build?

Quill is a production-ready form builder with real-time preview, sensible defaults, and just enough features to be genuinely useful for a small not-for-profit client of mine:

JSON schemas as the foundation

The architecture is a JSON schema approach to form definition. Every form is data: fields, types, validation rules, conditional logic, all expressed as structured JSON. Forms become portable, versionable, and completely decoupled from rendering.

When prompting the AI, I could specify exactly what shape the schema needed: "Text fields should support minLength, maxLength, and regex pattern validation. Dropdown fields need an options array with value/label pairs. Conditional visibility uses a simple expression language that references other field values."

The AI generates the implementation. I provide the specification. This only works if you know what a good specification looks like.

The expertise tax

The difference shows up in edge cases. Non-technical prompting gets you the happy path. Technical prompting gets you:

• How conditional logic cascades when multiple fields depend on each other
• What happens when a field's validation state changes while the form is submitting
• How multi-step forms preserve state when moving between steps
• When to validate eagerly vs. on submit vs. on blur

You can't prompt for these without knowing they exist. Domain expertise isn't just knowing what to build, it's knowing what to specify before problems emerge.

So...

The gap between "I want a form builder" and "I want a form builder with JSON schema-based field definitions, progressive disclosure for conditional logic, and ARIA-compliant error announcements" is the gap between a prototype and a product.

AI is a force multiplier for expertise, not a replacement. Knowing what to ask for, in precise technical terms, is what makes AI useful for building real software.

Try it at quill.flett.cc.