Sometimes the team that prefers the old way is right

Engage the preference for traditional methods with evidence instead of dismissing it, and you either win the argument honestly or learn something. Treat it as mere resistance and you may automate a step that worked.

B

Balagei G Nagarajan

3 MIN READ


A fork between a proven traditional method and a new agent, weighed on evidence

Key facts.

  • METR's randomized controlled trial found experienced developers about 19% slower with early-2025 AI tools despite feeling faster, so preferring the familiar method is sometimes the empirically correct call. source
  • The lost-in-the-middle effect documents a real model limitation, evidence that skepticism about replacing a reliable process can be grounded rather than reflexive. source

Why is "not invented here" sometimes correct?

It is tempting to file every preference for the old way under resistance and push past it. That is a mistake, because sometimes the people who know the existing process best are reading a real signal: the traditional method is reliable, well understood and good enough and the agent would trade a known quantity for a probabilistic one. The METR trial is the uncomfortable evidence, with experienced developers actually slowed by AI tools while feeling sped up. A team that resists replacing a working process is sometimes protecting a genuine advantage that the enthusiasm around agents is glossing over.

This does not mean defer to every objection. It means engage the preference the way you would any technical disagreement: define the comparison, measure the agent against the status quo on the metrics that matter and let the evidence decide. If the agent wins, you have converted a skeptic with proof rather than authority. If the old way wins, you have avoided automating a step that did not need it. Either outcome beats steamrolling a judgment that might have been right and documented limits like lost-in-the-middle are a reminder that the new way is not automatically better.

A decision fork comparing traditional method and agent on measured criteria

How do you engage the preference productively?

ResponseDismiss as resistanceEngage with evidence
FramingThey are blocking progressThey may be reading a real signal
MethodOverrideMeasured head-to-head
If agent winsResentful complianceSkeptic converted by proof
If old way winsYou automated a working stepYou avoided a costly mistake

An honest comparison needs reliable evidence about how the agent actually behaves, which is what VibeModel provides as the Pattern Intelligence Layer. When you can show the agent handling the contested process the same correct way every time, the head-to-head against the traditional method is grounded in real reliability data, so the team that preferred the old way is answered with proof rather than dismissed and you only replace the process when the agent genuinely earns it.

Frequently asked questions

Isn't this just letting skeptics block AI?
No. It is testing the agent against the status quo and deciding on evidence. Skeptics who are wrong get converted by proof; skeptics who are right save you a mistake.

When is the traditional method better?
When it is reliable and well understood and the agent would only add probabilistic risk. METR's trial shows the new tool is not always faster, even when it feels that way.

How do you run the comparison?
Define the metrics that matter, measure the agent against the existing process head-to-head and let the result, not the enthusiasm, decide.


Share this post

Join the discussion

Have a take, a war story, or a question? Sign in with GitHub to comment and react. Comments are powered by GitHub Discussions, ad-free and yours to moderate.

Continue Reading

Find where your agent breaks, before you build it

Faultmap maps where your agent will fail from the goal and your data, then hands you the first test suite it has to pass.