Destination v Journey Engineering in the AI Age
Why craft still matters, why outcomes still win, and how to go as fast as you should.
Years ago, I went on a backpacking trip to Philmont Scout Ranch . Context: I’m an Eagle Scout and was in Scouts from roughly kindergarten-ish through high school. Not everyone’s experience in scouting is great, but mine was extraordinary and deeply formative for me. I learned to lead, made some amazing friends, fostered tons of outdoor skills, including what to do when you (one day) run out of water . But that’s a story for a different time.
Anyways, Scouts do lots and lots of backpacking and camping. We spent time at most of the common areas in Southern California and even went to some of the nationally-popular ones, known as “high adventure”. There were/are three: Northern Tier (in Minnesota), Sea Base (Florida Keys), and Philmont (New Mexico). I was lucky enough to do them all and they were incredible experiences. I canoed 100+ miles in a week, crawled through swamps and slept on a deserted island, and trekked through mountain lightning storms. It was, without exaggeration, awesome.
Take a hike!
I want to talk about my time at Philmont , the high adventure camp in New Mexico. We planned a 70-ish-mile (I think?) backpacking trip over 10 days, with 6 people in my group. Two adults, 4 scouts. We were all relatively senior leaders in the troop (Scouting group) and were good friends. Everyone would go on to make the rank of Eagle and do cool stuff. My rough recollection of our plan was to leave Philmont HQ, loop through Cimmaroncito peak, transit a few mountains in that area, then return via the Tooth of Time.
Things mostly went to plan, with a few hiccups. We got caught in a lightning storm, had to improvise fuel for cooking during an unexpected rainstorm (lost some eyebrows), and a few other standard backpacking mishaps. Some park rangers terrified us with stories of a mountain lioness who was training her cub to track and hunt people and to this day I have a lot of “respect” for these animals.
I mainly have incredible memories from the trip and learned some cool new backpacking tricks; a former green beret taught me how to fashion a climbing harness from rope, I rappelled down a cliffside, experienced three new kinds of outdoor toilet.
Pilot-to-bombardier, pilot-to-copilot, and ‘Red Roof Inn’, if you were wondering.So, what?
On a philosophical level, the part I remember the most was seeing how different parts of our group approached the trip. A few of us wanted to attack the trip and treat it like a race. Arrive early, go as fast as possible, carry as much as possible, be up at the crack of dawn. The rest wanted to enjoy the process of getting there, take our time, quite literally “enjoy the view”.
These tensions simmered at a low level for most of the trip. The time-takers begrudgingly accommodated the completionists for most of the trip, and the completionists begrudgingly slowed down when the time-takers demanded it. We mostly compromised and then passive-aggressively stewed while either waiting or rushing in between having a great time.
The consequences of speed and exertion caught up around 2/3 of the way through, however. Some time-takers had to fireman-carry completionists with spasming backs. Blisters were cared for. Too-heavy backpack loads were redistributed. The time-takers had their own dose of justice, too, when we had to very , very slowly descend the Tooth of Time over countless switchbacks into basecamp. The scenic route is significantly less enjoyable at the end of 70 miles when you can see twinkling lights in the distance that represent showers, real food, and chairs to sit on.
¿Por qué no los dos?
I was mostly on the side of the time-takers when I went on the trip, but on reflection have come to a more balanced take. I was and remain deeply uninterested in waking up early for no reason (although I will happily do so for the right one). But it’s true that had we meandered through the trip, we would have covered less ground and missed out on some incredible experiences that happened at precise times and places because of the pace we were traveling at. Not to mention the feeling of accomplishment at going as far as we did would also certainly have been diminished.
Now, I write all of this, of course, so we can talk about AI. Why write anything for any other reason these days? Just kidding (mostly), but there are some real parallels. AI tooling (Claude, Codex, Pi, OpenCode, Hermes, etc.) have resurfaced the old “does the ✨craft✨ of it all really matter” discussion. Anyone who’s worked in tech long enough will be familiar with this as a sub-genre of things to argue about. Does anything matter beyond the outcome? Does the quality of the code matter? Do we build the foundation now or take a shortcut? Should we use Rust or the thing we know? Should it work or be fast? Even the classic “tabs versus spaces” is exists somewhere on the quality v. outcome spectrum.
I’ve been finding “destination” versus “journey” framing helpful recently when thinking about this. Journey engineers love the craft, spending time polishing abstractions, elucidating a coherent resonance in the software. They tend to love the making as much as what’s being made. Destination engineers, on the other hand, tend towards outcomes over polish. This is a false polarization to some extent - treat it as a ‘general tendencies' rather than a hard rule. I have seen this firsthand over my whole career though.
LLMs and agentic coding harnesses have made it cheap enough (time-wise, at least) that the destination engineers can (and should!) be having a field day. The smart-sand slop cannons can spew out somewhat-ok code faster and more coherently than ever before! You can one-shot software with good reference points enough prior art. Brand new stuff, maybe not so much , but hey — pretty wild times we live in.
Journey engineers, on the other hand, see the slop farms and lament the redundancy, the odd names, the repetitious madness. I hear questions like “is my job just poking these agents now?” or “I’m worried about what happens if I get too far away from the code.” And their worries aren’t unfounded. Today’s LLMs over-edit and can be unreliable delegates , despite the cool thing they can do. There’s also some early research about what happens when you’re “too far” from the code — atrophy of some kind seems inevitable there.
So who wins?
What do?
First, I don’t know how far the LLMs / harnesses will get in terms of their capabilities by what time. I also don’t know what impact that will or won’t have on the industry, society, etc. No one does and don’t listen to them if they tell you they do. But here we are a few years into the brave new AI world and at least a few things seem clear and true to me:
Already, Not Yet
You don’t have to only be a destination or journey engineer. Be both! Don’t fall into polarized thinking. If you care about outcomes, you’ll circle your way back to the quality because, surprise surprise! it matters and can affect the outcome. But because you care about outcomes, you also recognize that time is finite and we only have so much. So you’ll mind the clock and make sure you move along at a good pace. The craft and quality already matter, even at the outset, but the outcome they’ll impact hasn’t been impacted yet. Building things for a changing future is hard; what you’re doing now is already impacting the “not yet” of tomorrow.
Remember though, you're not Google. Just make a button.So you can — hear me out — use our brains and balance speed versus polish. Does making the button the bluest blue it could ever be actually matter? Maybe ! But it’s your job to work out when it does or doesn’t and invest accordingly. Use the tools of the day (LLMs today) to go fast where you should. Invest in detail and craft where it matters more with the savings you get from using AI tools.
Going Fast Matters
Go as fast as you should while you can
I tell teams to “go as fast as you should while you can” because it really is true that speed is unfair advantage. Build something good but as fast as you should where you can run free from consumers, changing demands, and the privilege of being in production. I say “should” and not “can” because at the outset you’re laying the foundation for the future and should take your best guess at what a system should be for the next, say, 18 months. Going as fast as you can might mean you underspec or make design mistakes that bite you even at the outset.
Something I got from Jensen Huang. Maybe the closest approximation to my whole philosophy of engineering.Do as much as necessary, but as little as possible.
Coding was never the whole job
Software engineering was never just about the typing of the characters on the screen. For one, that’s usually the easiest part. It’s way harder in my experience to make sure that you’re building the right thing, the business is aligned, and to convince a bunch of other people to do the right thing than it ever has been to create a helper function the right way.
For another, we’ve seen a steady abstraction over the programmability of electrons for basically the entire history of the profession. Vacuum tubes to punch cards to assembly to compilers to VMs to high level languages to SDKs to IDEs to agentic harnesses. I haven’t done this for 50 years, but a quick look shows that this AI stuff is new in form but not in progression.
Back to Basecamp
I really enjoyed my time at Philmont. Not every part. Carrying my buddy on my shoulders for a few miles? Not so much. The fireball that somewhat-gently toasted my head? Also maybe not so much. But the radically rewarding and beauteous experience that is standing on a mountain you just climbed? Immensely so.
The balance that came from the time-takers and the go-faster’s coming together resulted in what was ultimately a pretty perfect backpacking trip. We spent time where it was valuable, but didn’t dillydally. We went far and we enjoyed it.
And so it is with backpacking as with software: the only way to go far and fast is to go together and to go well.
