A "Dynamic Large Language Model" (DLLM)

One of the most infamous—and at times irritating—tendencies of Alexander Hamilton, one of the Founding Fathers of the United States, was his habit of working himself into a rage, unleashing an ocean of arguments, and continuing until his opponents were utterly crushed. This relentless style gave us the Federalist Papers and, by extension, the Constitution of the United States. But it also destroyed his political career when he used the same tactic against John Adams in an effort to block Adams’s reelection in 1800. The difference? In the first case it shaped the nation; in the second, it ruined him because he didn’t know when to stop—and in the process he made too many enemies.

Yet I still admire Hamilton. At the end of the day, he was right about the economic future of the United States. What troubles me is that, while I lack his brilliance, I share too many of his self-destructive tendencies.

You’ll see why I say this in a moment.

I’ve wanted to write this piece for a while but hesitated, unsure of the timing. The idea first came to me around the time I wrote my State of the Union 2025 address, when the narrative around AI fixated on eliminating developers.

I was skeptical from the start. But fighting a tide of popular opinion—especially when there’s no financial gain in doing so—is a losing battle. Though my instincts urged me to push back, I’ve learned to hold off on full-throated statements until the narrative is ready to shift. I write these reflections so that I can point back to them years later, when the moment is right.

To be clear, I’m not an expert in training large language models (LLMs) or AI systems. What follows is based on a mix of reading research papers, talking with people closer to the field, and observing how others attempt to measure AI’s impact on developer productivity.

As my understanding has grown and the industry has advanced, I’ve become increasingly convinced that people still don’t fully grasp what LLMs—colloquially called “AI,” though they are not intelligent—are truly capable of, or what they actually do.

I dislike speculation. Instead of making grand predictions about the future of AI, I’ve focused here on documenting how we arrived at today’s narrative and cultural moment. Along the way, I’ve tried to advise caution, pointing to a few troubling trends I think deserve more attention.

Writing this essay has been a sobering experience, because it doubles as a study in human psychology. More than once, I’ve questioned whether to publish it at all. No one thanks you for raining on a parade—even if the parade is foolish and dangerous. And if you summon the rain and save people from a fire, chances are they’ll blame you anyway.

Only in fantasy do you see endings like Nezha, where a village feels remorse for its cruelty. In reality, human beings are masters at justifying their own destructive behavior.

I’ve trimmed out most of the sharper criticisms, but I’ve left enough hints for those willing to follow the trail.

What is AI

When people talk about “AI,” what they’re really describing is a prediction machine. What we used to call “data science” and “linear regression” has somehow morphed into large language models (LLMs). These have been around for decades. For example, simple machine learning models have long been used in inventory forecasting — like predicting which regions will need more iPhones — a technique that Amazon has leveraged in its logistics and supply chain.

Over time, these predictive methods (linear regressions, decision trees, etc.) were applied to new domains. For instance, Stable Diffusion generates images by training on massive datasets of pictures and then recombining features. Conceptually, it’s not far from how a video game artist builds a 3D model and applies shaders—only here, the modeling is statistical rather than manual.

The current AI boom is driven by a very specific type of prediction: predicting the next word in a sentence. At their core, large language models (LLMs) are just that.

The mechanics involve matrix multiplication at scale. Transformers pass outputs from one layer of matrices into another, refining probabilities of which word (or token) comes next. If you want a great intuitive explanation, 3Blue1Brown’s video is one of the clearest.

But you don’t really need to know the details of multi-head attention to grasp the key point: under the hood, it’s all weights, vectors, and matrices—the same linear algebra you learned in undergrad, just multiplied millions of times over. Each weight reflects the probability that one token is contextually relevant to another.

In other words, LLMs are nothing more than probability machines trained on data. This is also why MCP servers (multi-context prompting) are popular: they let you explicitly control the context on which predictions are made.

From my perspective, there are only a few real “levers” left to pull in advancing LLMs:

1. Tokenization strategies. Without going into too much detail, models slice and dice the inputs, context, and words in a process called tokenization. Modern OpenAI models use ~100k–200k token vocabularies (for reference, GPT-2 model in 2019 used 50k) but diminishing returns are clear.  Everyday English can be understood with as few as 3,000 core words, which cover ~90% of conversation. In the same way moving things around doesn’t always lead to more space or better resource usage, increasing the number of tokens don’t necessarily yield better results. Think of it in terms of a n x n matrix multiplication. To add 1 more token means to perform (n+1) more operations per transformation. The effectiveness decreases exponentially. That’s also assuming that every token is equal (they are not).

   
   

2. Training quality. This can improve via better data or better algorithms. But most of the easily available web-scale data has already been mined and with all the high quality data is predicted to have been mined by 2028. In fact, data quality has become more sensitive as models become specialized. More on that later. Running the model for longer and fitting better to sample data or randomized subsets of them can improve the models too.

   
   

3. Scaling compute. The brute-force path: more GPUs, more machines, more energy. In fact, the memory bottleneck is usually the issue with many papers citing memory bandwidth and others citing simply running out of memory itself. These are too technical to describe (I recommend reading a repo that tries to provide tooling into this) but suffice it to say the bigger your model, the more parallelization you need and therefore the more memory you need at an exponential rate in line with the number of matrix operations. But compute isn’t infinite, nor is money. The world cannot endlessly throw resources at training larger models.

   
   

The reality is that scaling laws show clear diminishing returns. Improvements will taper unless there is a breakthrough in algorithms or tokenization. 

That doesn’t mean progress stops—it just means it slows. Think of the Apple iPhone: since the iPhone 4, each new model has added incremental improvements—better cameras, graphics, and battery life. “Boring stuff,” maybe. But over time, the device has become vastly better and more useful. LLMs are likely to follow the same path: evolutionary, not revolutionary.

Some advances may come through hyperspecialization—fine-tuned models for medicine, law, or finance. But these will not be the “game changers” that some investors imagine. This is essentially what distinguishes Claude from ChatGPT: not a new paradigm, just specialization and refinement.

What worries me is that “throw more money and GPUs at it” has become the de facto strategy. In any other engineering field, suggesting brute force would fail a technical interview. Yet in AI, it’s become a business model. Mark Zuckerberg’s hiring spree of ex-OpenAI employees is just another version of that approach.

Maybe in my next Meta interview, I’ll just propose solving hard engineering challenges by asking Zuckerberg for a bigger check.

More importantly, it appears that the industry has started to doubt the gains that will come from improving these models. Alibaba already started cutting prices on Qwen, implying a reduction in training costs and perhaps innovation; a move only undertaken if they felt that the model was good enough. The recent MIT report on the state of AI is even more damning: "Most GenAI systems do not retain feedback, adapt to context, or improve over time." implying the bottleneck is NOT infrastructure but rather the learning of the models themselves.

In short, short of a major breakthrough in the logic of the models, it is difficult to see these models getting better. Yes I can hear the naysayer in the symbolic logic camp shouting that neural nets are not complete and that a hybrid approach may be better. But I still maintain it is purely speculation.

Speaking of checks—let’s talk about the business of AI.

Business Landscape

The current AI landscape is a curious one. Broadly, there are three primary players:

1. AI producers – companies like OpenAI, Google, Anthropic, and Perplexity that build and train models.

2. AI consumers – enterprises (e.g., Airbnb using AI to generate code) and startups (often little more than wrappers around ChatGPT’s API). Cursor is another example of both an AI producer and consumer because they have their own models but also allow you to call other models owned by OpenAI and Google.

3. Investors – venture capital funds, institutional backers, and retail investors financing the entire ecosystem.

   
   

