Where AI Actually Fits

When execution becomes cheap, the discipline go-to-market never built becomes the only thing that matters.

A team I watched bought into the promise completely. The tools were going to change everything, and in a narrow sense they did. What had taken a small department now took one person and an afternoon, the outbound that used to trickle out now poured, the research that used to take days happened in minutes, the volume of everything the team could do went up by more than an order of magnitude almost overnight. Six months later they were in worse shape than when they started. The tools had not failed. They had worked, and working, they took a system that had been quietly mediocre and ran it at ten times the speed, so that every flaw in the design that had been small and slow was now large and fast. They had bought a faster version of a thing that was not very good, and the speed, which everyone had treated as the prize, turned out to be the problem.

The hard part was that nothing about the failure looked like failure while it was happening. The activity charts were magnificent. Every measure of output, of volume, of things done per person, climbed steeply and kept climbing, and for a while the team felt the exhilaration of a constraint lifting, of suddenly being able to do what had always been out of reach. The damage was accumulating underneath the activity, in places the activity charts did not show, and by the time it surfaced in the numbers that mattered it had been compounding for months at the new, higher speed. They had mistaken the volume of their own motion for progress, which is an easy mistake to make when the volume is truly unprecedented and the cost of it is silent.

This is the part of the AI story that the people selling the tools have the least incentive to tell, and it is the part that matters most for whether go-to-market becomes a discipline. The dominant narrative is that AI is the thing that finally makes go-to-market rigorous, technical, engineered, that the arrival of these tools is the arrival of the discipline. I think that has the relationship backwards. AI leaves the field’s missing discipline exactly as missing as it was before, while removing the one thing that had been hiding the absence, so that the absence becomes far more expensive than it used to be.

The constraint that was hiding the problem

For almost its entire history, go-to-market was rate-limited by human labor. Everything cost human time. You could only send so many emails, research so many accounts, run so many campaigns, have so many conversations, because each of these things required a person to do it, and people are finite and expensive. This labor constraint shaped the whole field, and it had one effect that nobody noticed because it was always there, a constant in the background. It throttled everything, including failure.

A badly designed go-to-market system, under the labor constraint, fails slowly. Its flaws are real, but they express themselves at the pace that human labor allows, a bad outbound approach reaching a few hundred people a week rather than a few hundred thousand, a poor qualification process wasting a manageable amount of effort, a misjudged message going out slowly enough that someone usually notices the response is poor before too much damage is done. The labor constraint was, among other things, a speed limit on the consequences of bad design, and because it slowed the failures down, it gave people time to catch them, and it kept the cost of any individual mistake small enough to absorb. The field could get away with not understanding its own systems, because the systems could not run fast enough to fail catastrophically.

There is something almost protective about a binding constraint, and it is easy to miss until it is gone. The labor limit forced a kind of involuntary discipline on the field, a slowness that functioned as a margin of safety nobody had chosen, because the time it took to do things was also the time available to notice they were going wrong. Plenty of bad ideas died quietly in the gap between conceiving them and executing them at scale, killed by the sheer effort that scale required, and the effort acted as a filter that caught some of the worst mistakes before they grew. Remove the constraint and you remove that filter along with it, so that every idea, sound or unsound, now reaches full scale at full speed, with none of the friction that used to slow the bad ones down long enough to be caught.

AI removes that speed limit. The whole pitch of the tools is that they remove it, that the labor which used to cap everything is now cheap and abundant, that one person can do what a department did. This is real, and it is a genuine change in what is possible. The thing nobody mentions is that removing the speed limit on a system removes the speed limit on its failures too. The same tools that let a good system run ten times faster let a bad system fail ten times faster, and since most go-to-market systems are not engineered, since most of them are improvised, undesigned accumulations that no one ever sat down and engineered, what AI mostly does in practice is take systems that were never sound and run them at a speed where their unsoundness finally has consequences large enough to see.

Removing a constraint exposes the design

There is a way to make this precise, and it connects to the basic behavior of any loaded system. Every go-to-market system has capacities, limits on how much it can handle while still working, set by various resources, the size of the market, the goodwill of the audience, the ability of the people downstream to handle what the top of the system produces. For most of history, the labor constraint kept the system running well below those other capacities, because labor ran out first. You hit the limit of what your people could do long before you hit the limit of what the market could absorb, so the other limits, the ones that really matter, were rarely tested.

Take away the labor constraint and the system rushes up toward those other limits, the ones that were always there and never reached. The audience’s tolerance for being contacted, which was safe when you could only reach a fraction of it, gets consumed quickly when you can reach all of it. The downstream capacity to handle volume, which was never strained when the top of the funnel was labor-limited, gets overwhelmed when the top of the funnel is suddenly uncapped. The system moves into the region where it strains and breaks, the steep part of the curve where small increases in load produce large degradations, and it gets there fast, because the constraint that used to hold it back is gone. Removing the labor constraint moves the system up to where its real limits are, with no improvement to the system itself, and if no one designed it for those limits, because the labor constraint meant no one ever had to, it arrives at them unprepared and fails.

