YouTube Transcript:
You're using AI coding tools wrong

Skip watching entire videos - get the full transcript, search for keywords, and copy with one click.

Video Transcript

I think it's fair to say that a lot of

people are writing way more code today

than they were a few years ago. And I

don't mean literally typing it all out

themselves. I'm talking about all these

cool vibe coding tools, AI agents that

help you produce and write a bunch of

code. That said, I don't feel like I'm

seeing a lot more shipping happening.

Are there more cool demos on Twitter

that people are posting of some thing

they built on the side? Maybe. But I

don't see more features coming out of

real products. I don't see more

innovation happening in the things I use

every day. If anything, it feels like

less is happening there. So, what's

going on? If suddenly we don't have to

wait for the code to be done, shouldn't

we have way more features out there?

Well, you'd think, but the harsh reality

is that code was never the bottleneck. I

have been thinking this for a while now

because I've historically been the guy

who pushes projects over the finish line

when they're falling behind. And I just

saw an awesome article that made me

really want to sit down and break this

concept apart with you guys. Because

coding, as much as it is what we want to

be spending our time doing and what we

aspire to spend our time working on,

it's not the thing actually slowing down

what we want to ship. There are so many

parts to releasing features and building

your applications that just aren't AI

generatable that aren't the thing that

happens in your editor for however many

hours a day that you're actually sitting

writing code. And those things might be

slightly better because of AI, but not

really. Certainly not to the level that

you would hope for or expect from the

stuff that we hear about constantly on

the internet. Does that mean we're about

to all become PMs? Not quite. I'm

excited to go deep on this and try to

share my thoughts on what an engineer is

going to be in a few years. There's so

much going on in this crazy world. And

this article seems like a really good

starting point. I'm excited to dive in,

but if I'm going to lose my job as an

engineer, someone's got to pay my bills.

So, quick word from today's sponsor and

then we'll go right in. It's clear AI

has gotten really good at writing code,

but it's also clear if you work in a big

codebase that it doesn't handle large

amounts of context well. It'll try and

find the right file in your codebase,

but what does it do from there? Often

the wrong thing, unless you're using

today's sponsor, Augment Code. The catch

line is cheesy, but it really is what it

says. It's better context and the result

is way better code. It can write code

for you, but honestly, I mostly use it

for finding things in the codebase

because it can traverse giant projects

really well, especially open source

ones. That's my favorite abuse for it. I

often have questions about how React

works. So, I have the entire React

codebase here. A 593,000 line of code

codebase. By the way, it has been fully

indexed. It only took a few seconds to

do it. And now I can ask anything and

get an answer in seconds. They're the

only AI agent that actually has the

balls to put a timer prominently in the

UI because it is so fast and I still

don't know how it manages to be as

absurdly fast as it is. And you look at

that, it figured it out. It found the

core implementation and the separate

serverside implementation in order to

make sure things work during React

server components. I didn't even know

they had a separate fake stubbed out

ustate for that. I'm learning things as

I'm recording the ad. That's how good

Augment is. If you don't trust me, you

should look through the testimonials on

the site. They're kind of insane. They

have this many quotes from people who

love it. And they're also the most

positively received sponsor I feature

and we feature some cool stuff here. If

you want to try it now, it's free to get

started and if you're a big business

trying to make AI work, they're the ones

to go with. Check them out now at.link/

augment. Writing code was never the

bottleneck. For years, I felt that

writing lines of code was never the

bottleneck of software engineering. The

actual bottlenecks were and still are.

Code reviews, knowledge transfer through

mentoring and pairing, testing,

debugging, and the human overhead of

coordination and communication. Shout it

from the mountain tops. This is so real.

All of this wrapped inside the labyrinth

of tickets, planning meetings, and agile

rituals. These processes meant to drive

quality often slow us down more than the

act of writing code itself because they

require thought, shared understanding,

and sound judgment. Now, with LLM making

it easy to generate working code faster

than ever, a new narrative has emerged.

The writing code was the bottleneck, and

we've finally cracked it. But that's not

quite right. The marginal cost of adding

new software is approaching zero,

especially with LLMs. But what's the

price of understanding, testing, and

trusting the code? Higher than ever. I

have so many thoughts already. And also

a bit of story time. Something I've

talked about a couple times in the past

is the role I've played at different

companies. A lot of the time that I was

at Twitch, I was the guy you called in

to make the deadline happen. There was a

lot of roles for this for me. One of

them is that I would tell my managers to

give me a fake deadline that was between

2 weeks and 2 months earlier than the

actual one so I could hit that deadline

and then we could spend the extra time

polishing. And I would convince myself

deeply every deadline I got was real.

And then once we hit it, then I'd spend

the extra time making the thing way

nicer and more polished. That's how some

of our best releases, like one of my

personal favorites, ModView on Twitch,

were able to happen and come out in such

a good state. It's funny that like chat

is as broken as it is there. It's very

funny cuz the rest of this all works

great. Very proud of what we built.

Having these different widgets that show

all of these details that are fully

customizable and movable. You can put

them in and out of the UI at any point.

Getting all of this ready day zero for