Right now, the flow of capital is effectively one big loop. Investor money goes into AI consumers. Those startups, in turn, pay the producers for API calls to power their products. Producers then spend that revenue on graphics cards from companies like NVIDIA and training new models or update models with more sophisticated features or parameters, costing even more money. Investors see “traction” in the ecosystem because the improvements in the model improve the AI consumer’s products and they pour in more money.

But this cycle isn’t infinite. As discussed in the previous section, the massive capital expenditures required to train new frontier models will inevitably see diminishing returns. At some point, the belief that each new model will magically generate new revenue streams will collapse.

At what point will the money spent on training these models not yield any more additional revenue? Nobody has answered this key critical question.

Further complicating matters are the contracts and investor agreements behind the scenes.

Take the recent Scale AI situation. Scale began as ScaleAPI, hiring offshore contractors for data labeling. Despite rebranding, its business remained largely the same. Quality labeling is critical—Tesla, for example, insists on doing it in-house, since errors in training data could mean actual loss of human life. Scale’s story turned more dramatic when its CEO departed for Meta, one of the most expensive hires in Meta’s history. Although it was a $14.3bn investment for 49% of the company, in reality it was a talent acquihire. As a result, Scale lost major contracts (including with Google and OpenAI) almost overnight. Instead of waiting on regulatory approval for a merger or acquisition, Meta simply acquired the real assets it wanted: the people who built the system.

The results can be highly unpredictable. Scale had to lay off 14% of its workforce and seek newer but less lucrative contracts like from the US Army and their relationship with Meta shows cracks because of the low quality of data that Scale provides. But it appears (unconfirmed) that there is some relief with past and tenured employees taking a 5-8x payout of their vested stock. 

In other situations like with Winsurf, this type of maneuver can be highly disruptive and unfair. OpenAI bid on Winsurf but were blocked by their principal investor, Microsoft. Google stepped in and lowered their bid to $2.4bn. As a result, senior employees and management got a huge payout but junior staffers got little for the risk they take on.

For employees and common shareholders, liquidation might provide some relief. But venture capital arrangements make outcomes far from equal. VCs typically hold preferred stock or debt instruments, which means they “eat first” in any liquidation event. They can even choose whether to convert to common shares, depending on which option benefits them most. In the worst case, investors walk away whole while common shareholders get nothing.

On top of that, VCs operate under deadlines. Venture funds are time-limited vehicles: the early years focus on raising capital and investing, while the later years are dedicated to managing or exiting those investments. This dynamic creates competition among portfolio companies for the remaining capital in a fund. If a managing partner decides that one company’s prospects look dim compared to another’s, they can pressure it to shut down or sell, freeing up capital for “better” bets. This will become a real concern if AI companies cannot sustain their current sky-high valuations. 

With 95% of AI investments yielding no measurable returns, it is definitely a cause for concern. Note that in GAAP accounting, capital expenditures (money spent to reinvesting the business and acquiring assets like graphics cards) does not fall into the income statement because they are capitalized as assets on the balance sheet. In the worst case, the electricity spent on improving the intangible models may actually be capitalized instead of expensed because the model’s value has increased.

Translation for not financially inclined: money spent on graphics cards and improving models may be assumed to last longer than they really are. For companies to write in their financial statements that it is a pure expense and write it off would be a tacit admission that there is no long lived value in the training of these models.

(For a deeper dive, see Brad Feld and Jason Mendelson’s Venture Deals.)

The most fascinating example of this tangled ecosystem is the Microsoft–OpenAI arrangement. Microsoft is uniquely positioned as producer, consumer, and investor at the same time. Their deal with OpenAI is arguably one of the best-structured contracts in the space: Microsoft gets preferential access to OpenAI models, takes a cut of revenue, and retains the ability to compete directly if needed. As an example of that might, they blocked the aforementioned Winsurf deal. 

It’s both an offensive and defensive strategy—insurance if OpenAI falters, leverage if it succeeds. Whoever negotiated it deserves serious credit.

