In the past year, I keep coming back to a character from a sci-fi novel when I’m planning work in a Claude Code session and simultaneously questioning my career choices, feeling both satisfied and terrified about where this all goes. In Verner Vinge’s 1999 sci-fi novel A Deepness in the Sky there is a character who founded the Qeng Ho trader civilization that lives between the stars, outside of time. Pham Nuwen has been kept alive through regular stints in cold sleep and relativistic time dilation as he traveled between the stars in the galaxy trading—and he has seen more technological eras rise and fall than humans have seen JavaScript frameworks.
Pham isn’t just a programmer. He became a bridge that spanned an old world civilization and its way to approach survival and profitability. As he grew up, he learned to patch together tools and systems from different technological eras, cultures and worlds. He made systems that were invented for radically different purposes and repurposed them for things that hadn’t been invented yet. He became valuable not because he knew the latest paradigm, but because he could figure out all the paradigms and weave them together so that information and knowledge could flow between unrelated systems. It gave him insight into what others couldn’t see — even when it was right in front of them.
The Qeng Ho and Multigenerational Software
In the universe Vinge creates for Pham, the Qeng Ho are a civilization of interstellar traders who’ve solved a problem we are just beginning to grapple with: how do you maintain software and hardware infrastructure across timeframes that span and dwarf human lifetimes and beyond the limits of human comprehension?
Their approach is fascinating. They don’t chase the new. They build translation layers on top and repurpose the old. Bugs and all, they maintain vast libraries of interface standards that can bridge incompatible systems. They treat software not as a product with features and a lifecycle, but as infrastructure that will outlive its creators. A Qeng Ho programmer might spend their career maintaining compatibility between systems separated by centuries of development.
The Qeng Ho are patient. They think in generations. They know that the hot new framework everything is built on will be legacy code even before one of their ships reaches its destination.
Sound familiar?
Except that we’re doing it in fast-forward. What the Qeng Ho experience across centuries, we’re experiencing in quarters. Newer models drop, more systems are generated with them and the pace keeps accelerating. We’re building systems that need to interface with what’s already there but has been forgotten, using tools we don’t fully understand, for a future we can’t predict. The Qeng Ho knew better than to try predicting — they built for compatibility instead. We might want to take notes.
The Archaeologist-Conductor
I’ve started thinking of my work differently lately. In the past two years, I’m not really a “software engineer” in the way I was five years ago. I’m becoming something else—something closer to what Vinge imagines in the Qeng Ho and Pham Nuwen.
Let’s call it an archaeologist-conductor.
For the archaeologist part: I spend more time digging through layers of existing code—understanding what it does, why it is built that way, what assumptions it makes—than I do writing to describe a net-new system that builds on top of what came before. With AI tools, I can generate numerous implementations in an afternoon to explore a problem. The hard part is knowing which one fits the archaeological context of the system I’m working in. The second hard part is knowing when good enough is good enough.
The conductor part: I’m orchestrating. I’m pointing AI agents at problems, reviewing their work and having them review their work. Then I’m stitching together outputs from different agents to review and combine in order to get the abstract idea in my head into a concrete form—detailed specs and working code. The popular term is orchestration but it feels more like I’m conducting a symphony where half the musicians are extremely confident in their output but occasionally play in the wrong key and try to tell me that it still sounds ok. Or worse, it insists that it’s playing Matchbox Twenty when I clearly asked for TOOL.
This isn’t what I thought “lead engineer” would look like. It’s weirder. And I’m still figuring out if it’s better, worse or just different. Even though I know there is no going back to the way it used to be, the only way out is through—one foot in front of the other.
The Trust Problem (Or: The Bug That Crossed Five Layers)
Here’s a real example of what this looks like in practice.
A bug report comes in. User sees wrong data in the UI. Simple enough, right? Except it’s not a frontend bug. Or maybe it is. Hard to tell.
In the old world, I’d add some console.logs, trace through the app components, check the API response, maybe dig into the api code. If it was a database issue, I’d find someone with production access to investigate.
Now? I tell an AI agent: “Trace this bug from the Chrome dev tools console to the database and help me identify the root cause.” Or even crazier, I’ll spend time writing up the details I wish were in the bug report—step by step recreation and expected vs actual behavior—and hand it off to the agent, who farms that out to the Playwright MCP, and the Postgres MCP so it can trace the system and compile a report for me to analyze.
And it does.
It uses the Playwright MCP to control the browser, Chrome MCP to inspect the browser state. It pulls the Linear ticket details to understand the context to layer on with my writeup so it can trace through the api and backend code until it queries the actual database to see what data exists versus what the frontend is displaying. Maybe it identifies a type coercion issue three layers deep in a service or a timing issue with the message queue that’s keeping stale data in the client.
Total time: maybe twenty minutes. Including the time I spent staring at the result wondering if I should trust it.
This is my Pham Nuwen moment. I just navigated through five different layers of the stack—frontend, API gateway, service layer, ORM, database—using tools that translated between each layer automatically—tools I couldn’t explain the internals of. I understood enough to verify the diagnosis. I didn’t understand enough to have found it myself, not without hours of work.
The question that keeps me up at night: am I becoming more capable, or less? In the Fox Mulder sense of the phrase, I want to believe (that I am more capable) but should I trust blindly or verify? Do I even have the time to verify? Sometimes I come up with a test case and do things like verify the data that goes into the database. Other times, I write down what I expect to happen in the client and test that by logging data from the service layer or the ORM layer so that I can touch the system, as it were.
I don’t know, I want to believe it’s making me smarter but is being more capable because of these tools making me smarter? Am I faster and smarter or just faster at getting things done and fucking things up because I lose control of the changes I introduced into the system without understanding the theory beneath them? ¯\_(ツ)_/¯ Maybe that’s just a different version of still figuring it out.
The Knowledge Gap Paradox
That experience—tracing a bug through the system I couldn’t have navigated alone—is changing how I think about the T-shaped engineer debate. I’ve always been able to trace through the whole system (T-shape) but found it a little tedious to be honest, my imposter system says that’s not really full stack in the traditional sense. Tracing and debugging an api or service and writing sql—meh. Staying focused on the intersection where a human touches the software—that’s why I stay focused on frontend. But in the past couple of years as I’ve used AI more and more, it’s become a tool to learn and explore everything. As those tools have become more capable and with the proper guardrails, trustable—I find that the system is even more interesting because of the interface it provides to users who have work to do and couldn’t care less what’s under the hood.
It helps me expand the breadth of the horizontal bar of the T—that broad awareness of how systems fit together—I’m getting that through AI-assisted archaeology. I’ll ask questions like “how does authentication flow through this system?” and get an architectural tour in real-time, with a guided map that quizzes me on what I think I understand. I’m reading code that was written generated by people who’ve since left the company or have moved on to other parts of the system. Instead of guessing what they were thinking I can see and interrogate the code they left behind. I get access to the unwritten tribal knowledge that only exists in the codebase itself.
I’ve started creating my own agent skills for this that live outside of the committed repo stuff—a teacher (what’s the theory or the why?), the researcher (what are the fundamentals or the how?), the educator (am I really sure of what I think I know?). Before AI the only way to really learn stuff like this was if I lucked out and found myself on a team of people more experienced than I was or spent a lot of time sifting through books, papers, posts and videos to get information that I could test and synthesize into knowledge and wisdom through practice.
Now, I can get there in an afternoon of conversation and exploration with a synthetic intelligence and turn that into something that can help my team, my product, my organization.
Is that “real” knowledge?
Honestly, I don’t know but it feels like this is what Pham Nuwen was doing all along. With synthetic intelligence we can all develop the meta-skill of bridging between layers we don’t fully understand, using tools that compress months of learning into hours of guided exploration. All it asks is curiosity and the humility to be tested on what you actually know.
Team Dynamics and the New Path to Senior
This creates interesting fractures in engineering teams, especially as our industry debates whether AI means fewer junior engineers or different ones. In the past, an engineer would spend twenty years building a deep expertise in a domain and would branch out as they gained experience and influence in an organization. They’ve seen the subtle production-only bugs and have the scars to show for it. They can see problems long before they arrive—and now they’re watching less experienced engineers aided by synthetic intelligence ship solutions that mostly work, most of the time without really understanding the fundamentals.
I’m seeing two archetypal reactions to this. Some are embracing these tools with excitement and curiosity and some are grieving, cynical and bitter that the world around them is changing. But beyond the emotional reaction, something structural in engineering growth and development is shifting—the path to becoming a senior engineer with influence is changing, the tools are different but the destination is surprisingly similar.
The old path: go deep in one area, gradually expand, accumulate scar tissue and wisdom and become the person who can help the organization see around corners to solve the problems they can’t see yet because they have been around those corners before and paid the price of failure.
The new path: learn to learn, then leverage synthetic intelligence as a tool for architectural investigation, orchestration and self teaching. Get good at verification and systemic guardrails and calibrate between the two to keep the system in motion. Develop a taste for good enough versus subtly wrong. Master the art of a clarifying question—it unlocks new ideas and different, sometimes better, solutions that we never would have had time for when on the old path.
Let me be clear, the new path isn’t a replacement of the old path. More like an evolution because both are valuable and being senior or exerting influence isn’t only a mastery of synthetic intelligence tooling—it’s walking the path of shipping and supporting software that solves real, human problems. If we don’t coach our junior and mid-level engineers—or worse, pretend we don’t need them so someone can make next quarter’s numbers look better—we’re setting ourselves up for systemic failure. It will be the AI version of a greenfield project—not because of technical debt and new technology, but because we failed to make both the old path and the new path part of the culture that produces software.
In short, if you were paying the Qeng Ho or Pham Nuwen to advise how you build products, teams and organizations they’d advocate for generalists over specialists—people who can translate between incompatible systems and maintain infrastructure they didn’t build and don’t fully understand. They’d insist that generational thinking is part of the culture, arguably more important than any single technology. (Vinge readers: yes, except for the localizers.)
Figuring It Out
Here’s what I keep coming back to: Vernor Vinge wrote A Deepness in the Sky in 1999, before GitHub, before the cloud, before frontend framework wars and the explosion of new tools and programming languages and paradigms. It was written long before most of the tools we consider fundamental. And yet he somehow intuited this exact moment we’re living through.
Not the specific technologies. The shape of the problem.
How do you maintain products across incomprehensible gulfs of time and context? How do you trust systems you can never fully understand? How do you bridge between eras of technology that have fundamentally different assumptions? What skills matter when the ground keeps shifting, faster and faster and faster?
The Qeng Ho answered those questions with patience, with translation layers, with a culture that valued compatibility and curiosity over novelty. They built for the long term because they had no choice—their timescales forced it.
I think we are in the same boat. We don’t have their luxury of long voyage times between stars and client planets. We’re doing it in real-time, with tools that are evolving faster than we can develop best practices for them. We’re becoming archaeologist-conductors not because we chose it, but because that’s what this moment requires.
We’re all the Qeng Ho and Pham Nuwen now. We went to sleep at some point between 2021 and 2026 and woke up treading water in a future we didn’t quite predict, using tools we don’t fully understand, trying to bridge between the code we wrote last year and the code we’ll need next quarter.
And in a field that’s changing this fast, sometimes the best thing I can do is spend a few hours thinking in timescales that dwarf my own anxiety about obsolescence.
