AI is a bubble, just like dot-com

AI is increasingly described as a constant presence in work tools rather than a program you launch, changing how teams expect to interact with it. This framing treats the model as a teammate that is always available, with access to shared context and internal tools. The shift moves the technology from occasional use to an ongoing collaboration. As a result, engineers must adapt to a workflow where the model’s output is continuously present.

Leadership frames the technology as a blanket imperative to increase usage, offering little guidance on what responsible use looks like. Engineers, meanwhile, rely on a learned habit of not shipping what they cannot explain, which creates tension between rapid deployment and safety. This split mirrors earlier debates about adopting new platforms without clear standards. The disagreement is less about which model is best and more about how much trust to place in generated output.

Teams are shipping code faster than they can validate it, turning comprehension into a separate task that must be scheduled after deployment. The rapid succession of specialties, prompt, context, harness, and graph engineering, shows how quickly practices become outdated, raising the ongoing cost of skill renewal. This pace leaves little time for deep understanding before the next shift arrives. Consequently, the risk of building on opaque foundations grows as the cycle accelerates.

The dot-com era showed that both excitement and doubt could be correct depending on the specific company, and success came from asking what the technology could actually do rather than adopting a mood. The same logic applies now: engineers must look past the hype to determine where AI genuinely adds value. Without that discernment, teams may either overinvest in dead ends or miss useful applications. Understanding the real capabilities, not the prevailing sentiment, is the practical path forward.