async function isOdd(n) {
const response = await chatGpt("Is the number ${n} odd? Answer only YES or NO");
return response === "YES";
}
For some time now, a certain type of joke has been circulating on social media where an LLM is used to determine whether a number is even or odd. The multidisciplinary nature of these models, which, by the way, are incredible, allows them to be used to solve all kinds of problems; however, it is necessary to ask whether their use is appropriate in every situation. In cases like this, it is obvious that the solution is incorrect: it isn't guaranteed to work 100% of the time, and it is certainly not efficient. Nevertheless, in other scenarios, it is not always clear whether using an LLM is the optimal solution.
When we focus on the use of language models for application development, the trend is clear: the use of LLM-assisted code generation is becoming the standard, not just for sporadic development but integrated into engineering processes and top-tier corporate environments. It is precisely in these cases where asking, "Am I applying the optimal solution?" becomes most valuable.
The alternative is not new; we have had code generation tools for many years, such as template-based or model-based generators. These are declarative generation tools. Their most relevant functional characteristic is their deterministic nature: given a specific input, they always produce the same result. This is a highly valued trait in software development as it ensures reliability in the generated code. Their main advantages are significantly lower costs and higher performance compared to an LLM. On the other hand, these tools are incapable of improvising; they cannot provide solutions that haven't been previously defined.
In short, we have two code generation tools, LLMs and declarative generators, each with its own pros and cons.
However, not all code in an application is the same. To simplify, we can distinguish between two categories: structural code, which defines the application's foundation (including integration components, configurations, and other common artifacts), and business logic code.
The former, structural code, is distinct because it is predictable, maintains a homogeneous and well-defined structure, and usually accounts for a larger percentage of the total codebase. This code is ideal for declarative generation tools, offering low-cost and high reliability.
On the other hand, business logic code is application-specific and unpredictable. This type of code is impossible to cover with declarative generators; however, language model-based generators can produce it successfully.
Combining both types of generation tools to cover an entire application creates a synergy. The output of the LLM is reinforced because its scope is narrowed, and it is fueled by the context provided by the structural code created by declarative tools.
Reducing the scope of the non-deterministic component leads to a result that is generally more reliable, secure, and potentially less prone to errors. The question I leave on the table is whether, with the rise of AI, we are casting aside the elegance of deterministic generation solutions.
Top comments (1)
Over the past two years, we’ve focused heavily on reducing the amount of non-deterministic logic in software generation by constraining LLMs with contracts, registries, gates and deterministic rules so that code generation becomes more reliable, efficient and scalable.
I think the probabilistic vs deterministic framing captures one of the most important tensions in AI-native software engineering and in many ways, we’re already late.
We cannot scale software engineering by simply introducing more AI variability into code.
LLMs are probabilistic inference engines. Asking them to repeatedly decide structural facts in a software system is a costly mistake.
While deterministic systems, enforce invariants so they guarantee that the same input produces the same output. They are the backbone of any serious engineering discipline.
At CodeFlow Lab, we solved this tension by refusing to let probabilistic systems produce authoritative facts. The LLM proposes, the deterministic compiler decides and the registry governs, the gates verify and the artifact proves.
You don’t let a model emit routes, entities, props or API calls. Those are facts which must have a single source of truth.
If you let a model generate them, you get exactly the defects we’ve seen across the industry: duplicated types, mismatched schemas, divergent route tables and artifacts that contradict their own contracts.
We've built a system where probabilistic intelligence → Candidate structure and
deterministic compiler → Authoritative code.
Would love to have your perspective on what we're building code-flow-lab.com