The Gulf of AI

AI is oddly polarizing among technophiles. The other major technological innovations I’ve experienced—social media, mobile computing, and crypto—certainly had their boosters and detractors, but none created anything near the level of polarization that AI has. Partly that’s a reflection of how much more seismic this innovation is compared to everything that came before (save perhaps the internet itself), but I think there is something deeper going on.

Among technologists, CEOs and startup founders seem generally very excited about the potential for LLMs, while developers seem much less enthusiastic, with many especially at larger companies being outright hostile. (Spend some time on Mastodon or in the Ars Technica comment sections if you don’t believe me.)

The lazy explanations tend to assume that all CEOs just want to lay off as many people as possible (greed! profit!) while lazy developers want to maintain their status and salaries as members in good standing of the Software Guild. The actual reasons for the schism, though, are both interesting and represent a massive competitive advantage for startups versus incumbents.

Some recent research indicates that knowledge of AI is inversely proportional to use of it. This gets us closer to the truth; we just need to recognize a few additional realities. Specifically, LLM coding assistants work best when: 1) writing de novo code; 2) using languages that have many examples available in their training sets; and 3) operating on code that LLMs themselves wrote (just like humans, they don’t much like dealing with other devs’ code).

When starting a project from scratch, coding assistants seem absolutely magical. The first time I asked Cursor to “build a web dashboard” and saw it create an entire TypeScript webapp from nothing, it was astonishing. It is not much of an intellectual leap to go from that experience to believing that these tools are basically magic and English really is the “next hot programming language.” As leaders interact with these tools, they’re often using them in this way: experimenting with new, clean-sheet projects or being persuaded by slick sales demos performing the same trick.

Of course, when actual developers get hold of this technology and start trying to deploy it on messy and fragile (not to mention critical) production code, things go awry rather quickly. For one, the codebase may be in a language on which models are poorly trained. I was recently catching up with a major figure in the Rust community, who told me that he and his entire team had given up on the real-time assistants at this stage because the models simply lacked sufficient training data on this relatively new language. Having in-line suggestions were more distracting than helpful and pulled them out of the flow (similar, I suppose, to how I feel about Gmail’s annoying attempts to (badly) write entire emails for me).

Compounding the challenge, computers can code a lot faster than humans, which also means they can screw things up a lot faster, too. Using these tools in existing, production code is just qualitatively different from prototyping and clean-sheet designs.

It’s not that the tools are bad; it’s that companies use them badly.

Managers of large companies, separated from the actual developers by oceans of middle management, are too removed from the day-to-day realities of modern development to understand how best to implement these tools. As just one example, Facebook is now deploying “AI use dashboards” for managers that measure how many hours per day their devs are using LLM coding tools, betraying a total ignorance of what high-level developers actually do all day in the first place.

The MIT paper that many cited as proof that AI tools are overhyped was in reality not an indictment of AI. Rather, it was a depressing elaboration on how poorly managed most companies are (emphasis mine):

Investment allocation reveals the GenAI Divide in action, 50% of GenAI budgets go to sales and marketing, but back-office automation often yields better ROI. This bias reflects easier metric attribution, not actual value, and keeps organizations focused on the wrong priorities.

The upshot here is that big, bureaucratic companies are going to struggle mightily to exploit the power of LLMs. Their codebases are often in languages that are poorly-represented in training data, their top executives are ignorant of the realities of modern software development, and their environments are comprised of complex, custom code that will complicate automation. They’re effectively helpless. Nothing is likely to change until a new generation of tech-native CEOs spends years climbing the greasy pole of corporate leadership.

But really, they’ll just get out-competed by startups.

Startups have massive advantages. They can use languages that are most appropriate for automation in the areas of their business that are most compelling to automate. Startup CEOs are either engineers themselves or work so closely with their CTOs that they can develop strategies to exploit AI effectively while keeping their expectations realistic. They can leverage nearly full automation to prototype and create internal tools while being more circumspect in how they generate production systems.

As just one example, I recently spoke with a founder/CEO who told me that the company had effectively banned their developers from spending time building internal tools and dashboards after realizing that automated coding tools could take care of those tasks, leaving the devs free to work on the (very much not-vibe-coded) production side.

If you want to see the true power of LLM-powered software, look at companies in the seed-to-Series-A stages. These companies are growing faster, leaner, and smarter than anything I have seen in my entire career, and they will run roughshod not only over the creaky old businesses that think using ChatGPT to write sales emails is cutting-edge but also big tech companies that think productivity is measured in “hours spent using Claude.”

The answer to the initial riddle is, of course, that both camps are correct—“absolutely right” as Claude might say. If you’re a developer at a big company, you have a highly rational reason to dislike these tools. If you’re the CEO of a big company, you’re probably ignorant enough to believe that the tools are magic. And if you’re a startup founder, you’re going to use these tools to build a billion dollar business.