Would you like to hear a controversial,

yet brave take in the 2026 year of our

Lord?

I read the code. Yes, that, my friends,

is now officially controversial. Now,

you're probably wondering, how is that

controversial? Well, it all started with

this nice little tweet here by Mitchell

Hashimoto, just expounding upon, "Hey,

what's going on with Fable?" A random

bot account said, "What metrics are you

using to measure success of this

approach?" I read the code. And this

right here got 800,000 views, just

saying, "I read the code." And then a

lot of people started chiming in saying

how much they also can see why reading

the code is actually a good thing,

except for Burke right here. Hey, Burke,

I actually appreciate that response.

Honestly, out of all the responses of I

don't read the code,

based. So, I figured I'm going to have

to open up a Yapp request on this one,

because we have to We just have to talk

about this, okay? There's no stopping

There's no stopping the words coming out

of my mouth at this point. And so, I

would actually like to maybe add a bit

more color to this talk, because here's

the problems that I just generally see

with the internet. First off, there's

just a bunch of bad engineers on the on

the internet. And they can say whatever

they would like to say, and this kind of

adds fuel to the fire of this entire

discussion. You know this. You've worked

at a job Well, most of you've worked at

a job. And you guys have seen teammates

and co-workers, and you're like, "How

are you employed? What is go" And yet,

these are the people also giving great

advice on Twitter. Second, there's

always people selling something, right?

They're always selling you something,

and this is that entire crowd that

exists. And third, there's always this

compiler argument that people make on

the internet. I don't know what it is

about. Stop, please, for the love of all

things good and holy. Stop comparing an

AI to a compiler, okay? This It's just

It's just a bad comparison. We can just

move on, okay? No need to expound upon

that. It's just bad. It has been bad. It

will continue to be bad. All right, but

I am actually going to give you what I

consider my framework for should you

read the code? Yes, I cannot believe I'm

saying these phrase I can't believe I'm

saying this, but hey, we're going to say

it anyways and we're going to actually

I'm going to actually going to give you

what I think is actually really good

spot-on advice. I'm going to give it to

you in three different ways, but before

I give it to you, babe, I would like to

say a quick thank you to the sponsors.

Don't read the code. I've personally

conducted hundreds of interviews and I

know how hard hiring is and that's not

even with today's problems of fake AI

profiles, resumes that are difficult to

read, and senior engineers who have

never even read code. G2I fixes that.

Not the reading code part, the hiring

part. G2I can help you hire front-end,

back-end, and even AI engineers

because they have pre-vetted 8,000 plus

engineers through real technical

interviews, so you can review quality

candidates in days, not months. Check

out g2i.co/prime

and take the headache out of hiring. Or

just read the code. So, I'm going to

give you my thoughts on this whole read

the code, don't read the code argument

and where I think everybody's

effectively wrong. I think the answer is

just significantly more complex than

that. And so, I'm going to give you kind

of three different examples or three

different ways in which I approach a

problem that kind of change the varying

degrees in which I'm going to read the

code. I think the third one is the most

interesting one because it's probably

the one that I think most people are

going to start falling into over the

course of the next year. But let's just

start with the first one, the don't read

the code ever. I do think that there's

actually just an entire set of projects

and things you should be doing where you

just don't read the code. The whole

purpose of it is MVP exploration. Now,

there's this thing that I used to get to

do at my job back in the day before all

of this AI crap kind of came out is you

used to get to put on some headphones,

throw on the Lord of the Rings and the

soundtrack and then just program for

like 16 hours straight cuz your goal was

to just create a nice little prototype

of some new things so everyone can come

together and kind of discuss how does it

feel? Is this the right direction? Is

this what we want to see? And that

experience was quite magical. You'd end

up building it, you throw it all away,

and you do a bunch of learnings. And for

the unlucky souls, you would build it,

they would do your bosses would say,

"SHIP THAT STRAIGHT TO PRODUCTION." And

that's what you would be now using for

the next year and trying to fix. So,

something I've been really kind of

playing around with the idea of is

actually getting an agent and the linear

MCP and saying, "Okay, let's discuss all

the things I kind of want to build."

Having it all go and be made as tickets

on linear and then just saying, "Hey,

loop and make all of that for me." I'll

come back in 12 hours and boom, the

thing is done. And I can try out my

idea. Was this a good idea? Like, I

don't even have to use expensive models

for this to work. I'm just there to see

does the idea actually work? Can it feel

good? I'm not going to keep any of the

code. Lord, no. I'm going to just simply

use it as a way to test out new ideas

and new ways to approach this. I've been

kind of starting to toy with this with

my game development. I go, "Okay, I

really want to try out this kind of

different way of doing things." Hey, I'm

going to kind of specify a bunch of

stuff, create 15 linear tickets, loop

And then just come back later and just

see how it feels. Now, I think this is

an excellent case for don't read the

code. I don't care what the code is cuz

I'm throwing it away. This is purely for

feels and for good times, right? I if it

does feel really good and I want to

