Following up after over a year of productive work with LLM-powered software development, I can offer the following assessment: vibe coding works well in many areas, and progress is both continuous and rapid. Anyone who works with Claude Code, RooCode, OpenCode, Cursor, or GitHub Copilot will experience a productivity boost that goes far beyond the generation of boilerplate code. LLMs assist architectural decisions, new framework explorations, and complex algorithm design.

At the same time, recurring patterns emerge in daily work that point to systematic limitations. These limitations are neither random nor model-specific; they arise from a fundamental tension where probabilistic systems meet deterministic requirements. An LLM is optimized for the statistically most plausible next token, while an enterprise application demands global consistency across hundreds of files, layers, and data models.

How can we provide probabilistic systems with deterministic guardrails so they operate more reliably? Guardrails can be implemented at different levels: from pragmatic approaches like MCP servers and RAG, through deeper integration of compiler structures, to formal methods from symbolic computation. Let’s examine these approaches.

In this article, a product information management (PIM) system with automatic Shopify synchronization serves as the “stage” for vibe coding.

This article is divided into four sections:

• First, we’ll present a FASTCODE generator approach that provides a deterministic framework for vibe coding.
• Next, we’ll examine the two main use cases: the product information system and an automated Shopify synchronization with AI-powered image generation.
• Then, we’ll analyze why the combination of generator and LLM works, and describe systematic error classes we’ve encountered during the project.
• Finally, we’ll outline approaches that have the potential to fundamentally push the boundaries of probabilistic systems-from AST integration to formal verification to symbolic computation. These are explicitly not fully developed solutions, but are lines of thought and open research questions that indicate the direction the tools could evolve in.

FASTCODE instead of Low-Code – The meta-level

Anyone vibe coding a data-driven application will quickly realize that certain tasks repeat in every iteration: creating forms, wiring look-up fields, mapping relationships between entities in the UI, building in validations, configuring navigation. The LLM reliably handles each tasks on its own, but inconsistencies creep in across the whole system. A form may use a different field name than the adjacent list, a lookup accesses the wrong database field, or a relationship is correctly resolved in Tab A but forgotten in Tab B. Developers have to spend time correcting and harmonizing the LLM’s results. These are vibe coding’s trial-and-error loops.

The insight led us to FASTCODE. If eighty percent of a data-driven application consists of the same patterns over and over again-CRUD forms, relational navigation, filter logic, lookup resolution- that eighty percent shouldn’t be regenerated using AI for every project, but it should be correctly fed into a generator once and for all. The generator was partially created with vibe coding. It reads the database schema, understands relationships between the tables, and generates deterministic, type-safe application pages from them. What it generates is correct-not just probabilistically plausible, but structurally guaranteed.

In the process, Vibe Coding doesn’t disappear; it shifts to a more productive level. Instead of discussing the correct wiring of a lookup field with the LLM, now we work together on the generator’s architecture, on complex business logic, or integrations with external systems like Shopify. The LLM is deployed where its strengths lie, namely in creative, locally limited tasks. Meanwhile, the generator ensures global consistency, something the LLM regularly fails at.

The motivation behind this approach is nothing new. Thirty years ago, tools like PowerBuilder, Gupta SQL/Windows, and Microsoft Access made it possible to build data-driven applications in just a few days. These tools have since all but disappeared, but the gap they left behind has never been fully filled. Modern frameworks like React and Next.js offer tremendous flexibility, but they require significant development time for an internal CRUD application. Spreadsheet solutions and “smart tables” like Airtable and NocoDB provide quick solutions, but their weaknesses show when it comes to more complex relational requirements. A form of shadow IT often emerges. Business departments can’t wait for IT to act so they map out their processes in increasingly complex smart tables or even Excel files. These are difficult to audit and often depend upon a single person.

The FASTCODE Generator is designed to close this gap. It generates forms, “one-to-one” lookup fields, “one-to-many” lists, and tabs, as well as an N:M mapping user interface.

For the remaining twenty percent that go beyond generic patterns, the generator provides a type-safe extension system. Developers write “code-beside”-separate TypeScript files that sit alongside the generated code and are integrated via typed extension points. The generated code remains untouched and can be regenerated at any time without overwriting the hand-written logic.

