Speaker 1: Also media.
Speaker 2: Hello and welcome to Better Offline. I'm your host ed
Speaker 2: zitron as eva by our merchandise.
Speaker 3: Subscribe to the newsletter.
Speaker 4: It's all in the episode notes.
Speaker 2: And today I'm joined by programmer Colton Bogie, who wrote
Speaker 2: an excellent piece about a month ago called no AI
Speaker 2: is not making engineers ten X is powerful.
Speaker 3: Colp. Thanks for joining me.
Speaker 1: Thank you for having me.
Speaker 2: So tell me a little bit about your day to
Speaker 2: day work. What do you do for a living.
Speaker 1: Yeah, so I'm a software engineer, and I work specifically
Speaker 1: in what's called web application development. So that's kind of
Speaker 1: like building rich applications that work in the web browser.
Speaker 1: So think of something like Amazon or Google Drive or
Speaker 1: something where you know you can do a lot of
Speaker 1: interactive features within the applihation within a browser, right, So.
Speaker 2: Kind of like the fundament of most cloud software.
Speaker 1: Yeah. I would say that the if not the majority
Speaker 1: of engineers work in web application development, then probably the
Speaker 1: plurality do right now.
Speaker 2: And it's also a large amount of how people interact
Speaker 2: with software is now in this way.
Speaker 1: Though, Yeah, exactly. Yeah, and that's why that's why most
Speaker 1: developers perhaps work in this field now.
Speaker 2: And you'd think something like that would be perfect for
Speaker 2: AI coding.
Speaker 3: It is.
Speaker 1: It is definitely the most applicable place for AI coding
Speaker 1: of all of them. There's sort of a there's sort
Speaker 1: of a thing where people are like, you know, oh,
Speaker 1: you know, lms don't really work really well for my language,
Speaker 1: and they'll be talking about something like RUST, which is
Speaker 1: more of like a a high performance language rather than
Speaker 1: a web language.
Speaker 3: What is a hypophobic language in this case.
Speaker 1: Just something that's designed to work on like weak hardware
Speaker 1: or a like extremely high speed So like for example,
Speaker 1: like video games aren't built in RUSS. They're usually built
Speaker 1: in a language called C plus plus, but they're they're
Speaker 1: built in a high performance language because you know, you're
Speaker 1: trying to max out as much as you can do.
Speaker 2: Ye're taking advantage of the high performance compute you have.
Speaker 1: Yeah, whereas with a website like you know, like Amazon
Speaker 1: or something like that, you're really not pushing the limit
Speaker 1: in terms of interactivity, and so more modest languages are fine.
Speaker 3: Got it?
Speaker 2: So you laid it out really nicely in the piece,
Speaker 2: so you can have to repeat a few things, I imagine,
Speaker 2: but run me through why AI coding tools can't actually
Speaker 2: make you a ten x engineer or ten times better engineer.
Speaker 1: Yeah, so basically AI is really good at AI is
Speaker 1: almost shockingly good at generating code, and it's almost shockingly
Speaker 1: good at generating code that runs, and it can answer
Speaker 1: a lot of questions that are that are like difficult
Speaker 1: or at least, you know, annoying is probably the better word.
Speaker 1: It's really good at dealing with things that are annoying.
Speaker 1: It's really good at, you know, so encoding. We have
Speaker 1: this concept called boilerplate, and it's it's just code that
Speaker 1: you have to kind of rewrite a lot. And as
Speaker 1: an engineer, ideally you don't have to write a lot
Speaker 1: of boilerplate. Ideal you automate things and distract things, so
Speaker 1: you you don't need to do that very often. But
Speaker 1: it's sort of like a requirement of the job. And
Speaker 1: it's really good at writing that because you know, it's
Speaker 1: just it's kind of like low intent, high volume code,
Speaker 1: quantity over quality type thing. So it's really good. It's
Speaker 1: stuff like that. The problem is that generating code really
Speaker 1: isn't the hard part of being a software engineer. It's
Speaker 1: it's one of the things that really matters, and it's like,
Speaker 1: obviously if you go to college to learn how to code,
Speaker 1: what you're going to spend most of the time doing
Speaker 1: is is typing code, but it's it's really just like
Speaker 1: one thing that you're doing, Like in reality, you're doing
Speaker 1: a lot more thinking about like, Okay, how does this
Speaker 1: work with the systems already have? How do I avoid
Speaker 1: creating what's called tech debt? So tech debt is basically
Speaker 1: like an easy way of thinking about it is when
Speaker 1: you write code that makes writing future code harder. So
Speaker 1: an example would be, you know, you want to write
Speaker 1: like a piece of logic that, let's say computes sales tax.
Speaker 1: If you're, you know, making an online story, you'd want
Speaker 1: to compute sales tax based on where they are. You
Speaker 1: only want to write that once. You don't want to
Speaker 1: have two different places that you know handle sales tax,
Speaker 1: because then, if you know, Illinois changes their sales tax, right,
Speaker 1: you have to change two places instead of one.
Speaker 2: It doesn't doesn't The very nature of code also mean
Speaker 2: that it naturally creates tech debt.
Speaker 1: You know, you can try to mitigate as much as
Speaker 1: you can, but there's not even an idea like that
Speaker 1: all code is tech debt. And and what LLLMS so
Speaker 1: kind of what I mentioned before. You know, lms are
Speaker 1: get at producing boilerplate. But if you get to the
Speaker 1: point where boilerplate is really easy to produce and you're
Speaker 1: not constantly thinking like, Okay, how do I avoid doing
Speaker 1: this in the future, you start, yeah, exactly, you start
Speaker 1: generating more and more code. And just like generating code
Speaker 1: is an it's kind of like writing in terms of,
Speaker 1: like you know, writing a book, like a good writer
Speaker 1: writes fewer words rather than more.
Speaker 3: Yeah. Yeah, brevity is the soul of wit.
Speaker 2: Now. It's because what I've been realizing is that there
Speaker 2: is this delta between people that actually write software and
Speaker 2: people that are excited about AI coding. Because I had
Speaker 2: Carl Brown from the Internet of Bugs on and it
Speaker 2: was this thing of yeah, being the software engineer is
Speaker 2: not just writing one hundred lines of code and then
Speaker 2: giving the thumbs up to your boss. You have to
Speaker 2: interact with various different parts of the organization. Early on
Speaker 2: in the piece as well, you had this bit called
Speaker 2: the math no link to this obviously in the episode notes,
Speaker 2: where it's any software engineer has worked on actual code
Speaker 2: in the natural company knows that you have these steps
Speaker 2: where it isn't just like icode and then I give
Speaker 2: the thumbs up and I'm dumb for the day. You
Speaker 2: have to go through a reviewer, you have to wait
Speaker 2: for them to get back to you. You have to
Speaker 2: contact switching as well. We have to change different windows
Speaker 2: and do different things. There's a shit ton of just
Speaker 2: intermediary work that is nothing to do with actually writing code, right.
Speaker 1: Yeah, absolutely, I mean it's it really is more of
Speaker 1: you know, there's parts of coding that is more science
Speaker 1: than there's parts of coding that are more art and
Speaker 1: more you know, in college, is really common if you're
Speaker 1: getting computer science deority to take communications classes because you
Speaker 1: just have to interact with a lot of people. So
Speaker 1: the standard way that a thing gets done in a
Speaker 1: software project is you have somebody called a product manager,
Speaker 1: and that person's that person's job is to think about
Speaker 1: what the product is as it exists now and what
Speaker 1: should be in the future, and like what features we
Speaker 1: should build, Like basically more than anything, it's you know,
Speaker 1: what what should we build next? And then you have
Speaker 1: designers who are going to decide how that thing should look.
Speaker 1: And engineers have to be this meeting influence because they're
Speaker 1: the only ones in the process who actually know what
Speaker 1: it's like, how hard it is going to be to
Speaker 1: build something. So a frequent interaction is like, you know,
Speaker 1: product maators are like, oh, we should add this, and
Speaker 1: an engineer has to kind of step in and be like, no,
Speaker 1: that's borderline impossible or you know that would take six months,
Speaker 1: right and you want coding.
Speaker 2: Lllms don't fix that problem. They don't do they actually
Speaker 2: make it easier to develop products.
Speaker 1: I think there are uses for LMS in coding, and.
Speaker 2: I'm not even denying that. I'm just like, how, like,
Speaker 2: what do what do those uses end up actually creating?
Speaker 1: Basically, you know, what I found is that I don't
Speaker 1: really like using lms for most product work, even though
Speaker 1: they're good at you know, say like oh add a
Speaker 1: button here that does this. They can be good at that,
Speaker 1: especially if you have a codebase that that works really
Speaker 1: well with lllms. So some programming languages, some tools, some
Speaker 1: we call them libraries and coding you know, they're basically
Speaker 1: like shared software. Some of those things work really well
Speaker 1: with lms because the lms are just trained on the Internet.
Speaker 1: So sites like stack overflow and sites like leak code
Speaker 1: and stuff like that, and so if they have a
Speaker 1: large body of this code to work within their training data,
Speaker 1: like these tools and these languages, they tend to be
Speaker 1: better at writing them. And so you know, I work
Speaker 1: primarily in JavaScript, as do most web application engineers, and
Speaker 1: lms are quite good at JavaScript, but I still don't
Speaker 1: like to use that much because it tends to just
Speaker 1: not understand context very well.
Speaker 3: And mean impracticality.
Speaker 1: So it's kind of just like you know, understanding the
Speaker 1: existing resources that you've already built in your code base.
Speaker 1: So this is like the avoiding writing the same like
Speaker 1: sales tax thing twice. They tend to default to rewriting
Speaker 1: things and they tend to struggle to reuse the same
Speaker 1: like style. So you know, an important thing in coding
Speaker 1: is maintaining consistent like styles of your code. So like
Speaker 1: there's there's a whole theory and practice of actual like
Speaker 1: how your code should look like as like how the texture,
Speaker 1: like how you should avoid, what things you should avoid,
Speaker 1: because there's there's bad patterns, there's good patterns, and you know,
Speaker 1: there's everything in between. I think it's very similar to
Speaker 1: like you know, when image generation AI kind of came
Speaker 1: onto the scene, you had a lot of people being like,
Speaker 1: all right, well, graphic designers are done. You know, they're
Speaker 1: out of a job. They don't need to do anything
Speaker 1: because I can generate a logo now and like it
Speaker 1: looks pretty good. Like I can generate a logo for
Speaker 1: my nail slam or whatever, and look at it looks great.
Speaker 1: But as soon as you try to generate a second
Speaker 1: logo that looks like the first one and you know,
Speaker 1: maybe has a slight modification or or something like that,
Speaker 1: it's really it's really bad at it. It's really bad
Speaker 1: at you using the context and you're like, okay, now
Speaker 1: I need a graphic designer. And as soon as you
Speaker 1: need you know one anyway, yeah, exactly, and so and
Speaker 1: and you know that's it's very similar to engineers, you know,
Speaker 1: they a lot of what you're doing is sort of
Speaker 1: working around context and avoiding redoing things and avoiding moving
Speaker 1: away from your existing styles.
Speaker 2: And what is the critical nature of styles?
Speaker 3: Is that?
Speaker 2: Because is that so the people looking at your staff
Speaker 2: in the future can say, Okay, this is what they
Speaker 2: were going for. This is so that everything doesn't break.
Speaker 1: Yes, exactly. It's about consistency. It's about so there are
Speaker 1: certain you know, for example, JavaScript, which is the main
Speaker 1: language I work in, is almost infamous for basically allowing
Speaker 1: you as the developer to do all sorts of buck
Speaker 1: wild stuff that you should like never do coding wise,
Speaker 1: like a lot of old patterns, a lot of recycled stuff,
Speaker 1: a lot of it just it just lets you. It's
Speaker 1: it's an extremely varied language in the things it supports,
Speaker 1: and so what you want to do when you're writing
Speaker 1: in JavaScript is only use the good parts. You want
Speaker 1: to strategically avoid doing a bunch of bad things. And
Speaker 1: some of those bad things, there's tools that will automatically
Speaker 1: detect if you're doing them.
Speaker 3: What are these bad things? Is it just the job?
Speaker 3: What's so special about Java that it allows you to
Speaker 3: do that?
Speaker 1: Yeah, JavaScript, which is technically different from Java, Yeah, no problem. Basically,
Speaker 1: the reason JavaScript has all these bad parts is because
Speaker 1: it was created in ten days as a toy language
Speaker 1: at Mosaic, which was the precursor to Firefox, you know,
Speaker 1: the first browser that really green traction and sat the Internet.
Speaker 2: I'm old enough to have used Mosaic somehow.
Speaker 1: Yeah. So JavaScript was created in like ten days almost
Speaker 1: like just as like a thing to test, like just
Speaker 1: something to try like, okay, what if we put a
Speaker 1: coding language into the into the browser that people could
Speaker 1: just like ship with their websites. And in response to that,
Speaker 1: other company said, okay, well we need to support JavaScript
Speaker 1: as well, and so when Internet Explorer came out, they
Speaker 1: shipped their own version of JavaScript, which was slightly different.
Speaker 1: And so you have this engineer that was kind of
Speaker 1: built on like these like very hacked to get their principles,
Speaker 1: that was then rebuilt with slightly different principles, and then
Speaker 1: what you have now is thirty years later, sort of
Speaker 1: the conglomeration of all those things into one language, and
Speaker 1: it's improved dramatically in that time. But the nature of
Speaker 1: coding languages is there's a lot of backwards compatibility. Like
Speaker 1: a video game where you know, you you know, you
Speaker 1: want to be able to build a computer that can
Speaker 1: run a game from nineteen ninety one, so you want
Speaker 1: the browser to be able to still run code largely
Speaker 1: that was written in nineteen ninety five or whatever. So
Speaker 1: a lot of that stuff still exists, and what they've
Speaker 1: done is introduce new patterns that can be better, and
Speaker 1: so there's a sort of an equal amount of like
Speaker 1: avoiding that and then also just consistency. So there are
Speaker 1: times where there's two good ways to write ways to
Speaker 1: do something, but you always want to do it only
Speaker 1: in one way so that anytime someone reads it, they
Speaker 1: see that pattern and they say, okay, I know exactly
Speaker 1: what this does.
Speaker 2: Right, And this fundamentally feels like something large of language
Speaker 2: world is bad at because they don't know anything and
Speaker 2: they don't create anything unique either.
Speaker 3: They just repeat yeah exactly.
Speaker 1: I mean, they are statistical inference models, and so they
Speaker 1: are very good at generating what they think should come
Speaker 1: next based on probabilities. And you can when you're training
Speaker 1: a large language model, you can try to push it
Speaker 1: in one way, push it in another way to say
Speaker 1: like no, don't do that, do that. But like trying
Speaker 1: to do that on the broad spectrum of all things
Speaker 1: code is impossible, and so you're going to get things
Speaker 1: that default to the way that they were done on
Speaker 1: the Internet, and so much like so, like like I said,
Speaker 1: JavaScript it is thirty years old, it's extremely it's gone
Speaker 1: through a lot of turk times in terms of patterns
Speaker 1: and so on the Internet, there are just fast swaths
Speaker 1: of terrible JavaScript and you know.
Speaker 2: So it's just these models are trained on bad code
Speaker 2: as well as good code.
Speaker 1: Yeah, exactly, and and that you know, I'm sure they're
Speaker 1: trying very hard when they're training the models to filter
Speaker 1: some of this stuff out, but like trying to do
Speaker 1: a broad filter on hundreds of thousands, millions even of
Speaker 1: what does say again, like decades, Like I mean, JavaScript
Speaker 1: has been around for thirty years. I just have most
Speaker 1: programming languages that are in use right now.
Speaker 2: Right, but this particular one seems particularly chaotic in how
Speaker 2: it's sprawled.
Speaker 1: Yes, JavaScript is a particularly thirty language. Yeah.
Speaker 2: Why So what you're describing, I'm not trying to put
Speaker 2: words in your mouth, is that this stuff doesn't do
Speaker 2: the stuff that everyone's saying it does. Like it's not
Speaker 2: replacing engineers. It doesn't even seem like it could replace engineers.
Speaker 2: Like it's just not it doesn't do In fact, maybe
Speaker 2: it's fair to say that. So it doesn't do software engineering.
Speaker 1: That's almost the perfect way to put it. It does coding,
Speaker 1: but it doesn't do software engineering, and software engineering is
Speaker 1: kind of this broader practice of like everything that comes
Speaker 1: together around coding. So you know, some people really integrate
Speaker 1: lms deeply into their everyday work and they do similar
Speaker 1: work to what I do. So you know, there are
Speaker 1: people who who are primarily having like lms write their code,
Speaker 1: and they can be good engineers, but they're intervening pretty
Speaker 1: constantly from what I understand, and you know, they're having
Speaker 1: to sort of redirect it, make sure it stays on
Speaker 1: patterns and all that stuff, and there's just kind of
Speaker 1: you know, this is the reason that I don't really
Speaker 1: elms that much, is there's just a constant tension between
Speaker 1: the the lack of context they have and you know,
Speaker 1: what you want them to do and constantly reviewing the
Speaker 1: code and making sure it's up to standards when I
Speaker 1: know I could just write it and you know it'll
Speaker 1: take up out as much time then as it would
Speaker 1: take prompting and re prompting. It's just I get better
Speaker 1: code that way, and that's that's what I care about most.
Speaker 2: So do you think it's kind of a mirage al
Speaker 2: most the productivity benefits?
Speaker 1: I think it would vary a lot. I think yes, broadly,
Speaker 1: I think that there are productivity benefits, but like these
Speaker 1: like huge outsides, like oh my gosh, I'm galaxy brained
Speaker 1: right now, I'm doing so much. I think that that
Speaker 1: is largely a mirage based on like extrapolation of like
Speaker 1: small wins. I talk about this a little bit in
Speaker 1: my article that you know, there are times. One thing
Speaker 1: that I use LMS for a lot and not a
Speaker 1: lot sometimes, but that they are really good at is
Speaker 1: you know, sometimes you're writing code and you're like, I
Speaker 1: need to write a thing that I will only run
Speaker 1: once and I will throw in the trash, or I
Speaker 1: need to write a thing and it uses this tool
Speaker 1: that like I don't have the time to learn, but
Speaker 1: like I'd really like to have this tool, Like I'd
Speaker 1: really like to just like use this once and so
Speaker 1: you can you can vibe code something and not really
Speaker 1: understand what the code does. You can run it once
Speaker 1: and not you know, validate the output and make sure
Speaker 1: it works fine, and you know I've saved in that time.
Speaker 1: You know, it might have taken me five hours to
Speaker 1: like learn how to use this tool properly and like
Speaker 1: learn how to use it with good standards. It could
Speaker 1: even have taken me more, and instead I spent twenty minutes.
Speaker 2: You know, wouldn't that be dangerous because you don't know
Speaker 2: how it works exactly.
Speaker 1: Exactly why I like to only use it for these
Speaker 1: like one time like low. You know. So for example,
Speaker 1: I wrote some code the other week and I was
Speaker 1: basically I basically refactored some existing code. So I adjusted
Speaker 1: how it worked a little bit, and I realized there
Speaker 1: was a way that I could break some existing code
Speaker 1: with it. But I didn't have an easy way of
Speaker 1: checking across the entire code based. So we have tests
Speaker 1: in our code base that would you know, catch issues,
Speaker 1: but there's always some code that isn't quite up to
Speaker 1: up to par with tests. And so I had this
Speaker 1: idea that you know, a simple a really simple language
Speaker 1: parser could go through and make sure that this code
Speaker 1: was right, you know, something that is only like thirty
Speaker 1: lines of code. But language parsing is really complicated, and
Speaker 1: the tools to do it are you know there, there
Speaker 1: are a lot of them, and they're very well supported.
Speaker 1: And because language parsing is a huge deal, but it
Speaker 1: would it would take me a lot of time to
Speaker 1: learn that. So I just I just vibe coded a
Speaker 1: little tool. I said, hey, find me every case where
Speaker 1: I use this function, and I call it like this
Speaker 1: in this entire code base, or actually said, I said,
Speaker 1: write a script that will find me that and I
Speaker 1: looked at the code, I was like, yeah, that looks right,
Speaker 1: that looks right, looks right. I ran it, it said
Speaker 1: there was there's no issues in my code base. So
Speaker 1: I intentionally created an issue just to make sure it worked.
Speaker 1: And it worked, it showed it, and so then I
Speaker 1: got rid of the intentional issue. I was like, Okay,
Speaker 1: this is probably good, and I pushed my code and
Speaker 1: it turned out to be good.
Speaker 3: But that's you know, that also seems low stakes.
Speaker 1: Exactly, and it's it's what I would say, wouldn't scale.
Speaker 1: So if I really needed to start doing like language
Speaker 1: person constantly, like I was doing it daily at my job,
Speaker 1: I simply would have to learn. Like you said, you know,
Speaker 1: how do you know that there are any issues? I
Speaker 1: would have to learn the tools, right, So the time
Speaker 1: that I saved was by avoiding learning for this one thing.
Speaker 1: But eventually, like if you're going to make something your
Speaker 1: full time job, you have to learn it because you
Speaker 1: can't fully trust the output.
Speaker 3: Because it isn't your job, like you were just kind
Speaker 3: of mimicking.
Speaker 1: Yeah, and you know you have to. You know, the
Speaker 1: llms make mistakes in occasionally extremely catastrophic ways. There's a
Speaker 1: thing called slop squatting. Have you heard of slap squatting?
Speaker 3: No, but please tell me. I love this term so
Speaker 3: much already.
Speaker 1: Yeah. So basically you might you might have heard like
Speaker 1: domain squatting.
Speaker 2: So this is where like I think I know what
Speaker 2: this is and I'm very excited to hear more.
Speaker 1: Yeah. So, like you know, this was a thing where
Speaker 1: like in nineteen, you know, ninety one, you're like, Okay,
Speaker 1: I think the Internet's gonna be big, so I'm gonna
Speaker 1: grab Nike dot com. Right, I'm just gonna hold it.
Speaker 1: So that's squatting a domain. So slap squatting is basically
Speaker 1: where you the the lms. You know, they're statistical inference machines.
Speaker 1: They don't they don't actually understand uh, what they're doing.
Speaker 1: And so you know, sometimes they will import software.
Speaker 2: They will oh is this when it looks on GitHub
Speaker 2: for something that doesn't exist.
Speaker 1: Yes, and and it it It will just add code
Speaker 1: to your project that's like import this thing and it
Speaker 1: will stall it and it'll say like, okay, this is
Speaker 1: the library that you want to use, and it's it's
Speaker 1: not right. It's it's either misspelled or it's you know,
Speaker 1: for example, you would be looking for a library called
Speaker 1: uh left dash pad, and it would import something called
Speaker 1: left pad with no dash. And so what people realized
Speaker 1: is that they can, you know, when the the lms,
Speaker 1: there's statistical machines, and so they frequently they do the
Speaker 1: same thing a lot, they make the same mistakes a lot.
Speaker 1: So you could grab that library left pad with no
Speaker 1: dago and jet and put code in there that works,
Speaker 1: that does the thing that the library is supposed to do,
Speaker 1: but also retrieves, you know, all of the secrets that
Speaker 1: are in your environment or like looks for and crypto
Speaker 1: wallets or like production database passwords and stuff like that.
Speaker 2: And if you're someone that can't read code or can't
Speaker 2: read that kind of code, you would have no idea
Speaker 2: this is happening.
Speaker 1: You'd have no idea. And even if you're somebody who
Speaker 1: does read code really well, if you you know, look
Speaker 1: at that he said, it's it's important left You're like,
Speaker 1: that sounds right, that looks right, like unless you are
Speaker 1: really familiar with this library, and even if you are familiar,
Speaker 1: you might just like gloss right over it. So it's
Speaker 1: it's really really really dangerous, and like, this is the
Speaker 1: type of thing that could you know, like maybe if
Speaker 1: like if the LM is making you even twice as productive,
Speaker 1: you know, that doesn't mean much if you know, there's
Speaker 1: a chance you could destroy your entire company with a
Speaker 1: catastrophic security breach, you know, yeah, leak all your database
Speaker 1: to this this hacker.
Speaker 3: And so yeah, not good. Yeah, is that becoming preblem?
Speaker 1: I haven't heard much of it like happening in the wild,
Speaker 1: but it's it's just one of those things that is
Speaker 1: bound to happen because again, these are just just statistical
Speaker 1: models that they don't they don't have the ability to
Speaker 1: really reason about the actual nature of the things that
Speaker 1: they're doing. They can try, you know, they can make
Speaker 1: a sub LLM call and ask the other element like
Speaker 1: does this look right? But then you're you know, burning
Speaker 1: more and more.
Speaker 2: And I also, at some point you are trusting the
Speaker 2: statistical model to measure a statistical model's ability to do
Speaker 2: is job.
Speaker 1: Yes, exactly, And you know it kind of devolves. Anybody
Speaker 1: who's who's used an LLM for coding knows that the
Speaker 1: deeper you go into like a single prompt, like the
Speaker 1: more back and forth, the larger the context window, the
Speaker 1: more garbage it gets. And so like as you have
Speaker 1: things like working off of other LLLM input, which is
Speaker 1: effectively what you're doing in a large context window. You know,
Speaker 1: it's just what the LM is sort of reprocessing the
Speaker 1: text that it generated and that you've added to it.
Speaker 1: It steadily gets worse the later in the context window.
Speaker 1: So so basically all of these sort of mitigations are
Speaker 1: you know, they've made surprising progress with the way that like,
Speaker 1: you know, things like this don't happen is like just
Speaker 1: raw hallucinations of like I think this library exists. They
Speaker 1: happen a lot less now than they used to, but
Speaker 1: they're they're just always they're always.
Speaker 3: Gonnask and they're also always gonna be there.
Speaker 2: Yeah, it's not it's not really something you could unless
Speaker 2: we invent new maths.
Speaker 1: Yeah, I mean, at least with the way we approach
Speaker 1: AI right now, which is is is based purely on
Speaker 1: language as tokens and it can't really fundamentally like understand
Speaker 1: things outside of you know, word probabilities.
Speaker 3: So where is this pressure coming from?
Speaker 2: Because it feels like it's everywhere and you've got people
Speaker 2: up Paul Graham who are wanking on about Oh that
Speaker 2: I met a guy who writes ten thousand lines of code.
Speaker 3: I think he said, what is it?
Speaker 2: Are we just finding out how many people don't know
Speaker 2: how code is?
Speaker 1: Wooks? I think a lot of that. Yes, Like I said,
Speaker 1: it's exactly the same way as like people, you know,
Speaker 1: when the first image generation models were like, oh great,
Speaker 1: we don't need graphic designers anymore, and then they are,
Speaker 1: you know, oh great, we don't need customer support chat anymore,
Speaker 1: because they fundamentally don't understand what those roles do. You know,
Speaker 1: they're they think graphic designer and they think image generator.
Speaker 1: But a graphic designer is a human being. That's that's
Speaker 1: dealing with different stakeholders, dealing with people saying like no, no, no,
Speaker 1: the logo can't have that, or you know, yes the logo.
Speaker 3: Must get bump.
Speaker 1: Yeah, yeah, exactly, and they're dealing with you know, different requirements,
Speaker 1: and then they're needing to make variations, which is something
Speaker 1: that LMS are not always very good at, or I
Speaker 1: should just say jeneratorf AI is not always very good at. Yeah,
Speaker 1: and so so I strange part of it is is
Speaker 1: is people who you know, like I said, you know,
Speaker 1: you get these like brief bursts where you're like, oh
Speaker 1: my god, I just say so much time and you
Speaker 1: extrapolate that. So some of it I think as engineers
Speaker 1: who are just like actual engineers who know how to code,
Speaker 1: who see these things and they think like I did
Speaker 1: this today, and like I must have been so much
Speaker 1: more productive as a result. You know, I saw this
Speaker 1: one thing happen. But they don't really actually measure in
Speaker 1: depth what they produced and was it more than what
Speaker 1: they would have produced. There have been some studies to
Speaker 1: measure that, and they haven't looked particularly good for lllms.
Speaker 1: You know, if you actually compare people, you know, using
Speaker 1: AI versus not using AI, the results don't always look
Speaker 1: particularly great for AI. And one thing that's very common
Speaker 1: out of that is that people overestimate their performance.
Speaker 2: So I think that might be a problem across or
Speaker 2: like a lot of people don't. I also think my
Speaker 2: grander theory with all of this is a lot of
Speaker 2: people don't know what work is.
Speaker 3: Like a lot of these.
Speaker 2: Investors and managers and such, and even people in the
Speaker 2: media don't seem to actually know what jobs are and
Speaker 2: how the jobs work, and they think that things like
Speaker 2: coding is just like I said earlier, yeah, just walk
Speaker 2: into work or write ten thousand lines of code on
Speaker 2: a walk home. But now I can write twenty billion
Speaker 2: lines of code because that's all my job is.
Speaker 1: Yeah, absolutely, I mean this is this is something I
Speaker 1: talk about in my article, is that there's always this
Speaker 1: like degree of separation and the people who are talking
Speaker 1: the most about AI coding' aren't really coders and they're
Speaker 1: not really providing like detailed reproduction steps.
Speaker 4: You know.
Speaker 1: I know engineers who love using AI like every single day,
Speaker 1: and they use it for like all of their projects.
Speaker 1: And I know really good ones to do that. And
Speaker 1: if I asked them like, hey, how could I like
Speaker 1: be more likely be more like you? How could I
Speaker 1: be a better coder? One of the last things they'll
Speaker 1: say is, probably, you know, start using AI more, for
Speaker 1: it's really just a tool to accomplish part of their job.
Speaker 1: And so so yeah, I think there's a lot of
Speaker 1: you know, there's probably you know, plenty of genuine people
Speaker 1: who who just like you know, they've never written a
Speaker 1: line of code in their life. They pull up Lovable
Speaker 1: they say, generate me an app that does this, and
Speaker 1: like they legitimately are like, oh my gosh, it actually
Speaker 1: worked like I I can code, and they just yeah,
Speaker 1: they just you know, naturally, you know, they don't realize it.
Speaker 1: They don't realize that, like there is so much more
Speaker 1: to this actual practice, and you know they're they're they're
Speaker 1: just not in tune with the way that coding actually works.
Speaker 2: Yeah, it's a little bit sad as well, because it
Speaker 2: really feels like a lot of this is just the
Speaker 2: point you've made about like the image generators.
Speaker 3: It's just this immediate moment of wow, look what this
Speaker 3: could do.
Speaker 2: Imagine what it could do next, and then you look
Speaker 2: at what it could do next, and it can't, Like
Speaker 2: it looks like it can generate code, but it can't
Speaker 2: actually generate software like it cut.
Speaker 3: It doesn't seem to do the steps.
Speaker 2: That make software functional and scale because there's these tendrils
Speaker 2: of from software into the infrastructure to make sure it
Speaker 2: can be shown in different places or to make sure
Speaker 2: that it actually functions.
Speaker 3: On a day to day basic Yeah, and it's like, yeah.
Speaker 1: It's a pretty simple like curve, Like you know, you
Speaker 1: start out and it generates so much code that's like
Speaker 1: pretty correct, really fast. When you if you start a
Speaker 1: completely bare project from just like a lovable prompt or
Speaker 1: something like that. But as you go on, you know,
Speaker 1: it's like the curve kind of flattens and it goes
Speaker 1: down and it becomes less and less productive, and I
Speaker 1: think eventually, usually like pure vibe coded projects hit a
Speaker 1: pretty big wall because you're just introducing so much code
Speaker 1: and it's not consistent, it's not it's not using shared tools,
Speaker 1: and so eventually you just end up with this you know,
Speaker 1: they call it spaghetti code. It's you know, code that
Speaker 1: is so interwoven and difficult to understand that like you
Speaker 1: can't actually see what's going on with it.
Speaker 2: Yeah, it was like context is the whole problem, just
Speaker 2: because even if not to say, like LLM generated writing
Speaker 2: is dog shit, and I think it's worse than code
Speaker 2: because code code, code is functional in a way that
Speaker 2: I don't think writing has to be. Like writing conveys meaning.
Speaker 2: But good writing is usually more than just I am
Speaker 2: entering this writing into someone's brain. So something happens in
Speaker 2: the way that code is, but writing it they share
Speaker 2: the same problem, which is great writing has contextual awareness,
Speaker 2: It builds, it connects, there is an argument or there
Speaker 2: is an evocation from it. In the case with software,
Speaker 2: it appears to be. If you don't know every reason
Speaker 2: that everything was done and fully understand the reasons that
Speaker 2: were previous and the reasons that are happening right now,
Speaker 2: you kind of will fuck something up naturally, even if
Speaker 2: you do know how to code, if you just don't
Speaker 2: read any of the notes, if you if if it's
Speaker 2: not clear why things were done, things will break anyway, right.
Speaker 1: Yeah, exactly. And great writing, you know, it knows when
Speaker 1: to you know, you know, a great knows you know,
Speaker 1: when they need to explain something, when they don't need
Speaker 1: to explain something. You know, they know, you know, I'm
Speaker 1: writing a trade publication like I don't need to explain
Speaker 1: how friction works, or I'm writing, you know, a public
Speaker 1: press release, Okay, I do need to explain how friction works,
Speaker 1: or you know whatever. So it's it's very you know,
Speaker 1: these are the things that the lms are like, yeah, exactly,
Speaker 1: just like very not good at you know, they can
Speaker 1: they can generate stuff that looks good, but it's just
Speaker 1: the more you try to build on top of it,
Speaker 1: the more it'll it'll end up restating. Like you know,
Speaker 1: lms are really good at writing, Like the classic school
Speaker 1: level five paragraph essay. But everybody who actually writes anything
Speaker 1: at all knows that, like the five paragraphed essays that
Speaker 1: you wrote in high school are like terrible and like
Speaker 1: nobody wants to read something structured as like you know,
Speaker 1: premise three, argumented a paragraphs conclusion like that's it's really
Speaker 1: bad like unconvincing writing. Uh. And it's the same with
Speaker 1: you know, lms are really good at making toys and
Speaker 1: like like quick things that like are are fun or
Speaker 1: you know, maybe a little bit useful in certain situations,
Speaker 1: but really bad at writing things that you know, uh,
Speaker 1: like like a book level type things like you know,
Speaker 1: ais are horrible at writing books because they restate things
Speaker 1: and they lose track of what they're talking about.
Speaker 2: And the more stuff it creates, right, the more it
Speaker 2: looks over, the more confused it gets.
Speaker 1: Exactly It's it's really really similar. I think that coding
Speaker 1: has really just followed the same trajectory as like all
Speaker 1: of these other things where we're like, oh, we don't
Speaker 1: need copywriters anymore. Oh, we don't need uh designers anymore.
Speaker 1: We don't need graphic designers, we don't need this, that
Speaker 1: and the other. We don't need lawyers anymore we have
Speaker 1: an ll m P or a lawyer, and you just
Speaker 1: very quickly realize that like these these jobs aren't uh
Speaker 1: you know, dumb factory uh like producing you know, pulling
Speaker 1: a lever type jobs. They're they're about interaction.
Speaker 2: And that's an insult to factory labor. That is very
Speaker 2: hard work. But it's not like a repetitive action that
Speaker 2: is always the same thing.
Speaker 1: No, not in a sense anyway. Yeah, and like a
Speaker 1: factory worker, you know, is doing a lot more than
Speaker 1: just pulling levers.
Speaker 2: Yeah, of course, but it's not just hitting a button.
Speaker 2: But I think people condense coding to this thing.
Speaker 1: Yeah, And it's very similar to like robotics in factories too,
Speaker 1: where you know, the promise is like, oh, you know,
Speaker 1: we'll just have a robot do this thing that a
Speaker 1: human does. But the human is doing a lot more
Speaker 1: than just you know, pulling the lever. They're like observing
Speaker 1: the process. They're making sure that things are not getting
Speaker 1: broken or getting gummied up and stuff like that. So
Speaker 1: there's just there's just limits to what machines can do
Speaker 1: when they're not actually intelligent. And that's just what it
Speaker 1: comes down to.
Speaker 2: Do you buy the any of these companies like Google
Speaker 2: a writing thirty percent of their code with AI.
Speaker 1: The thing about like those numbers is that they are
Speaker 1: soon easy, maybe not to game, but to First of all,
Speaker 1: I don't know anyone who's actually like measuring this in
Speaker 1: a really like effective way, because the thing about your
Speaker 1: like coding editor is that it's a lot of people
Speaker 1: I don't like to use the AI autocompletion, but some
Speaker 1: people do. You know, there's there's pieces where it'll you know,
Speaker 1: you'll start writing some boiler plate and it'll like pop
Speaker 1: up you know what it thinks you mean to write,
Speaker 1: and you'll just hit tab the tab key on your
Speaker 1: keyboard and it'll just like finish the line of code
Speaker 1: that you were writing. And maybe that would yeah, yeah, exactly,
Speaker 1: and it might even very often what it produces is wrong,
Speaker 1: but it's like seventy five percent, right, So you're like, oh,
Speaker 1: I can just like use these keystrokes, I can save
Speaker 1: these keystrokes, and I can just fix what it did wrong.
Speaker 2: Oh God, it's like saying auto correct wrote parts of
Speaker 2: your book.
Speaker 1: Yeah, it really is. And you know there are times
Speaker 1: where like an AI does is fully write the code
Speaker 1: for a feature, so people use you know things where
Speaker 1: they can prompt an LLM and it will with like
Speaker 1: what they want the feature to be or what they
Speaker 1: want the bug fix to be, and it will go
Speaker 1: and we'll write all the code and it will make
Speaker 1: the sort of we call it a merge request, but
Speaker 1: that's the request for new code that then gets reviewed.
Speaker 1: It will go all that way. But the thing is,
Speaker 1: you know, it might have written the code, but somebody
Speaker 1: took time away from you know, their normal job, which
Speaker 1: just be writing code, to write a really good prompt
Speaker 1: to make sure it didn't screw it up, and then
Speaker 1: reinteract with it. And so you know, did it write
Speaker 1: the code, yes, but did it do the task not really,
Speaker 1: because it needed somebody else to do some support work
Speaker 1: to make it even possible for it to do it.
Speaker 1: And that person could have That person needed to be
Speaker 1: technical and needed to be able to say like, oh,
Speaker 1: you need to look in this part of the code base,
Speaker 1: And so you end up just getting the same type
Speaker 1: of like actual work from the actual specialist who knows
Speaker 1: how to code the same amount of work. They're just
Speaker 1: doing something slightly different.
Speaker 2: Cole has been such a pleasure having you here. Where
Speaker 2: can people find you?
Speaker 1: For sure. My blog is Coulson dot dev c O
Speaker 1: L t O N dot dev. I don't post that
Speaker 1: often because I work full time and I just I
Speaker 1: just post when something really gets to me. But you know,
Speaker 1: I might. I might say some things here and there.
Speaker 3: And you have your excellent blog that I brought you
Speaker 3: on for.
Speaker 1: Yeah, yeah, that's my that's my most recent one. You
Speaker 1: can feel free to check it out. I'm sure the
Speaker 1: link to that will be in the description. But yeah,
Speaker 1: it was great being here.
Speaker 5: Thanks so much, Thank you for listening to Better Offline.
Speaker 6: The editor and composer of the Better Offline theme song
Speaker 6: is Matosowski. You can check out more of his music
Speaker 6: and audio projects at Mattasowski dot com m A T
Speaker 6: t O s O W s ki dot com. You
Speaker 6: can email me at easy at Better offline dot com
Speaker 6: or visit better offline dot com to find more podcast
Speaker 6: links and of course, my newsletter. I also really recommend
Speaker 6: you go to chat dot Where's youreaed dot at to
Speaker 6: visit the discord, and go to our slash.
Speaker 5: Better Offline to check out our reddit. Thank you so
Speaker 5: much for listening. Better Offline is a production of cool
Speaker 5: Zone Media. For more from cool Zone, Media.
Speaker 4: Visit our website cool zonemedia dot com, or check us
Speaker 4: out on the iHeartRadio app, Apple Podcasts, or wherever you
Speaker 4: get your podcasts.