proceed with it, I might just take a

peek at the code, see, "Hey, how did you

accomplish this?" If there's anything I

can like or glean from it, I will take

it. But generally speaking, I RMRF that

crap as fast as possible. I also think

there's just this second category of

just internal tools that need to be

created. No one's going to create them.

You just need to get them out there

because they're going to make

everybody's life a lot easier and

they're going to be fantastic to use.

And so, just it doesn't matter the

quality. It is about the perceivable

value of them. At some point, you may

need to go in there and you may need to

start reading the code. But to kind of

get the idea out there to see if it

actually really makes people's lives

better. Again, this is kind of prototype

MVP phase. I think it's just so

important. All right, so the second kind

of category of read the code, if we

will, if it's a spectrum, is just read

every single line. Now, me personally,

been developing a sweet little video

game. Here's the sweet little video game

right here. Yeah, I made all those

animations. I made the card draw. I made

all these kind of things. They're

absolutely fantastic. Made these little

boop. Put it in there. Do this. Faster

turns. Right now, I don't really care

about the speed, how it looks. Right

now, I look this the arrow's even

sideways cuz I have the rotation off by

90°. I don't currently really care about

that because right now my goal is to

make this game. The process of making

this game, the process of going through

everything is part of the entire quest,

right? I want to be able to create this

and love this, not just externally, but

also internally. I want this to be the

best thing I've ever created. And so, I

actually care about this a whole bunch.

And there's a different kind of style of

development I would like to take about

the things I really care about and I

really want to be exactly the way I

want. Because the more I were to

introduce a vibe coding into this

situation, there's things I couldn't

control like exactly how does this feel?

I don't know if I could control that

nearly as well if I didn't if I didn't

have the full kind of programming

ability where I understood and knew

everything that was happening on here. I

know exactly how this highlight works. I

know exactly how this drag works. I know

exactly how that shrink works. I know

exactly how that placement works, how

the upgrades are calculated, how

everything flows through the system. And

so, this is a very special kind of

project to me. And there's also just

tons of great software out there that's

making tons and tons of money where

people just do this. I don't think this

is really an argument for or against

software being made by hands or by

agents. It's more that this is just what

I care about deeply. I do think that

this realm of programming is shrinking.

Like the in in all honesty, I think that

the amount of times you need to be

perfectly concerned about every single

line of code is just fundamentally going

down. But for this particular project, I

want to be concerned about every line of

code. I actually do want to be engaged

in how it looks, how it feels, just

exactly every last part of it. And since

I want to be that engaged, I feel like

the only way to be that engaged is also

to be engaged on the line count and

exactly what is being produced for

everything as well, for better or for

worse. All right, so the third category,

the one that I actually think is much

much more interesting on this whole read

the code debate, is is there a halfway

ground? Is there some sort of in between

of like I don't read code and I read

code. Obviously, there is some sort of

level, but what does that actually look

like? Well, if you look at this thing

right here, what you will see right here

is a program that I have created. It

actually plays that same game in which

you just saw, but it plays it in a

headless mode, so I can actually see an

AI play my game. Right now, you can see

exactly what's in my hand, you can see

my towers, how much ammo each one of the

towers have left, the upgrades that are

on the towers, the in-game upgrades that

happen to each tower. You can see

everything about it. Pretty kind of

cool, right? This is being completely

played by composer 25 fast. I don't It

just goes and it runs and it plays the

whole game. So, that thing that you just

saw there, the actual runner itself, I

kind of have what I would consider a

unique way to approach this. So, the

first thing I do is I go and like I

build the components, right? So, I'm

like, "Hey, okay, this is how I want you

to run cursor. This is how I want you to

run the agents. This is what it looks

like. This is what the interface should

look like. I should be able to call dot

prompt on it, and I want to be able to

pass in these things. This is the exact

shape I expect." It goes off and it

builds it. I go and kind of test it and

okay, yes, that's exactly it. Next, for

this particular thing, I built the

client server, right? It's the client

server interaction, and I want to be

able to add certain methods to it so I

can call calls onto the server that will

then route them into my game and be able

to run. Like, I want to be able to start

a new game. I want to be able to end a

game by by ID. I want to be able to go

and move a mouse by certain game IDs. I

want to be able to have 10 games running

at the same time with 10 agents all

running the games at the same time. So,

after I take the time and think really

hard about the API APIs I need for each

one of the parts, the thing I do is I

actually handwrite the actual piece of

like integration logic. So, for this

one, this is the run loop that actually

goes, "Okay, if I'm in my title screen,

character selection, or victory, or

defeat, I want to kick off the starter."

The starter is this starter contents

persona, and the starter MD is just

something all it does is like, "Hey,

your only goal is to go in and figure

out how to get from the defeat screen or

the victory screen back into game mode."

Like, that's it. If you're in the title

screen, get to game mode. If you're in

the character select, select blacksmith.

That is it. Go to the game mode. And so,

this is by the way, this is what they

call building a harness, blah blah blah,