this launch was really fun because I had

told my PM to give me a deadline a month

early. So, I had this done and working

at the end of the month prior to the

actual release. And then we spent the

whole thing fixing bugs, finding

performance issues, and polishing the

hell out of it. This was a lot of my

role. The reason that I bring all of

this up is because that didn't benefit

me as much as you might think. This

might sound like I'm bragging about how

great an engineer I am. I'm not. This

was just a weird unique skill I had. I

had the strange ability to find the

right corners to cut to ship fast. I

could ship fast without meaningfully

compromising quality, usually by

trimming the right edges. I still work

like this today when I'm shown a plan

that my team has for some T3 chat stuff.

I try to find the edge that we can

remove to simplify the problem space

that we're working in to get a better

path to success. I'll also look at

things that work well and try to figure

out how we can make a simple beneficial

version to let us ship better. Things

like the full stack type safety of

GraphQL were massive wins for the teams

I was working on and the way I was

building at Twitch. The fact that the

GraphQL side took a actual team of

people to make it work well both for

devs and users meant that you had to

have a lot of employees before it was

worth dealing with to get the benefit on

the other side. I want to figure out how

we can get this benefit and the safety

and agility that comes with it without

the huge buyin of GraphQL. And that's

how the T3 stack was born. When I found

the right way to glue these parts

together so that we could ship faster.

It's a big part of why the apps we built

were so good. It's not because I built

it perfectly the first try. It's

actually quite the opposite. So I could

build it wrong but working quickly and

then through cycles of feedback with

users improve it rapidly because it was

so easy to make changes confidently in a

system built this way. That's how I like

to think. This gave me a huge advantage

for a long time. I got consulting gigs.

I was helping companies unfuck their

build pipelines and rethink how they

were actually architecting stuff. But

now it feels like these benefits are way

less real because you can use AI agents

to do a lot of the type of thing I used

to do here. I was the one who would come

in and figure out how things work and

simplify to the best of my ability so we

could ship fast again. The AI agents can

just do the fast shipping for you and

skip a lot of those steps. But there was

another aspect of this that I found was

really useful. Here I take the design

process at Twitch. It looked something

like this. Step one is that the product

manager identifies a problem. This could

be by going through user voice, by going

to events and talking to people, by

thinking too deeply about Twitch and

what is missing and trying to fill

holes. It's really common. The product

managers would try to find a problem

that needs to be solved because that was

their job. Step two was talk to users a

lot about that problem. To be fair, a

lot of PMs would skip this step, but it

was very nice when they didn't, so that

they could get more info on what the

problem actually was and what needed to

be solved. Step three was work with

design to figure out what the solution

looks like, both in a literal sense and

in a like spiritual sense, like the

design plus PM time would be spent

showing what it would look like.

Sometimes making mocks or fake versions

of the app, but deeply trying to figure

out what this should feel like and how

it should work. Then step four was a

product proposal spec. This would be

what their vision was of the product. It

would have mocks in it. It would be five

to 30 pages of documented what they

think this will be. They would then give

a presentation on said spec. They would

give a separate one to PMs to get

approval there and then give one to the

general team or the org that they're

working in to get the approval from

execs and whatnot. And then devs take

over and do pretty much the same thing.

The devs would then look at the spec,

figure out what's needed, talk with

product about what they talked about

with the users, and then write their own

super long spec. There's a problem with

this though. This process takes forever.

We're talking like from step one here to

step 8, 6 to 18 months just to go from

top to bottom down the spectrum.

Obviously, if there were more urgent

problems, we would do this much quicker.

Like when I was in the safety or we

would skip a lot of these steps, not

because it's not important, but because

it's really important. We need to fix

safety problems as quickly as we know

they exist. But in other orgs, it would

take months, if not years, to go from a

problem being identified to a document

ready to work against for a solution.

But as I had mentioned before, I was

previously in the safety or where we

didn't do this very much. And the rare

times we did, it was because we had a

working solution, but we wanted to

rethink it from scratch. Again, like Mod

View, there were solutions to moderate

streams on Twitch, but the solutions to

moderate streams on Twitch were not as

deep as we wanted for the type of

moderation that streamers had to do. And

the moderators in particular, they work

really hard. Shout out to all my mods

helping out right now. Those tools

needed a rethinking and we knew that.

So, we went and reought them. And even

then, it took us 7 months from decision

to actually shipping it instead of 18

months to just get started. Where this

got very painful is when I would

encounter projects that had made it like

this far past the presentation on the

spec from product and it was very

apparent to me that this product would

suck because I actually talked to

streamers and cared about the creator

world. And the fact that a product would

get to here and be garbage

was terrifying to me. like how can we go

this far in and not realize down this

process that this isn't the thing anyone

actually wants that it might even be a

regression for users or even worse when

the project gets all the way down to

here and then engineers are assigned to

work on it Jira tickets are cut months

to years in advance and then deadline is

set much later deadline isn't going to

be hit and then they ask me.

They got all the way down here and then

ask me to save it just for me to come in

and say this is a bad idea and get in a

bunch of arguments with it and then have

