AI & Avoiding Hyperbole

by

AI will save us. AI will doom us. AI will enslave us. AI will enlighten us.

Every week brings a new wave of hyperbolic AI headlines, each more dramatic than the last.

The discourse around AI is mostly ill-informed. Take a recent article from Fortune magazine (see comments). The headline goes: “AI doesn’t just require tons of electric power. It also guzzles enormous sums of water.”

In the article, there this statement: “In order to shoot off one email per week for a year, ChatGPT would use up 27 liters of water, or about one-and-a-half jugs… that means if one in 10 U.S. residents—16 million people—asked ChatGPT to write an email a week, it’d cost more than 435 million liters of water.”

Predictably, the article (from September 2024) has lots of likes and replies on social media talking about how AI is going to doom us all and is a waste of precious energy.

So this article assumes the amount of power required to run inference – i.e. when ChatGPT helps compose an email and maps to the amount of water required to generate that power.

Interestingly, the cost of running inference has gone down substantially over the last year. Recent research by DeepSeek (see comments) also shows how it is possible to train a state of the art model for a fraction of the cost of training foundation models.

Discourse about how AI is ruining the planet conveniently takes data from today and projects it infinitely into the future. Let me put it this way – in 1965 the average gas mileage for a small car was around 15 – 20 MPG. A modern car is 3X more fuel efficient (Toyota Prius or Honda Civic). And it is still fundamentally an internal combustion engine.

Software and AI move much, much faster than the automobile industry. So the next time you see a headline about AI’s apocalyptic resource consumption, remember – you’re probably reading tomorrow’s equivalent of “The Internet Will Crash Under Its Own Weight” articles from 1995.

On DeepSeek

by

Is it really doomsday for U.S. AI companies? The harbinger of the apocalypse appears to be a blue whale.

Nvidia’s stock is down 12.5%. There’s a broad tech sell-off, and Big Tech seems a little uneasy.

The reason? A Chinese hedge fund built and trained a state-of-the-art LLM to give their spare GPUs something to do.

DeepSeek’s R1 model reportedly performs on par with OpenAI’s cutting-edge o1 models. The twist? They claim to have trained it for a fraction of the cost of models like GPT-4 or Claude Sonnet—and did so using GPUs that are 3-4 years old. To top it off, the DeepSeek API is priced significantly lower than the OpenAI API.

Why did this trigger a sell-off of Nvidia (NVDA)?

  • It shows that building cutting-edge models doesn’t require tens of thousands of the latest Nvidia GPUs anymore.
  • DeepSeek’s models run at a fraction of the cost of large LLMs, which could shift demand away from Nvidia’s high-end hardware.

For U.S. companies, this is a wake-up call. The Biden-era export restrictions didn’t have the intended impact. But for anyone building on AI, there’s a silver lining:

  • Building LLMs and reasoning models is no longer limited to companies throwing billions at compute.
  • This will likely kick off an arms race as U.S. companies race to optimize costs and stay competitive with DeepSeek.
  • Data sovereignty will still matter—most companies won’t want their data processed by a Chinese-hosted model. If DeepSeek’s approach proves viable, expect U.S. providers to replicate it.

Categories AI Tags

Show, Don’t Tell: Enhancing Communication with AI Tools

by

“Show, don’t tell” are words I live by.

Recently, I put this into practice when prototyping a UI change for Adapt, Jeavio‘s LLM-powered knowledge platform. Instead of writing requirements docs, I tried something different.

I uploaded a screenshot to Claude, described the changes I wanted, and got back a working React component – turning what typically takes days of back-and-forth into a clear demonstration in under an hour.

Over the last few months, we’ve enhanced Adapt’s capabilities to handle complex queries like:
“Summarize last week’s meeting notes and identify action items.”
The platform breaks these down:
☑ Actions (what to do)
🗄️Resources (what to use)
🔎Constraints (how to filter)

While this approach has made Adapt very powerful, it also makes it difficult to understand how a user prompt results in a set of outputs.

Inspired by GitHub Copilot’s inline explanations, I wanted Adapt to provide similar transparency about its reasoning. Using Claude’s Artifacts feature, I quickly created and shared a high-fidelity prototype with my team, showing how this could work.

Playground by Richard Powers

by

I read most of “Playground” in a rattly old plane as it shook and juddered over the Atlantic and then the vast emptiness of Russia before landing in New Delhi. I finished the book in a crowded airport, in tears and in awe of what Richard Powers has achieved.

Playground has a beautiful cover

The novel weaves together an exploration of friendship and the games people play with one another, a hypnotic love letter to the ocean, and a deep meditation on technology and meaning. Like memory itself, the story refuses to follow straight lines. Instead, it spirals and circles, guided by a narrator whose version of events becomes increasingly complex and layered as the story unfolds.

At its heart are four people – Todd, Rafi, Ina, and Evie. Todd and Rafi both call Chicago home, but they might as well be from different planets. Todd is wealthy, white, and obsessed with computers; Rafi is poor, African American, and a precocious reader. What bridges their worlds is a shared love of games – chess, Go, and eventually the intricate game of their own peculiar friendship. When they meet Ina in college, their duo becomes a trio, and their lives become permanently entangled in ways that echo across decades.

In contrast stands Evie – a scientist and pioneering diver whose sections contain the book’s most luminous writing. Through her eyes, we discover coral reefs, sunken ships, and manta rays in passages that evoke pure wonder about the ocean’s depths. While others build virtual worlds, Evie explores an actual one, until all four lives ultimately converge on the Pacific island of Makatea – a place strip-mined for phosphate in the 20th century and slowly being reclaimed by jungle. The island stands as a testament to both human intervention and nature’s resilience.

Threading through these human stories runs the history of modern technology and machine learning, embodied in Todd’s journey. He transforms his obsession with computers and gaming into a wildly successful social platform that crosses Reddit with Facebook. But as his success peaks, tragedy strikes – a debilitating neurological disease that leads him to narrate his story to an AI assistant before memory fails. This creates layers of uncertainty about perception and reality that build toward a wonderful (and slightly puzzling) final act that questions what it means to be alive and how technology might reshape our understanding of consciousness and truth.

As a technologist, I found “Playground” to be a powerful lens for examining both my relationship with technology and my feelings about the natural world as we venture deeper into the Anthropocene. The book doesn’t choose sides. Instead, it shows us how the awe inspired by a coral reef and the possibilities of artificial intelligence can coexist, each raising questions about consciousness and reality that the other helps us explore.

If only I could write like Mr Powers

There’s still so much to process in this book. Like the games its characters play, each move reveals new possibilities, new uncertainties to consider. And I’m nowhere near done processing.

Negotiating with a strange peer ..

by

An under-appreciated facet of LLMs is just how *weird* they are.

Claude, ChatGPT, and pretty much every other application built on top of an LLM have a system prompt. This is a set of instructions that drives the application’s behavior. The good folks at Anthropic recently released the system prompts used for the Claude application (see link below).

Anyone building applications on top of LLMs should examine Claude’s system prompts to understand how “prompt engineering” is done in production.

Take this example:

“Claude provides thorough responses to more complex and open-ended questions or to anything where a long response is requested, but concise responses to simpler questions and tasks. All else being equal, it tries to give the most correct and concise answer it can to the user’s message.”

This is how “programming” in an LLM-powered world works. As a recovering Java programmer, this blows my mind 🤯.

Here is the thing—we are going to see wild new software experiences built on top of LLMs in the coming years.

But this will only happen once software engineers shed decades of iterative or declarative approaches to “programming” and learn how to work with LLMs.

A paradigm shift will be required to move us beyond the idea that LLMs are just another fancy API that we can integrate into existing applications.

We call working with LLMs “prompt engineering,” but there isn’t much engineering here. This art or skill should probably be called “LLM Whispering” or “LLM Negotiation.” Because what we will be doing isn’t engineering so much as negotiating or working with a very strange peer.

Melanie Mitchell on the Turing Test

by

From “The Turing test and our shifting conceptions of intelligence” by Melanie Mitchell.

In her insightful piece, “The Turing Test and our shifting conceptions of intelligence,” Melanie Mitchell challenges the traditional view of the Turing Test as a valid measure of intelligence. She argues that while the test may indicate a machine’s ability to mimic human conversation, it fails to assess deeper cognitive abilities, as demonstrated by the limitations of large language models (LLMs) in reasoning tasks. This prompts us to reconsider what it truly means for a machine to think, moving beyond mere mimicry to a more nuanced understanding of intelligence.

Our understanding of intelligence may be shifting beyond what Turing initially imagined.

From the article:

On why Turing initially proposed the Turing Test

Turing’s point was that if a computer seems indistinguishable from a human (aside from its appearance and other physical characteristics), why shouldn’t we consider it to be a thinking entity? Why should we restrict “thinking” status only to humans (or more generally, entities made of biological cells)? As the computer scientist Scott Aaronson described it, Turing’s proposal is “a plea against meat chauvinism.”

A common criticism of the Turing Test as a measure of AI capability

Because its focus is on fooling humans rather than on more directly testing intelligence, many AI researchers have long dismissed the Turing Test as a distraction, a test “not for AI to pass, but for humans to fail.”

The Mountain in the Sea by Ray Naylor

by

In times of rapid change, fiction serves as a reflective lens, casting light on current anxieties and offering insights beyond simple commentary. “The Mountain in the Sea” by Ray Nayler navigates the complex relationship between humans and technology.

But Nayler’s work goes further. While the book revolves around first contact with a civilization of Octopii, it delves into the nature of consciousness. It critiques our relentless drive to build, optimize, and consume. Nayler raises pertinent questions about loneliness, isolation, and the role of technology in our lives.

In the pages of “The Mountain in the Sea,” these themes come alive through well-realized characters and intricate plotlines, providing a vital tool for understanding our relationship with the worlds we live in – social, internal, external, and digital.

There are three PoV characters – Ha Nguyen is a scientist who has spent years studying Cephalods – the family of animals that include Octopus, Squid, and Cuttlefish. The second character is a hacker, Rustem, who specializes in breaking AIs. The third is a young Japanese man, Eiko, who, through a series of unfortunate events, ends up a slave aboard an AI-powered fishing vessel.

Each character in the book deals with loneliness and isolation and has somewhat awkward if dependent, relationships with technology.

In general, AI, or the nature of intelligence, is a key theme that runs through the various plot lines of the book. Ha Nguyen and her team try to make sense of the culture and symbolic language of the Octopus civilization. Eiko has to deal with a murderous and indifferent AI driven by optimization algorithms built to maximize the amount of protein the ship hauls from the depleted oceans.

While I picked up the book because of the striking cover and because I love First Contact books – I read it in a couple of sittings because of the underlying themes of our relationship and dependence on technology and what it does to us and the world around us resonated deeply with me. As someone excited about technology’s promises and challenges, this book prompted me to consider where our pursuit of innovation is taking us.

For example, people in “The Mountain..” have AI companions called point-fives. These companions form relationships but do not make any demands on their human owners. They give, but they do not take. There is only one point five instead of two “people” in a relationship. Hence the moniker.

The loneliness of people in this world is mollified by technology, but it is not solved. The only way is through genuine contact, through a process of both taking and giving.

I spend a lot of time working on and thinking about systems that would save time, optimize workflows, and make more money. Despite the potential for disruption and displacement, I welcome new technology like Generative AI.

But, there are clearly issues and risks in the somewhat reckless attitude to embracing technology. Threats not just to our environment but also to society and to ourselves.

“The Mountain in the Sea” is a cautionary tale and a story of hope. Each character’s arc in the novel is discovery and possible redemption. This book had me thinking long and hard about where our obsession with optimization and technology is taking us.

Smallville, Agent Based Modeling, and Capital Markets

by

Google and Stanford cooked up something intriguing—a virtual village called Smallville, populated by agents running on the #ChatGPT API.

The researchers witnessed interesting emergent behavior, from coordination and communication to downright adorable interactions among the village’s wholesome residents.

Smallville even comes with cute graphics. But beyond the little sprites organizing Valentine’s Parties (yes, that’s what happens in Smallville): this experiment made me think of my time, a long time ago and in a City far away, in Capital Markets.

Smallville (courtesy Ars Technica)

Sidebar

Derivatives are a vast market. And derivatives, like options, are priced using a somewhat arcane mathematical field called Stochastic Calculus – the Black-Scholes equation being a famous example.

The underlying assumption is that markets behave randomly, and Stochastic Calculus provides a way of modeling this behavior. But – this approach can have problems. Even the famous creators of the Black-Scholes equation spectacularly blew up their fund LTCM.

Enter Agent Based Modelling (ABM): a nifty but niche approach that relies on simulating the behavior of market participants via Agents. The idea is that these simulations provide a better insight into how the market may evolve under different conditions.

Smallville shows us that LLM-driven agents are a possibility. Is it a stretch to envision specialized LLMs, trained on financial data, being used in ABM to predict how a particularly temperamental market might behave?

If you are a quantitative analyst on a sell-side firm looking to market-make a particularly exotic derivative, an LLM-powered approach may be viable. Or at least less boring than reaching for the Stochastic Calculus textbook.

The future might find traders armed with their own simulated worlds to forecast the price of, oh, let’s say, a derivative on the price of an exotic tulip of a non-fungible JPEG of a smoking Ape.. who knows?

PS – The painting is called “The Copenhagen Stock Exchange” by P.S. Krøyer. You can see why an agent-based approach to simulating capital markets is a .. possibility..

The Future is Here..

by

It’s just not very evenly distributed ..

This thought-provoking quote by William Gibson has been on my mind recently. The frantic pace of AI development contrasts sharply with the casual indifference of friends and family who do not care about cutting-edge technology.

Most people outside the tech community may have heard about ChatGPT, LLMs, or other “autonomous” technology in passing.

However, we will increasingly see these worlds intersect. Take, for example, this amusing video of a San Francisco police officer attempting to reason with a wayward Waymo car.

The cop steps before the slow-moving vehicle, commanding it to stop and stay like an errant puppy. He then lights a flare in front of the car, hoping the smoke would make it stop.

The video is funny but is also a cautionary tale of the types of issues that we will face when introducing autonomous agents to the broader public.

Just like the bewildered cop, we will have to deal with users who do not understand the capabilities and limitations of new technology.

Designing effective User Interfaces and Experiences for these complex new technologies will be critical to broad and safe adoption.

Book Review – A Philosophy of Software Design by John Ousterhout

by

“A Philosophy of Software Design” by John Ousterhout is a short and thought-provoking book about practical software development.

Key Concept

The book starts with a bold claim – the most critical job of a software engineer is to reduce and manage complexity.

Mr. Ousterhout defines complexity as “anything related to the structure of a software system that makes it hard to understand and modify the system.”

This definition serves as a motivating principle for the book. The author explores where complexity comes from and how to reduce it in a series of short chapters, which often include real-world code examples.

My well-thumbed copy of the book

Summary

The book starts with identifying the symptoms of complexity:

  1. The difficulty in making seemingly simple changes to a system.
  2. Increasing cognitive load – i.e., a developer’s ability to understand a system’s behavior.
  3. The presence of “Unknown unknowns” – undocumented and non-obvious behavior.

Mr. Ousterhout states that there are two leading causes of complexity in a software system:

  1. Dependencies – A given piece of code cannot be understood or modified in isolation
  2. Obscurity – When vital information is not apparent. Obscurity arises due to a need for more consistency in how the code is written and missing documentation.

To reduce complexity, a developer must focus not only on writing correct code (“Tactical Programming”) but also invest time to produce clean designs, and effective comments and fix problems as they arise (“Strategic Programming”).

The book provides several actionable approaches to reducing complexity.

Some highlights:

  • Modular design can help encapsulate complexity, freeing developers to focus on one problem at a time. It is more important for a module to have a simple interface than a simple implementation.
  • Prevent information leakage between modules and write specialized code that implements specific features (once!).
  • Functions (or modules) should be deep – and developers should prioritize sound design over writing short and easy-to-read functions.
  • Consider multiple options when faced with a design decision. Exploring non-obvious solutions before implementing them could result in more performant and less complex code.
  • Writing comments should be part of the design process, and developers should use comments to describe things that are not obvious from the code.

The book concludes with a discussion of trends in software development, including agile development, test-driven development, and object-oriented programming.

Conclusion

“A Philosophy of Software Design” is an opinionated and focused book. It provides a clear view of the challenges of writing good code, which I found valuable.

Mr. Ousterhout provides actionable advice for novice and experienced developers by focusing on code, comments, and modules.

However, the book is also relatively low-level. The book contains little discussion around system design, distributed systems, or effective communication (outside of good code and effective comments).

While books such as “The Pragmatic Programmer” provide a more rounded approach to software engineering, I admire that Mr. Ousterhout sticks to the core concepts in his book.