The Pipeline: From Schema to Application

A PostgreSQL schema is our starting point. PostGraphile 5 handles the first step. This is an open source tool that connects directly to a PostgreSQL database, reads its structure, and automatically generates a fully-fledged GraphQL interface from it. It generates all queries, mutations, and filter and sort operators for every table and view without you needing to write resolver code. This provides typed queries for reading each table with pagination, filtering, and sorting; mutations for creating, updating, and deleting; and navigable fields across all foreign key relationships. PostGraphile compiles even deeply nested GraphQL queries into a single, optimized SQL statement. The N+1 query problem, which frequently occurs with manually written APIs, doesn’t exist here.

PostgreSQL-Schema

→ PostGraphile 5 → GraphQL-API (Querys, Mutations, Filter, Sorting)

→ GraphQL Codegen → Typed TypeScript Definitions (graphql.ts)

→ FASTCODE-Generator (Schema-Registry + TSX Templates)

→ Complete React application (Lists, Forms, Tabs, Look-ups, Navigation)

The GraphQL code generator generates typed TypeScript definitions. Listing 1 shows what the types of an entity may look like.

Listing 1: TypeScript type generated from GraphQL

export type Offering = Node & {

offeringId: Scalars\['Int'\]\['output'\];

price?: Maybe<Scalars\['BigFloat'\]\['output'\]>;

productDefinitionByProductDefId?: Maybe<ProductDefinition>;

materialByMaterialId?: Maybe<Material>;

formByFormId?: Maybe<Form>;

offeringImagesByOfferingId: OfferingImageConnection;

// ...

};

The relationships are already included in the type. For example, productDefinitionByProductDefId is not a separate API call, but a navigable field that PostGraphile resolves in the same SQL join. Similarly, there are typed mutations for each entity (Listing 2):

Listing 2: GraphQL Mutations

export type Mutation = {

createOffering?: Maybe<CreateOfferingPayload>;

updateOffering?: Maybe<UpdateOfferingPayload>;

deleteOffering?: Maybe<DeleteOfferingPayload>;

// ...for each additional entity

};

The FASTCODE generator processes these types and merges them with the introspected database structure to form a schema registry. This is a central data structure that documents, for every table, column, and relationship, the exact name of the database field, the corresponding GraphQL type, whether it is nullable, which foreign keys it has, and which inverse relationships reference it. This registry is the generator’s single source of truth, so that it can detect faulty configurations as early as build time.

TSX templates generate the complete frontend code from the registry. This produces a list, a form, the associated navigation, and the GraphQL queries for each entity. Data loading and caching are handled by TanStack Query, which combines the generated GraphQL calls with automatic cache management, background refetching, and optimistic updates.

In line with the Pareto principle, this covers eighty percent of a data-driven application’s requirements. The remaining twenty percent of the functionality is ideally suited for a combination of a deterministic generator and vibe coding.

Use Case: Product Information Management (PIM)

To illustrate the collaboration between Generator and Vibe Coding, let’s describe the system they created. From a business perspective, it’s used for centralized management and the sale of a specialized product range in the gemstone, natural products, and energy sectors. The Product Information Management (PIM) system serves as the connected online store’s data foundation. If you’d like to see the resulting shop in practice, you can find the system at this link here.

The Domain Model

The data model comprises around thirty tables and maps the entire supply chain: from suppliers and their offers through abstract product definitions to a multi-level categorization into product categories, product types, and main categories. Add onto this material-related dimensions that will later serve as filterable metadata in the Shopify store. Figure 1 shows an excerpt from the object model.

Fig. 1: Excerpt from the PIM object model

The Generated Application

FASTCODE generates a complete administrative interface from this model (Fig. 2), so we don’t have to write a single line of UI code for its basic functionality. Lists with configurable filters, detail forms with automatically resolved lookups, tabs for dependent entities, cascading lookups, and user-friendly mapping UIs for n:m relationships are generated deterministically from the schema. Where the generated forms aren’t enough, type-safe extensions are used.