them just go and ship it anyways and

then the product sucks and they have to

revert it. This happened multiple times

during my time at Twitch, especially

during my last bit with my last team at

Twitch. The fact that it could go that

long without anyone having the

realization that the product they're

making doesn't solve any real problems

for any real user and is a mistake or

even better would cause regressions for

users that matter a lot. That was a very

common one is a new feature that would

make the site or app work way worse for

the users that they were supposedly

trying to help. Super [ __ ] common. So

why am I bringing all of this up? Is

this to highlight how the bottleneck was

never the code? No, actually the

opposite. I want to show one of the ways

I used my fast coding to unblock us. I

was lucky that a handful of PMs realized

that I cared a lot about product because

to be frank, most engineers don't.

That's not how most engineers work. They

want to write their code and close the

tickets that they were given. So here is

what I did differently. When the PMs and

also designers, I was very close to the

design throughout a large portion of my

career at Twitch and they love pulling

me in at the stage. Product manager

would identify the problem. PM would

grab a designer and Theo to talk about

it. 1.6 Theo would have a rough idea of

what this was meant to be and would go

build it in 3 days to 2 weeks. 1.7 PM

shows the Theo edition to actual users

to get feedback. And then 1.8

write a way better proposal or kill the

idea entirely based on said feedback.

And now that we've done this this way

instead, let's see how many stops that

we can get rid of. That one's gone. Now

the design step's kind of gone now

because we're iterating incrementally

like back and forth. There's a good

feedback loop for all of that. Product

proposal spec not really needed anymore.

The spec is often just the demo. It's

here's what we made. Maybe they do like

a one pager that is the things that

we're doing it for and why. Presentation

on said specs no longer needed. They

send a video out of the demo app saying

look at what we built. See how useful

this is. Devs take over. There's no devs

to take over. We were there the whole

time. Now there's nothing else for them

to do. We just have to either rebuild

the app and take all the learnings that

we had or if they really want to do a

spec, which admittedly does happen

sometimes, suddenly we can actually

write a good realistic spec because we

know all the shortcomings because we

already built the [ __ ] thing. The

harsh reality here is that I was just so

frustrated with the fact that we would

go down this whole pipe for a thing that

I could prove was obviously false in a

few days that I would just start working

on the thing super early and by the time

we got even partially down the pipe, I

could raise my hand and say, "Hey, I

have a working version of this if we

want to test it before we go down all of

this process." And then if you're the

one who says, "No, we're going to do the

process first." You look [ __ ] stupid

because you are [ __ ] stupid. The

reason I'm showing this is that I found

a way to take advantage of my ability to

build things fast to skip a ton of

process and make everything make a lot

more sense and most importantly waste

significantly less time. Even if we

still go through all of these steps, the

steps are way more efficient and way

more realistic about what we're building

because we have a reference version. And

if we have something we're not sure

about, we can go update the reference

version and see how users respond and

then go update our process and plan

accordingly. So the process being

research, then design, then spec, then

build, then ship, then prey, which is

usually what happens. Oh, there's

another step after, deprecate because it

sucked. Instead of this being the

process, I pushed for something very

different. My process was identify,

prototype, collect feedback, repeat

until good, spec, but really just write

down a short list or of how to build it,

right? build beta collect feedback and

go to five until great and that's the

big difference for me is I focused a lot

on this idea of looping like just

building the feedback loop and not

passing a certain stage until the thing

is in a state that we like and this loop

is super powerful especially if you

bring in users and designers and other

people in the process for it one

engineer one designer and one PM all

working on this part-time time can save

you months if not years of work and

potentially save you from building and

shipping a bad product with seven

engineers just by doing this part first.

And one of the things that I'm excited

about with all this AI code and vibe

coding is this small glimmer of hope

that people will realize they can build

this way first. That instead of spending

years on a spec and then days building

the thing that they can spend days

building the right thing or more

importantly days building the wrong

thing so they figure out what the right

thing is. a few more days respspecing it

once they figure that out and then

things go way more smoothly. So I do

believe we can use code to solve these

other things that are bottlenecks. I

just don't think that the thing at the

end of the pipe is the bottleneck. Like

there's a ton of bottlenecks in this

process. Each of these steps requires

humans to do a lot of different things

and also decide when to move on. That

means that there's a ton of stop gaps

and making the part at the bottom here

faster. Like speeding up this doesn't

help a lot. I know that because I'd be

pulled in here and as fast as I was, it

doesn't solve the product problems that

exist way earlier in the chain. If we

use these AI building tools to iterate

and prototype and figure out what is

actually needed significantly faster,

this is really powerful. Back to the

article cuz I want to see what Pedro has

to say cuz he kind of inspired me to

rant about this. LM shift the workload,

they don't remove it. Yes, tools like

cloud can speed up initial

implementation. Still, the result is

often more code flowing through systems

and more pressure on the people

responsible for reviewing, integrating,

and maintaining it. This becomes

especially clear when it's unclear

whether the author fully understands

what they submitted. The generated code

introduces unfamiliar patterns or breaks

established conventions as well as edge

cases and unintended side effects that

