It’s been a month since I began executing the AI-first development plan for Eibria. The journey so far has been frustrating at the edges and exciting at the core.
As I move from the successful execution of my first product journey to the next, I have seen a dramatic shift in how I interact with AI in product development.
And central to that interaction has been understanding the difference between perfectionism and exactness.
Perfectionism is a myth
A perfect AI has these characteristics:
- It doesn’t hallucinate (never sees a constellation when there are only stars)
- It is deterministic on each run (like building a batch of cars in an assembly line)
- It is fault-tolerant (forgives our trespasses in prompts)
Such a perfect AI has not been invented, at least not as of this date.
After six months of rigorous prompt engineering aimed at achieving this holy grail, the realisation is now seeping in.
AI-first systems are not about building the perfect intelligence. It’s about achieving a high probability of repeat behaviour.
In other words: how do you design needs + constraints so the system behaves repeatably, even if the LLM itself isn’t deterministic?
Thinking inside the box
Where perfection is a myth, exactness is possible at the boundaries.
That exactness is the balance between allowing AI to drift (being creative) and staying within acceptable boundaries (being reliable).
I call it ideas with constraints.
And this thinking has been very helpful to me in building a rigorous AI-first system that:
- is loyal to “halt”, even when the grass is greener on the other side
- is smart enough to know that it can be ignorant and builds checks and balances to self-improve
- and is disciplined to scale slowly but surely (a hard-learned realisation, because it is very difficult to be slow with AI).
An AI-first system works when you give AI a garden, then have it build a fence, and let it play within that fence.
But how do you build such a garden?
It’s not prompt engineering, silly!
A prompt is useful as long as it is a one-off query.
And 200 lines of prompt do not make a system.
In Eibira, this ideas with constraints approach uses the SDD (spec-driven development) framework.
SDD helped me move beyond prompt engineering to thinking more broadly about building an AI native development architecture.
An architecture that allows exactness via contracts, invariants, templates, and policies, and brings them together through a process that AI intuitively understands.
My goal with Eibira is simple. As a bootstrapped start-up, I need AI to carry the tech load. And SDD seems a dependable bet.
If you are interested in learning more about Eibira’s SDD framework, let me know, and we can exchange notes.
Found this helpful?
If this article resonated with you, please share it on LinkedIn to help me spread the word on Mindful Productivity.
Related article:
Nikhil Kabadi 