Fig. 2: Generated Interface

As early as the development phase, a typical vibe coding pattern emerged. The LLM generated redundant TypeScript interfaces even though a structurally identical one already existed. This resulted in two types for the same concept that increasingly diverged from one another. This is a classic example of a lack of type unification (see the “Error Classes” section).

Use Case: Shopify Synchronization – Multidimensional Product World

While the PIM handles internal management for suppliers, offers, product definitions, and categorization, all sales occurs via a Shopify store. An automatic synchronization process bridges the two worlds and transfers the products, along with their multidimensional categorization, to Shopify via Shopify’s GraphQL API. Vibe coding both helped us enormously in this sync, but also revealed its limitations.

The Sync Pipeline

The sync process goes through three phases in a fixed order, with each phase producing results that are consumed by the next. The product and image syncs calculate fingerprints from the relevant product fields and the image, respectively, and synchronizes only the changes. Phase 3 generates Shopify Collections from the existing products.

The Sync Pipeline

Phase 1: Image Sync

• Local product images → Shopify CDN
• Result: an index that maps each local image path to its CDN URL

Phase 2: Product Sync

• PIM offerings → Dimension resolution → Shopify products with meta fields
• Uses the image index from Phase 1 to map product images
• Delta sync: only changed products are synchronized (fingerprint comparison)

Phase 3: Shopify Collection Sync

• Synchronized products → Bottom-up collection generation
• Generate and upload collection images via fal.ai
• Store the navigation structure as JSON meta fields on the collections

Deep PIM Model vs. Flat Shopify Model

Shopify offers a flat product structure by default: title, type, tags. But our domain model works with multiple independent dimensions that describe a product simultaneously (Table 1). These dimensions are synchronized as Shopify meta-fields and form the basis for faceted navigation and filtering in the store.

Table 1: Shopify Product Dimensions

Shopify Collection Generation

Shopify organizes products into collections, where product list pages are rendered in the Shopify storefront. We generate the collections from the actual products and their dimensions. A declarative configuration specifies which combinations of dimensions should exist as collections (Listing 3).

Listing 3: Configuration of Collection Dimensions

export const COLLECTION_CONFIG: DimensionKey\[\]\[\] =

\[

\["mainCategories"\], // "Gemstones"

\["mainCategories", "productTypes"\], // "Gemstones > Beads"

\["mainCategories", "chakras"\], // "Gemstones > Heart chakra"

\["mainCategories", "essenceName"\], // "Gemstones > Amethyst"

\];

During synchronization, all synchronized products are processed, their dimension values are extracted, and only the collections that products already exist for are generated. The resulting navigation structure is comparable to an OLAP cube. The user navigates by drilling down from the main category into greater detail and can switch the viewing dimension at any level (Fig. 3).

Fig. 3: Multidimensional shop navigation

Image generation with fal.ai – AI beyond vibe coding

Vibe Coding isn’t the only place where AI saves time in this project. Every Shopify collection needs a representative image. With dozens of collections, manual assignment would be too time-consuming and involve searching for or creating images, cropping, uploading, and assigning them. Instead, we fully automate image generation via fal.ai using the Flux model, at a fraction of the cost and time. A prompt builder generates context-dependent image descriptions based on the respective dimension combination.

Vibe Coding Lessons from the Shopify Sync

Two particularly instructive error categories emerged with the Shopify Sync. For instance, the LLM repeatedly generated GraphQL mutations using an older Shopify version’s API syntax, even though we explicitly specified the current API. Older versions simply appear more frequently in the training data, so the probabilistic “next token” model tends to favor them. During refactoring, log and trace statements that were essential for debugging the sync pipeline regularly disappeared. The LLM treats them as non-functional code and removes them without realizing that a sync process handling hundreds of products simply cannot be maintained without detailed logging.

The deterministic framework: why generators and LLMs are complementary

The experiences from the PIM and the Shopify Sync coalesce into a pattern that extends beyond individual projects. In some tasks, an LLM reliably delivers good results, while in others it causes a trial-and-error loop. The dividing line doesn’t run between “simple” and “complex,” but between local and global.

