Why reuse matters more in AI-assisted development

Your developer just asked an AI assistant to build a new customer lookup screen, and it worked in minutes. Nice — except your system already has three slightly different versions of "look up a customer" scattered across old modules, and now there's a fourth. Nobody planned this. It just happened, one AI-generated shortcut at a time.

This is the quiet risk of AI-assisted development: it makes writing new code so cheap that reusing existing code starts to feel like the slower option. It isn't. This article explains why reuse has to become a deliberate discipline again — maybe more than ever — and gives you a practical way to enforce it.

Why does AI coding make duplication worse, not better?

AI code assistants are pattern-matchers. Ask one to "add a function that validates a Dutch VAT number" and it will happily generate one from scratch — even if your codebase already has a validated, battle-tested version three files away. The AI doesn't know your codebase's history. It doesn't know that the existing function was patched six months ago after a real customer submitted a VAT number with a lowercase country prefix that broke everything.

Before AI tools, writing a new function took enough effort that a developer would usually search first: "surely someone already solved this." That friction was accidentally healthy — it forced reuse. AI removes the friction, so now the default instinct is "just generate it," not "go find it." The result, in real projects, looks like this:

• Three near-identical date-formatting functions, each with a slightly different edge-case bug.
• Two separate customer-address validation routines — one used in the web portal, one in the FileMaker back office — that quietly drift apart until reports stop matching.
• An API integration to a shipping carrier written twice, six months apart, by two developers who didn't know the other one existed.

None of these are exotic failures. They're the normal outcome of fast code generation without a reuse habit.

What's actually wrong with a little duplication?

A duplicate function isn't just wasted effort — it's a maintenance liability that compounds silently.

Say your VAT validation function has a bug fix applied in January. If there are three copies of that function, only one gets fixed unless someone remembers to check the others. Six months later, a customer in Belgium gets a rejected invoice because they hit the other copy — the one that never got patched. Nobody connects the dots quickly, because from the outside it looks like a one-off glitch, not a systemic duplication problem.

Duplication also inflates the size of the system a new developer or an AI assistant has to reason about. More surface area means more places for the AI to also miss the existing pattern next time, and the problem compounds. This connects directly to the idea explored in Necessity-Driven Development: start with what must exist — every piece of logic that exists but shouldn't is a piece of complexity you're paying to carry, whether or not it was ever necessary in the first place.

How do you make reuse the default again?

You can't rely on willpower or good intentions — you need a small number of concrete checkpoints built into how work actually gets done.

1. Give the AI assistant context, not just instructions. If your team uses an AI coding tool, point it at the existing codebase or a curated reference of core functions before asking it to build something new. A prompt like "before writing this, check if validate_vat_number() already exists in the shared library" changes the outcome dramatically.
2. Maintain one visible, current library of shared logic. This sounds obvious, but most teams' "shared library" is really three abandoned folders and one Slack thread. In a FileMaker system, this means real shared scripts and custom functions with clear names and comments — not copy-pasted script steps duplicated across layouts.
3. Add a reuse check to code review, not just a style check. Before approving new code — AI-generated or not — someone asks explicitly: "does something like this already exist?" This single question, asked consistently, catches most duplication before it ships.
4. Name things so they're findable. A function called checkVAT2 will never be found by a future developer or an AI search. A function called validateDutchVATNumber will. Naming discipline is a reuse strategy, not a nitpick.
5. Refactor duplicates on sight, don't schedule it for "later." "Later" is where duplication goes to multiply. If you spot two versions of the same logic during a sprint, consolidate them in that sprint — it's cheaper now than after a third version appears.
6. Log where reused logic lives in your project documentation. Even a simple internal wiki page listing "core reusable functions and what they do" saves hours of AI and human guesswork later.

Does this slow down the speed benefit of AI coding?

A little, at first — checking for existing logic takes a few extra minutes an AI-only workflow skips. But it's a fraction of the time you'd otherwise spend debugging why two "identical" reports show different totals, or explaining to a client why the fix you shipped last month didn't actually fix their specific screen.

In practice, teams that build a reuse habit end up moving faster over time, not slower — because the AI assistant itself gets better output when it's pointed at a smaller, cleaner, well-organized codebase instead of a sprawling pile of near-duplicates. Clean reuse compounds in your favor the same way duplication compounds against you.

Quick checklist: is your AI-assisted workflow protecting against duplication?

• Does your AI coding assistant have access to (or awareness of) your existing shared functions?
• Is there one clearly maintained location for reusable logic, not several scattered ones?
• Does code review explicitly ask "does this already exist somewhere?"
• Are functions and scripts named clearly enough to be found by search?
• Do you refactor duplicates immediately, rather than filing them under technical debt?
• Has anyone audited the codebase in the last 6-12 months specifically for near-duplicate logic?

If you answered "no" to more than one or two of these, duplication is probably already growing quietly in your system.

FAQ

Does this apply outside of FileMaker or custom-built systems? Yes — it applies to any codebase where multiple developers (or an AI assistant) can add code independently: web apps, ERP customizations, API integration layers, all of it.

Can an AI assistant itself help enforce reuse? Yes, if you set it up to. Some teams feed their AI tool a summary of core shared functions as part of its context window before every coding session, effectively giving it the same "check first" habit a disciplined human developer would have.

Is some duplication ever acceptable? Occasionally — genuinely different business logic that merely looks similar shouldn't be forced into one shared function just for the sake of reuse. The goal is deliberate reuse of truly identical logic, not reuse at any cost.

If your system has grown through a mix of manual development and AI-assisted shortcuts, it's worth stepping back and asking what's actually duplicated versus what's genuinely necessary. Loggix helps teams do exactly that — auditing and consolidating custom FileMaker systems, building shared logic into ERP and API integrations, and setting up AI tools inside a workflow so they reinforce good habits instead of quietly working against them.