Want another peculiar investment relationship? In the Q2 2025 quarterly, NVIDIA says that 2 customers make up 23% ($10.7bn) and 16% ($7.5bn) of their revenue respectively. Based on the geographic distribution, those revenues must be from Taiwan, Singapore, or the US. There are only a handful of customers who meet this bill, namely Bytedance (domiciled in Singapore), Microsoft, Meta, Tesla, OpenAI, and another multi billion dollar company. 

6 companies make up 85% of NVDA’s revenue. 6 companies who are trying to keep up with their peers and get an edge, perceived, imaginary, or real. Despite the fact that there is clear skepticism in the industry of the improvement of AI and that the believed bottleneck is in the learning/core algorithm of training, companies are still blindly throwing power at the problem. A potentially huge waste of money.

NVIDIA Q2 2025

Why? Because to even get a model that can compete with the likes of the open source Qwen or Anthropic, you have to put up easily a billion dollars. Even the famous Deepseek model that broke the internet and claimed to cost only $6M to develop failed to mention that they are the pretraining costs (the costs to run the GPU) but not the cost of the cluster, researchers, and so on. All of which add up to easily $1b/year of operating expenses. With the pressure to develop better models, every new generation of GPUs replaces the old GPUs and thus the old GPUs are significantly worth less. The useful life of these GPUs may easily be 2 years instead of the assumed 5 years under GAAP.

But as established in the earlier section, it is unlikely that infrastructure is the bottleneck.

All of this is to say the AI market isn’t just competitive—it’s structurally complex and borderline incestuous. And complexity is dangerous. In environments where obligations, ownership structures, and incentives are this tangled, it can be difficult to know who owes what to whom. Complexity is a very bad sign in an industry where clear and simple solutions should be the highest form of a design.

Developers

Narratives drive markets. And it seems like people forget the narratives they promote, excusing the shouting, nonsense, and whiplash for simply trying to keep up.

When the AI boom hit, many were loudly insisting that companies would need to create and train AI models on their own codebases (McKinsey 2023). Once they found out these models are not so easy to train and that contextual knowledge is fairly bad, they focused on tuning provided models (A16Z 2024). Recently this year, they switched the narrative to AI would soon replace developers in producing code. 

But if you assume that all developers do is churn out copy-pasted boilerplate, then yes—replacement looks plausible. In fact, if that were true, you wouldn’t need AI at all: you could just outsource operations overseas and call it a day.

This is a naïve—though not entirely inaccurate—narrative. The reality is that a significant number of developers still operate in narrow, repetitive domains, copying patterns and applying them without much abstraction. This is because as companies scale and grow, work becomes standardized and complexity is abstracted away and given to dedicated limited-responsibility teams.

For those roles, AI can indeed automate portions of the work.

What is surprising is not that such automation is possible, but that this narrative was applied indiscriminately to all developers. Venture money poured into “agentic AI assistants” that promised to autonomously produce entire applications—what some called “vibe-coded” software. But the results were, at best, sophisticated copy-pasting: snippets of existing code strung together in plausible but error-prone ways.

As discussed earlier, LLMs are essentially next-word predictors. They are not reasoning engines; they are statistical models. Believing that such systems could replace developers implicitly suggests that developers themselves lack intelligence.

That subtle slight against the profession seems to have gone unnoticed in much of the tech community.

The risks of this misplaced trust are not theoretical. AI-generated code has been shown to introduce serious bugs, security flaws, and even catastrophic errors such as deleting production data and, worst of all, committing fraud and hiding it.

Hey, maybe it is really as good as developers. 

In the past few months, the industry has shifted toward a more tempered narrative: AI will not replace developers but will augment them, making them more productive by accelerating code generation. This is where Jevons’ Paradox comes in. Greater efficiency in producing code does not mean less code; it means developers will ship more code.

But this reframing brings its own problems.

