DEV Community: BJ Kennedy

Journey Before Destination: What The Stormlight Archive Teaches Us About AI Engineering

BJ Kennedy — Tue, 10 Nov 2026 01:09:54 +0000

"Life before death. Strength before weakness. Journey before destination."

This is the First Ideal of the Knights Radiant. This simple phrase from one of my favorite fantasy series, The Stormlight Archive, is a surprisingly practical guide for both life and software engineering. It isn't about perfection. It is simply a commitment to growth over outcomes, reminding us that how we reach our destination is just as important as the outcome.

While we haven't mastered the art of Elsecalling and Oathgates, we have built technology that lets us skip the journey entirely and jump straight to a destination. Today, we can simply state "complete JIRA ticket ABC-123" and it just happens. I could say "write a thinly veiled AI-related blog post based on the concept of Journey Before Destination" and a modern fabrial would Soulcast the blog into existence. Although it wouldn't have nearly as much rambling.

In the books, Soulcasters convert one type of material into another. Using large amounts of energy stored in gemstones, they can turn stone into food. However, Soulcast items are bland replicas of the real thing. Soulcast berries lack the sweetness of real fruit, and every single one tastes identical. Real berries have subtle variations from differences in soil nutrition, rainfall, and sunlight. Every element of the journey from seed to fruit matters. Especially talented Soulcasters can improve the results, but when every step of the journey changes the outcome in subtle ways, they can't work miracles.

We see this exact phenomenon every day now. Every youth sports team suddenly has identical flyers for their social media posts. Every small-town restaurant shares the exact same style of photo for their daily special. And in software, we are seeing a flood of Soulcast pull requests. The code passes the linter and unit tests on the surface, yet it completely lacks architectural context.

Let's extend the metaphor a bit further.

Imagine an Engineering Leader named Taravangian comes to you after a stroke of brilliance.

Taravangian: "I've plotted out our entire quarterly roadmap! I call it 'The Diagram.' It is the path to our salvation! It shows everything this new Nightwatcher model says we need to do based on the current state of the project."

You: "Okay Taravangian, what's it do? How does it work?"

Taravangian: "Well, I'm not sure. I need a few days for my weekly usage limit to reset before I can explain it. Still, I told the Nightwatcher to build a roadmap that takes everything we know about the project into consideration, and to make no mistakes. So you know it must be correct."

That sounds ridiculous. No one would blindly trust vibe-transcendence. Taravangian's approach relies on a key assumption that arriving at the destination of the next milestone is the only thing that matters. He's not thinking about building a solution that is flexible enough to handle all of the changes that can occur along the way. Not even the gods themselves have all of the necessary context upfront.

Now let's look at an alternative approach to building that quarterly roadmap. This time, we have a wise Project Manager named Dalinar working alongside his Principal Engineer, Navani. (Mild spoilers ahead for Book 5 as I stretch this analogy to its limits).

Dalinar: "To build our roadmap, we need to identify the gaps in our current understanding of Roshar. We can't hit our next milestone without knowing the inner workings of our project."

Navani: "Maybe we should take a journey into the Spiritual Realm (our legacy codebase). We can see what actually caused the last few Desolations (missed deadlines). Every time the client changes direction, our architecture breaks. Once we resolve those foundational issues, delivering on the milestone itself will be much easier. We will also be far more equipped to adapt for whatever comes next."

Hoid (the greybeard staff dev who knows everything yet refuses leadership roles even though he would be great at it): "Be careful in the Spiritual Realm. Some of that spaghetti logic and buffer overruns are hard for mortal minds to comprehend. Running that code without knowing what you're doing could brick your entire system and trap it in an infinite crash loop."

Navani: "That's only because this tech debt has gone untouched for millennia without anyone auditing it. We need to go back and examine the project in detail. We have to trace the design decisions that led to our current state. By studying the project history, we can finally resolve the tech debt that caused the last few Desolations. We'll build a foundation that doesn't collapse the next time the requirements change."

These are two opposite approaches. The second requires far more work, and it is much more likely to succeed. Crucially, it doesn't succeed or fail because of any lack of capability in the AI. It succeeds because at the end of the journey, you can speak intelligently about the state of your system. You can present the problem to the client and explain your proposed solution. You can articulate why specific tech debt puts the project at risk, securing the time and resources needed to fix it.

The key problem with AI is that Taravangian's shortcut does work... sometimes.

The problem with "sometimes" is that it tricks us into thinking the destination is all that matters. When Taravangian's Diagram works on a straightforward sprint, it feels like magic. However, The Diagram was written from a static snapshot of all known context. In real-world software engineering, most of the context that matters is still unknown. It leaves you in a state where you're stuck with a brittle, misunderstood codebase that has no way of pivoting when things change.

