Lisp: The Strange Little Language That Helped Invent AI

In this episode of The Agile Software Engineering Deep Dive, Alessandro Guida takes a historical and slightly playful look at Lisp - one of the strange little languages that helped shape the early world of artificial intelligence.

Long before AI became associated with Python, neural networks, GPUs, and large language models, artificial intelligence was also about symbolic reasoning, rules, lists, logic, search, and knowledge representation. Lisp was built for that world. Its focus on symbolic expressions, recursion, lists, and the close relationship between code and data made it a natural fit for early AI research.

This episode is not a call to abandon modern AI tools and return to 1960s programming. It is an invitation to understand where some of the deeper ideas in AI and software engineering came from - and why an old language full of parentheses can still feel strangely modern.

Transcript

SPEAKER_01 0:30

Welcome to the Agile Software Engineering Deep Dive, the podcast where we unpack the ideas shaping modern software engineering. My name is Alessandro Guida, and I've spent most of my career building and leading software engineering teams across several industries. And today I want to take a small historical detour. Not to talk about the newest AI model. Not to talk about GPS, prompt engineering, vector databases, agents, or yet another framework that promises to change everything by next Thursday. Today I want to go back to one of the strange little languages that helped shape the early imagination of artificial intelligence. Lisp. A language famous for Lisp, recursion, symbolic reasoning, code that looks like data, data that looks like code, and an irresponsible number of parentheses. For many modern engineers, Lisp may look like a historical artifact, something from another age of computing. But behind the unusual syntax is a surprisingly modern story about abstraction, representation, and the ambition to make machines reason about the world. Before AI became mostly associated with neural networks and large-scale statistical learning, it was also about symbols, rules, logic, search, and knowledge structures. And Lisp was one of the languages built for that world. In this episode, we look at Lisp as a piece of engineering history, as a curiosity, and as a reminder that many ideas we think of as modern have much deeper roots than we sometimes remember. There will be parentheses. There may even be a small Lisp puzzle. Let's dive in.

SPEAKER_00 2:18

So if you picture the modern artificial intelligence industry right now, uh you're probably imagining like massive data centers, right?

SPEAKER_02 2:26

Yeah, acres of servers.

SPEAKER_00 2:28

Exactly. Specialized GPUs, mountains of Python code, all trying to solve this one glaring problem, which is that modern AI hallucinates.

SPEAKER_02 2:37

Right. It's a huge issue.

SPEAKER_00 2:39

I mean, we have these incredibly fluent systems, but when they hit a wall, they sometimes just, well, they make things up.

SPEAKER_02 2:44

And with absolute confidence too?

SPEAKER_00 2:46

Yes. Total confidence. And the entire industry is scrambling for a structural fix for this, pouring in hundreds of billions of dollars. But uh what if the actual solution to this massive crisis was, you know, already solved?

SPEAKER_02 3:00

Wait, you mean like historically?

SPEAKER_00 3:02

Yeah. Not by some new piece of hardware, but back in like 1958.

SPEAKER_02 3:06

Wow. 1958.

SPEAKER_00 3:08

Yeah, by this exotic, deeply misunderstood programming language that honestly it looks like someone just dropped a bag of brackets onto a keyboard.

SPEAKER_02 3:15

Aaron Powell I mean, that sounds like a massive stretch, to be honest. Yeah. The tech industry basically treats computing history as like a graveyard of obsolete ideas. Right. We always assume whatever we're using right now is the ultimate peak of evolution. And, you know, everything from the 1950s is basically the Stone Age.

SPEAKER_00 3:33

Aaron Powell And that is exactly the assumption we are challenging today. So we're exploring why Lisp, which is a language notorious for its completely bizarre syntax, why it actually holds the structural secrets to the future of artificial intelligence.

SPEAKER_02 3:49

It's a fascinating premise.

SPEAKER_00 3:50

It really is. And our source material for this deep dive is issue number 37 of the Agile Software Engineering Newsletter. It's an article titled Lisp, The Strange Little Language That Helped Invent AI.

SPEAKER_02 4:02

Great article, by the way.

SPEAKER_00 4:03

Oh, it's fantastic. So our mission today is to unpack the historical context of Lisp, decode its strange philosophy, and you know, discover why the deepest, most urgent questions in modern AI are pointing us right back to its core ideas. I love it. So, okay, let's unpack this. Look, nobody is hiring massive teams of Lisp developers right now, right?