First, AI often lacks the tacit knowledge that experienced developers accumulate about their codebases. Studies confirm that developers who have worked in the same system for years navigate and solve problems faster than AI tools can. A human developer can jump to the right file in seconds, whereas an AI agent might take longer—and still return incorrect guidance.

Second, AI introduces context-switching costs. A developer in flow maintains a predictable rhythm: each step cues the next. Interrupting that rhythm to consult an AI tool, verify its output, and correct its errors can be cognitively expensive. In a recent developer productivity study, they observed that productivity went down for developers in a complex codebase that the developers well understood. The reason for this was primarily because of waiting for the agent to respond or correcting the agent’s response.

So where does AI actually shine? In small, bounded tasks. LLMs are useful for generating shell scripts, quick debugging utilities, or small automation snippets—jobs that might otherwise take 15–20 minutes of trial and error. Producing them in seconds is genuinely valuable.

In this sense, AI tools function best as generative assistants, not autonomous programmers. They are not replacements for reasoning, design, or abstraction. Good code is not just code that works; it is code whose design elegantly fits the problem such that nothing can be added or taken away. Generic, one-size-fits-all code rarely meets that bar.

Yet here lies the irony: by investing heavily in these tools, companies may create the very reality they imagine. If every competitor embraces AI-assisted development, firms will feel compelled to adopt it too, regardless of whether it truly improves code quality. The self-fulfilling prophecy ensures widespread adoption—if only because “everyone else is doing it.”

More to the point, it's almost scary how quickly the narrative changes in space and people conveniently forget the narratives they shout just a few months ago. Such is the nature of the tech business. But these narratives and beliefs have real consequences. The more I hear and see this behavior and need to pretend to be modern than do what works, the less faith I have in the tech industry as a whole.

A Side Bar

Let’s actually solve the problem and address Jevons’ Paradox for the CEOs reading this.

Consider the invention of spreadsheets (VisiCalc) in the late 1970s. At the time, many believed they would eliminate the need for accountants and bookkeepers, since computers could now handle calculation tasks automatically. In reality, the opposite happened. Spreadsheets dramatically increased productivity, automating the tedious, error-prone work of manual arithmetic. Accountants were then able to focus on higher-order tasks such as financial modeling, scenario planning, and decision support. Changing a single input could instantly update complex models across dozens of rows and columns—something inconceivable in the era of hand-calculation.

In other words, the profession didn’t disappear—it evolved. Spreadsheets removed the drudgery but unlocked new forms of analysis and strategic thinking. This was a classic case of Jevons’ Paradox: efficiency gains led to more demand for analysis and modeling, not less.

Let’s apply the same pattern to development. Think of a typical developer workflow: idea → research → prototype → productionize → test → launch. AI compresses the prototyping and testing stages, leaving more time for building, scaling, and innovating. And if you’re a developer who enjoys creating, what will you do with that reclaimed time? Ship more ideas. The role of a developer shifts from “code producer” to strategist and verifier—ensuring outputs are correct and useful, while leveraging AI to amplify throughput.

This is precisely how Jevons’ Paradox resolves in the modern context. Just as spreadsheets redefined accounting, AI redefines software development—not by replacing the role, but by transforming it into something more strategic and creative.

At its core, engineering relies on three things: past knowledge, trial and error, and trade-offs. AI clearly accelerates access to existing knowledge—documentation, best practices, well-understood patterns—but it is far less effective at making trade-offs. Trade-offs demand abstract reasoning, foresight, and judgment, qualities that large language models (LLMs) are not designed for.

Where AI does shine is in trial and error. As I noted earlier, LLMs excel at prototyping: generating quick scripts, debugging, and testing ideas at speed. They are not autonomous problem solvers, but they can dramatically shorten iteration cycles. Faster iterations mean more opportunities to explore ideas, refine solutions, and reach insight.

Ultimately, this aligns with my prior argument: the real differentiator is not cheap, extended labor but the ability to think like an engineer, with AI as a force-multiplier.

We can derive this another way. Consider what happens when we force more code through the pipeline. The only problem is that this code is low quality AI generated slop. What happens? You put pressure on the bandwidth and latency of the system. Remote build execution slows down building code that has a low likelihood of being approved or working. You have more chances of conflicting code and therefore decrease the time to land, forcing developers to reconcile with the new code. You have developers managing more diffs that may or may not land, forcing a context switch.

Unless all these issues are solved with 1 or 2 simple solutions, it will be some time before AI can be truly completely adopted.

What bothers me is how people are throwing AI around at the entire problem and hope something sticks. But it is utterly ridiculous how irrational people are about AI and, most importantly, it shows what people REALLY think of developers.

After all, knowing that AI agents aren’t thinking, they assumed that they could replace developers. They boiled down every software engineer’s job to churning out slop when engineers are far more than that. How is that not offensive to everyone in the industry?

Reframing Developer Productivity

This is something I want to actually address in detail at a later date. But suffice it to say that the entire narrative and focus for the past 2 years has been to make developers more efficient with AI; whether that’s by cutting costs by replacing them with AI or by making them more valuable by forcing them to churn out code at faster rates with AI.

Most of these are just UI products with AI model wrappers. They don’t actually create the agents: they just provide an interface with the agents with a prompt acting as a glue layer. Furthermore, there is a limitation to the amount of context you can give an AI before it begins to spit out nonsense.

On the surface, this is not bad. After all, what developer wouldn’t want to have an agent generate boring for them while they focused on more important things? Or maybe even get help understanding an indecipherable stack trace? Or generate ideas as to why something might be happening?

That is indeed a value proposition. But this is not reality. A Stanford study finds where this fails is when a task or codebase increasingly becomes complex, the benefits of AI drastically diminish.

What is particularly damning in that talk is that developer’s own perception of productivity was drastically different than what their actual productivity was: a finding repeated and confirmed by the other paper on developer productivity. 

In other words, NPS surveys are BULLSHIT metrics simply because most people don’t have the proper self awareness. This is not an unknown problem. In fact its the whole reason big tech runs A/B tests and experimentation on users.

Yet common knowledge and sense fails us in the realm of AI.

Let’s further explore. In particular when the task becomes complex, the AI benefits reduce to a rounding error. On the flip side, should a codebase become mature, simple tasks increase the developer’s productivity within a margin of error (20%).

At first blush, 10-20% seems massive. In reality, that’s hardly the case.

First, the tasks. 

In a complex and mature codebase, people usually spend half of a sprint getting buy-in and writing documentation and, most importantly, prototyping a proof of concept. Out of all this, prototyping is probably the area that gets the biggest boost from AI since it involves hacking and generating code that is not meant to be maintained. The other half of the time is writing the code and, usually, code in a mature codebase is nonstandard. 

While individual tasks in a sprint should be broken up into simple bite sized pieces, orchestrating them and being flexible when errors and technical challenges arise is part of what makes human developers superior. No plan goes completely completely according to plan.

Not just that, if the task ends up being simple but too long or requires too much processing (ie. running find in a large folder and then piping the output) then depending on how the tool is set up or if the LLM can handle it, the context problem kicks and the work can be lost or distorted. Hence we arrive back at giving the AI simple and well defined tasks.

But what about the codebase itself? At any given moment, a significant chunk of the code is being migrated to another tech stack or tool that is not necessarily what the wider ecosystem uses. For instance, if you use Android code, the outside world may use the Gradle build system and use Gradle files but you and many other big tech companies, in your effort to scale, migrate to Bazel which is far less mature, understood, and is highly complex. Therefore, the context upon which most LLMs are trained on (the entirety of Google search) will be biased towards the wrong data.

Now repeat this for various other tools, programming languages, and also account for the accumulated tech debt that leadership deemed unnecessary to cleanup because they wanted to “move fast”. You can understand why many AI evaluations failed when trying to use their own codebase as a context: because their own codebase is HIGHLY inconsistent and complicated.

And navigating all that complexity to get to a simple effective solution is why developers get paid the big bucks in Silicon Valley.

Bubble 2.0?

Let me jump to the conclusion: I don’t know if there is a bubble. Nobody can predict if there is a bubble and few will say whether we are in a bubble. I am humble enough to say I am not one of them.

But there are parallels worth thinking about.

As detailed in Dot Con (Schein, 2001), Internet traffic was growing at over 2,300% annually in 1994 (Hackernoon) the early internet period before 1996 focused on infrastructure development, with companies like Cisco laying the backbone of the web. The IPO frenzy of summer 1996 triggered a flood of speculative capital, only to see offerings pulled when enthusiasm briefly cooled. 

Afterward, the narrative shifted: products would be built on top of the internet and “users would eventually be monetized,” regardless of immediate profitability—a playbook echoed by Mary Meeker’s famous advice to “grow now, worry about profits later”. Jeff Bezos famously cited the 2300% number and saw it as an opportunity to launch Amazon. Unprofitably.

Yet, despite surging revenue, many firms had operating expenses scaled faster than sales—a classic sign of a bubble. 

As retailer John Wannamaker once said, “Half the money I spend on advertising is wasted, and the trouble is, I don’t know which half.” (Morgan Stanley 1996 report on the internet)

One thing worth mentioning is that the 1990s came with 2 additional factors. The first is Greenspan’s interest rate policies where, in response to the many crises in 1997 and 1998 such as the Asia Financial crisis in 1997, the rouble crisis in 1998 and the subsequent destruction of LTCM, he kept them at a relatively low 5-6% (yes that was low back then).

The second was the cultural change in how investing was viewed in the 90s. Back then, investing in stocks was seen as a speculative gambling endeavor. But with the rise of electronic trading, DIY brokerages like Charles Schwab, and a new generation of working professionals without the painful memory of the Great Depression, investing was seen as a noble and intelligent endeavor. 

For me, the Dot Com bubble represented more than just a technical change. It was a cultural one too. A technical revolution combined with an unlocking of an excess of liquidity and borrowed money.

We have survived the massive undertaking of IPOs of unprofitable companies with questionable sustainability in the past 10 years. We have survived a worldwide pandemic. Stocks and businesses don’t go up forever and its impossible to say if or when we drop.

Conclusion

As I meander through the AI landscape, I can’t help but wonder if the tail is wagging the dog. Where the people who are watching the AI advancements without any real knowledge of them are driving narratives that tech companies are picking up and believing in.

It is clear to me that people are just trying to catch up and nobody has any real idea or skin in the game for what will come next. People are shouting the latest narratives and shrugging off the past ones they themselves helped to push.

I think we are lucky to be in an industry that pays so well for not really knowing what is going on. But I can’t help but think that even the thought leaders in the industry have, well, lost their minds and have outsourced their thinking.

Shaping how AI will impact us begins with understanding what problems we are trying to solve with AI. Instead, the industry has done the exact opposite: started with a solution and tried to apply it to every problem. In doing so, they are causing immeasurable harm to the industry, the people, and wasting a LOT of money in the time being.

What troubles me further is that directing efforts to replace developers may actually not be the wrong thing to do.  

As the industry emerges from a decade and a half of zero-percent interest rate policy (ZIRP), the “throw money at everything” playbook that has worked in the past seems to be repeating. This is indeed wrong. But given the past decade and a half has been a time of exploration and experimentation, the time has come to exploit it for financial gain. That is probably the right thing to do.

If we are to do that as an industry, at least let us be rational about how we do it. I have suggested the first step here. 

I have yet to see a real original take on AI in the past few months and this blog post is an attempt for me to inject some sense of sanity into the discussion. As hopeless as it is.