but I didn't write this mode function

right here. I know what it does. I set

up the interface for it. I wanted this

exact interface. I made sure it's doing

all the right calls. I make sure that

start actually starts a Mordoria game in

the background. I make sure that end

ends the exact, you know, item that I

want to make sure it's ending. It's not

just ending some random game. But,

nonetheless, this whole idea of being

able to be like, "Okay, here's all the

pieces I want. I will do the integration

programming. I'll actually do the

application programming, whereas you do

all the rest of the stuff." I found this

to be very, very nice because I didn't

write starter. I said, "Hey, make it

like a top-level thing and read a file

sync and do all that." And if you look

through exactly what it does, it jumps

in here, and somewhere along the way it

does a whole reading of the values, does

everything, puts all that crap together.

I don't care how it got there. I just

care that it got the prompt at the end

of the day. That's it. That's all I

wanted. And then for me, it's like, I'm

the one going, "Okay, here, this is what

I'm going to do in this mode. This is

what I'm going to do in this mode. If I

encounter a mode I don't know how to

handle, I want to intentionally print

that out and throw an error. And then I

want to kill the server at the end. I

want the whole thing to die, and I want

the game underneath it to die." And so,

for me, this is like this third approach

that I actually think is going to be

much, much more popular over the next

year, effectively. Is that you really

are starting to design on the interface

{slash} the function level. The function

contents themselves you care less about,

but at the function level, at the type

level, you're like, "This is what I want

to see. Now move quickly." Now, this

works really, really well if you have a

couple pieces. First off, you have to

know how to build things, right? I think

if you don't know how to build things, I

think this is really hard. You don't

even know what the right interfaces are,

let alone you don't know how to actually

like iteratively build it with an agent.

Hey, build this command to be able to

run stuff from the command line. Okay, I

want to take that. Okay, this is how I

want the server to look. Okay, this is

how I want each endpoint to look, right?

Like you don't have how you would

normally build it already built into

your head, so how are you going to get

the, you know, the client or the agent

to be able to respond properly. But

second, more importantly, I think that

this approach, it really allows you to

kind of flex all of that knowledge and

move quick enough to where you get a lot

of the benefits of the agents and being

able to move really fast, where the

parts that you're actually concerned

about, you can really kind of just dial

it and go, "Okay, these are the things I

really want to have happen. I want this

and I want this and I want this, and I'm

going to have this nice compact 50, 100

lines of code that are just mine, and

the rest of it, the 1,000, 2,000 uh

lines of code that is just like getting

everything set up so that the actual

thing works, uh out of my hands now. So,

I think that most of the ideas about

read the code suck. Okay, I think you're

going to go on the internet, you're

going to read a bunch of people's

tweets, and they're all going to come

down to, "You should never read it." or,

"You should read it 100% of the times."

And I think there's just a much more

kind of gray answer to this whole thing.

I will keep on reading more Dory source

code line by line, and I'll be hand

editing a good portion of it always and

making sure that it always stays at the

exact level I want it to be, because it

is my game, the way I want it to be. I

want every last feel of the game to be

exactly the way I feel like want it to

feel in the exact polish I want it. I

want to be able to control that. Now,

there's a whole set of programs where

that concern is much more fluid, if you

will. Yeah, that looks about right. Yes,

this is okay. And that I can move

faster. And then there's some programs I

don't care at all, right? I can just

vibe I just want them to work once, or

maybe I just want to work this one

little simple kind of reproducible

script to just run whenever I need it to

run. I don't really care how it looks, I

just want it to work. And so, please,

for the love of all things good, don't

compare AI output it to a compiler. Stop

saying you should always do one or the

other, and just also have a little bit

of fun, okay? If you're a person that

just refuses to ever use an LLM because

you think that it writes terrible code,

just buy code something for once. It's

kind of fun. You'll go, "Oh, yeah,

that's pretty cool. That was pretty

nice." But don't do anything too

serious, you'll drive yourself nuts,

right? Like you just got to know your

weaknesses and strengths. It's pretty

easy. And then you can actually have a

much better time because I think we live

in such a wonderful and beautiful part

of the world ever in the sense that

everything that is up here, you can now

manifest onto a computer. Like that is

so cool, and it's never been easier.

Every single year that bar for

manifesting goes significantly down.

This ain't the '90s anymore. We don't

even have Most of you don't even think

about memory allocations. When was the

last time you thought about the stack,

bucko? When was the last time you

managed some memory? I don't think you

have. I think you just live with a

garbage collector. You slob. Honestly,

garbage collector's pretty great, also.

Can I just say that for a second? The

thing is is this kind of argument always

makes me a bit sad because it's just a

bunch of people who had something that

worked for them in some particular

situation, and then they prescribe for

everybody else this exact same approach

when not all software is the same. Like

the software I want NASA to write should

look nothing like the software I want

some random web web crud app, right?

Like these should have vastly different

experiences, and I'm okay with that, and

you should be too. The name

is the primogen.