Pod Insights Inspire AI: Transforming RVA Through Technology and Automation Ep 66 - From Prompts To Process: Building Trustworthy AI Workflows w/ Tianzhen Lin About this episode Send us Fan Mail When intelligence is everywhere but correctness is scarce, how do we lead without cutting corners? We sit down with Tianzhen (Tangent) Lin—veteran engineer and systems thinker—to unpack a practical, durable approach to building AI‑assisted products that hold up under pressure. No hype, no shortcuts: just the patterns that make teams faster and safer at the same time. We start by reframing large language models as “eager interns”: fast, helpful, and prone to saying yes. That ...
Transcript Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.
0:01 Jason McGuinthe? Welcome back to Inspire AI, the podcast where we help leaders, builders, and communities stay capable and intentional in an AI-accelerated world. Today's episode is a special one for me personally. I'm joined by Tangent Lin, someone I've had the privilege of learning from for years, and without question, one of the most technically rigorous thinkers I know. Tangent isn't just fluent in AI systems. He's disciplined about how thinking happens around him. While much of the conversation in AI today is dominated by prompts, tools, and surface-level productivity gains, Tangent has been quietly focused
0:44 Jason McGuinthe? on something deeper and far more important: judgment, accountability, and workflow design in a world where intelligence is cheap, but correctness is not. He has a rare ability to take deeply technical realities, how large language models actually behave, where they fail and why, and translate them into mental models that leaders can use, not to move faster blindly, but to reduce risk, increase reliability, and build systems that hold up over time. And on a personal note, Tangent has been a mentor to me, not just in the technical depth,
1:28 Jason McGuinthe? but in how to think about systems, trade-offs, and long-term consequences. He's someone who constantly pushes for clearer reasoning, stronger foundations, and better design, and who believes that real progress comes from challenging each other to think more rigorously. Many of the ways I approach AI today, especially around systems thinking, continuous learning, and building structures that help people grow rather than cut corners, have been shaped by years of conversations with him. In this episode, we're not talking about hype. We're not talking about shortcuts. We're talking about what it actually takes
2:12 Jason McGuinthe? to lead responsibly when AI becomes ambient.
2:16 Jason McGuinthe? When assistance is everywhere, but accountability still rests with humans. If you care about building systems you can trust, leading teams through uncertainty, and staying grounded as the pace of change accelerates, this conversation is for you. Tangen, welcome to Inspire AI.
2:38 Speaker 01 Well, thank you for having me.
2:40 Jason McGuinthe? Outstanding. Can you tell us a little bit about your background, what brings you here today?
2:45 Speaker 01 Yes, absolutely. My pleasure being here. So I've been a software engineer for a good number of years. I'm working different startup and also have a privilege to work in big tech, Capital One, Amazon, and Facebook. I have a passion of building software. And the most recently, I realized that instead of spending a lot of late night hours troubleshooting, learning about writing code, AI can accelerate that. The more that I use, the more flaws I see, some of the blind spot we have with AI. But also, I realized that a lot of opportunities that we can harvest, we use it correctly. It can actually accelerate us building what we love and what we want to bring to the humanity.
3:26 Jason McGuinthe? Yeah, that sounds great. Bringing our passion to humanity is something we all strive for with identifying with our purpose. I resonate with that. So I've heard you argue that prompting often fails and you compare it to building a sandcastle. What's the core misunderstanding that teams have about working with LLMs? That makes failure almost inevitable?
3:51 Speaker 01 Yeah, a lot of times that we have seen some of these magical output, maybe from a blog post or maybe from someone else that you can whistle a small sentence and the AI can come back with an example that or some code that works and looks at, my goodness, this would have taken me a day or even longer for that. Problem is that our work does not stop there because once you build a software, it's not a software that's going to keep running for the next 10, 20 years. We're going to keep making modification here, making changes there. So and therefore making changes on a prompt that you have written about a day or two ago or even a couple of hours ago becomes increasingly difficult. It is almost like.
4:37 Speaker 01 If AI come back to you is in a large document and that you have about fifteen, twenty paragraphs and you have to describe, I wanna make change in this very sentence and so on and so forth, things are gradually becoming going sideways in many ways. And then therefore, not only that you're not really guiding the AI in the way that you want, but also some other times that AI could start creating new requirement or hallucinating things using a function that doesn't exist or using a library that you think that is not, shouldn't be there or missing a security queue here and there. Yeah, so that's kind of where I usually see where the problem fails and we spend more time course correcting an AI than actually getting AI to do meaningful work.
5:21 Jason McGuinthe? True, yeah. With the proliferation of these AI tools, I expect many folks are gonna be running into these problems and if they haven't seen it yet, a great opportunity here to tune in to what you're saying. So tell us, I think you describe LLMs as an eager intern, right? And it's helpful, fast, but not accountable. How does adopting that mental model change how leaders should think about responsibility, trust and risk?
5:50 Speaker 01 Absolutely. There are a few things that you can equate AI to because and some of that is just how AI is being tuned out of the box. So in imagine an AI, it's like a very knowledgeable intern who has read everything from the best materials, best PhD paper and so on and so forth. But here are a couple of problems that you have to realize is that, first of all, when AI make mistake, it's not the AI's problem. You are still ultimately the one being held accountable for. If AI slip in a algorithm problem and it causes financial institution miscalculated billing or things like that, it's not the AI's problem because it's still you who being held accountable for.
6:34 Speaker 01 And two is getting to them even more of a core of a problem, which is AI tuned out of a box is more of just like an eager intern and try to please you by saying yes to everything that you ask for. And start filling the assumptions because they are afraid of telling you what they assume, what they don't know. And therefore you don't get the pushback needed. So imagine when you hire a very seasonal consultant or someone very knowledgeable. When I come in, they actually ask you more questions than what you actually ask them to do because they're really trying to understand the history of things and context of how the business is built, what you really tried to achieve and spell every single assumptions or even challenge your thinkings at a good or bad way.
7:17 Speaker 01 So that's a big difference between an intern mentality and some who's very senior and very seasonal.
7:25 Jason McGuinthe? Yeah. Yeah, it sounds like we're shifting from traditional prompt engineering to what might be considered context engineering.
7:34 Speaker 01 That's correct. So because a lot of things that context matters. Um, and context is a very interesting thing. You can treat it more like a finite resource, even though you can hear context windows such as hundred K, two hundred K, or and probably just recently dropped a model with one million context window and Google gem and I both about two million context window. But the truth of the fact is that if you remember Bill Gates many years back, that no one used over six hundred forty kilobytes. He has not quite foreseen that the more that you throw at a people, the more they want to get out of it. So the contest window is always a very finite resource that you have to kind of work with. And using this resource is like a Goldilocks problem. You give it too little and it's not making a lot of assumptions.
8:20 Speaker 01 But if you give it too much, you actually get into a problem called like the loss in the middle problem, which is the two thousand twenty-three paper. So if you have a very, very long prompt, talk about many things and out of the ten documents you paste it in the fifth one, it's talking about some key security principle that AI should not forget. Guess what? That's very likely get glimpsed over and forgotten towards the end.
8:43 Jason McGuinthe? Yep, I remember reading that paper a little over a year ago. It's an interesting one. I'd recommend it. So you repeatedly emphasize prefer durable artifacts over chat history. Why do specs, plans, and docs suddenly become more valuable to an AI-assisted world and not less?
9:05 Speaker 01 Yeah, so I think we've all been there many times when we use AI to build code. Let's go back a little bit of context. The longer you have a chat session open, the more of a context window being used. And over time, you kind of exhaust all the context window. Even today, AI can automatically compact the window, free up some space again. But then you're at the mercy of AI automatically cheerpick the key information that you really care about. And hopefully, compact that. So you're praying on a magic that may or may not happen.
9:37 Jason McGuinthe? Right.
9:38 Speaker 01 Therefore, coming back to the context as a finite resources. So the good practice is generally, once you've finished getting your goal done, exit that and start over again.
9:46 Jason McGuinthe? Refresh the chat window.
9:48 Speaker 01 Exactly. So you have a fresh set of context window. But here's a problem. It is like hiring a new intern every other hour. And every intern is going to have a whole new context you have to feed again. It does not remember what he's said before. Or something durable is more important. Just think about when you run an enterprise, unless you have someone work with you 30 years and remember everything you have said. But you're likely going to onboard new employees. And what do you have left for them? That they can read, they can get up to speed quickly. So these global assets become very important. Now surely you can say, here is my Slack chat history from the last couple of months and please read through them. But we probably don't persist that well. We can treat history as more like a ephemeral asset.
10:34 Speaker 01 A durable asset is like things that you have organized, you have distilled down so that you don't have to explain, re-explain it every single time. Which is more important for AI because now AI becomes such an easy resource that you can onboard on a very frequent basis. And therefore, having some of these assets such as your spec, your architectural decision. And a lot of things can be good that you can refer to AI so you don't have to re-explain. Instead of wasting your energy to re-explain things, now you're durable assets. If you manage it correctly, it turn the AI into a confused partner because of lack of context.
11:14 Speaker 01 Or maybe sometimes it's over fed with way too much raw material into a focus worker because they understand and read your blueprint. Again, the blueprint is a condensed version of everything and going back to the very same thing about a context window is how you effectively give it just enough in your context window so that the AI can actually perform great work.
11:35 Jason McGuinthe? That's fantastic.
11:37 Speaker 01 So I actually have a very good personal experience of things. So I have a code base with a very nice sense of documentation written and generated along with AI that I constantly refer AI to and a lot of magic moment usually happens. For example, I can see a bugs coming in, I paraphrase a bug and even have AI to rewrite a bug. And then a clock could read the jury ticket. And because already have context, how the software being written, all the trade off, all the convention we have with the software and they actually fix the bug, how it would have fixed that.
12:07 Jason McGuinthe? Wow.
12:07 Speaker 01 And we also have software written in the pre-AI phase that doesn't have this set of documentations. And I noticed the performance dramatically drop with that. Not only turn through more tokens, it generally start to hallucinate. It cannot, it's not capable of making good decision. Even I would ask it to give me a plan or ask me for ambiguity. But, but I noticed that the AI just constantly need a lot more nudging to get the work done correctly. So I've gone through this personal experience that really lead me to realize there's a good set of documentations and good set of durable artifacts. It's very important for your AI to stay focused and perform well.
12:47 Jason McGuinthe? So I'm picking up on the pattern here. It sounds like you're pretty strict about breaking work into small verifiable steps. So why does decomposition matter more with L L Ms than it did with the traditional software teams?
13:02 Speaker 01 Yeah, we start with the context windows to find that resource. The more complex that task, the more context this has to churn through. So breaking up a task would allow you to leverage this resource more effectively. Now, some would argue that maybe over time that the AI is smart enough to start breaking it down and run with it and clear a context window every single step, which I've done recently. And I should achieve some good results of that. Another dimension of this is less on just the context windows, it's more on risk management. Because as you have all these things laid out or these things broken down,
13:44 Speaker 01 without some supervision, you're actually enlarging the number of degrees of freedoms. So this degree of freedom, what does that really mean?
13:54 Jason McGuinthe? Right.
13:54 Speaker 01 Is that you're giving more room for someone to improvise.
13:58 Jason McGuinthe? Right.
13:59 Speaker 01 You're actually knowing it could be picking a library or using a CSS that you don't like or using a practice you don't like, maybe using a database you already wrote up. It's not something that you want to go for. These degree of freedom give AI a room to wander off.
14:15 Jason McGuinthe? Time.
14:16 Speaker 01 But by putting it down, it's not you don't trust that, but you also verify it in every instant, give you stepped or early verification to realize that are you really, is the train staying on track or is it going off the wrong direction? And it gives you a lot more room to course correct and start establishing patterns so that the AI can stay on the rail versus wandering off. Again, because of the context window issues, AI sometimes just like an intern that can get a squirrel moment and get distracted.
14:47 Jason McGuinthe? For sure. So we've talked about offline, the usefulness of specs these days. And they're hard to maintain, right? Specs are often seen as just pure process overhead. How does writing a spec, especially one an LLM will use, actually increase the speed in alignment instead of slowing teams down?
15:10 Speaker 01 A good spec, the amount of time you put writing a good spec, it's pretty much the amount of time you would have spent and speed your execution and spend time debug later. It's whether you pay your debt upfront or you pay your debt later. Good specification also allow you to clearly think of what you need ahead of time. I'm not talking about waterfall here, it's basically clear your understanding. Because a lot of time when I see that in a lot of software and product management is that when a spec is not clear and people get suboptimal results, who is that to blame? Is that the implementation problem?
15:54 Speaker 01 Because of intelligence of the engineering community? Or is it just something that have been given too vague for them? Or too much degree of freedom or not specific enough? So that they actually build a solution and not really addressing the most pressing needs of it. They may overindex on things that actually don't matter. So spec allow you to really giving that a clear brush of what you want to do and clearly laid it out and also clarify a lot of the assumption that you have been taken advantage of because you have all those concepts already in your brain that other people do not inherit.
16:30 Jason McGuinthe? Yeah, filling in a lot of gaps that I've had before today's conversation.
16:35 Speaker 01 Yeah.
16:35 Jason McGuinthe? This is awesome.
16:36 Speaker 01 I want to give another example, an interesting experience that I have recently with a spec. Good specification actually can come with many, many different benefit. So we were working late night on this brush piece of software and in the middle of building that we realized some new requirements come in.
17:01 Speaker 01 And some reality come in that completely flipped over our original assumption how it should be written. And I realized that this is great because I actually have a very long written spec. That is completely agnostic how we implement it, so how the system should behave. So go back to the L M and say, forget about what we have written. But let's look back spec and if I change. Instead of this volume of data, we now have 10 times the volume of datas. Spread all over in different resources. We initially envisioned this would be only a 10 second delay when boot starting the application. This now will be one, how you would have designed it differently.
17:45 Speaker 01 AI start looking into spec and say, well, you should move this data ingestion from this part of our process to another part of our process. And these are three options I think that you should evaluate. And then the very next three hours is when the magic happens. We idea different approaches. We really kind of. Make sure that AI can explain every single option and make sure it is going correctly and it actually just rewrite this spec. And rewrite the software. Because it also has architectural blueprint of a software. So no, instead of completely rewrite everything, actually know where to move the code and where it changed. And I ended up having a software that pretty much nearly buckless.
18:26 Speaker 01 During the transition, which would have taken days and days of engineering time, that magic happened within three hours. Kind of helped me understand is that sometimes having a spec, not only it is there as a documentation we refer to. But also make some part of a decision become a two way door that you can reverse some of the decision. And change it because situation has changed. So it's not a waterfall and somewhat actually make your process become more agile. Because you have a very nice source of truth you can patch or create from. Autoify them from that can be and still have an elegant result.
19:03 Jason McGuinthe? Yeah, no, I read a lot these days on success stories. About using this, that or the other AI tool and saving hours, days, weeks, months. Of developer time and some of it's overblown. I'll be honest, but when you say it, I a hundred percent believe it. You and I have talked also about verification. It's a line that you just don't cross. What's the most dangerous illusion teams fall into when AI-generated work looks correct but really isn't?
19:36 Speaker 01 Yes, because I think it comes down to how AI is being trained. AI is called a large language model. It's being trained on our language. It's being motivated by observing a pattern of how we use our language and mimic that. And therefore, sometimes it may have understanding of what the language is, but most of the time it doesn't. Very good at generating formatted text that looks legit at the first glimpse. But the devils are usually in the details. I've gone through that lesson many, many times when I glimpse over huge wall of text. And I think the first two lines look good, the last 10 lines look good. And let me give a stamp of approval. Next thing I realize the software doesn't work.
20:21 Speaker 01 And I cannot just say, well, because I use Claude Code, but because I'm the manager of the output of an AI.
20:29 Jason McGuinthe? You're accountable.
20:30 Speaker 01 Yeah. Ultimately, I'm the one accountable for that. And that puts more pressure on verifying and making sure that this resource that come and go, because we open up a whole new chat session every time that we pay no insurance for, we're still ultimately responsible for its own outcome.
20:50 Jason McGuinthe? Yeah. Okay. You're consistently framing documentation as a way to reduce future context load. So how does leaving these artifacts behind change what teams and future AI sessions are capable of, let's say, six months from now?
21:10 Speaker 01 Yeah, so we talk a little bit about specifically how you want things being built. Documentation is a reflection how it is being built. Basically, it's a sibling asset as your source code.
21:24 Speaker 01 Imagine the world, we only have spec, but without the documentation. And then therefore, what we force this AI to do is they read the spec and then they have to turn through a lot of lines of source code, which is some of its work and some of its well documented, some other work that could be human patched around. Then that means a lot more files that AI has to go through, which will eat up the context window. Again, context window is a finite resource. And then the more context windows being consumed, the more AI would get distracted and actually get derailed from the origin. Either some of the discipline you mentioned before, or some of the goal it has to attain to, or even some of the source code has glimpsed over before because of the loss in the middle of fact.
22:08 Speaker 01 So imagine documentation is like a hyper condensed version of Cliff Note of your source code. And correctly representing the state of the implementation without actually overblowing that with every single lines of detail, only highlighting what's important. And a good documentation, that's not mean you have to write on every line of source code per se. If you want to know about this is the portion of source code you can get to. And therefore, it can be at its own discretion to say, well, this is relevant to my work. Let me go and read what's necessary instead of being forced to read end to end. Because anytime when AI today churns through documentation, they will have to read all the file end to end. Because it does not know what to select and what not.
22:53 Speaker 01 And having a documentation can help AI to be selective and prioritize its own resource.
22:59 Jason McGuinthe? So when you say documentation, you mean functional documentation of how this system works or is supposed to work?
23:08 Speaker 01 Yeah, there are a lot of details you can go into documentations. The state of implementation, for example, for example, I have this 50 files of code. How they're being divided, what are the architectural patterns being going to it? Um, some of the trade off that we have, for example, a reason work has to do with. Uh, we have to make some trade off between performance and precision. So I have to constantly, without our documentations, would be difficult for AI. Because let's just say that we have a piece of data grid is going to display a lot of data. Usually when AI is being trained is that, well, the data grid only showed about first fifty records of data. But our decision is this data grid is actually holds about a million records. All in the memory.
23:53 Speaker 01 So therefore the processing that going to it. If we're not careful about the AI can actually write a code that loop through from one to the end in one shot. And actually practically will freeze the UI. And then we basically have to come back and help AI to understand that. Well, these are some of the trade off we have in order to handle this volume of data.
24:14 Jason McGuinthe? Right.
24:14 Speaker 01 And please follow this particular pattern. These are things that generally a lot harder for someone to just read this first corner and understand it. Because just from a prompt coming back and say, well, I would like you to do so and so forth with the data set that I have. But knowing that this is a one million records that should be handled very differently from some common scenario. So having that documentation would document some of these nuisance or unconventional approach. Or some other times are just pure decision of trade off to you trace some one off from the other. And documentation will provide that level of guidelines.
24:51 Jason McGuinthe? Yeah. Yeah, I, it sounds like there's a lot of consequences to not providing the right documentation.
24:57 Speaker 01 That's correct.
24:57 Jason McGuinthe? Yeah, if I think about it, like you. When an organization adopts the L L Ms, but not this kind of workflow. What would you say are some of the failure modes they're setting themselves up for?
25:09 Speaker 01 I would. I've been through that before and I feel like I'm building a sandcastle. It looks good, it looks great on a sunny day when it's first built and the moment when the tidal wave comes in. It's gone. So I don't believe in, unless that's our intention for one day show and AIs can accelerate you building that. But I think over time we're building a skyscraper, we need a solid foundation. And we need the discipline and discipline does not mean it's one magical prompt that can get to it's a lot of engineering rigor sometimes it's exciting sometimes can be boring but rigor will help you create a concrete foundation and guardrail that can gradually up level
25:53 Speaker 01 your enterprise one level at a time because AI has been very good at churning out a lot of code and sometimes I find that AI is eager to churn on more code than I actually wanted does not really mean you're accomplishing your goal you actually through this process if not careful you actually lose institutional knowledge why this decision being made why this frameworks being used what are the trade up we have with all these finite resources where we should be optimizing our decision towards and a lot of knowledge key for one AI to hand to another for a new generation of AI pick it back on top of the older generation meaning that you have knowledge upgrade of how you would have tackled a problem differently so then instead of leaving
26:38 Speaker 01 with very little institutional knowledge you're actually accumulating knowledge which is a key part for the future AI or your future virtual coworker in many different ways to have a knowledge you can build upon I look at this more like process over problem problem is only a snapshot of what you have done but the process is the one to endure over time and AI is it AI does not denigrate the traditional engineer excellence or a good process what I actually find out is that AI actually amplified the penalty of not having this discipline because traditionally it takes a long time from the moment having a thought to work it down and change and have the
27:22 Speaker 01 engineering team engineer software and then see the end result and by the time it's many many months from the time that I have the idea now this timer is completely compressed where I find that a good discipline will yield a good result and this is almost like eating a old karma of some of the homework we didn't do before and now and actually end up seeing that down the road
27:45 Jason McGuinthe? So stepping back what does this workflow say about the kind of leaders and teams we will need as intelligence becomes a commodity?
27:55 Speaker 01 I think in the end, it's not about just getting a result. It's more about how do we improve the reliability of a result that we can also over time scale this reliable results. And a lot of this is not about the prompt or it's not about just one or two assumption or one or two magical moment. It's about all these recurring rigors on making assumption explicit. And you beat over the spec and make sure the spec is correct. And also, even with the spec is being correct, you verify your outcome. All of these are key discipline that enabling the AI to stay within a guardrail, creating
28:37 Speaker 01 a pattern that the future AI or future thinking partner can continue to follow and build a level of your enterprise. So a lot of these part is to bringing AI in as a very knowledgeable resource, turning them from always saying yes to what you're asking for into a critical thinker. Because the moment you invite them as a critical thinker, you open up yourself, open up your assumption that you actually, not only they churn out the output that you need, they actually go back to your original idea and offer you insights and ideas. And even blinds where you have not considered about, because they have read through a lot
29:18 Speaker 01 of good materials, a lot of things that actually could have added to your idea, but they're not tuned to give you that input unless being asked for. Some of these good use will amplify the outcome. And I always look into that is AI is an accelerator or amplifier of what your discipline, how, what is your management style is. And if an organization management style is more leaning on go do it, instead of let's take a pause and think about it and verify what we have. And just start imagining the analogy of the intern. If you have a very vague idea and and churn it out to the intern, the intern come around and produce a result, not what you're looking for.
30:02 Speaker 01 I don't think that's an issue of the intelligence of the intern is actually the quality of the management problem. So I look at that is. The quality of outcome is a reflection of your management style and how you manage the resource and how you manage the clarity, not the model's intelligence. So in the end, you're still in the driver's seat. It's how you take this accelerator, making sure that it aimed in the right direction to take your enterprise off to the space.
30:30 Jason McGuinthe? There it is. That's amazing. Well, thank you, Tanzen. I learned so much from you today.
30:37 Speaker 01 Thank you, Jason. You provide very insightful questions. I learned a lot. You're like a super intelligent AI to probe into things I've learned and force me to even think about how I should explain this. And a lot of that started verifying my own assumptions, too.
30:53 Jason McGuinthe? Yeah, we work well together. My imponderables turn into real actions between us. I think that's great.
31:01 Speaker 01 Thank you.
31:02 Jason McGuinthe? All right, folks. As I like to say, until next time, stay curious, keep innovating, and lead with judgment as intelligence becomes ever more abundant. Cheers.
31:16 Speaker 01 Cheers.
31:22 Jason McGuinthe? This episode of Inspire AI Podcast is sponsored by Exponent 21. I keep hearing the same thing from business leaders lately. We're doing the work, but leads are harder to explain. Traffic is down, attribution feels fuzzy, and the old answers don't really fit anymore. What's changed is how people search. Instead of clicking links, people are asking questions, and AI is answering them. Tools like ChatGPT, Google's AI-powered results, and Perplexity are shaping which brands get mentioned, referenced, and remembered.
32:05 Jason McGuinthe? Exponent 21 specializes in AI SEO. They help businesses understand how to show up consistently inside those AI-generated answers across questions about their industry, their services, and their brand. What stands out to me is that when people ask AI tools, who's leading in this space? Exponent 21 and its leaders are often referenced near the top. That comes from doing the work and shaping how this new search environment actually functions. To understand what this shift means for your business, visit exponent21.com.
Previous Ep 65 - LLM-as-a-Judge: Evaluations That Scale Next Ep 67 - RAG Done Right: Measure The Evidence Or Drift Into Error Page updated September 30, 2026 · transcript and summary are machine-generated