SPEAKER_02 4:23

No, definitely not.

SPEAKER_00 4:24

The billions of dollars are flowing into generative AI and massive neural networks. So prove it to me. Prove to me that a 70-year-old language with annoying syntax is actually relevant to you and me today.

SPEAKER_02 4:36

Well, if we connect this to the bigger picture, we really have to recognize that artificial intelligence has fundamentally split intellectual traditions.

SPEAKER_00 4:45

Okay. What do you mean by that?

SPEAKER_02 4:46

So the face of AI today is driven by massive data scale. Right. But the original ambition of artificial intelligence, like back in the 1950s and 60s, it wasn't about scraping the internet for data.

SPEAKER_00 4:58

Because the internet didn't even exist.

SPEAKER_02 5:00

Exactly. It was about pure symbolic reasoning. They wanted to build a machine that didn't just, you know, guess the next word in a sentence, but one that could explicitly map out concepts, rules, and relationships.

SPEAKER_00 5:11

Aaron Powell Yeah. The Agile software engineering newsletter makes a really sharp distinction here. Uh early AI researchers were trying to represent knowledge explicitly using symbols. So like a symbol could represent a physical object or a mathematical relationship or a fact or a logical rule.

SPEAKER_02 5:27

Aaron Powell Yeah. They wanted machines to actually reason about the reality of those symbols, to like prove theorems and logically deduce solutions step by step.

SPEAKER_00 5:36

Which is so different from what we do now.

SPEAKER_02 5:38

It really is. Think about the mechanics of that. If you want a computer to prove, say, a geometry theorem, you can't just feed it 10 million pictures of triangles and hope it intuits the concept of angles.

SPEAKER_00 5:51

Right, which is basically the modern approach.

SPEAKER_02 5:53

Exactly. Instead, you have to give it the hard rules of geometry and a mechanism to logically chain those rules together to reach a verifiable conclusion.

SPEAKER_00 6:02

I was actually trying to visualize this difference for anyone who isn't, you know, spending their weekends reading dense machine learning papers.

SPEAKER_02 6:09

That's probably most of us.

SPEAKER_00 6:10

Right. So if modern AI is like a student trying to learn a new language by reading 10 million books until they can intuitively guess the patterns of how words fit together, early symbolic AI was like handing that same student a dictionary and a strict book of grammar rules. I like that. The goal was to have them logically construct a structurally perfect sentence from scratch, understanding exactly why every single word was chosen.

SPEAKER_02 6:36

That gets you halfway there, but the symbolic approach is actually even more rigid than that.

SPEAKER_00 6:40

Oh, really?

SPEAKER_02 6:40

Yeah, it isn't just about constructing the sentence, it's about knowing the absolute truth value of the sentence. The symbolic approach tries to understand the fundamental, undeniable architecture of reality.

SPEAKER_01 6:53

Wow.

SPEAKER_02 6:53

It wants to know the rules. But uh here is the historical bottleneck. To build a system that relies entirely on pure logical reasoning and branching rules, those early researchers hit a massive wall.

SPEAKER_00 7:06

Because of the hardware.

SPEAKER_02 7:07

Partly hardware, but mostly the software. Standard programming languages of the 1950s were built for crunching numbers, you know, calculating missile trajectories or balancing accounting legs.

SPEAKER_00 7:17

Oh, right. Pure math.

SPEAKER_02 7:18

Yeah. They were virtually useless for mapping out abstract thoughts.

SPEAKER_00 7:21

Right. So they needed a completely different medium. And Enter Lisp, created by John McCarthy at MIT in the late 1950s.

SPEAKER_02 7:28

A true pioneer.

SPEAKER_00 7:29

And the name literally stands for list processing. And, you know, reading this agile software engineering newsletter, what really stands out is how features we consider totally standard today were basically science fiction when McCarthy introduced them.

SPEAKER_02 7:45

Oh, it was a monumental leap in abstraction. I mean, in an era when most programming was incredibly close to the machine, literally tracking which physical memory slots were holding your specific numbers. Lisp introduced automatic memory management. Trevor Burrus, Jr.

SPEAKER_00 7:59

Which we call garbage collection today.

SPEAKER_02 8:01

Exactly, garbage collection.

SPEAKER_00 8:03

Let's actually pause on garbage collection for a second, because we throw that term around a lot in modern coding.