aren't obvious. Another hot take, this

is something that I would do before all

of this AI stuff when I was working on

this prototype stage. I would be okay

with and often expect to run into these

things. I would not fully understand the

code that I submitted. Half of it was

copy pasted from other places to fix

problems. The goal wasn't to submit code

that is good and should be shipped to

production. It was to figure out this

thing's worth building at all. It was

never a code quality goal. It was a put

in front of someone goal. The generated

code introduces unfamiliar patterns or

breaks established conventions. Oh man,

the amount of times I install some

random package and get yelled at by

someone else to say, "Yeah, I don't

actually plan on using said package. I

plan on figuring out if this

functionality is worth building and this

package makes it easier for me to do it.

Sorry that you don't like reviewing this

code, but we're not merging it anyways.

Just shut up. And then of course the

edge cases and unintended side effects

that aren't obvious. I can't tell you

how many times I ran into that in

particular. And also huge shout out to

my team, especially when I was on the

safety side. I would sometimes be

working on one of these like spec or

tech prototypes that was really focused

on the pieces coming together and be so

deep in my prototype madness that I

would hit some awful edge case, not be

able to solve it, and then start burning

out on the thing I was building, and

then someone else would come in with

fresh eyes, look through all my

[ __ ] and see the way the pieces

weren't coming together how they should,

and then fix it in like an hour. So,

yeah, I hit all of this. It was a very

real thing I would experience when I

built this way even without the AI. But

the purpose of building this way and the

reason I was okay with it isn't because

I expect to merge this code and ship it

to prod. It's because I'm trying to

build an understanding of what we're

actually making. This is not meant to

replace the build step in your

traditional pipe. This isn't meant to be

the thing you do after Jira. This is why

all of the AI agents that are built

around this idea of getting handed a

linear or Jira ticket and then going and

implementing everything for you make no

[ __ ] sense because code review is a

bigger burden than writing the code half

the time. Once you have it speced out,

it's easy to build the thing, but it's

not easy to build the right thing if you

wrote the wrong spec. Each of these

steps has fail cases in them if you want

to think about it that way. If we think

about it this way, if the research comes

to a bad conclusion, everything below is

now [ __ ] And I've seen this a lot too

where a PM sees some random request on

user voice and suggests that we build

this thing that makes literally no sense

and then it gets handed off to design.

And design does not pretend to know more

about the users than PMs do. So if the

PM comes in and says we need to do this,

they'll just go do it. And now they're

designing something against a failed

spec or even if it's a good spec, but

they design something that doesn't make

sense to users, we don't know that until

we're all the way at the bottom here.

And then they write a spec. Maybe the

design and research were good, but the

spec is talking about this in a way that

isn't actually understandable to people,

but they don't know that. They hear the

plan. They listen to the presentation.

They think they understand exactly what

this is going to be, and then they go

and write the tech spec, which carries

those bad assumptions through and says

the PM doesn't understand the tech spec.

So then when the PM shows up to that

tech spec planning meeting, their eyes

glaze over because they don't care about

the software dev side. So if they hear

these assumptions that are incorrect

about their spec, they don't even notice

it. But assuming all of that goes well

and you start building, what if you're

building things in a way that doesn't

come together well or doesn't actually

solve the problem that you're all trying

to solve? How long does it take to

notice that? Chances are you have a lot

of things blocking through the review

process where developers are reviewing

other developers code and when they

don't know why they're doing a thing,

they go check the spec that might

already have bad assumptions baked into

it. And then you finally ship it. You

pray that this is what users want. You

realize that things that were done all

the way back at the top at the research

phase were bad assumptions. And then you

have to kill the whole product and fire

the [ __ ] team because the teams were

based around specific products which was

a mistake. But you wouldn't fire the

team. Instead, you do a reorg and

suddenly I'm expected to teach a bunch

of C game developers how to write React

code because the company didn't have the

balls to accept its mistakes. Definitely

not venting about real experience here.

So yeah, making this build step faster

doesn't do a [ __ ] thing. I totally

agree. If you're trying to make this

faster, that gets us nothing because you

just made the review process even slower

and harder and potentially higher risk.

You made it more likely that this stage

fails. And you didn't help any of the

parts on top that are just as, if not

more, slow. The benefit of AI helping us

building is that we can move build from

step four here to be part of step one to

make sure we're doing the right thing.

And that's an awesome win if we take

advantage of it. But I'm scared

companies are trying too hard to dig

their heels into this process. As I've

seen with a lot of these wonderful vibe

coding tools, I just filmed a video on

GitHub Spark and immediately ran into

the chaos of them doing PRDs where it

deeply describes exactly what it wants

to build. Or if we look at the stuff

that I did with Kira not long ago, we

can see the absolute chaos of what it

was trying to do here. Probably deleted

the spec because I didn't feel like

dealing with it. Yeah, I did. So, I

deleted the spec that it wrote, but it

wrote like thousands of lines of

markdown to describe what it wanted to

do and how it wanted to think about it.

It's do it's like vibe coding the top

parts here, which I would argue is even

worse because part of what's cool about