Requirements shift. Budgets get cut. Clients discover what they actually want only after seeing what they asked for. The ways a software project can change from one day to the next are as incomprehensible and unexpected as a Bondsmith renouncing his oaths. When that kind of cosmic shift hits your project, a zero-shot roadmap generated three weeks ago becomes worthless overnight.

At the start of a project, you often get a deceptively simple requirement like "Unite Them." You can have meeting after meeting where all stakeholders nod along. Everyone assumes they are speaking the same language and understand the scope completely. Then you hit the middle of the Sanderlanche. Two days before launch, when every dependency, edge case, and integration collides at once, you realize nobody actually understood the requirement from the start. First you thought you were just uniting the frontend components. Then you realized you had to unite the microservices into a single coherent API. Only at the very last moment during the client demo do you realize they literally expected you to just clap your hands together and unite the three disparate cloud environments into one.

If you followed Taravangian's path and let a fabrial Soulcast a fragile architecture aimed at a single static destination, a sudden requirement change destroys you. All of your unspoken tech debt compounds at once, and you are stuck with a broken system you don't understand that is built to satisfy a requirement you never actually had. If you took the journey, you already hold the map in your head. You walked the codebase, wrestled with the tech debt, and used AI to illuminate the system rather than bypass it. You don't need a new Diagram to survive the pivot. Better yet, you don't need to throw out the progress you've made from taking a step back to resolve that technical debt that caused the False Desolation. You now have a more flexible solution that can adjust to whatever nonsense Odium throws at you.

None of this means I am against using AI. Quite the opposite. We still have to go along for the journey and understand everything we build with AI, just at a different level of abstraction than we are used to. We no longer need to agonize over every individual line of code. Instead, the journey has shifted from writing functions to understanding systems. When a single prompt can touch the frontend, backend, and database simultaneously, we can no longer rely on separate developers owning isolated domains. To survive the Sanderlanche when the true requirements reveal themselves, we must understand the entire stack holistically. We need to know how the data flows, where the fractures live, and how the pieces unite.

Let the machine handle the syntax, and take the Oathgate for the boilerplate. When it comes to the architecture of your system, remember the First Ideal: Journey before destination.

What 90s Game Dev Teaches Us About AI and the Future of Software Engineering

BJ Kennedy — Fri, 30 Oct 2026 20:16:27 +0000

While the speed of disruption from AI feels unprecedented, we can look to history to see what happens when a technical industry undergoes a massive, orders-of-magnitude jump in developer productivity.

If you want to see this playbook in action, look at the video game industry.

The Era of Floppy Disks and Bespoke Engines

In the early 1990s, when a studio built a new game, there were no ubiquitous off-the-shelf commercial game engines. Virtually every major title was built around a bespoke, ground-up rendering codebase. If your project fell behind schedule, you couldn't just hire a contractor who "knew the engine". The engine only existed on your studio’s hard drives.

Collaboration tooling was equally non-existent. Git didn't exist. Integrating your co-worker's code meant saving a file to a 3.5-inch floppy disk, walking across the room, physically handing it to them, and praying you didn't overwrite local changes. Want to ship on multiple platforms? You weren't tweaking build targets; you were manually rewriting C or assembly line by line for entirely different CPU architectures.

By today’s standards, the teams that created foundational genres were ridiculously small:

Final Fantasy (1987): Defined the JRPG—crafted by a core team of roughly 7 people at Square.
Wolfenstein 3D (1992): Practically birthed the modern FPS—built by a core team of just 6 people at id Software.
Quake (1996): Brought true 3D and client-server multiplayer to the genre—required roughly 9 core developers at id (a lineup that reads like a hall-of-fame roster of gaming legends) working 100-hour crunch weeks for nearly two years.

The Productivity Explosion

In the decades that followed, a firehose of productivity tools reshaped development:

Commercial engines like Unreal and Unity abstracted away lower-level graphics math so designers could focus on mechanics rather than writing custom texture-mapping routines.
Git saved us from email threads full of pathfinding_v2_FINAL_for_real.zip.
Cross-platform compilation allowed a single codebase to target PC, consoles, iOS, and Android simultaneously.

Fast forward 20 years from Quake, and even before the rise of LLMs, game development productivity had increased so dramatically that a single developer at a 48-hour game jam could routinely build a functional 3D prototype with technical feature parity to id's 1996 masterpiece.

The breakthroughs that once required an entire R&D phase on the project delivery timeline—true 3D rendering, baked lighting, a high-level scripting language, and client-server netcode—are now done the moment a developer clicks File -> New Project in Unity.

Jevons Paradox in Action

