The Real Problem with AI Coding Tools (It's Not What You Think)

Three months ago, I was working with Cursor on a fresh project. The AI was genuinely impressive—it understood my codebase, suggested clean solutions, and saved me hours. By week two, I was frustrated enough to close the IDE and just write the code myself.

Here's what happened: I'd establish a pattern—proper error handling, documented decision-making, test-first thinking—and the AI would follow it perfectly for a day. Then it would drift. A function would balloon to 200 lines. A critical decision would be implemented without any Architecture Decision Record. Tests would be skipped "for speed." I'd remind it of the rules. Repeat. Repeat again.

The worst part? I realized I was spending more energy training the AI to follow my engineering standards than it was saving me in development time. I wasn't collaborating with a tool; I was babysitting one.

The Root Cause Nobody Talks About

Most AI coding tools work within a context window. They're stateless. They don't have memory of your project philosophy because your project philosophy exists nowhere but in your head and scattered across conversations. Every new chat is a fresh blank slate.

That's the insight that struck me about GEF. It's not revolutionary—it's just pointing out something obvious that we've somehow normalized: we've been solving the wrong problem.

Instead of training AI better, GEF embeds the rules directly into the project itself. Git hooks enforce conventions. CI/CD pipelines validate practices. Cursor rules live in your repository. The engineering standards become part of the code, not just something you repeat in prompts.

What GEF Actually Does (Beyond the Hype)

The framework generates more than just boilerplate. It creates:

• Git hooks that prevent bad commits before they happen
• Conventional commits setup so commit history stays parseable
• PR templates that guide code review discipline
• Architecture Decision Records as a first-class citizen, not an afterthought
• AI-specific rules that configure Cursor, Windsurf, and other tools to respect your boundaries

The elegant part is that none of this is hidden in IDE extensions or external services. Your project rules live in your repository. An engineer on your team, or an AI pair programmer, encounters the same constraints immediately.

My Take: The Good and the Honest Questions

I'm genuinely interested in this approach. The problem it solves—AI drift from your standards—is real and I've felt it acutely.

But I have some friction points. First, there's a false assumption that engineering rules are universal. My team's architectural preferences might conflict with yours. GEF provides a scaffold, but the real work is still deciding which rules matter for your specific context. It's a starting point, not a solution.

Second, tool dependencies matter. Right now, this works well with Cursor and Windsurf. But what happens when you need to integrate with a different AI tool in six months? The framework needs to abstract the rule definitions more completely.

Third, I'd want to see how this scales across teams. Can junior developers accidentally disable critical rules? Can you enforce when ADRs matter versus when they're overkill? The solution works best if it's opinionated but has escape hatches.

What I'd Actually Use From This

If I were setting this up on a project tomorrow, here's what I'd keep:

The git hooks that enforce conventional commits—that's non-negotiable and saves real friction in CI/CD pipelines. The PR template is table stakes. The ADR structure is genuinely useful because it forces documented thinking before implementation.

The AI prompt configuration is what intrigues me most. If I can encode "never implement security-related changes without tests" and "document performance assumptions" as project rules rather than conversation reminders, I've fundamentally changed how the AI behaves.

The Actual Question This Raises

GEF suggests we've been thinking about AI tooling wrong. We've treated them as smart text generators that we need to guide. But what if the problem was always infrastructure?

What if instead of better prompts, better models, or better context windows, we just needed engineering discipline baked into the project itself? Then the AI's job becomes simpler: follow the established structure.

I'm curious whether this works in practice on a six-month project with three developers and two AI assistants collaborating. Does the governance feel enabling or restrictive? Does it catch real problems?

Have you tried embedding your engineering rules directly into your projects? Do you use something like this, or are you still in the "repeat the rules to every tool" cycle?

Source: This post was inspired by "I got tired of repeating engineering rules to AI on every project. So I built GEF." by Dev.to. Read the original article