SPEAKER_02 8:07

We do.

SPEAKER_00 8:08

But why was that specific feature such a game changer for early AI? Like why did McCarthy actually have to invent it?

SPEAKER_02 8:15

Well, before garbage collection, programmers spent a massive portion of their mental energy manually telling the computer, hey, put this piece of data in memory slot A.

SPEAKER_00 8:25

Right.

SPEAKER_02 8:25

And when I'm done with it, explicitly clear slot A so I can use it again.

SPEAKER_00 8:29

That sounds exhausting.

SPEAKER_02 8:31

It was. Now imagine you were trying to write an AI program that searches through thousands of branching logical possibilities. Like uh a chess engine exploring possible future moves.

SPEAKER_00 8:43

Aaron Powell So the computer is constantly creating temporary like what-if scenarios.

SPEAKER_02 8:48

Right, and constantly discarding them when they turn out to be bad moves.

SPEAKER_00 8:51

Oh, I see where this is going.

SPEAKER_02 8:53

Yeah. If the programmer has to manually allocate and delete the memory for every single hypothetical thought the AI generates, the code becomes impossibly complex.

SPEAKER_00 9:02

Aaron Powell You'd spend 90% of your time doing memory janitor work and 10% actually writing AI logic.

SPEAKER_02 9:08

Exactly. McCarthy's garbage collector was a background process that automatically detected when a piece of data was no longer being used and just swept it up.

SPEAKER_00 9:16

That's brilliant.

SPEAKER_02 9:17

It freed the human mind to focus entirely on the high-level logic.

SPEAKER_00 9:20

It essentially outsourced the chore so the researchers could do the real math.

SPEAKER_02 9:24

Precisely.

SPEAKER_00 9:25

The newsletter also highlights that Lisp popularized recursive thinking and programming, which uh for the uninitiated is when a function calls itself. It's like standing between two mirrors and seeing an infinite tunnel of reflections. But again, how does a function calling itself help build artificial intelligence?

SPEAKER_02 9:43

Well, recursion is the absolute perfect mechanism for exploring those branching decision trees we just mentioned.

SPEAKER_00 9:49

Okay.

SPEAKER_02 9:49

If an AI is trying to solve a maze, a recursive function says take a step forward and then run this exact same maze solving function from the new location.

SPEAKER_00 9:59

Oh wow.

SPEAKER_02 10:00

Yeah, it keeps calling itself diving deeper and deeper into the maze until it hits a dead end. Then it unwinds, backs up, and tries another path.

SPEAKER_00 10:08

That is so elegant.

SPEAKER_02 10:09

It really is. Recursion allows you to write incredibly elegant short code that can navigate infinitely complex logical structures.

SPEAKER_00 10:17

Okay, so that makes sense for the mechanics, but we really need to talk about the core structure of Lisp, the lists.

SPEAKER_02 10:23

Oh yes, the lists.

SPEAKER_00 10:30

The newsletter points out that Lisp was built entirely around lists. And you know, if you write Python or Jama today, you use lists and arrays all the time as handy data containers. So why were lists the absolute center of the universe in list rather than just like another tool in the toolbox?

SPEAKER_02 10:47

So that is the core philosophical shift of Lisp. In Python, a list is just a bucket holding data.

SPEAKER_00 10:53

Right.

SPEAKER_02 10:53

The code that manipulates the bucket is totally separate from the bucket itself. The engine is separate from the cargo.

SPEAKER_00 10:59

Okay, that makes sense.

SPEAKER_02 11:00

But in Lisp, a list is the universal structure for literally everything.

SPEAKER_00 11:05

Everything.

SPEAKER_02 11:05

Everything. A list can represent a simple set of numbers. It can represent a mathematical expression. It can represent a logical rule. Or most importantly, it can represent the program itself.

SPEAKER_00 11:16

I hear what you're saying conceptually, but uh looking at actual Lisp code, I mean, it feels like it's intentionally designed to be hostile to the human eye.

SPEAKER_02 11:24

It definitely takes some getting used to.

SPEAKER_00 11:26

The newsletter has this whole section dedicated to beginner coding examples. There's like a recursive factorial function, some math operations, and this notoriously tricky puzzle at the end.

SPEAKER_02 11:38

Yeah, that puzzle is a fun one.

SPEAKER_00 11:39

Now, I am definitely not gonna read these coding examples out loud right now because reading raw syntax on an audio deep dive is just a fast track to giving everyone a headache.

