Coyote vs. Acme flips an old joke around: what if Wile E. Coyote, who we've spent decades dismissing as hopelessly incompetent, was actually an ambitious engineer working with terrible tools? The story behind the name Coyotiv begins, more or less, with that question.
Looking back over Wile E. Coyote's long career, engineering is probably not the first thing that comes to mind. Bad decisions, high explosives, and a vast desert apparently beyond the reach of workplace-safety regulations are more obvious.
And yet, what he has been doing all these years looks remarkably like engineering.
There is also an odd fact that changes the way we look at the whole chase: in real life, coyotes can outrun roadrunners.
The cartoon, obviously, operates under different laws of physics. But this gives us our own slightly different interpretation of Coyote. He is not desperate. He is not pursuing an impossible problem because catching the Road Runner is his only chance of survival. In principle, he could just run.
Instead, he wants to know whether he can solve the problem another way.
So he designs rockets, rigs pulleys, deploys magnets, paints roads, builds elaborate mechanical systems, and learns whatever the next attempt seems to require. A fair number of these experiments end "slightly" differently from what the manufacturer had in mind.
The next day, though, Coyote is back at work.
New plan, new machine, new box from Acme.
That is essentially the idea at the heart of Coyote vs. Acme. After years of ordering products that explode, malfunction, or somehow end up falling on his own head, Coyote finally takes Acme to court.
It's a wonderful premise because it reverses an assumption most of us have carried since childhood: what if Coyote isn't actually that incompetent? Or, at the very least, what if incompetence isn't the whole story?
Look a little closer and his persistence starts to look different too. He keeps failing, but he never treats failure as proof that the problem cannot be solved. A rocket explodes. Fine. That tells him something about the rocket. It does not tell him that the Road Runner cannot be caught.
So he tries something else.
That distinction was part of what drew us to Coyote when we chose the name Coyotiv.
What would you order from Acme?
There are parts of Coyote's engineering practice that are hard to defend. His supplier choices, for one.
You buy a rocket from a company. The rocket blows you up. The next week, you order a giant magnet from the same company. It sticks you to a mountain instead of your intended target. So you open the catalog again and see what else they sell.
In software today, we would call that a serious vendor lock-in problem.
But there is something Coyote gets surprisingly right. He may be loyal to Acme, but he is not particularly loyal to any one method.
The rocket fails, so he does not spend the next twenty episodes becoming the world's leading expert in non-exploding rockets. He tries a magnet. A catapult. A pulley. A trap. A painting. Some improbable combination of several of them.
This matters more than it sounds.
Our catalog has fewer rockets. Instead, we have frameworks, cloud services, open-source libraries, APIs, AI models, coding agents, and new platforms appearing every week. Almost all of them promise to make something faster, easier, or smarter.
We've never had this many tools at our fingertips. Strangely enough, software still has plenty of problems.
One reason is that teams become attached to the tools they already know. If you have a hammer, every problem slowly begins to acquire the suspicious appearance of a nail.
A team that knows one framework starts designing problems that fit that framework. A company that has invested heavily in one platform starts treating the platform as a constraint of nature. An engineer who knows how to build rockets may spend months trying to build a better rocket when the problem never required a rocket in the first place.
Coyote, for all his faults, rarely makes that particular mistake. He is willing to use whatever the problem seems to demand. If he does not know how yet, he figures it out.
At Coyotiv, we try to work the same way. First, understand what we are actually trying to achieve. Then identify the real constraints. Then look at the options.
Tool selection comes later.
The important thing is not which tools you use. It is whether you get the result.
AI has made that distinction even more important. Things that were impossible a short while ago are becoming possible at extraordinary speed. But the job of engineering is not to do everything that can be done. Deciding which possibilities are worth pursuing, and which tools actually help pursue them, is part of the job too.
Sometimes the right response to an exploding rocket is to build a better rocket.
Sometimes it is to stop thinking about rockets.
Why coyotes don't go it alone
Wile E. Coyote is only half the story behind our name. Real coyotes are part of the story too. They can move alone when they need to, but in difficult conditions they form small packs, look out for one another, and work together.
When we started Coyotiv School, that reminded us of something we already knew about how engineering is learned.
From the outside, software development can look like a very lonely job: one person, one screen, and one thing that has refused to work for the last few hours.
In reality, a good engineer carries a whole pack of other engineers in their head. You learn debugging from one person, system design from another. Someone else made a mistake years ago, so you don't have to. Another person asks one question and suddenly a problem you've been staring at for days looks completely different.
Coyotiv School was built around that idea: not just teaching tools, but creating a place where engineering experience could pass from one person to another.
Then the idea grew beyond the school.
Today we build our own technologies and products, develop software and AI products with companies, and work alongside engineering teams. What we do has changed, but the original instinct is still the same: we rarely assume that the solution in front of us is the only possible one.
The world is not a finished design
Wile E. Coyote is usually remembered for his persistence, and rightly so.
He fails spectacularly. He gets flattened by rocks, launched off cliffs, blown up by his own equipment, and betrayed by basic mechanics. Then he returns.
Giving up apparently never makes the shortlist.
That matters. Engineering involves spending a surprising amount of time in the uncomfortable space between "this doesn't work" and "this cannot work." The two statements sound similar when you have been staring at the same problem for three days, but they are not remotely the same.
What makes Coyote interesting is that he keeps looking for another way through that space.
If one approach fails, he changes the approach. If a tool does not work, he reaches for another tool. If the way he framed the problem leads nowhere, he is perfectly willing to frame it differently.
That does not mean starting from zero every time.
In real engineering, throwing away everything you have learned and rebuilding the whole system from scratch is often a very expensive way of repeating old mistakes. Persistence is only useful if knowledge accumulates. Otherwise you are not iterating, you are resetting.
The useful lesson from Coyote is not "redesign everything every time." It is almost the opposite: keep what you learned, but do not become attached to the particular solution that taught it to you.
The problem stays. The knowledge stays. The tool is negotiable.
And behind all of this is another characteristic we have always liked about Coyote: he does not regard the world as a finished design.
The fact that something works a certain way today does not mean it has to work that way tomorrow. When he hits a limit, his first instinct is to test whether it is really a limit.
A lot of good engineering questions begin with exactly that kind of restlessness.
Why do we do it this way?
Is this genuinely a technical constraint, or simply a decision nobody has revisited in years?
Why is a person still doing this task?
Why are we asking a machine to do that one?
Does all this complexity belong to the problem itself, or did we introduce it with the solution?
Of course, not every old assumption is wrong. Sometimes people do something the same way for a very good reason. Sometimes the wall really is a wall.
But every so often, you find out that the mountain everyone has been walking around for years can actually be moved.
That is where things get fun.
Back to the drawing board
There is a simple reason Wile E. Coyote never catches the Road Runner: if he did, the cartoon would be over.
In the real world, we need things to work. We need systems to stay up, products to earn their place, and the engineering teams we work with to eventually do great work without us.
But there are a few reflexes we've borrowed from Coyote.
- Do not give up just because the first solution failed.
- Do not confuse your tool with your job.
- Do not spend years perfecting the rocket simply because you happen to know rockets.
- And when something does not work, do not immediately call it impossible.
Sometimes the code is wrong. Sometimes the architecture is wrong. Sometimes it is the tool. Sometimes the problem has been framed badly from the start.
And sometimes the obvious way already works perfectly well. You could just run.
But engineering often begins with a different question:
Could there be another way?
Years later, the two ideas behind the Coyotiv name still fit together: Wile E. Coyote, alone in the desert, refusing to give up on a problem and endlessly willing to approach it from another angle; and real coyotes, forming small packs when things get difficult.
One reminds us to question the limits.
The other reminds us that nobody has to do it alone.
The tech world already has enough people saying, "That's just how it's done."
We still like asking, every now and then, "Are we sure?"
Wile E. Coyote would probably ask that question and then open the Acme catalog.
Luckily, our methods are a little less explosive.