The AI code dilemma and generative friction

Where I am at

In the past months, AI-assisted development has turned from a thing that I sometimes used until I got fed up with it to more of a daily routine. Whether it’s Copilot, Cursor, or Gemini, these tools are now living inside our IDEs, CI/CD pipelines, versioning systems, command lines, and beyond. For those of us building test frameworks and internal tools, the temptation is huge because so much of our work involves the glue that holds things together. This includes things like scaffolding, adapters, and configuration layers. These are exactly the areas where LLMs perform convincingly well.

But after using them for a while, I’ve started to realize that the question isn't whether they work or not. The real question is how this is shaping the way we build systems in the long run and whether we are losing our grip on the architectural intent.

Statistical and intentional gaps

When you’re building a framework, your design decisions often come from previous failures or specific environment constraints that aren't yet written down in the code. An LLM only knows what's in the current context window. It produces code that is statistically plausible. It looks right and it compiles, but it might subtly violate the way you actually want the system to behave.

For instance, you might have a specific way of handling domain exceptions to keep your reporting clean. However, the AI will suggest a generic runtime exception because that’s the most common pattern it saw during training. It isn’t a dramatic failure that breaks the build. Instead, it is a slow drift that weakens the integrity of your framework over time.

Pressureless abstraction

In my experience, abstractions usually emerged because we hit a point of friction. You get tired of writing the same adapter three times, so you finally formalize it. The abstraction is justified by actual experience.

AI tools tend to work backward by jumping straight to Industry Standards. If you ask for a component, it might give you configurable constructors and interface-based decoupling even if you don't need that level of complexity yet. This completely ignores the YAGNI (You Ain't Gonna Need It) principle. You end up with premature abstraction that adds cognitive load for no real reason.

Consistency is the number one thing that keeps code maintainable. When you let an AI decide the structure, you lose that consistency because it suggests what is statistically common rather than what fits your specific project. You’re essentially building a complex solution before you even know what kind of problem you’re solving.

Local speed and systemic flaws

Test frameworks don't live in a vacuum. They have to play nice with GitHub workflows, Docker containers, and reporting tools. A human engineer usually knows that a certain concurrency model might cause issues in your specific GitHub Action runners because they've seen it happen before.

An AI, however, optimizes for the immediate task at hand. It wants to give you a working function right now. It doesn't simulate the downstream consequences or the scaling limitations of your specific infrastructure. It’s locally efficient, but it can be globally misaligned with how the rest of your pipeline operates.

Debugging muscle memory

Building a framework requires a deep understanding of failure modes. These are the kind of race conditions and environment side effects that don't show up in a simple stack trace. When you build something step-by-step, you’re forced to reason about every state and boundary.

If we move toward a workflow where we mostly just review and approve AI suggestions, we stop building that mental map. Reviewing code is a fundamentally different cognitive process than constructing it from scratch. If we lose that depth, we might be fine during routine development. However, we’re going to be in a lot of trouble when a rare, systemic failure hits and no one on the team truly understands how the core logic functions from first principles.

Power trap and burnout

There is also a hidden danger in having this much power at your fingertips. In the past, time constraints acted as a natural filter. If an idea was an edge case or didn't provide enough value, you simply didn't have the time to build it. Now, you can churn out an implementation in seconds.

This creates a new kind of pressure. Just because you can generate a feature doesn't mean you should. You can quickly end up with a bloated framework filled with ideas you never actually wanted to commit to. Every one of those implementations now requires testing, documentation, and long-term maintenance. If you aren't careful, you can easily burn out just trying to manage the sheer volume of code you've allowed the AI to produce. The mental overhead of owning a feature doesn't go away just because the code was generated quickly.

Clean code and ownership

I am a clean code and code craftsmanship enthusiast. I’d rather wait to release something solid than push something I know is flawed. AI-generated code often looks very polished and idiomatic on the surface, which is actually quite dangerous. It triggers a bit of a bias. If it looks professional, we tend to scrutinize it less.

In a foundation-level framework, those small, lazy design choices propagate everywhere. I’m not saying we should stop using AI. It’s great for repetitive tasks or migration scripts. However, we have to be careful about which layers we delegate. The more foundational the code, the more important it is that we internalize the trade-offs ourselves. AI can produce code that works, but long-term framework quality depends on us actually owning the design.

Final thoughts

AI is great for the repetitive stuff and for quickly exploring an idea, but the foundation of a framework has to stay human-centric. Long-term quality doesn't come from how fast you can churn out code. It comes from actually internalizing the trade-offs and being deliberate about where you draw the line. AI can give you a working implementation in seconds, but you are the one who has to own that design and maintain it when things get complicated.

If you don't own the decisions, you're just building a future headache.