"Bumpy roads lead to beautiful places"
- Senior Director @ Oracle 🧑💻
- #orclapex fan since '99 🛠️
- https://spendolini.blog 💻
- Oracle Ace Alumni ♠️
- Bleed Syracuse Orange 🍊
- Golf when I can ⛳️
- Austin, TX 🎸🍻
- Views are my own 🫢
In his article, “DSLs Enable Reliable Use of LLMs”, Unmesh Joshi argues that specifications are hypotheses rather than finished blueprints.
That perspective contrasts with the many people touting the benefits of spec-to-code development with LLMs, where the specification is treated as the “source of truth.”
I can’t help but agree with him. In 15+ years of consulting and another 15+ years working at Oracle, I’ve yet to see the perfect specification from anyone. Some have come fairly close, but every one required some level of revision.
That’s the problem with treating a specification as a finished blueprint. For the past few months, I’ve heard repeatedly that the specification is supposed to be the source of truth: complete, perfect, and flawless. If you generate an application and it doesn’t quite come out right, the advice is to update the specification and re-generate.
While that sounds great, it’s not the reality most of us live in. Development comes with real constraints such as time and money (or tokens, these days). In theory, if I know exactly what I want and can articulate it perfectly on paper, then my application is just one click away. But while LLMs are getting better all the time, humans remain fallible. We forget things, describe them incompletely, or simply don’t have time to be thorough. Hence, any specification we produce is, at best, an approximation or hypothesis.
So are specs still worth it?
Yes—absolutely. Any effort you put into a specification will pay off during the generation phase of your application. And the more that can be offloaded to stakeholders, the better. Let them discuss and resolve how an application should work, including workflow specifics. I've never found it productive to sit in a room where stakeholders argue about cosmetic changes involving their application. It's way more productive and less stressful to let them hash through this without being involved.
Once the stakeholders believe that they are done with their specification and have clarified the initial workflows and domain decisions, that specification becomes a solid starting point and can be used to generate the initial application. Once that's done, it's time to polish the application and fill in the gaps. Users will undoubtedly have feedback on what works and what doesn’t.
You can continue to use an LLM and APEXlang during this phase, switch back to the Application Builder, or use a combination thereof. No matter which way you choose, you've already gotten a head start over a traditional development process, as the LLM has hopefully generated the majority of the application.
The specification gets you started; traditional iteration helps you cross the finish line.
How a DSL like APEXlang helps
When using APEXlang, the LLM generates APEXlang files rather than unrestricted general-purpose code, and those files must be properly formatted to compile. That is the core advantage of the APEXlang-as-a-DSL approach: the language provides a constrained vocabulary and a finite set of supported constructs, giving the LLM fewer ways to express the same intent and less room to invent unsupported components.
The compiler acts as a deterministic validator, so malformed output can be rejected and corrected as part of the generation loop. In the best case, the resulting errors are expressed in terms of the language or application domain rather than buried in generated implementation details.
Nudge your users to consider their specs as solid starting points, not the be-all and end-all. Show them just how close you can get with generative development and well-written specs. As a developer, it's in your best interest to ensure that your users spend quality time with the spec, regardless of how close the results will be.
If you embrace this approach, you’ll reset expectations to a more realistic level when it comes to specifications, while still being able to greatly increase the velocity of your development teams.
Title photo by Vitaly Gariev on Unsplash