This is why the team that bought the promise ended up worse off. The tools moved their system up to limits the design had never accounted for, because under the old constraint those limits were never in play, and the design had never needed to be good enough to handle them. The speed revealed and amplified the problems the slowness had been hiding, rather than creating new ones, and it did so faster than anyone could respond, which is the worst way to discover that your system was never designed for the conditions it now faces.

The audience’s tolerance is the limit that gets tested most brutally, because it was the one the labor constraint protected most completely. A market has a finite patience for being contacted by a given company, a reservoir of goodwill that depletes when it is drawn on and refills slowly if at all. Under the labor constraint, a company could only ever draw a thin trickle from that reservoir, reaching a small fraction of the market in any stretch of time, so the reservoir was never seriously depleted and nobody had to think of it as a resource with a limit. Cheap execution lets a company drain the whole reservoir in weeks, contacting the entire market with a volume and a sameness that the market experiences as noise, and the goodwill, once spent, does not return on any useful timescale. The company has converted a renewable trickle into a one-time flood, and the flood is the kind of success that forecloses the future.

The oldest irony in automation

None of this is new, and the people who study automation have a name for the pattern, because it has played out in every domain that automated before this one. In 1983 the researcher Lisanne Bainbridge wrote a short and famous paper on what she called the ironies of automation, and its central observations describe the AI moment in go-to-market almost perfectly, four decades early.

Her first irony is that automation relocates the human to the harder job rather than removing the human from the system. When you automate the routine, well-understood parts of a task, what remains for the human is the part that could not be automated, which is the judgment, the handling of the cases the automation cannot handle, the knowing of when the automated system has gone wrong. Automation takes the easy work and leaves the hard work, so the human’s remaining role is more demanding, more dependent on understanding, than it was before. Her second irony is sharper and more uncomfortable. By automating the routine work, you deprive the human of the practice that built their judgment in the first place, so their skill degrades exactly as the system comes to depend on it more, and you end up with operators whose judgment is more critical and less practiced at the same time.

Translate this into go-to-market and it describes precisely what is happening. The tools automate the execution, the doing, the parts that were always laborious, and what they leave behind for the humans is the design, the judgment, the understanding of the system as a whole and of when it is going wrong, which is exactly the engineering knowledge the field never built. Automation has handed go-to-market a bill for the discipline it skipped, by removing the labor that used to substitute for understanding and leaving understanding as the only thing that matters, at the very moment the field is least equipped to supply it. Bainbridge’s irony is that the more you automate, the more it matters that someone understands the system deeply, and go-to-market is automating faster than any field in memory while having done the least to build the understanding the automation makes essential.

The de-skilling half of the irony is the quieter danger, and it is already visible. When the tools do the research, the writing, the sequencing, and the qualifying, the people who would once have done those things by hand, and learned the texture of the market in the doing, no longer build that knowledge, because the doing was where the knowledge came from. A generation of operators is growing up able to direct the tools and unable to do the underlying work, which would be fine if the tools were infallible, and they are not, so the moments that most require human judgment, the cases the automation handles badly and the signs that something has gone wrong, arrive to people with less of the hard-won feel for the system than the generation before them had. The understanding becomes more essential and less available at the same time, which is Bainbridge’s irony landing exactly on schedule.

The component and the system

It helps to be clear about what AI actually is, in relation to the system go-to-market builds, because the category error in the popular story runs deep. AI is a material and a tool, an extraordinarily powerful new capability that can be built into the system that creates and captures a market. It is a component, in the way that a new alloy or a new kind of engine is a component, something that goes inside the artifact and changes what the artifact can do. It is not the artifact. The system that reliably creates and captures a market is still the thing being engineered, and AI is now one of the most important things you build it out of, which is a different role from being the thing itself.

The field keeps confusing the component for the system, and it is the same confusion that runs through everything go-to-market gets wrong about its own work, the confusion of the tool for the discipline, the stack for the object, the part for the whole. A new component, however powerful, does not relieve you of the need to design the system it goes into. It raises the stakes of the design, because a more powerful component in a badly designed system produces a more powerful failure, the same way a more powerful engine in a car with no brakes is more dangerous rather than less. The question of how the system is designed, how its parts compose, what it can carry, how it fails, survives the addition of AI and in fact becomes the only question that matters, because the execution that used to absorb everyone’s attention is now handled, and what remains is the design, which was always the hard part and is now the whole game.

Seeing AI clearly as a component does something useful, which is to restore the right set of questions. Once it is a material that goes inside the artifact, you start asking the questions you would ask of any material, what it is good for and what it is bad at, where it strengthens the system and where it introduces new failure modes, how it behaves at the edges of its competence, and how the rest of the system should be designed around its particular strengths and weaknesses. These are engineering questions, and they are far more useful than the questions the hype encourages, which are about how transformative the technology is in the abstract. A material earns its value in specific ways inside specific designs, never in the abstract, and learning those ways is the work.