vibe coding [ __ ] is that you don't have

to feel bad throwing it away. If you

were to have the average developer build

really early, realize the product was

bad, and scrap it, they'd feel like

[ __ ] But if you're letting an AI do it

or you're letting Theo do it where I

love when my code is thrown away. It

feels great to know it's being replaced

by something that makes more sense or is

being deprecated because it didn't make

sense. I love that vibe coding out this

part doesn't give us any of those

benefits and comes with even more

negatives. It just kind of sucks. Like I

think we can all agree with this. The

hard part of one of these like product

specs isn't even writing it. Writing one

of those things is not that hard.

[ __ ] forcing yourself to sit and read

it is the worst thing in the world. And

I don't know if this is my ADHD

speaking. Correct me if I'm wrong, chat,

but just sitting there and reading

through these specs is the worst thing

ever. It's so much worse than code

review, or more importantly, so much

worse than just coding yourself. And I

would way rather be building prototypes

and demos and testing these things

myself than I would be sitting there

reading a spec trying to keep myself

from losing interest in order to find

the actual problems in it. Personally,

the things I do like fit into that

general mindset. I like code. I like

conversations. I like playing with new

ideas and solutions. And personally, I

like deprecating things that don't work.

Also simplifying where I can. These are

all things that I do like doing. And

here are things that I don't like. code

reviewing, reading long specs,

convincing a PM to end a project that

they've been planning for 8 to 12 months,

months,

sitting in meetings with 10 plus people

where nobody is paying attention because

it's boring as hell. I hate these

things. Okay, I actually do kind of like

code review. I need to I I say it's

important to like code review. No one

really loves it, but it is an important

process and I owe my team so many

reviews now that it makes me literally

sick. But yeah, the point being here, if

the tools you're introducing make it

easier for people to spend their time

doing this part and harder to spend

their time doing this part, then your

tools [ __ ] suck. So look at something

like hero, which is AWS's AI coding IDE.

It makes it so I don't have to code as

much. Makes it so I don't talk with

other people as much because I'm just in

my editor waiting for things to finish.

It doesn't make it easier to play with

new ideas because everything has to be

baked into those giant markdown files

that it generates. It doesn't

necessarily make deprecating things

easier or harder. It's kind of a noop

there, but you have no incentive to

remove things or simplify. You just let

it do the work. So, it takes away the

incentives for these bottom parts and it

doesn't let you do the top parts

anymore. It's replacing these. What

about the things I don't like? It means

I have to review way more code. It means

I have to spend half my time in my

editor reading specs. I go to my editor

to escape reading specs. Why are you

making it my job? It doesn't help with

convincing PMs to end projects because

now they're convinced they can go build

it themselves using this. Or when I tell

them it's a bad idea, they're like, why

don't you go use Curo and whip it up and

then we'll see how you feel about it.

And now that I'm not spending my time

coding, we have so much more time to sit

in these useless meetings with a bunch

of people. Yeah, that's the problem I

have is a lot of these tools take away

the parts that we actually enjoy, the

things that we can actually have fun

doing, and potentially improve the

product while we do, and replaces it

with more of the things that we don't

actually enjoy. And not in a way that

makes us more productive, just in a way

that is shifting of the effort. We've

replaced writing code in our editor by

hand with reviewing the code. We've

replaced making prototypes with letting

AI write this giant spec for us. That's

not a good trade. And if we want to

benefit from these tools, we have to go

all the way back up here and rethink our

process. Old process doesn't work well

with these new tools. It effectively

just kills the fun parts and makes the

shitty parts way easier to generate way

too much text for. But I saw this chart

forever ago. I don't feel like finding

it right now, so I'm not going to. But

the chart was like a hilarious curve

that had a couple points on it of like

points in time where the length of the

average law was relatively short if you

just counted by words and then over time

it started to spike pretty meaningfully

and then suddenly spiked again. And then

it spiked way harder recently. And these

spike points were things that will make

a lot of sense. The first one was the

introduction of the typewriter. Suddenly

law started getting way longer really

fast. Then we had the word processor

where you could copy and paste. There

was a time before copy and paste or law

and I don't even want to think about

doing that job. But then what we have

now with AI generation has made the laws

skyrocketing in length because once you

make something way easier to do, we end

up with way more of it. But if the

problem wasn't the amount of the thing,

it was the quality of the thing, this is

bad. The problem with laws in the US or

wherever else is not that there aren't

enough words in the law. I hope we can

all agree that more words does not make

a better law. I know we can similarly

agree that more code does not equal

better apps. If anything, I would argue

this often means the opposite. There's

an inverse correlation here. And these

new technologies made the wrong part

easier. They made writing lots of words

easier, but they didn't make writing

good legislation easier. And the result

is that it is harder to ship good

legislation because now you have to

parse through way more words of [ __ ]

before you can get to the point. And if

that's where we end up with AI code, we

are [ __ ] If it's literally just like

if our job is now just code reviewing

gigantic piles of slop that don't follow

patterns or practices because some other

random person told us to go generate the

[ __ ] That's going to suck. So we need

to rethink our process if we want to