SPEAKER_02 11:49

Oh, please don't. It would be impossible to follow.

SPEAKER_00 11:52

Exactly. But you listening should absolutely go look at the written article in the Agile Software Engineering newsletter to see these examples and try to solve the puzzle yourself. Visually, it is quite an experience.

SPEAKER_02 12:06

To say the least.

SPEAKER_00 12:07

Yeah. The author actually jokes about Lisp's reputation for having a heroic number of parentheses. Like to a modern developer, it literally looks like someone dropped a bag of brackets onto the keyboard.

SPEAKER_02 12:18

It really does look completely backwards to modernize. I mean, if you want to add two and three in almost any other language, you just write two plus sign three.

SPEAKER_00 12:26

Right, simple.

SPEAKER_02 12:27

The operator, the plus sign is in the middle.

SPEAKER_00 12:29

Right.

SPEAKER_02 12:29

But in Lisp, you write an open parenthesis, a plus sign, the number two, the number three, and a closed parenthesis.

SPEAKER_00 12:36

So the operator comes first.

SPEAKER_02 12:37

Exactly. The operator comes first, and everything is wrapped in a list.

SPEAKER_00 12:40

But why do that? Like why design a language to look like an alien mathematical ritual rather than readable human-like text?

SPEAKER_02 12:48

Aaron Powell Because it's not trying to look like human English. It is intentionally exposing the naked underlying structure of the logic.

SPEAKER_00 12:56

Okay. Unpack that a bit.

SPEAKER_02 12:58

Think of it this way: when you write code in Python, the computer has to translate your readable human-like text into a tree-like data structure called an abstract syntax tree before it can actually run it.

SPEAKER_00 13:09

Okay.

SPEAKER_02 13:10

It translates your text into pure logical branches.

SPEAKER_00 13:12

So the computer is secretly converting everything into trees behind the scenes anyway.

SPEAKER_02 13:16

Always. But Lisp doesn't hide the tree. Lisp code is the tree.

SPEAKER_00 13:20

Oh wow.

SPEAKER_02 13:21

Yeah, those endless parentheses are just defining the branches. The first element of the list tells the computer the action, like the plus sign, and the rest of the list are the branches it operates on.

SPEAKER_00 13:30

That makes so much sense now.

SPEAKER_02 13:32

It is an unusually regular syntax. There are no special formatting rules, no complex keywords to memorize. Everything has the exact same shape.

SPEAKER_00 13:41

And that absolute consistency sets up the massive payoff.

SPEAKER_02 13:44

It does.

SPEAKER_00 13:44

Because here's where it gets really interesting. This strange bracket-heavy syntax directly enables Lisp's most revolutionary concept. And it's the one that completely shaped the early AI imagination. It all comes down to a single tiny character. The quote mark.

SPEAKER_02 14:03

Yes. The quote mark is where Lisp crosses from being just a programming language into being a medium for self-modifying thought.

SPEAKER_00 14:11

That sounds intense. So the newsletter explains that if you put a quote mark in front of a list in Lisp, the language instantly stops trying to run it as executable code. Right. It suddenly treats that entire list of instructions strictly as passive data. I was trying to come up with a real-world equivalent for this.

SPEAKER_02 14:27

Okay, let's hear it.

SPEAKER_00 14:28

Imagine you have a massive automated factory. The machines are buzzing following a highly complex set of physical blueprints to build cars. Got it. Adding that quote mark in Lisp is like the factory assembly line suddenly reaching out, picking up the very blueprints that are running the factory, folding them up and putting them on the conveyor belt.

SPEAKER_02 14:45

That's a great image.

SPEAKER_00 14:46

Right. The instructions have temporarily become the product.

SPEAKER_02 14:50

And that gets to the heart of it, but the reality of Lisp is even weirder and more powerful than that.

SPEAKER_00 14:56

How so?

SPEAKER_02 14:57

Well, once those blueprints are on the conveyor belt, acting as data, the factory can modify them.

SPEAKER_00 15:02

Wait, really?

SPEAKER_02 15:03

Yes. It can chop the blueprints up, swap out a section, bolt on a new instruction, remove the quote mark, and then plug the modified blueprints back into the master control machine.

SPEAKER_00 15:12

So the factory just redesigned its own operating instructions on the fly.

SPEAKER_02 15:16