The obvious rejoinder is that the models will eventually get good enough to do the design too, to engineer the system and not only execute it. Perhaps, someday, in part. For now the design work is exactly the kind of thing these tools are weakest at, the judgment under constraint, the reasoning about how a system fails, the choices that turn on understanding a particular business and market in their specifics, and even as the tools improve at it, someone has to know enough to direct them, to recognize when their proposed design is wrong, and to own the system that results. The judgment survives, moving up a level to the person deciding what to ask the tools to build and whether to trust what they build, which is the same engineering judgment wearing a new costume.

Using it well

It would be a misreading of all this to conclude that the answer is to use less of the technology, to hang back while others race ahead. The answer is to use it as a component inside a system someone has actually designed, which is a different posture from pointing it at the existing mess and turning up the volume. A team that has done the design work, that understands the load its system can carry and where it fails and what it is rated for, can hand that understood system a vast amount of cheap execution and watch it come out stronger, because the execution is being poured into a structure built to take it. The same execution poured into an undesigned system comes out as faster failure. The technology is identical in the two cases. The difference is entirely in whether there was a sound system for it to amplify.

This reframes the sequence most teams are following. The common order is to acquire the tools first and figure out the system later, which puts the amplifier before the thing to be amplified, and amplifies whatever happens to be there, which is usually the undesigned status quo. The order that works runs the other way, designing the system first, to the standard an engineering discipline would demand, and then using the cheap execution to run that sound system at a scale that was previously impossible. The tools turn out to be most valuable to the teams that needed them least, the ones that had already done the thinking, and least valuable, sometimes actively harmful, to the teams that hoped the tools would do the thinking for them.

Why this is good news for the engineer

There is an optimistic reading of all this, and I think it is the correct one, though it is optimistic only for a particular kind of person. As execution becomes cheap and abundant, execution stops being a source of advantage, because anything everyone can do confers no edge on anyone. For a long time, a great deal of competitive advantage in go-to-market came from being able to execute, from having the people and the resources to do more than your competitors could. That advantage is evaporating, because the tools give everyone roughly the same execution capacity, and an advantage everyone has is not an advantage.

What rises in value as execution falls in value is the thing execution cannot supply, which is the design, the judgment, the engineering of the system that decides whether all that cheap execution is pointed at something sound or something broken. When everyone can execute, the winner is whoever designs the better system, and designing the better system is exactly the engineering knowledge the field has never built and the rare operators have always had. AI is the best thing that ever happened to the person who understands the system deeply, because it strips away the executional advantages that used to let well-funded, well-staffed, badly-designed operations beat better-designed ones through sheer force, and it leaves the contest to be decided on design, which is the ground the engineer was always standing on. The people who should be worried are the ones whose value was in execution, and the people who should be glad are the ones whose value is in understanding, and the whole shift rewards exactly the discipline this field has been refusing to build.

There is a justice in this that I find almost satisfying. For years the field has been able to substitute resources for understanding, to win by outspending and outstaffing rather than by knowing more, and the substitution worked because execution was scarce and whoever had more of it carried an edge. That era is closing. When execution is abundant and nearly free, having more of it means little, and the only remaining scarcity is understanding, which cannot be bought in bulk or automated away, because it is precisely the thing the automation cannot supply. The advantage moves, slowly and then quickly, to whoever understands their system best, and understanding has always been the cheaper investment the field declined to make, because the expensive one, sheer resource, was good enough. It stopped being good enough the moment execution became free.

What it changes

The practical conclusion is uncomfortable for the dominant narrative and clarifying for everyone else. Buying the tools is not the project. The tools are now a commodity, available to everyone, conferring no lasting advantage on their own, and the team that thinks acquiring them is the transformation has mistaken the component for the system one more time. The project is the design, the engineering of a distribution artifact sound enough that cheap, abundant execution makes it stronger rather than faster at failing. That project requires exactly the things the field has been postponing, an understanding of how the system behaves under load now that load is cheap to generate, a theory of how it fails now that it can fail at full speed, a way of knowing whether it is working now that it is producing far too much to inspect by hand.

That last point is the one that turns out to bite hardest, and it is where this leads next. Once execution is cheap and the system is running fast and producing enormous volumes of activity and outcome, the question of whether it is actually working, whether the things it is doing are causing the results you want, becomes both more important and much harder to answer. You cannot watch it by hand any longer, because there is too much of it, so you come to rely on measurement, and the measurement has to be trustworthy enough to steer by, and whether go-to-market’s measurement can bear that weight is a question the field has never seriously faced. Cheap execution makes everything faster, including the rate at which you can fool yourself about what is working, and a discipline that wants to survive its own speed has to be able to tell, reliably, what its fast and abundant activity is actually causing.

---

References

• Lisanne Bainbridge, “Ironies of Automation,” Automatica 19, no. 6 (1983): 775–779, on the relocation and degradation of human skill under automation.
• On the behavior of systems pushed toward their capacities once a binding constraint is removed, see the queueing and constraint literature referenced elsewhere in this work.
• The critique here engages the prevailing 2023–2026 industry discourse on AI in go-to-market (the vendor and practitioner writing on AI-driven automation of outbound and revenue operations).