benefit from these things. We end up in

a situation where code is more

straightforward to produce but more

complex to verify which doesn't

necessarily make teams move faster

overall. Absolutely. It would probably

make us move slower. The review process,

the spec process, all of that would be

slower if we had more code to deal with

throughout it. Not a new challenge.

Developers have long joked about

copypaste engineering, but the velocity

and scale that LM enable have amplified

those copypaste habits. Absolutely

agree. You could argue that all LLMs and

backard agents and this stuff is is

Google searching stack overflow and copy

pasting code on steroids. Understanding

code is still the hard part. The biggest

cost is understanding it, not writing

it. Absolutely agree. LMS reduce the

time it takes to produce code, but they

haven't changed the amount of effort

required to reason about behavior,

identify subtle bugs, or ensure

long-term maintainability. that work can

be even more challenging when reviewers

struggle to distinguish between

generated and handwritten code or

understand why a particular solution was

chosen. Absolutely agree. And to again

emphasize the points that I was making

before, it almost feels like there's two

types of code where we have throwaway

code and we have production code. The

goal here being on the left you have

things that your goal is to figure out

what the product is or whether or not

the thing can work and you don't care if

it all goes away and the right is code

that is expected to be maintained for a

long time and keep doing the thing it's

supposed to do for even longer.

Throwaway code this is stuff like my

shitty scripts for benchmarks or stuff

like sandboxes or prototypes for some

new feature. Whereas the production code

side is core infra for main product or

rust library powering millions of apps

or new feature being built by 12 devs.

The problem was that up until recently

the cost difference between these two

things was not that big. It seems

obvious now that like things on the left

are very easy to build and things on the

right aren't. But we're still fresh off

an era where people were sincerely

saying that we should write everything

in Rust, even small side projects,

because people were so unable to

perceive the gap between these two types

of code. The thing that made me special

was that I was good at distinguishing

between the two, knowing when it was

best to just write throwaway code,

writing this part really fast, and then

figuring out what subset of it should be

productionized to go to the other side.

I would rapidly rotate between these two

sides with projects that I was working

on. I would make a demo on the throwaway

code side. We would iterate with users,

figure out what features they actually

want. I would then go build a more

production version and then I would run

into some weird tech problem with it and

I would go back to prototype different

tech implementations. I wasn't using

code exclusively as a thing that's put

up on GitHub for someone else to approve

and then ship to users. I was using code

for a lot of other things, too. I would

use it for figuring out what to build. I

would use it for testing out different

tech implementations. I would use it for

processing my emails to figure out which

reports we were getting more often. I

would use it for all sorts of things

where the code itself didn't matter and

I didn't want anyone to review it

because that wasn't the point. If there

was something worth reviewing in the

code on the side, I would copy paste it

out, put it in a real PR or in a gist

somewhere and send it to my team to look

at. But this distinction wasn't one that

many engineers could or would make

because most engineers write code the

same way regardless of what they're

doing. I can't tell you how many side

projects I've seen by people who work at

fang companies. And these fang interns

working on side projects are spinning up

the equivalent of like Facebook or

Netflix's stack for their personal to-do

list. And people's inability to

distinguish between these and find

patterns that work for different parts

and learn things from each side is a

very real problem. And as a result,

these AI tools are going to confuse a

lot of people because if you're looking

at something like lovable, but you see

throwaway code and production code is

like the same thing and you write these

the same way and lovable to be frank

falls under the throwaway code side as

most of these agent code tools do. If

that's where this is built to do things,

but you don't meaningfully distinguish

these two in your head, you see this is

bad and this is good, not as different

values for different purposes. Now you

see this as a shitty useless tool. But

if you think about this as a way to make

your production code simpler and better

because you don't have to prototype the

same way that you write the real thing,

you start benefiting a lot from these

same tools. That's the thing I want to

really emphasize here is if you took the

code that you write in something like

lovable or even the code that I write

when I'm during this prototype stage and

you throw it at your team to review,

they're going to hate you because that

code wasn't meant to be reviewed. That

code wasn't meant to be read. That code

was meant to figure out something. This

code is meant to be maintained. This

code is meant to solve a problem,

usually a knowledge gap. Teams still

rely on trust and shared context.

Absolutely. Software engineering has

always been collaborative. It depends on

shared understanding, alignment, and

mentoring. However, when code is

generated faster than can be discussed

or reviewed, teams risk falling into a

mode where quality is assumed rather

than insured. That creates stress on

reviewers and mentors, potentially

slowing things down in more subtle ways.

Absolutely agree here as well. If by the

time your mentee is caught up on the

codebase, half the shit's changed

because something filed a PR destroying

all the stuff that was there before,

good luck. If you don't have the right

mindset to mentor this person because

you think you can just go AI generate

the work that they're going to take

longer to do anyways, you're [ __ ] If

you let them go AI generate something

and it looks just like the code you

normally AI generate, so you hit merge,

but it doesn't actually work, you're

[ __ ] These problems happen if we

don't distinguish between throwaway and

production code. And the final point in

this article, LM are powerful, but they

don't fix the fundamentals. There's real

