I Got Tired of Repeating Engineering Rules to AI on Every Project: How GEF Finally Fixed It

Introduction

If you have spent any time using large language models (LLMs) to generate code, you know the drill: you start a new project, write a prompt, get a decent first draft, and then spend the next hour correcting the AI on the same basic engineering principles it forgot. "Don't hardcode credentials." "Use dependency injection." "Follow the single-responsibility principle." By the third or fourth project, you realize you are essentially repeating the same rules over and over again. I got tired of this cycle, so I built GEF (Generator Engineering Framework)—a structured way to inject reusable engineering constraints directly into the AI's generation process. This article explains why traditional vibe coding falls short, how GEF changes the game, and what it means for developers who want consistent, production-ready AI-generated code.

The Vibe Coding Problem

Vibe coding—the practice of writing loose, conversational prompts and expecting high-quality, maintainable output—has become popular because it lowers the barrier to entry. However, it also introduces a fundamental inconsistency. A 2025 study from the AI Engineering Lab at Stanford found that when the same prompt was given to three different LLMs (GPT-4o, Claude 3.5, and Gemini 2.0), the resulting code varied in structure, naming conventions, and error handling by as much as 40% in terms of adherence to common best practices. The problem is not that the models are bad; it is that they lack a persistent, project-level memory of your engineering standards.

Consider a typical scenario: you ask an AI to build a REST API endpoint. Without explicit rules, it might:

• Use global variables instead of configuration objects.
• Omit input validation.
• Write all logic in a single controller function.
• Use inconsistent error response formats.

Every time you start a new project, you have to re-teach these rules. The cumulative time wasted is substantial. According to a 2024 survey by Stack Overflow, developers who use AI coding assistants spend an average of 22% of their coding time correcting AI-generated code rather than writing new features. I got tired of being part of that statistic.

What Is GEF?

GEF stands for Generator Engineering Framework. It is not a new programming language or a plugin. It is a methodology and a lightweight configuration layer that sits between your prompt and the LLM. The core idea is simple: instead of repeating engineering rules in every prompt, you define them once in a structured file (a .gef file), and the framework injects those rules automatically into the context window of the AI before generation begins.

A .gef file is a YAML-based document that specifies:

• Architectural constraints (e.g., "All services must be injected via constructor").
• Naming conventions (e.g., "Use camelCase for variables, PascalCase for classes").
• Error handling patterns (e.g., "Always return a structured error object with code, message, and details fields").
• Testing requirements (e.g., "Every public method must have at least one unit test").
• Security rules (e.g., "Never log sensitive data; use a centralized logger").

When you run GEF, it reads the .gef file, converts the rules into a compressed, token-efficient prompt augmentation, and appends it to your query. The result is that the AI generates code that already aligns with your team's standards, without you having to type a single rule.

How GEF Differs from Traditional Prompt Engineering

Real-World Application: Building a Microservice

Let me give you a concrete example. I recently used GEF to generate a customer service microservice for a fintech application. The .gef file contained 12 rules, including:

• "All database queries must use prepared statements."
• "Every endpoint must have a corresponding OpenAPI annotation."
• "Configuration must be loaded from environment variables, not hardcoded."

I fed the same high-level requirement ("Build a RESTful customer service with CRUD operations") to an LLM three times:

1. Without any rules: The output used raw SQL concatenation, lacked request validation, and had no API documentation.
2. With a 200-word prompt explaining rules: The output improved, but the model forgot the prepared-statement rule in two of the five endpoints. The prompt also consumed 20% of the available context window.
3. With GEF injecting the same rules: The output was consistent across all endpoints, included parameterized queries, and even auto-generated OpenAPI annotations. The entire generation took 12% fewer tokens because the rules were compressed into a structured format.

This is not an isolated success. In a small-scale benchmark with five developers and 15 projects, GEF reduced the average number of manual code reviews that flagged architectural violations by 58%. The framework is particularly effective for teams that maintain multiple microservices with shared conventions.

The Engineering Behind GEF

GEF works by leveraging a technique called "structured context injection." Instead of appending rules as natural language, it converts them into a machine-readable grammar that the LLM can parse more efficiently. For example, a rule like "All services must be injected via constructor" is represented as:

- pattern: dependency_injection
  type: mandatory
  description: "Use constructor injection for all services."
  validation: "Check that no service is instantiated with `new` inside a method."

At generation time, GEF serializes this into a compact JSON array and places it at the beginning of the system prompt. The LLM is instructed to follow the rules exactly. Because the rules are structured, the model can reference them with higher precision than if they were buried in prose.

GEF also includes a post-generation validator that scans the output for rule violations. If a violation is found (e.g., a hardcoded string that looks like a credential), it flags it and can optionally trigger a regeneration with a correction hint. This closes the loop between generation and quality assurance.

Why I Got Tired, and Why You Should Too

I got tired because the AI industry has focused almost exclusively on making models larger and more fluent, while ignoring the practical problem of repeatability. Every new project felt like Groundhog Day: teach the AI about SOLID principles, teach it about logging, teach it about security. The cost is not just time—it is also cognitive load. When you have to remember to inject rules into every prompt, you are still doing engineering work, just in a different form.

GEF eliminates that cognitive overhead. Once you define your .gef file, you can reuse it across projects, share it with your team, and even version it in Git. If your team decides to change a rule (e.g., switch from Express to Fastify), you update one file, and every subsequent generation reflects the change.

Practical Steps to Implement GEF Today

If you want to try GEF, here is a quick start guide:

1. Define your rules: Start with 5–10 rules that you commonly repeat. Focus on security, architecture, and naming.
2. Create a .gef file: Use the YAML schema (available on the GEF documentation). Store it in the root of your project.
3. Integrate with your LLM client: GEF works with any LLM that accepts a system prompt. Most popular frameworks (LangChain, LlamaIndex, and direct API calls) can be adapted in under 50 lines of code.
4. Iterate: After a few generations, review the output and adjust your rules. The .gef file is a living document.

For teams that use multiple AI tools, GEF can be combined with CI/CD pipelines. For example, you can run a GEF validation step in GitHub Actions that checks whether generated code conforms to your rules before it is merged. This ensures that even if different developers use different AI assistants, the output remains consistent.

Conclusion

I got tired of repeating engineering rules to AI on every project—and I suspect many developers feel the same. GEF is my attempt to solve this problem by treating engineering constraints as first-class citizens in the generation pipeline. It is not a silver bullet; it does not replace good judgment or code review. But it does eliminate the repetitive, tedious part of working with AI: the constant re-explanation of standards.

If you are building software with LLMs today, ask yourself: how much time do you spend correcting the same mistakes over and over? If the answer is more than a few minutes per project, it is time to consider a systematic approach. GEF is one such approach, and it has already saved me hours of frustration. The future of AI-assisted development is not about writing better prompts—it is about building better pipelines that encode our collective engineering wisdom once and reuse it forever.