A Life Engineered · A Life Engineered · Transcript & summary by WhipScribe
It gives junior engineers a concrete test for whether their AI-assisted work still makes them worth delegating to.
Tap a chapter to open that moment in the transcript; the link to it is copied for you.
“Are you team read the code? Or are you team like Vibe, you just care about the outputs?” Steve Huynh · at 3:55 — open in the transcript →
“For my own personal work, I am on team read the code for sure.” Guest · at 4:01 — open in the transcript →
Steve Huynh, the former Amazon principal engineer behind A Life Engineered, puts one question to a guest who helps companies adopt AI and does his own work in mathematical computing and AI internals: does an engineer still need to understand the code a model writes? The guest's practical answer is a two-part one. Set aside his personal love of the craft and, he says, a junior could probably ignore data structures, algorithms and hardware for the next two or three years, because models keep improving and employers are hungry for AI-native hires. Past that window he is guessing, and his worry is evaluation: senior work means choosing systems whose effects, such as a rewrite in Go or Rust, cannot be cleanly measured, and that judgment rests on knowing at least one layer below where you work.
On reading generated code, he describes the split among his clients as mostly personality. Some heavy AI users still read every line of a 10,000-line change; others ship whatever passes the test suite. His own field pushes him to read, since a wrong sign or an integer where a float belongs will not show up in the outputs. Huynh raises Mitchell Hashimoto's whiteboard test, and the guest offers a parallel idea: the control surfaces an engineer holds, meaning a mental model detailed enough to say which three components cause the latency and where a styling change belongs.
The career advice follows from that model. Citing Kun Chen's remark that directors care only about outcomes, Huynh asks whether understanding will matter at all. The guest's test is whether a director, wanting better P95 latency, would rather route the task through you than hand it straight to an AI. Over a five-year horizon he thinks that stays true for engineers who know the architecture, as long as the expertise is shared and not hoarded for job security.
The guest on A Life Engineered, who advises companies on AI adoption, says a junior could probably ignore data structures, algorithms and hardware for the next two or three years and still get hired, because models are improving fast and employers want AI-native engineers. He stresses he is not endorsing that, and that anything past the short term is speculation.
Asked by Steve Huynh whether he is on team read the code, the guest says yes for his own work, which is mathematical computing and AI internals. There a wrong minus sign or an integer used where a float belongs is invisible in the outputs; even an LLM built from scratch cannot be verified just by looking at what it produces. Among clients, he finds the choice is driven more by personality and the kind of work than by engineering management.
As Steve Huynh describes it on A Life Engineered, Mitchell Hashimoto's whiteboard test says you should understand your system well enough to draw it on a whiteboard and explain what each component does and how the components interact. The guest calls the test very reasonable and possibly the better way to explain the idea to junior engineers.
The guest frames understanding as control: the mental model and the knobs, sliders and inputs an engineer has into a project. The bad case is asking an AI for an application, getting 100,000 lines, and knowing only that the URL returns the right result, with no idea of the subsystems, database schema or microservices. The good case is being able to say which three components cause the latency and which module a styling change belongs in.
Steve Huynh cites Kun Chen, an L8 engineer at Meta, Atlassian and Microsoft, saying directors do not know what the code looks like and care only about outcomes. The guest agrees a director could type 'make the P95 latency better' into an LLM, so his advice is to make sure the director would still rather route that task through you, because you know the architecture and can direct the AI to the right places.
Our own transcript of the public episode, with a timestamp about every 90 seconds. Tap a timestamp or the link button on a paragraph to copy a link that opens this page there.
0:00What do you think about the concept of understanding what the code is that the AI creates? If you're a junior, should you still be going into data structures and algorithms? Should you still understand what's going on under the hood, how the hardware works, what the design of the system is? I'll give you an answer in two parts. One is just my personal bias, which is that's partly why I got into this business in the first place. So for me, just speaking personally, that's something that I like and the people I work with usually like that as well for its own sake. So that's my bias. Let me not tell you what I think is practical for someone who's thinking about career growth. I think you could, at least in the very short term, like the next two or three years,
0:47you could just ignore all that stuff. And it would probably work because the models are getting so good and people are so motivated to hire people who are AI natives and who are adopting AI agentic workflows. I think in the short term, you could get away with it and so anything past the short term i'm speculating i worry that if you don't do that then eventually you are not going to know how to evaluate the answers that an ai gives you in say three years when you have to do something that is above the scope of a typical junior engineering task right so a typical junior engineering task is maybe a single feature or a single cluster of bugs on one part of the system. Everything's tightly focused and it's clear what success and failure mean. It's clear
1:31why we're doing it. If you resolve the bug or you ship the feature, then it's done and you don't have to think about it very much anymore. That's typical, I think, of junior engineering work. As you become more senior, the decisions you make and the systems you build, and especially the systems that you choose to integrate or adopt, those systems have long-term consequences that are harder to measure. Just picking something very concrete, it's difficult to, for example, to evaluate, we changed everything to Go or we changed everything to Rust. And now everything is 20% faster, whatever, right? How much of that was the fact that you chose Go? How much of that was the fact that you chose Go? How much of that was the fact that you rewrote it?
2:08How much of that is changing demand patterns in the usage? All of those things are very hard to evaluate in a strict quantitative way. And that's where intuition and fundamental understanding are, for me anyway, deeply tied, right? Whatever intuition you have about the behavior of your system, that's coming from you having an understanding that's at least one level below wherever you're working. Let's just say hypothetically you're working in Python. One level below that is at least understanding what's the Python interpreter doing? What are the native data structures of the Python interpreter? What's the memory consumption of a dict versus a list versus whatever, right? Those are all things that in the short term,
2:49I think you could just ignore right now. The thing that is less clear to me is if for most people that will bite you in three years and how that will bite you. Because the LLMs also, they're getting better at this kind of broad informal reasoning. So most of the talk lately these days is just about how much better it's getting at coding and closing linear tickets, right? Like very, very quantitative, specific objective things. We don't have good metrics for the broader reasoning powers yet. But just my own subjective opinion is that they're getting substantially better there as well. I know that's not very, very concrete in being able to tell you, hey, it's 7% better at informal engineering reasoning this year, and it'll be 12% better next year. But that's something that
3:33is changing. Maybe I can summarize that by saying, I think you could get away, I'm not endorsing this, but I think you could get away with not understanding data structures and algorithms for a couple of years at a minimum. And then it's a question of how quickly LLM progress catches up to the informal engineering wisdom that is not easily captured in metrics. Are you team read the code? Or are you team like Vibe, you just care about the outputs? For my own personal work, I am on team read the code for sure. For client work, my job working with clients is I'm not usually building the application. I'm helping them figure out how to adopt AI technology and AI patterns. I think that with clients, there's, I think the split, the read split versus the just watch the output split.
4:23You can sort of predict it just by knowing the team. It really seems very personality driven. I know people who are very heavy users of AI generated coding, but still they read everything. Maybe it generates 10,000 lines, but they still read everything. And it's a little bit slower, still much faster than writing it yourself. My experience has been, at least with clients, that it's much more of a personality choice than it is like an engineering management choice. For me personally, I'm on team read the code. But also I do pretty specialist stuff like mathematical computing and AI internals. And there it really, really matters. If you get like a minus sign wrong, or if you're multiplying by one as an integer versus
5:03like one point something as a float those are all things that are very subtle and you have to read the code to verify the correctness because you can't easily verify the correctness just from the outputs you might get for example let's say you built an llm from scratch right most people wouldn't do this but if you built an llm from scratch and got outputs you can't easily verify from the outputs that you implemented everything correctly. That's the kind of thing that I do for my own personal work. And so naturally, I'm driven more toward having to read it. But I have friends I respect who are very smart. They just generate artifacts and test them and see whether or not it passes the test suite. I think really the big
5:40difference there is partly personality and partly what kind of work you're doing. So, Michele Hashimoto states that he has a whiteboard test, basically. So, the idea is that you should understand how your system works such that you could actually whiteboard the system out and talk about what each one of the components do and what their interactions are with each other. What do you think about that? I think it's very reasonable. I have a parallel thing. His might be better, actually actually for communicating to junior engineers. But the way that I think about it is not the whiteboard, but what kind of control surface do you as the engineer have into the project, right? So if you tell me, for example, here's the bad end.
6:16The bad end is I asked it to make me an application. It generated, whatever, 100,000 lines of code. I have no idea what the subsystems are. I have no idea what the database schema is. I don't know if there are many different microservices involved. All I know is that when I go to this URL, I get the result that I want. Okay, that's the bad version. The good version is someone can say, okay, you don't like, for example, the latency. The latency is coming from these three components, and here are some of the ways that we can control that you don't like the fact that the styling is the same in both you know like the cat section of the dog section we need to come up with a way to have different styling for cats and dogs and maybe
6:55we need to do look at some kind of factoring and that factoring belongs over in this module over here right this is a very similar kind of thing where I think about it as the person responsible for the project. What knobs do you have? What's your mental model of the project? And what are the control surfaces, you know, sliders and knobs and inputs that you can put into your mental model of the project so that you can improve it, control it, adapt it to whatever the new needs are? And that sounds very similar. Maybe it's not exactly the same thing, but that sounds very similar to what you described from Ashwin. I haven't seen that myself, but it makes a lot of sense that you would want to address the same
7:33concerns that if I put it on the whiteboard, why am I putting it on the whiteboard? I'm putting it so that I can explain to somebody else why do they want to understand because they might want to change something, right? So in the end, I think the most important thing for me is having some kind of sufficiently detailed understanding of what's happening so that you can aim your changes in a reasonable way. If the only thing you can do is say, please, LLM, make it so that I can have separate styling for dogs and cats. Again, maybe you can get away with that for a few years, actually, but I think in the long run, having an understanding of where internal engineering decisions have been made, I think that will remain valuable,
8:08even if the way we do it is shifting. Well, I think it's interesting. It feels like there's a lot of compression going on in terms of like frontline and middle managers and the senior engineers or staff level engineers that are doing their work. In this new AI age, I see less and less of a distinction. Kun Chen, he's a L8 engineer at Meta and Atlassian and Microsoft. He says directors don't know what the code looks like. Directors can't really go in and whiteboard how the systems are going to go. They order the people underneath them to go and do their work, and they just care about outcomes. If I hear you correctly, you're basically saying like, hey, you can probably get away with it for a couple of years,
8:53but there is a universe where it sort of catches up to you. What I'm getting at is like, which do you see as the more likely outcome? That we will still need some understanding of what the LLMs and the AIs are doing within our systems, or far future, we don't need to have any sort of understanding about what's going on underneath the hood. I would separate that from the pure technology question from what I would advise younger people to be thinking about. So one of the reasons I have this framework of what is your understanding that you can use to exert control over the project, that is the value that you are bringing as someone separate from an LLM, right? Because hypothetically, the director kind of person that you mentioned,
9:35they could just go type into the LLM, hey, make the P95 latency better. I don't care how it happens, right? I don't even want to see a whiteboard diagram. Just go do it, right? So they could do that. I'm encouraging people to maintain the engineering expertise that lets them do that better than the director so that you still have a role even when the director says, hey, I want P95 latency to be better. Obviously, I'm not going to get involved. But then that person is going to be wondering, can I just hand that off to an ancient swarm or should I hand that off to Steve or whatever? Someone more junior than you, but Steve 10 years ago, right? The advice I've been giving people is whatever it is you do with AI, make sure that someone
10:15at the director level still prefers to route that through you rather than routing it directly to the AI. And maybe I'll make an aside, which is saying you could do this badly, right? Like we all know the one engineer who has the sneaky system for job security that no one else understands. You can do it badly, okay? So I'm recognizing you can do it badly and in a pathological way, just please don't do that. But you can do it in a virtuous way as well. And I think at least over the next five years, which is the timeframe that I'm keeping in mind for advising the junior people I'm mentoring, at least over that timeframe, I think we will still have directors who want to route tasks through junior people,
10:57even if that ends up in the nuts and bolts going to an AI. So I encourage people to develop their skills and their knowledge of the system, going back to the reading the code versus not reading the code, so that when the director talks to you, you can say, yes, actually, I have read the code and I understand the internal architecture and I can direct the LLM to work here and here and here. And the director wouldn't know to do that. And at least for now, you can keep an edge over the LLMs in this sense. But that brings back the earlier point I was making about AI is getting better and better at informal holistic engineering judgment. That's very hard to quantify. And I can't tell you that that's going to be 5% better or 20% better next year. But to the extent that you're thinking,
11:39how do I keep justifying myself in this human organization, right? The reason people find junior engineers valuable is that as a more senior person, you can say, look, this P95 thing, it's killing us in the market. Our competitor has a much better P95. We just really need to improve P95, right? That's the kind of decision that happens at a more senior engineering management level. And they want to delegate, right? They want to have humans they trust and say, hey, you person who is five years more junior than I am, I really want to improve P95. Give me the five things that you think we can do. And then I can evaluate the business trade-offs. They have to figure out what's the business impact, right? Because whatever, maybe one of
12:19the things you do has some impact on cloud services bill or something, right? And that's not a decision you can make purely technically. That's a decision that incorporates business decisions as well. So just wrapping up, I think whatever it is you do with AI, try to make sure that you remain useful to the people who would like to delegate to you. And don't leave them asking, why wouldn't I just delegate to the AI? What's the point of delegating to the junior person what I could delegate to the AI? Yeah, that totally makes sense. Like just getting back to like the control service, what are the knobs? What are the sliders? How can I actually change the system to have the types of outcomes that I want? You should always have a really good
13:02sense of that, right? And I think it's difficult to do if you don't really understand what's going on underneath the hood. Quick word from today's sponsor, Linear. Linear has been a sponsor for almost a year now. And in that time, a lot has changed in how teams build software. Coding agents like Clog Code blew up and they're being used to write more and more code. Writing code got fast, but reviewing it didn't. A lot of the speed that you get out of agents just gets swallowed back up in review. I spent 18 years as an engineer at Amazon, a lot of it reviewing other people's code, so I know the feeling. You get a huge pull request with changes in some random order, the context is scattered across other tools, and at some point you're either grinding through it or rubber stamping it.
13:46What people forget is that code review is how accountability spreads across the team. When you approve a PR, you're putting your name next to it. You own that change now too. That's the part that only a person can do, deciding whether the change fits the system and solves the problem the customer actually had. So a rubber stamp just puts your name on code that you didn't read. That's what this is for. It's a code review inside of Linear, right next to the issue that started the work. It opens up instantly and breaks a giant PR into readable chapters. The Y sits next to the code, so you can decide whether it solves the problem instead of hunting through tabs to remember what the problem was.
14:27Linear used to track the work. Now it reviews it too. Check out diffs at linear.com slash a-l-e.