value in faster prototyping,

scaffolding, and automation. Oh, look at

that. We agree fully right at the end. I

had a feeling. But yeah, this is the

thing that I'm excited about is

previously most devs weren't capable of

doing the throwaway version much faster.

Like I honestly believe if you would ask

the people on some of my teams at

Twitch, if they were to just make this

to see if the feature worked and the

production ready version was going to

take nine months and you ask them how

fast can you do a demo version for us to

play with, they would say probably 2 to

3 months. You can do it in 2 to 3 days.

There are very very few products that

you can't build a usable version of in a

few days unless they're like deep tech

bets, but that's not the case for your

[ __ ] crud app. Stop pretending. If

you honestly think the best you can trim

your production process is from many

months to a few months, then get out of

the way of the people who can do it

faster so they can figure out what you

should build. If it takes you that long

to build anything, then don't build

things that are uncertain. If it takes

you 6 months to build a prototype,

you're not building prototypes. You

shouldn't be calling them that because

you're going to feel so bad throwing

that 6 months of work away. If I spend

two weeks making a demo version or three

days making a demo version and we throw

the whole thing away, I don't give a

[ __ ] That's the point. We still learned

the lesson. As the author says, the LMS

don't remove the need for clear

thinking, careful review, and thoughtful

design. That can be your problem after

we figure out what to build. It's not

going to replace those parts. But if you

can't acknowledge the gap here, then you

just sound dumb because this is the

problem that I see a lot of is somebody

whose life is on this production code

side. So, some principal engineer. Let's

say some exec or some PM goes to this

principal engineer. I'll just make a

fake Slack thread down here. CEO. Hey,

at principal, think we could use lovable

to test out new ideas? Could be useful

so we stop building bad features. Lol.

Principle. Seriously at CEO, you think

some vibe coding BS is better than your

bestin-class edge team? Do I have to

remind you that I'm Azure certified?

That we just took a great class on agile

last week. What more do you want? This

is the problem because this CEO or even

they're not a CEO. Let's say they're

just like some random PM says this and

that product manager really wants to

figure out what features are good or bad

ideas earlier because they were tired of

wasting so much time doing random

[ __ ] But as sarcastic as I made

this look, this is a very real thing. It

would probably look more like this. I

don't think we can get meaningful info

from something that took less than 3

months to build. Lovables for non-devs

making personal apps, not for real work.

I could absolutely like I've seen

messages like this from PMs and if you

don't think this really happens, watch

this. Could have changed the word

lovable to something a bit different.

Electron or React or JavaScript or

Superbase or Convex or any of the

technologies that we like to talk about

here, you'll realize this is a very real

message people like this send all the

time. And the fact that lovable is one

of those things shows what I mean. The

point here is that the principal

engineer is so unable to think outside

of their perspective because to them the

meaningful info isn't is the product

useful. What they mean by this point

here is much different. What they mean

is meaningful info about does the tech

spec work. They assume the product

already works. They don't hear the PM

for where they're at. All they can think

about is whether or not they can figure

out how to build the thing through

building the thing. and lovable is not

going to give them any unique insights

on how to engineer the thing. So,

they're going to ignore that path and

that possibility entirely, but the PM is

going to see other people building

useful stuff with it. They're going to

realize that the problems that they want

to solve can absolutely be solved with

these tools. They're going to build a

deep frustration because they're talking

past each other. And that's how you end

up with these adversarial relationships.

I legitimately believe that these types

of conversations are going to start

happening a lot and that the PMs and the

principles are going to start fighting a

ton because these guys just cannot see

the value of a prototype and these guys

don't understand that all the principal

engineers thinking about here is the

technical details not whether or not the

features worth building or not in the

first place. One of the coolest moments

I had at Twitch was when my designer

started hitting me up with random

questions about HTML and JavaScript

stuff. And I was really confused because

none of that had to do with her role and

it was not questions about things that

we used at Twitch. So I just asked her

what she was working on. She sent me the

screenshot and it turned out she was

trying to build a prototype version of

Mod View and it was really compelling in

terms of how it looked, but nothing

worked in it at all. It wasn't even

using real data. It was meant to be a a

demo demo like just showing what this

could be. So she could put that in front

of moderators and ask how this looked to

them, how useful this would be to them.

Someone like that, like Iris, one of the

best designers I've ever worked with,

would benefit so much from these tools.

Not because she'll be filing a whole

bunch of PRs, but because she could

figure out in a much more iterative

process what the right thing is. This is

the big thing I want to drive home.

Improving time to next realization is a

very good thing. We should be optimizing

for insights. How quick can you go from

an assumption to a new learning? If I

have an assumption that users want a

thing, what's the shortest path to

figure out if they do or not? If I think

this button should work this way, what's

the shortest path to figure out if it

should or not? How quickly can we get to

the next learning, the next insight, the

next understanding, the next moment

where we understand something we didn't

before? And if we can use these tools to

get more insights, to have more aha

moments as we figure out [ __ ] they're

useful. But if we use them to speedrun

through the process without getting any

insight throughout, this sucks. And I

