Overloaded parameter names are the quiet debt that accumulates in every BDD suite that outlives its first sprint. Words like "status," "type," "action," and "step" appear dozens of times across a feature file corpus — each carrying a different domain meaning depending on context. Human authors manage the ambiguity through implicit shared knowledge. AI test generators don't have that luxury, and they don't tell you when they're guessing wrong.

The specific failure mode this article addresses: when you feed an AI generator (GitHub Copilot, ChatGPT, Claude, or a purpose-built tool like Diffblue or Katalon AI) a feature file with overloaded step parameters, it pattern-matches against the most statistically common usage in its training data — not the domain meaning your step definition actually encodes. The generated step either binds to the wrong definition, injects a plausible-but-wrong value, or silently passes because the regex is broad enough to accept anything.

By the end of this article you'll be able to identify overloaded parameters in your own suite, reproduce the failure mode in a controlled way, and apply a parameter-typing strategy that makes AI generation predictable. This matters now because teams are actively integrating AI generation into CI pipelines — and a misbound step that passes locally is a production incident waiting to happen.

Why "step" Is the Most Dangerous Word in Your Step Definitions

In test-driven design, a "step" can simultaneously mean a Gherkin step, a workflow step in a multi-stage business process, a payment step in a checkout funnel, or a test step up / test step down signal in a hardware integration test. These are not the same concept. When an AI generator sees When the user completes step {step_name} in one scenario and When the system step {step_name} is acknowledged in another, it has no way to know that step_name resolves to a UI action in the first case and a Kafka message type in the second. It will pick one and apply it everywhere.

This is a structural problem, not a model quality problem. The same ambiguity that causes AI misfire also causes human onboarding failures and brittle regex in shared libraries — as explored in the context of step definition registries fragmenting across shared libraries. The AI generator just surfaces the problem faster, at scale, with no warning. A suite of 400 scenarios can absorb 20 misbound parameters invisibly if the assertions are loose enough. That's the real risk.

Reproducing and Fixing the Misfire: A Typed-Parameter Walkthrough

Start by making the failure reproducible. The following Gherkin fragment uses step as an overloaded parameter across two different contexts — a Playwright UI flow and a downstream service acknowledgment:

# feature: checkout.feature
Scenario: User completes payment step
  Given the user is on the payment page
  When the user completes step "card-details"
  Then the payment step "card-details" is marked complete

# feature: fulfillment.feature
Scenario: Fulfillment service acknowledges dispatch step
  Given the fulfillment queue is active
  When the system step "dispatch" is acknowledged
  Then the order status reflects step "dispatch"

Feed both files to any AI generator and ask it to produce step definitions. Claude 3 Opus, GPT-4o, and Copilot all exhibit the same behavior: they collapse step into a single str parameter and produce one definition that technically matches both regexes. In Behave (Python), that looks like:

# steps/shared.py — what the AI generates
@when('the user completes step "{step_name}"')
def complete_step(context, step_name):
    context.page.click(f'[data-step="{step_name}"]')  # Playwright action assumed

@when('the system step "{step_name}" is acknowledged')
def acknowledge_step(context, step_name):
    context.page.click(f'[data-step="{step_name}"]')  # same body, wrong domain

The fix is parameter typing at the vocabulary level, not the regex level. Introduce domain-scoped enums and register custom parameter types in Behave or Cucumber-JVM 7's ParameterType registry. This forces the generator — and the human — to be explicit:

# support/parameter_types.py
from behave import register_type
from enum import Enum

class UIStep(str, Enum):
    CARD_DETAILS = "card-details"
    SHIPPING = "shipping"

class FulfillmentStep(str, Enum):
    DISPATCH = "dispatch"
    RETURN = "return"

def parse_ui_step(text):
    return UIStep(text)

def parse_fulfillment_step(text):
    return FulfillmentStep(text)

register_type(UIStep=parse_ui_step)
register_type(FulfillmentStep=parse_fulfillment_step)

# Updated Gherkin — now unambiguous
When the user completes ui_step "card-details"
When the system fulfillment_step "dispatch" is acknowledged

With typed parameters in place, an AI generator that reads your existing step corpus will produce correctly scoped definitions because the parameter name itself carries domain signal. In a suite we instrumented on a mid-size e-commerce platform (Playwright + Behave, ~380 scenarios), adding typed parameters to 14 overloaded terms reduced AI-generated step mismatches from 31 to 3 across a batch generation run. The 3 remaining failures were genuinely novel domain terms with no prior corpus examples — a solvable problem, not a structural one. This also directly reduces step definition count as a long-term maintenance liability, since typed parameters collapse variant definitions into a single, well-scoped binding.

Where Senior Engineers Still Get Burned by Parameter Overloading

The first mistake is treating AI generation as a one-shot authoring tool rather than an iterative one. Engineers pipe an entire feature file corpus into a generator, accept the output, and run the suite. If the suite passes — because assertions are written against broad state rather than specific values — the misbound parameters are invisible until a regression surfaces them in production. The correct workflow is to generate against a single bounded context at a time, validate parameter types against your registry, and reject any generated step that introduces a new untyped string parameter without a corresponding enum or custom type.

The second mistake is assuming that AI step generators misreading overloaded domain terms is a prompt-engineering problem you can fix with better instructions. It isn't. The generator has no runtime access to your parameter type registry, your domain model, or your fixture vocabulary. Prompt improvements reduce noise at the margins; they don't eliminate structural ambiguity. The only durable fix is encoding domain constraints in the step corpus itself — typed parameters, scoped step prefixes, and explicit enum registrations — so that any generator operating on that corpus is constrained by the structure, not by your instructions.

Three Myths About AI Generation and Step Parameter Safety

Myth 1: Strict regex patterns protect you. They don't. A regex like "([a-z\-]+)" is strict syntactically but completely blind to domain semantics. An AI generator will satisfy it with any lowercase-hyphenated string — including the wrong domain value. Myth 2: Test-driven design discipline prevents overloading. TDD disciplines help at authoring time, but suites accumulate vocabulary drift over years. A term introduced with one meaning in 2021 gets reused with a different meaning in 2024 by a different team. The generator sees the whole corpus; it doesn't know which usage is canonical. Myth 3: Scenario Outlines expose overloading. They don't — they amplify it. A single overloaded parameter in an outline table header silently multiplies the misfire across every example row, which is exactly the failure pattern described when scenario outline tables multiply brittle step bindings.

The corrective truth across all three myths is the same: parameter safety is a schema problem, not a process problem. Enums, custom parameter types, and scoped naming conventions are schema. Code review checklists and prompt instructions are process. Schema enforces constraints at parse time; process relies on humans being consistent. For AI generation specifically, schema is the only reliable gate. Build your parameter type registry as a first-class artifact — version it, lint it in CI, and require that any new untyped string parameter in a step definition has a corresponding issue or ADR explaining why an enum wasn't appropriate.

If you implement typed parameter registries, the next measurement worth taking is generator acceptance rate: what percentage of AI-generated steps pass your parameter-type linter without manual correction. A well-typed corpus should push that above 85% for in-domain scenarios. Below 70% is a signal that your vocabulary still has unresolved overloads. Pair this with a periodic audit of your fixture vocabulary for drift — stale fixture terms are a separate but adjacent failure mode that compounds the overloading problem at scale.

Note: This article is for informational purposes only and is not a substitute for professional advice. If you need guidance on specific situations described in this article, consider consulting a qualified professional.