"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.
Top comments (1)
The journey framing works if it encourages observable iteration rather than perpetual experimentation. Teams still need a destination in the form of an evaluation target, a stopping rule, and a record of what each iteration changed in reliability or cost.