Locally scoped tasks-implementing a function, designing an algorithm, writing an extension, and formulating a prompt-work exceptionally well with vibe coding. The LLM has a complete grasp of the relevant context, can work creatively and efficiently, and delivers results that developers often need to only marginally adjust. Our PIM’s entire business logic, the Shopify integration, image generation, and the mapping changes were all created with substantial LLM support, and much faster than would be possible without it.

Globally consistent tasks, on the other hand-like ensuring that dozens of tables are consistently resolved, layer separation is maintained across many files, and type declarations are not duplicated-can overwhelm the LLM. The reason for this lies not in lacking performance, but in the architecture. The context window is finite, and the optimization goal is the next token, not system consistency.

The FASTCODE generator addresses this weakness by structurally eliminating key error sources. Layer separation is firmly embedded in the templates and cannot be bypassed. Strict adherence to the extracted GraphQL and database schemas ensures that no incorrect types, properties, or relationships are used. Most errors are detected at build time.

What remains is precisely the area where the LLM demonstrates its strengths. For example, the mapping chain between PIM and Shopify was developed iteratively in dialogue with the LLM. We described the business problem, the LLM proposed architectures, and we evaluated and refined them. If the LLM took a wrong turn in the process, damage was limited because the deterministic framework set the boundaries. A faulty mapping function cannot disrupt the entire application’s layer separation because it is anchored in the FASTCODE generator, not in hand-written code.

Developers stay within the architect role and pilot throughout the process. They delegate subtasks to the LLM but keep the big picture in view and retain decision-making authority. This does not represent a step backward from the promise of autonomous vibe coding. It’s a variant that can be implemented in practice.

Types of AI Challenges

The following nine classes repeatedly recurred during the development of FASTCODE, the PIM, and the Shopify sync. They aren’t random bugs, nor are they model-specific, as we observed them across different LLMs. We’ve classified them according to the nature of the underlying failure and outlined why they arise from the architecture of probabilistic systems.

Class 1: Violation of structural invariants (architectural mix)

In our PIM, there are operations that must be executed server-side within a database transaction, like a cascading delete, where all dependent records are analyzed before the actual deletion, or a “Copy & Link,” where a record is duplicated and simultaneously linked to the original. Both operations are implemented as backend endpoints since they require transactional safety and atomic behavior. However, the LLM tended to implement this logic directly in the frontend code using individual, non-transactional API calls. The point is less about these specific examples and more about the underlying pattern. The LLM optimizes for the functional correctness of generated code without taking the system’s architectural invariants into account. Layer separation is a property of the overall system, not of the individual code block. That’s exactly what makes it difficult for a token-based model to grasp.

Class 2: Lack of type unification (redundant interfaces)

The LLM generates a new interface even though a structurally identical one already exists. Both types run in parallel, must be kept in sync, and subsequently diverge. The LLM fails because of structural identity. It doesn’t recognize that two syntactically slightly different declarations represent the same type semantically. A canonization step that checks before code generation if an equivalent type already exists in the codebase is missing.

Class 3: Semantic escape via type casting (any-laziness)

Instead of guaranteeing correct generic typing throughout the entire derivation tree, the LLM sometimes casts more complex types (generics, union types, indexed types) to any. The compiler doesn’t flag this and the code compiles. Type safety is compromised and errors caused by newer framework versions only become apparent at runtime. The LLM takes the path of least resistance. An any cast resolves the local type conflict, while the correct solution might involve multiple files and type parameters. The result is a compromise of global type correctness in favor of local consistency.

Class 4: Temporal inconsistency (version mismatch)

The LLM generates code for an outdated library version, even though the current version was explicitly specified in the system prompt. During the Shopify sync, this resulted in GraphQL mutations using field names from the 2024 API, even though we were using the 2025 version. The cause is statistical. Older API versions occur more frequently in the training data and the probabilistic language model prefers to use common patterns. There is no mechanism to explicitly exclude outdated facts from the inference.

Class 5: Lack of normalization (code duplication)