don't think a lot of these tools are

being pitched this way. I think these

tools are being pitched as developers

are slow. Replace them and make it

faster. And not we can figure out what

our users want faster. We can iterate

more effectively. We can make tighter

iteration loops and get more feedback

faster. That's the magic of this. The

cost of writing code has indeed dropped,

but the cost of making sense of it

together as a team has not. That's still

the bottleneck. Let's not pretend it

isn't. I absolutely agree. Team

understanding is a massive bottleneck

for most things. The additional point I

would drive home here is this. If you

have a giant spec, just we'll say this

rectangle is the spec. And this was

built primarily by the product lead, the

design lead, and some tech lead coming

up with all the pieces that are going to

be in here. Generously speaking, maybe

this much of it, like maybe is actually

good and correct. And then the rest,

whatever is left in this box here, that

all is garbage that needs to be thrown

away. I would argue that the ratio here

is often quite a bit worse. I can't tell

you how many times I would read the

spec, the whole team would be bought

into the spec and then the thing we

shipped looked nothing like the spec

because the spec was bad and had a lot

of bad assumptions in it. What if

instead of the spec, we have the

prototype and instead of it being this

giant thing, the prototype

is this small thing and maybe the ratio

is way worse. Maybe the prototype is

more bad than good. But we get some good

insights here. Maybe the whole prototype

is bad and now we have the insight this

idea was bad in the first place. It

takes a lot less time to do this part to

build this thing. And if we build this

thing, which is way simpler, the

communication gets easier, too, because

it's way easier for two to three people

to communicate about a small prototype

than it is for 20 plus people to talk

about this giant spec. And the

likelihood that you learn things and

catch things is significantly higher

when you start this way. Maybe you have

a second prototype after that takes

these good parts and extends them. And

now you have more good parts and you

make something slightly bigger, but it

also has more bad parts. And you make

another prototype where the good parts

are even smaller because you had some

bad assumption and you got screwed over

and now you have a ton of bad parts. But

the bad parts are good because you just

learned a bunch of lessons. Now all of

these bad parts can be thrown away

forever and never done again. And now

the next version ends up being twice as

big, significantly better, and it still

has some rough edges, but you know

exactly what those are. And you learned

a bunch of lessons not long ago that are

applicable here. You can trim those off

and it turns out the product you're

building is way smaller than that other

spec might have suggested. And as people

in chat are saying, this also makes the

job way more fun. It's not fun to be

slaving away at [ __ ] Jira tickets. I

don't believe you if you say it is. It's

so much more fun to be trying new

things, playing with new solutions,

iterating with a team of people, trying

to solve real problems. It's so much

more fun. And these tools make it so

that doing each of these steps is way

cheaper than it used to be. If it took a

team three months to build this and nine

months to build this, I would understand

the hesitation. But if it takes 20 devs

9 months to build this, but it takes one

dev 3 days to build this, you are really

stupid if you're still building this way

initially when you don't actually know

if the product is needed or not. Really

dumb. And that's why I am excited about

these AI tools. The way I kind of think

about it is suddenly way more teams have

their theo that can get this prototype

out way faster, iterate heavily on it to

find the real thing you want to solve

and then kick it off to the traditional

product lead PM principal engineer

people to spec out and do the right way.

But if we have way less pieces as we get

there, we can communicate way better

throughout it and everyone has a much

better understanding. Three people

trying to understand this will always be

a better experience than 20 to 30 people

trying to understand this. Think that's

pretty obvious. Huge shout out to Pedro

for writing this article. It was

absolutely awesome and inspired what's

been one of my favorite rants in a

minute. So, thank you for putting this

out. Appreciate you a ton as well as the

permission to react to this. This was

great. Give his blog a look if you

haven't yet and give him a follow on

Twitter. Thank you all for watching this

rant. I had a lot of fun with this.

Clearly, I had some things to get off my

chest. I'm curious how y'all feel

though. Was this a good one? Was this

misguided? You think it being weird the

split between prototypes and more

traditional building for production? Let

Click on any text or timestamp to jump to that moment in the video

Most transcripts ready in under 5 seconds

One-Click Copy125+ LanguagesSearch ContentJump to Timestamps

Paste YouTube URL

Enter any YouTube video link to get the full transcript

Most transcripts ready in under 5 seconds

Get Our Chrome Extension

Get transcripts instantly without leaving YouTube. Install our Chrome extension for one-click access to any video's transcript directly on the watch page.

Add to Chrome — Free

Works with YouTube, Coursera, Udemy and more educational platforms

Get Instant Transcripts: Just Edit the Domain in Your Address Bar!

YouTube

←

→

↻

https://www.youtube.com/watch?v=UF8uR6Z6KLc

YoutubeToText

←

→

↻

https://youtubetotext.net/watch?v=UF8uR6Z6KLc

YouTube Transcript:You're using AI coding tools wrong

Video Transcript

Paste YouTube URL

Transcript Extraction Form

Get Our Chrome Extension

Get Instant Transcripts: Just Edit the Domain in Your Address Bar!

YouTube Transcript:
You're using AI coding tools wrong