So, logically, game development studios should have shrunk, right? If one engineer can now do what required nine world-class wizards in 1996, the industry should need fewer people. Marketplaces full of cheap 3D assets should have put artists out of work.

The reality was the exact opposite.

Today, end-game credits for a AAA title routinely run for 30 to 40 minutes. Top studios employ teams of PhDs dedicated entirely to the procedural physics of how individual strands of hair, grass, and cloth react to wind. These hyper-specialized roles were completely unimaginable when John Carmack was writing raycasting algorithms. And while individual legacy roles disappeared (few people earn a living hand-porting assembly between custom chipsets today), the total workforce building games has expanded exponentially over the last three decades.

This phenomenon isn't a fluke. It's a classic economic principle known as Jevons Paradox: as technological progress increases the efficiency with which a resource is used, total consumption of that resource increases rather than decreases.

When you make software production 10x cheaper and faster, you don't get 10x fewer developers. You get 100x more ambitious software.

What This Means for AI and Software Engineering

Of course, this won't be a smooth, uninterrupted climb. Every tech paradigm shift brings market volatility: a wave of layoffs one year as executives try to pocket the efficiency gains, followed by a hiring boom the next when competitors use that same efficiency to ship vastly superior products. There will always be good times, bad times, and painful transitional jitters, but the trendline will bend upward.

We are about to see this exact paradox play out with AI and general software engineering. As AI tools lower the cost of writing syntax, we won't stop needing engineers. We’ll just build systems so complex, immersive, and context-aware that today’s software will look like Wolfenstein 3D by comparison.

I look forward to seeing what software roles we have in ten years that sound as absurd to us today as "Senior Hair Strand Simulation Engineer" would have sounded to Carmack and Romero in 1992.

The Power of Names: What Taborlin the Great Teaches Us About AI Prompting

BJ Kennedy — Fri, 16 Oct 2026 16:58:44 +0000

In The Kingkiller Chronicle, Taborlin the Great was a legendary wizard whose power was quite simple. He knew the names of things, and in knowing their true names, he commanded power over them. He could call the name of stone and demand it split in two. He could step off a tall tower and call the name of the wind, and the wind would carry him to safety.

While AI sometimes feels like a superpower in itself, it can also be incredibly frustrating. An image that seems clear and simple to describe in your head comes out looking like an artistic war crime when the model tries to interpret your prompt. The feature that seems straightforward in your application does not function at all as expected after implementation.

Furthermore, it can often be hard to even describe what makes the first implementation seem so off. I find this similar to how I feel at a wine tasting. While an aficionado can tell you all about the balanced, layered complexity of the wine, I simply know, "yes, I like this," and struggle to say why.

I believe this is why different people have such different experiences with AI and why the term "vibe coding" has become so overloaded. To some, it means blindly prompting off pure vibes with zero engineering rigor. To others, it just means directing an AI in natural language instead of typing every line of syntax yourself. In engineering work, I commonly hear, "The architecture of the code it generates is garbage," which comes from confusing the two.

Sure, it takes the path of least resistance. If you tell it, "implement code that gets data from Service A, transforms it, and loads it into our data warehouse", you're likely going to get entirely imperative-style code that does those steps in a giant, 500-line single god-method that would horrify the Chandrian themselves. No abstraction. Direct inline calls to the DB. It will not track historical changes or trends over time.

If instead you tell it to isolate side effects behind DAOs and service client classes, utilize IoC and DI for testability, and structure the warehouse around a medallion data model using Type 2 SCDs to track change over time, you'll get drastically improved, more maintainable results without significantly more effort. This comes simply by knowing the names of these basic patterns and knowing when to use them.

This doesn’t apply just to code. If you can picture an art style but don’t know what it’s called, you might ask for something like "old-timey storybook" and hope the model interprets that the same way you do. Learning that the look you’re after is Art Nouveau gives you a much more specific starting point. Technical documentation stops sounding like it was written with the flourish of the Edema Ruh when specifying that it should be written in Simplified Technical English instead of a more vague prompt like "keep it concise and unambiguous."

What I find about my own AI usage is that I’m now spending more time understanding these sorts of fundamentals in areas I'm not very familiar with. I’m studying art styles in order to better generate images. I’m studying writing styles in order to better generate prose fit to purpose. AI guides that study to help me learn the basic names, as I can now simply drop an image in and ask questions about the artistic style in a way I could never do before.

Taborlin the Great became a legend by learning the names of things to wield their power. AI gives us this superpower for far less effort. Although I'm still searching for the true name of Book 3. "Write 'The Doors of Stone.' Make no mistakes." unfortunately did not work very well.

If you're looking for a starting point, check out Semantic Anchors, a cool project that attempts to capture the names of many patterns, styles, and concepts that are useful in your prompting.