The LLM implements a new helper function even though one with identical logic already exists. Since it relies on token similarity and cannot check for functional equivalence, it fails to recognize that a subtask has already been solved by an existing function. Two functions can have different names, contain different code tokens, and still be semantically identical. This insight lies beyond what a purely token-based model or a RAG with semantic search can reliably achieve.

Class 6: Complexity blindness (O(n*m) instead of O(n+m))

When assigning products to collections, code generated by the LLM iterated over all products and checked each one against all collections for a match, resulting in a nested loop with a complexity of O(n*m). A precomputed index would solve the problem in linear time. However, the LLM is optimized for the next token, not for algorithmic complexity. The code was correct, but its runtime scaled poorly.

Class 7: arbitrary deletion (non-monotonic behavior)

Log statements, debug output, and tracing code disappear during refactoring. The LLM considers them non-functional and silently removes them. It lacks a model for distinguishing between essential and incidental lines of code. While logging is non-functional in terms of business logic, it’s essential for maintainability. A synchronization process that synchronizes hundreds of products with an external API is difficult to debug without detailed logging. Formal specification would need to define which code properties should be preserved during transformation-a kind of post-condition for refactorings.

Class 8: Semantic context loss (Short-term memory)

The LLM “forgets” key definitions it had previously correctly used in the same session and instead generates a new, incompatible data structure. The context of an LLM is not a symbolic state, but a sliding window of probabilities without a true persistence model. We need a single source of truth that serves as a reference throughout the whole session that validates against every generation step-similar to a proof assistant in formal verification.

Class 9: Missing Guards (Null/undefined Logic)

The LLM generates code that accesses potentially empty values without checking them first. While the standard case works, edge case leads to a crash. The necessary safety checks are missing because they occur statistically less frequently in the training data than the successful code path. A formal approach would immediately reject code as unprovably correct since the precondition is not guaranteed.

Guidelines for probabilistic systems: From the pragmatic to the formal

We can address these nine error classes through better prompts or larger context windows, but that’s not the sole solution. We can also use tools and methods that operate at different levels. Let’s outline these three levels, ascending in depth and ambition.

In the World of LLMs: Context Enrichment and Agentic Tool Use

The next level works with tools given by the LLM ecosystem itself. In my previous article, we described the underlying mechanisms in detail: the four layers of context provision (local index, semantic index, RAG, LLM), the Model Context Protocol (MCP) as a structured interface to curated knowledge, prompt caching as an economic enabler, and the generate-validate cycle with AST integration.

To sum it all up, MCP allows architectural specifications, quality rules, and codebase knowledge to be given to an LLM via dedicated servers. RAG, in turn, enriches the context with relevant information from external sources. Both mechanisms complement each other. MCP defines the protocol; RAG describes the pattern. In both cases, the result ends up in the LLM’s same context window.

However, this context enrichment only becomes decisive with agentic tool use. The LLM recognizes what information it’s missing and actively requests it. For example, it may determine that it lacks current API documentation and retrieves it, instead of the client needing to “guess” this in advance. The difference between passive information provision to the model and one that fetches what it needs makes context retrieval significantly more precise and directly addresses classes 4 (version mismatch) and 5 (code duplication).

These are pragmatic approaches that can be implemented today. While they mitigate symptoms, they don’t address the root cause yet. The LLM remains a probabilistic system that cannot provide any structural guarantees. It may ignore the MCP server or misinterpret the RAG result. Error rates decreases, but the error classes do not disappear.

Deterministic Integration: Language Servers and AST Structures

An even deeper level addresses the interface between the LLM and the deterministic tools present in every modern IDE: language servers, compilers, and type checkers. Today, these tools operate downstream. They analyze code the LLM has already generated and report errors after the fact.

Pioneers like Cursor and RooCode have already taken promising first steps by actively integrating language server diagnostics into automated validation loops (Generate-Validate). They feed linter errors and compiler warnings directly back to the model, so that the LLM can use deterministic feedback to iteratively correct its generated code before developers need to intervene.

The key step is integrating these deterministic structures into the code generation process itself. If the LLM has access to the Abstract Syntax Tree (AST) for the existing codebase during code generation, it can answer structural questions before writing code. Does this type already exist? Is this field nullable? Which imports are valid? The compiler’s type inference can be incorporated into the generation as a constraint, rather than only appearing afterward as an error message.