Exactly, based on the current conditions on the floor.

SPEAKER_00 15:19

That is wild. That's called metaprogramming, right? The ability to treat code and data as the exact same thing. Yes. And if I am an AI researcher in 1960 trying to build a machine that can actually learn and adapt, I mean this is a superpower.

SPEAKER_02 15:33

Aaron Ross Powell Well, what's fascinating here is that it was the absolute holy grail of early AI, because the code and the data are represented in the exact same format as nested lists. Programs can inspect, generate, and transform other programs.

SPEAKER_00 15:46

Using the exact same tools they use to manipulate normal data.

SPEAKER_02 15:49

Exactly. The boundary between representing a piece of knowledge and executing an instruction basically vanishes.

SPEAKER_00 15:56

So if a LIST program encounters a logical problem it doesn't know how to solve, it can what? Write a sub-program, test it, and if it works, absorb that new code into its own logic tree.

SPEAKER_02 16:08

Precisely why it was the darling of early AI labs. It allowed researchers to build expert systems, theorem provers, and planning systems that could dynamically manipulate symbolic structures directly. That is incredibly they were building programs that could reason about their own code.

SPEAKER_00 16:24

Which is brilliant and historically fascinating. But I feel like we have to address the modern reality here.

SPEAKER_02 16:30

Okay, let's do it.

SPEAKER_00 16:36

So what does this all mean? If the industry has clearly moved away from pure symbolic logic, I mean nobody's building the latest massive language model in Lisp. Are we just indulging in computing archaeology?

SPEAKER_02 16:48

I wouldn't say that at all.

SPEAKER_00 16:49

But we live in a world of generative AI, massive neural layers, multi-billion parameter models. Why does Lisp matter for tomorrow?

SPEAKER_02 16:58

This raises an important question, and it's because modern engineers are running headfirst into the limits of massive data scale.

SPEAKER_00 17:04

Right, the hallucinations we talked about.

SPEAKER_02 17:06

Exactly. Modern AI has astonishing capabilities. It generates incredibly fluent, convincing text and images. But generative systems operate on probabilities. Okay. They are incredibly sophisticated next token predictors. They don't inherently know the underlying rules of logic or reality. They're just mimicking the shape of logic they observed in their vast training data.

SPEAKER_00 17:30

Aaron Powell Which goes back to our earlier analogy. The student who read 10 million books can guess what word comes next with eerie accuracy, but they don't actually know the structural rules of the grammar.

SPEAKER_02 17:40

Yes.

SPEAKER_00 17:41

And when they guess wrong, they guess wrong with total, absolute confidence.

SPEAKER_02 17:45

Aaron Powell And as these AI systems are deployed in higher states environments like medical diagnoses, legal analysis, or autonomous driving, that probabilistic guessing becomes a massive liability.

SPEAKER_00 17:55

Aaron Powell A dangerous liability.

SPEAKER_02 17:56

Very much so. When a generative model hallucinates or makes a critical error, the engineers face the black box problem.

SPEAKER_00 18:03

The black box problem.

SPEAKER_02 18:04

Yeah. It is incredibly difficult to figure out why the model made that specific mistake. Because there is no clear, explicit logic tree to audit. The reasoning is smeared across billions of mathematical weights.

SPEAKER_00 18:19

So you can't just open the hood and point to the broken rule.

SPEAKER_02 18:23

You can't. So the engineering world is starting to ask the old symbolic questions again.

SPEAKER_00 18:27

Oh, coming full circle.

SPEAKER_02 18:29

Exactly. They're asking how do we build systems that are understandable? How do we verify that a piece of reasoning is structurally sound and not just statistically plausible? That's a huge distinction. It is. How can we represent definitive knowledge explicitly so we know the system isn't hallucinating facts?

SPEAKER_00 18:47

Wow. So they basically need the dictionary and the grammar rules back.

SPEAKER_02 18:50

They really do.

SPEAKER_00 18:51

They are realizing you cannot solve the hallucination problem purely by throwing more data and more compute at the wall.

SPEAKER_02 18:57

No. Eventually you have to tackle abstraction. You need reliable structure and interpretable meaning.

SPEAKER_00 19:02

Which brings us right back to the domain of Lisp. It reminds us that artificial intelligence is not just about scale and probabilities, it must also involve representation and rigorous reasoning. Right. I really love how the newsletter frames this. It says, Lisp pioneered the idea of treating ideas as computational objects.

