When the how is no longer the bottleneck
then what exactly are we trying to build?
I once built a CRM with Fable in like three or four hours. I did not do much. I gave it one broad prompt, asked it to do a pre-flight for every key or access it would need, and told it not to stop until I could test the CRM end to end.
Within a few hours, I had the SMS booking flow built, owner notifications working, and a Stripe test payment completed. The live voice agent came later that night. I understood the workflow, but Fable figured out most of the implementation.
That made me think: if the how is no longer the bottleneck, then what exactly are we trying to build?
Imagine if next year everybody has Fable for almost free. You may not need every nitty-gritty detail to build an app. But if everybody has the same model, why are some people going to build much better things than everyone else?
The map is not the territory
The first article that made me think about this was Thariq’s “A Field Guide to Fable: Finding Your Unknowns”. The prompt, skills, and context we give the model are the map. The territory is the real product, user, codebase, and its actual constraints.
The gap between the map and the territory contains four kinds of knowledge. Known knowns are basically what we put into the prompt. Known unknowns are the questions we already know we have not answered. Unknown knowns are things we do not think to write down but would recognize immediately. Unknown unknowns are the possibilities, limitations, and failure modes we have not considered at all.
I think UI and UX are full of unknown knowns. Sometimes you cannot explain the exact layout, interaction, or feeling you want. But once you see the work, you can say, “This is something I would probably want to dive deeper into,” or, “The format is not as good.”
The surprising capabilities of the model are different. If you do not even know it can create a certain interaction or combine tools in a certain way, that is an unknown unknown. You could not have requested it because the possibility never occurred to you.
Until you see the product or the work done, you are often not able to give better instructions.
This is where experienced engineers still have an advantage. They carry more tacit knowledge about infrastructure, failure modes, and what good looks like. But a non-coder may understand the customer, the workflow, and the ideal experience much better. The model can turn both forms of knowledge into questions, prototypes, references, and choices. Maybe the new skill is continuing to discover what you do not know instead of already knowing everything.
What kind of instructions do we give?
The second article was sysls’s “What the New 100x Agentic Engineer Looks Like in the Era of Fable & GPT 5.6”. One part that stayed with me was the difference between declarative and imperative preferences.
Declarative instructions describe what you want to be true. You define the outcome, the boundaries, and the ideal state, then let the model decide how to get there. Imperative instructions describe the path. You use them when the order, method, or process itself matters.
My CRM prompt used both. The declarative part was: customers can book, the owner gets notified, and I can test it end to end. I did not prescribe the database or how Twilio should connect to Stripe. The imperative part was: do a pre-flight, ask for every key, and do not keep stopping halfway through.
The more capable the models become, the more useful declarative instructions will be. That does not mean being vague. Without boundaries, the model fills the gaps with assumptions. But if you prescribe every step without knowing enough, you can lock a capable model into your own bad solution.
The skill is choosing the right mix: what you care about, which trade-offs are non-negotiable, and which parts should stay open so the model can show you something better.
The new gap between vibe coding and the 100x agentic engineer
I do not know if anyone is literally going to become a 100x agentic engineer, but it is definitely gonna be more. The same model in two people’s hands can already produce very different results.
A beginner may only know the outcome they can see. A vibe coder can produce something impressive quickly, then accept the first plausible result because they do not yet know what good can look like or what could be missing.
The next level is using the model to dig deeper. Ask for a blind-spot pass, the decisions that would change the architecture, or four different prototypes when you cannot describe the UI. Give it references. Let it interview you. Ask it to explain the data flow back to you.
An experienced engineer still starts with an advantage. They know more about infrastructure, security, maintainability, and which small decisions could become expensive later. But I do not think a non-coder is locked out. AI can teach the foundation, identify missing questions, and turn experience with a real workflow into technical instructions.
Maybe the gap now depends less on who can write the code and more on who can move information between the four boxes. Can you turn an unknown unknown into a question? Can you turn something you only recognize when you see it into a preference? Can you decide whether that preference should be declarative or imperative?
That is what makes the agentic power user more powerful. They steadily reduce the amount of important information the model has to guess.
A practical way to move up
The framework that has been most useful for me is the ideal state and the current state. What should the final experience be? Where are we now? What is the gap between the two?
Then ask the model to uncover the unknowns inside that gap. Do a blind-spot pass. Show different possibilities. Ask which decisions would materially change the result. For UI or UX, make prototypes before wiring up the whole product.
Next, decide what belongs in declarative instructions and what needs an imperative process. Describe the final user experience clearly. For payments, private data, or verification, give stricter instructions about review and testing.
There are also some things you can not escape. You may not need to write the code, but understand how information is processed from one place to another. Where does the input come from? What does the service return? Where does the output go? What does the customer finally see?
Finally, test the real thing. Once you see the product working, failing, or surprising you, you have new knowns. Feed them back into the next prompt, skill, or workflow. That is how your map slowly becomes closer to the territory.
What exactly are we trying to build?
If everybody has Fable almost for free, implementation may become available to almost everyone. But that does not automatically give everyone the same judgment, taste, curiosity, or ability to ask the missing question.
The advantage will belong to people who can define the destination and keep discovering what they did not know about the road. The question of the future may not be whether we can build it. It may be whether we know what we are actually trying to build.
Till next time, Cheers!
Previous column articles can be found here: