An AI Doomster's Murmur

More than a year ago, our CEO asked me a straightforward question: “Do we have a plan for fine-tuning our models when we grow bigger?” When we started, we hadn’t planned for it for obvious reasons - we were small, and the tech was nascent. I told her that people were already moving away from the term “fine-tuning.” They were calling it “alignment.” That conversation happened way before DeepSeek-R1. Of course, in the AI era, “forever” is a concept measured in months. And then came the RL (Reinforcement Learning) rampage, and now everyone is talking about alignment.

I have often observed comparisons between LLM outputs and dreams; the similarity is not merely poetic, but functional. Both are fluid, associative, and prone to hallucination. This raises a critical engineering question: How do you control the dream? To answer this, Christopher Nolan’s Inception offers the perfect mental model.

1. Dream Architecture: Time Dilation via Abstraction

The central conceit of Inception - that moving deeper into dream levels slows time relative to the surface - provides a potent framework for interacting with Large Language Models (LLMs). When you prompt a model, you are effectively asking it to “dream” a response. Like a dream, the output is probabilistic: a vivid hallucination of logic that usually aligns with reality but occasionally drifts into surreal error. To harness this, we can borrow the film’s strategy: go deeper to move faster. A single prompt represents the surface level. However, to achieve high-velocity engineering, we must utilize meta-prompts - prompts designed to generate other prompts. We do not merely ask the model to write code; we ask it to construct a code generator. At this deeper layer of abstraction, the “physics” of development shifts. A human working at the surface might spend hours writing boilerplate API endpoints. By dropping down a level - into the layer where the AI builds the tooling that generates the scaffolding - that same work compresses into minutes. It is technically more demanding, but it offers the exponential reward of time dilation.

The Writing is on the Wall

We are entering a new era where intelligence is shifting from a scarce resource to an abundant commodity. In the software industry, new models and coding agents are being released and updated not just annually, but daily. The current atmosphere carries the eerie vibe of the night before the meteors hit Earth. Much like the characters in the movie Don’t Look Up - or the dinosaurs wandering around while the sky burned - many are ignoring the inevitable. The fundamental truth that humanity has relied on for thousands of years - that intelligence is rare, requiring organic collaboration and slow, steady civilization building - is gone. This is uncharted territory. We don’t have a definitive answer for what the future looks like yet. However, after several rounds of discussions with engineers - both veterans and those early in their careers - I have found a framework for adaptation. We must become like the rodents who survived the extinction event: smaller, faster, and fundamentally different from the giants of the past.

Two Fridays ago, I had an idea: why not try to use Codex to write a PDF renderer, i.e., a tool to convert a PDF into an image? This certainly wouldn’t have been possible before coding agents, as PDF is a notoriously complex format, and a renderer can easily exceed 100K+ lines of code. But I had some unused quota, so why not?

The beginning was quite promising. I already had a JBIG2 decoder from pdfium. I quickly implemented a JPEG2000 decoder using openjp2 and cgo. And Codex created a libfreetype wrapper in no time. I asked it to use xpdf (the origin of Poppler, the other popular PDF library). In just two days, it could already render a PDF, albeit with some small issues. I thought maybe in two more days it would be done.

With my OpenAI Codex weekly token quota about to reset, I finally decided to tackle a project I’d been wanting to do for a long time: convert a JBIG2 decoder from C++ to Go. For context, JBIG2 is the codec for monochrome images in PDF files, such as scanned pages. The process involves a fair amount of math (specifically, arithmetic coding), making it a non-trivial task. However, the codebase isn’t enormous (around 7,000 lines), so it seemed like a manageable job for Codex. While several open-source JBIG2 decoders exist, I picked the one in PDFium, Google’s PDF engine used in Chrome. I chose it for its liberal license and my prior familiarity with it. I had considered other approaches, like the rule-based C to golang translator from modernc.org/sqlite, but its generated code isn’t human-friendly and carries unpleasant dependencies like a libc runtime.

“Tokens” are everywhere these days. When people say “tokens”, they’re usually talking about one of two things, and proponents of each might call the other a scam. For our purposes here, we’re not talking about crypto. It’s hard to piece everything together, so I’m going to take a stab at it for software development - after all, “software has eaten the world.” But please take this analysis with a huge grain of salt.

As large language models (LLMs) evolve from fascinating curiosities into influential tools, it’s understandable to feel swept up in the excitement. We often fixate on today’s quirks - hallucinations and context windows - and treat them as waypoints on a road toward AGI, as if each will vanish with enough scale. But some constraints aren’t bugs to be patched; they’re rooted in the architecture and the interface between people and machines. Here are four hard-coded limits that will shape LLMs, no matter how powerful they become.

For new graduates and those at the early stages of their careers, joining a startup has always been both exhilarating and daunting. But in the age of large language models (LLMs), generative AI, and accelerating breakthroughs in machine learning, this decision takes on a whole new dimension. AI startups aren’t just offering jobs; they’re providing a front-row seat to one of the most transformative technological revolutions of our lifetime. This article explores why you should consider starting your career at an AI startup, and how to evaluate which ones are worth betting on.

There’s a lot of talk about “vibe coding” lately, and I recently had an experience that may be an interesting story showing how LLMs could actually work for technically challenging problems.

Image formats and decoders have long been an interest of mine. I witnessed the hype and eventual demise of the wavelet transform-based JPEG 2000 and have been following the struggling adoption of the new JPEG XL. I’ve seen Apple’s HEIC format gain popularity, but generally, this is no longer a headline-grabbing field. That’s why I was surprised to see people already using AVIF in the wild.

At TidalWave, we are rapidly growing our product and engineering organization. A common question I get is how we manage hiring without a traditional talent acquisition team. The short answer is that we take inspiration from the very technology we work with: we practice Vibe Teaming. In the AI era, this is more than just a feeling. It’s a methodology. Think of it like crafting a high-level prompt for a generative AI: you provide a clear direction and a set of core principles, then embrace the emergent, often surprising results. It’s about aiming for high velocity and productivity by navigating uncertainty, not trying to eliminate it. While we are still bound by the laws of physics, this new paradigm of human-AI collaboration allows us to build teams in a fundamentally different way. Here are the core principles of Vibe Teaming.

A photo of Linus Torvalds and Dave Cutler (and Bill Gates) surfaced the other day, and it sparked a wave of nostalgia. Back in college, my favorite book was Inside Windows NT. I was captivated by the sheer elegance of its design - how beautifully components like schedulers, I/O request packets, and structured exception handling were engineered and assembled. Even as a die-hard Linux fan, I had to admit the NT kernel was in a class of its own in some respects. Its I/O Completion Ports (IOCP) were a masterpiece of asynchronous design, years ahead of what Linux would offer with io_uring.

It’s wild to look back at how AI has evolved. Before LLMs took over everything, we had Seq2Seq (shoutout to Ilya Sutskever’s 2014 paper) and Neural Machine Translation, which made headlines when Google Translate switched over in 2016. Then came Attention Is All You Need (2017), GPT (2018), ChatGPT (2022), O1 (2024), and now an open weight equivalent (R1) in 2025. What a ride.

By early 2023, it was clear to us that chatting would become a core interface for applications - ChatGPT was training an entire generation to interact this way. Multi-language support has always been a challenge in mortgage systems, where traditional i18n effort is heavy lifting and low ROI. But with LLMs, a new approach emerged - one where language support is built into the model, and we can shift a meaningful portion of functionality to a chat interface.