This differs from static analysis tools or “code tomographs,” which operate on code that’s already been written. While these tools are valuable, they inherently work too late for our given use-case. The code has already been written and architectural decisions have already been made. What we need isn’t better diagnosis, but prevention. We need deterministic guardrails that can restrict the space of potential generation results before generation, not after. Here lies the natural interface between AI research and compiler construction.

Formal Methods: From Generate-then-Check to Symbolically Guided Generation

The third level goes beyond practical software development and touches on fundamental computer science questions. Error classes 6 (complexity blindness) and 7 (arbitrary deletion) cannot be fully resolved either through better context provision or through AST integration. They need a system capable of formally reasoning about generated code. Is this algorithm equivalent to the previous one, only more efficient? Are all invariants preserved in this transformation?

Harmonic Aristotle, an AI agent for formal mathematical proofs, provides a specific example of just how far formal verification combined with LLMs has come. The principle behind it is that the LLM generates proof steps, which the Lean compiler formally verifies. Anything that cannot be proven is discarded, and a new attempt is made.

Aristotle impressively demonstrates that combining probabilistic generation and formal verification works, but it also highlights the current approach’s limitations. The system operates heuristically in a “generate-then-check” mode. It tests something out, checks the result, and discards it if necessary before starting a new attempt. Every failed attempt costs computing time. Furthermore, so far it only works for mathematics, not for software architecture.

However, its actual vision goes a step further. For decades, research into symbolic computation, computer algebra, and automated proof focused on methods that systematically narrow down solution spaces before the search begins. Professor Bruno Buchberger, founder of the Gröbner basis theory, is pursuing an approach with his Theorema system at the RISC Institute at JKU Linz to automate mathematical reasoning-not as a post-hoc verification, but as a constructive process. The core of the Gröbner basis method-transforming a system of equations so solutions can be systematically derived instead of found with trial and error-is precisely the principle that can apply to code generation.

Instead of generating heuristically and then checking, symbolic methods could narrow down the solution space before generation. This way, the LLM would follow only the correct paths from the outset. A symbolic reasoner wouldn’t validate the finished code, but guide the generation itself.

This would result in qualitative improvements as well as enormous resource savings. Fewer failed attempts means fewer tokens, fewer interference calls, and lower power consumption.

This would not only result in a qualitative improvement but also in enormous resource savings: fewer failed attempts mean fewer tokens, fewer inference calls, and lower power consumption. In an industry that’s increasingly discussing data centers and energy consumption, is no minor issue.

Europa – quo vadis?

These considerations raise a question about Europe’s position that goes beyond technical matters. Europe has likely lost much of the race for the largest language models and the most powerful data centers because of a less developed venture capital scene and regulatory caution. The question is if this means that now we’re merely consumers of models and platforms that the United States and China impose on us.

However, the nine error classes show that raw model performance isn’t everything. Disciplines like formal verification, compiler construction, and expertise in symbolic mathematics and automated proof have a long tradition and an active research landscape in Europe. If the future lies not just in scaling parameters, but also in combining probabilistic models with symbolic, deterministic methods, then Europe has trump cards it can play.

This is also a cultural issue: it’s the master-apprentice-master cycle. If we developers increasingly delegate tasks to LLMs without penetrating the underlying structures, we’ll eventually lose the mastery we need to develop the next generation of tools. The deterministic framework-either as a code generator, an AST-integrated type system, or a formal prover-is a tool that works against this creeping competence loss. It forces us to understand the architecture before we delegate it to a probabilistic system.

So the real question is not about building the largest models. The question is about if we’re building the tools that make these models reliable.

Conclusion

Probabilistic language models are excellent tools for local logic, but they often fail when it comes to the global consistency of complex applications. A practical solution lies in establishing deterministic guardrails-from code generators to AST integration to formal methods. Vibe coding can only be reliably scaled in an enterprise context with sacrificing technical mastery when developers define the architecture and the system enforces it structurally.