Every team has one: the developer who opens a laptop, chooses a direction, and starts turning ambiguity into code before everyone else has finished framing the discussion.
Before AI, this person could brute-force a solution through sheer volume of keystrokes and stubbornness. They were often the person you counted on to get the feature over the line.
AI coding assistants fit that style perfectly.
A strong Fighter with a good assistant is genuinely formidable. This is not about a weak developer being dazzled by a shiny tool. It is about one of the team’s strongest implementers receiving a machine that can turn instinct into output at extraordinary speed.
The problem is that AI amplifies every Fighter instinct, including the ones that should be tempered.
Action crowds out reflection
The Fighter’s defining trait is a bias toward action so strong it leaves little room for reflection. They trust their tools, their instincts, and their ability to deal with consequences later.
Velocity metrics reward them. Sprint demos are built around them. Managers point to them as proof that the team is delivering.
AI makes them faster and more confident, even when the confidence is not entirely deserved. The model generates two hundred lines of plausible code in thirty seconds. The Fighter reads the first few lines, decides the direction looks right, and moves on.
That is not always carelessness. Questioning each suggestion takes time. Slow feels like the enemy when the ticket is already late and the next one is waiting.
The model also supplies a steady stream of confirmation. The solution is described as elegant. The implementation is called robust. The developer is told the approach is sound. The Fighter has built a career on trusting their gut, and the gut says: this looks fine, ship it.
"It works" is not the same sentence as "it was a good idea."
Accepted decisions become architecture
The technical debt is not always in one bad decision. It accumulates through the decisions that were never really made.
The model suggests an abstraction. The Fighter scans it and accepts it. A generated helper gets copied into another module. A retry policy appears because the assistant included one. A dependency enters the project because it was convenient in the moment.
The Fighter did not choose the architecture in a deliberate sense. The model suggested pieces, the Fighter approved them, and the pieces became the architecture.
Multiply that by every ticket, sprint, and late-night session in which the assistant kept generating and the developer kept shipping.
The Fighter’s gift is that things stop being theoretical around them. Tickets close. Broken systems come back to life. Somebody delivers. The trap is that AI can make the charge feel so productive that nobody notices the crater until later.
Keep the strength, add resistance
You do not fix this by slowing the Fighter down everywhere. You fix it by making the practices around them strong enough to keep momentum from becoming damage.
Code review should catch plausibility passing for proof. Reviewers need to inspect assumptions, not just syntax. A generated diff deserves the same scrutiny as hand-written code, especially when it touches authentication, data movement, billing, or other high-impact boundaries.
Rotate ownership so the Fighter’s modules do not become black boxes. Have another developer trace the path, change a small behavior, and explain what could fail. If nobody can do that without the original author, the team has a knowledge problem.
Match approval gates to blast radius. A tiny formatting change should not require the same process as a change to permissions or customer data. But high-impact work should not move from model suggestion to production because one experienced developer recognized the pattern.
Require the why, not only the what. A short pull request explanation can record why a dependency was added, why a boundary exists, or why a simpler approach was rejected. That explanation gives future reviewers something to challenge.
Fighters do not produce slop because they are careless. They produce it because they are fast and confident, and AI makes both traits stronger.
The question is not whether your team should have Fighters. It is whether the team’s practices are strong enough to keep speed from becoming a crater.