SPEAKER_02 19:22

This is a beautiful way to put it.

SPEAKER_00 19:23

It really makes you rethink what code even is. It's not just instructions for a machine, it's a way to map out thought.

SPEAKER_02 19:31

Now the tools will undoubtedly look different. The industry isn't going to scrap trillion-dollar infrastructures and go back to writing pure 1960 symbolic Lisp code.

SPEAKER_00 19:40

Right. Obviously not.

SPEAKER_02 19:42

But the philosophy Lisp embedded into computer science, the necessity of interpretable, verifiable, and modifiable logic structures is exactly the philosophy we need to crack the next era of AI development.

SPEAKER_00 19:54

To make that concrete, how would that actually work? Like how do you combine a modern massive neural network with the old school symbolic logic of Lisp?

SPEAKER_02 20:02

Well, you build a neurosymbolic hybrid.

SPEAKER_00 20:04

A neurosymbolic hybrid. Okay, paint me a picture.

SPEAKER_02 20:06

Think of it like a professional writing team. The generative AI model is the incredibly prolific, fast typing author.

SPEAKER_01 20:13

Okay.

SPEAKER_02 20:13

It can brainstorm a hundred ideas a minute, write gorgeous prose, and make intuitive leaps, but it occasionally makes up historical dates or gets the math wrong.

SPEAKER_00 20:22

As authors sometimes do.

SPEAKER_02 20:24

Exactly. Now, the symbolic AI operating on Lisp-like principles is the ruthless fact-checker and editor sitting right next to the author.

SPEAKER_00 20:33

The editor has the rigid rule book.

SPEAKER_02 20:35

The editor has the hard-coded laws of physics, the mathematical axioms, and the explicit logic trees.

SPEAKER_00 20:41

I see.

SPEAKER_02 20:42

So the generative author proposes an answer, and before the system outputs it, the symbolic editor runs it through the rigid logic tree.

SPEAKER_00 20:49

So if the author hallucinates a legal precedent.

SPEAKER_02 20:51

The symbolic engine flags it, explicitly shows the broken logical branch, and forces the author to rewrite it.

SPEAKER_00 20:57

That is a phenomenal way to visualize it. You get the creative, intuitive leaps of the modern massive models, but they are structurally bound and audited by the rigorous symbolic logic that Lisp pioneered 70 years ago.

SPEAKER_02 21:10

Exactly. It's not about replacing one with the other. It's about recognizing that true intelligence requires both intuition and logic.

SPEAKER_00 21:18

The ghost of Lisp, with all its perfect, nested parentheses, might actually be the only way to build an auditing system capable of making the AI of the future truly trustworthy.

SPEAKER_02 21:30

It really might be.

SPEAKER_00 21:31

That is an incredible thought to end on. A hybrid architecture of massive scale and pure self-rewriting logic. Listen, if this discussion sparked your curiosity at all, I highly recommend you subscribe to the Agile Software Engineering newsletter.

SPEAKER_02 21:46

It's an absolute must read.

SPEAKER_00 21:48

It really is. You need to read issue 37 in its entirety. You can see the actual Lisp examples we joked about. Try to wrap your head around the syntax puzzle and really let these concepts sink in.

SPEAKER_02 21:57

And while you are doing that, make sure you're subscribed to this deep dive as well.

SPEAKER_00 22:01

Yes, definitely.

SPEAKER_02 22:01

But most importantly, share both the Agile Software Engineering newsletter and this deep dive with the engineers, tech leaders, and curious minds in your network.

SPEAKER_00 22:10

Honestly, sharing is absolutely the best way to spread the knowledge of Agile Software Engineering and keep these vital conversations going.

SPEAKER_01 22:17

Completely agree.

SPEAKER_00 22:18

Send it to that one coworker who is constantly hyping up the latest massive language model. It will give them a totally different perspective on where the structural limits are and how computing history might just hold the key to our biggest modern problems. Keep questioning the tools you use, keep looking at the history behind the hype, and we will catch you on the next deep dive.

SPEAKER_01 23:00

A colleague, your team, or your network. You can access all episodes by subscribing to the podcast and find their written counterparts in the Agile Software Engineering newsletter on LinkedIn. And if you have thoughts, ideas, or stories from your own engineering journey, I'd love to hear from you. Your input helps shape what we explore next. Thanks again for tuning in, and see you in the next episode.