We all fell for it…

AI code is here and it's here to stay.

Who hasn't seen the productivity gains?

We're talking CEOs of companies doing

37,000 lines of code every single day. I

mean, what else is there to our lives as

developers? If we can put out that much

code, why would we do anything else?

This totally isn't going to come back to

bite our asses, right? It's not like

we're going to lose all our skills as we

rely on the slot machine more and more,

and as a result, the slot machine

becomes a slot machine and nothing ever

works how it's supposed to. This

definitely isn't currently happening and

people definitely aren't starting to

notice, right? Oh, Aenta coding is a

trap. This sounds like it's going to be

a very, very fun article. I have a lot

of thoughts here, as you guys can guess.

On one hand, I love coding. I love

building things. I care about the

nitty-gritty of syntax. I've built

entire stacks around my specific tech

preferences that have went so viral that

they helped build my entire career on

platforms like this. On the other hand,

I very much enjoy these AI coding tools.

So much so that they've fundamentally

changed how I think about tech and the

things that I build. And I've never

spent less time actually writing code.

In fact, if I open up my code editor

right now, I'm not even looking at code

in it. I'm looking at a prompt file and

then a bunch of CSVs for the data for

all of the runs that I'm currently doing

with agents. I'm barely looking at code

anymore. There are things I'm doing more

of, which is cool. Like I've never

gotten so good at git in my life. I've

never used SSH and remote boxes as much

as I do now. I'm trying out all sorts of

new things. I am learning all sorts of

new technologies, but I also feel some

of my skills atrophying and I find

myself when something doesn't work just

rolling the slots again and again hoping

that this time might be the one where I

get the output I'm looking for. Pulling

that lever costs a lot of money. You

never know what you're going to get, but

at the very least, you know what you're

going to get in our sponsor break is a

really cool company like this one. Are

you the type that pays attention to what

tool calls your agents make? Cuz I am.

And I've noticed that there's one thing

they tend to do a lot. Curl. The

frequency at which I see my agents

making curl calls to get information

about web pages, documentation, and more

is honestly kind of funny, especially

because of the frequency at which it

fails. Because it turns out a lot of the

web doesn't respond with the real

contents when you hit it via curl.

Whether it's an empty HTML page that

requires JavaScript to populate the

content or something that's hidden

behind a capture or a firewall or some

off layer of some form, there's a good

chance your agents are going to struggle

if they're relying on doing curl

exclusively. It'd be really nice if you

could just wrap your curl request in

some way where it won't fail on those uh

oh, it's on the screen already, isn't

it? Yeah. Today's sponsor is browser

base and they just added a new fetch

feature that makes it easier than ever

to get the real content from any

website. If you want it as HTML, JSON,

or even markdown, they'll handle it all

for you. Instead of curling the site you

want directly, you make a post request

to the API.base.com/fetch

endpoint. You pass it the body with the

URL you want, and then all it needs is

an API key, and it will now be able to

scan that site reliably for you and get

you what you want. On the pages that

require JavaScript to run, they have you

handled, too, because Browserbase can

spin up real browsers in the cloud.

That's why they exist. That's how they

got their whole name. They provide real

browsers for your agents to do real

things on the web. Whether it's clicking

buttons, signing in, getting

information, running JavaScript, and

more, they have you covered. Going to be

real with you guys though, there were

some use cases a cloud browser wasn't

great for, like search. Oh, is it on the

screen again? I need to stop doing that.

The search stuff is really cool, too.

Adding a real way for your agents to do

search and get the context they need to

unblock themselves is incredible, and

that's why so many companies rely on

them for it. So if your agents need

better searching, better fetching,

better curling, or just better access to

the web through a real browser, look no

further than soy. Browserbase. Back to

where we were. Agentic coding is a trap

written by Lars Fay. I'm actually really

excited about this one. Multiple people

who I trust sent this to me to take a

look at. I haven't read it yet, so we

get to go through this together and

hopefully we'll have interesting things

to add. Remaining vigilant about

cognitive debt and atrophy. Interesting

that the angle here is cognitive debt

and not technical debt. I already have a

feeling I'm going to like this a lot

because I've personally found tech debt

is actually one of the coolest things to

deal with with AI. It's actually kind of

amazing how willing models are to go

after tedious tasks like making a new

lint rule work across your whole

codebase or updating a package that

broke the definitions for a thing that

occurs in 5,000 places. I have done

crazy work for tech debt in my life that

just required so much brute force and

manpower it wasn't worth it. Like I I

still vividly remember a time at Twitch

where we were doing a migration for our

GraphQL layer that broke I think it was

8,000 or so TypeScript files. So we took

all the ones that were now broken, put

them in a Google sheet and would assign

chunks to different engineers to go

through and manually update on the

shared branch to try and get everything

up to date. Like those are the types of

things we used to do by hand that often

would get left and the tech that would

just sit there because the process of

fixing it was too much manpower to be

worth it. AI is phenomenal at those

things. So whenever I see the like AI

causes tech debt argument, I get

frustrated because it also solves a lot

of the same tech debt that it can

potentially cause. But cognitive debt is

a much much more interesting idea. So

let's see what Lars has to say. Starts

with a quote. AI does the coding and the

human in the loop is the orchestrator.

This is the sentiment being hyped up

around the industry currently.

Traditional coding is all but dead.

Inspect driven development is the

future. Okay, I really think we're going

to agree if he's talking [ __ ] on STD

already and we barely started. Oh boy.

You generate a plan and disconnect from

writing any code. The agents know better

and handle all the implementation. You

are there as the expert to provide good

taste, review the outputs, and

constantly steer the agents to execute

the plan that you meticulously put

together. How meticulous are you guys

writing these plans out to be? Cuz I I

don't believe you. I don't believe any

of you are actually putting that much

effort into the plans if you're not

watching the agent when it runs after.

Yeah, there's there's another angle I

could talk about with the expert thing

here. I'm not going to go into it yet

cuz I want to read a bit more first, but

I already have so many thoughts. The

workflow takes many shapes at this

point, but in general, it's a process

where someone defines the project's

requirements simultaneously at a micro

and a macro level. Very, very good call

out here. They generate a plan, and then

they pull the slot machine lever over

and over, iterating and reiterating with

often multiple agent instances until

it's done. All the while putting a

growing distance between the

orchestrator and the code that is

actually being generated and committed.

Coding agents are helpful and powerful,

but there's already some quantifiable

trade-offs that need to be discussed.

First, we have an increase in the

complexity of the surrounding system to

mitigate the increased ambiguity of AI's

non-determinism. Very real problem.

Second, we have the atrophying of skills

for a wide swath of the population. I'm

definitely starting to see this. Third,

we have vendor lockin for individuals

and entire teams. Cloud code outages

have already had entire teams at

standstills. Yep. and fluctuating and

increasing costs to access the tools. An

employees cost is fixed. Tokens are a

constantly moving target. Yeah, I do

think that the demand going up is

causing our brains to fall out a bit

with the costs increase. I don't think

long-term the cost for agentic work is

going to keep going up. The same way I

think people are going to do more with

AI and use more tokens, but the cost of

intelligence at a given level is

consistently going down. Flashbang

warning. I talk about this a lot with

the new GPT models because they are more

expensive per token. So if you're

measuring a given input and output that

are the same work between the old and

new models, 5.5 is 2x more expensive.

It's double the cost for input and

output tokens. But if you compare per

level of intelligence and the number of

tokens generated, things get much more

interesting. GBT55 is the highest

scoring model on artificial analysis. It

is at 60 points whereas the previous

generation with Opus 47, Gemini 31 Pro

and GBD54 were only at 57 points.

Meaningful improvement, but I'm going to

add something to this. GBT 5.5 low as

well as GPT 5.5 medium. And here's

what's super interesting. 55 medium

scores the same as 54x high. And 55 low

still scores very well, too. comparable

to Claude's sonnet 46. But when we go

back down to the cost efficiency, this

is the cost that artificial analysis

paid or would have paid if they weren't

comped to run their entire benchmark

suite. Opus 47 is the most expensive by

far at 5 grand, even though it's less

smart than 55. But remember, 55 medium

and 54x high are the same level of

intelligence. 54x high cost $2,800 to

run this bench. 55 medium cost under

1,200. So if that level of intelligence

was enough for you, your cost just got

cut in more than half. You're now at

less than 50% of the cost to do those

same tasks as you were at before. That

is a very, very meaningful change. Sure,

the best model in the world got slightly

more expensive, going from 2,800 to

3,300, but that same tier of

intelligence from before, the one that

came out 2 months ago that we were

totally happy with, is now less than

half the price. And if you're okay with

going a little bit dumber, not even much

dumber, just like sonnet levels, the

price drops all the way to $500. Another

having of the price. And this model 55

low is as smart as 46 sonnet max, which

is the second most expensive model at

$4,200. And this model came out very

recently as well. So again, if we look

at this based on the intelligence level

per dollar, the cost per IQ point here

has dropped by 8x in just a few months.

Sonnet 46 came out earlier this year,

$4,200 to run this benchmark, 51 points

on the bench. 55 Low, which I would

argue is a much smarter and nicer to

work with model. Same level of

intelligence and eighth the price. So, I

just wanted to jump on that because I

don't necessarily agree that the costs

are increasing in the sense that every

month if you do the same thing the

number goes up. It's that we are doing

more with tokens. So, the amount of

tokens we're using is going up, but

we're also finding ways to get more

intelligence per dollar. So, the cost

per task and the cost per level of

intelligence is going down. So, we need

to be realistic about those differences.

It doesn't mean that companies aren't

getting a little screwed here because

they hired a bunch of developers. They

pay their devs I don't know let's say

company pays their devs 5 mil a year

last year they paid 100k in cursor this

year they've already paid a half a mill

in cursor and they're only a few months

in that that is a legitimate cost that

they are eating that sucks so on the

bill it does look like prices are going

up but by the metrics on how things are

actually changing and improving much

less so we're just using the AI more

just want to jump on that cuz I agree

with almost all of the rest of this

being successful with this approach to

coding agents hinges on a rather crucial

element ment. Only a skilled developer

who's thinking critically and

comfortably operating at the

architectural level can spot the issues

in these thousands of lines of generated

code before they become a problem. Yet,

in an ironic twist of fate, it's the

individual's critical thinking skills

and cognitive clarity that AI tooling

has now been proven to impact

negatively. This is all around the term

cognitive debt, which is a really good

phrasing. Many relevant people like

Simon Willis and Martin Fowler are

describing the experience of cognitive

debt directly. They talk about getting

lost in their own projects and finding

it harder to confidently add new

features. They can move faster, but they

lose the deeper sense making that

connects decisions to intent and the

intent to the code. So, my hot take on

this is that if you weren't already

experiencing a bit of it, you weren't

shipping fast enough. I can't tell you

how many projects I had that I went

really hard on for a month, got to a

pretty good state, then had to go do

something else, came back to it, and had

no idea what the [ __ ] was going on

anymore. This is this is inherently the

way humans work when they're doing

enough different things. You can't keep

the details of all of the context of

stuff in your head. The problem is I

perceive it here is that more people

became theos because of AI. I used to

ship like five plus projects a year

before AI cuz I just loved building

things and putting them out there for

people. That took a lot of not like

expertise in the traditional sense, but

it was a just like the way I built, the

way I thought about things and how I

would cut project scope down to get a

deliverable, usable version as

efficiently as possible. Hell, this is

why I made the T3 stack. I wanted to be

easier to build things with confidence

rapidly that would work reliably without

having to fully understand all of the

pieces. I was kind of an early vibe

coder. Not because I was using AI to

write all my code, but because as soon

as it worked, I would move on to the

next thing and forget what the hell I

had just done. It was just like

willy-nilly deleting giant chunks of

code, writing code mods to update

thousands of things, hoping that it

worked and just checking if the build

came out correct in the end. I have been

slinging far too many lines of code for

my levels of expertise for my entire

career. And it's fun seeing everybody

else have the problems that I have had

for the better part of a decade now.

Specifically around remembering where

everything is in the codebase and having

confidence when you review code that

things are actually changing the right

way. I would also argue and many would

push back on it but I understand both

sides that my ability to do this was

novel and potentially exceptional. It no

longer is. The thing that made me

special on a team is that I could

unblock and make things move and hit

deadlines that didn't seem possible

before. I was a bargaining chip at my

job where my team would negotiate with

other teams to lend me to them to

unblock something that they were

complaining about so they would unblock

us on something we had to do. Very

common that I would be traded around to

make things move faster. Now you can

just prompt your way through it. The

issue is I had to work to get there. You

can argue whether or not I was an expert

and that's why I could do this. But you

can't argue that it was a novel thing

that I could do this. It was novel

enough that I was paid exceptionally

well and had a really good career

because I was able to jump between a lot

of things and I could deal with the

cognitive load and the cognitive

shifting going between all of these

different things. Now everyone is doing

it and most people aren't built for this

and it sucks. There's a separate problem

that combines with this though. The

reason I could do this is I deeply

understood the building blocks I used to

build in this way. I might not remember

exactly how I assembled the things, but

I knew the pieces I used to assemble

well enough that I could infer why a

problem happened based on my knowledge

of the pieces. AI disincentivizes you

from learning about the pieces. And I

think that's the biggest problem. Humans

are very pain. Feeling dumb hurts. When

you're trying a thing and it doesn't

make sense, you feel pain. When you try

a thing and it just goes as expected,

you feel good. AI has made it easier to

avoid that pain and feel that reward.

And what used to be a upfront cost you

would pay to learn the pieces and then

you could get the reward of solving the

puzzle is now a slot machine. And your

choices are go learn the pieces so that

you can actually solve the puzzle

correctly or keep pulling the slot

machine until hopefully the correct

answer comes out because each pull hurts

a lot less than reading the docs for a

language you don't understand or

learning a library that doesn't map with

your mental model properly or debugging

something that feels hopeless. I learned

about this from skateboarding. The

reason most skaters give up before

learning to ollie, much less kickflip,

is because it feels so bad. You hate the

feeling seeing others so effortlessly

jump on their skateboard, ollie

downstairs, and do all these fancy

tricks, and you can't even get the board

to come up off the ground with you. And

then maybe you try a little too hard,

and you hit your shin really hard, and

now walking's uncomfortable for a few

days. Most people give up before they

learn those tricks because the pain is

so great and the feeling of stupid and

incompetence is so strong that they

don't want to push through it. At least

in code you didn't have the physical

pain. You just had to feel dumb. And

I'll be real, I kind of miss feeling

dumb. I haven't gotten to as much lately

and I try to find ways to like

intentionally picking languages I don't

know like Rust when I build a new

project so that I have to not get it and

start learning things about it. But

every time I start feeling dumb, I feel

the itch. I feel the temptation to pull

the slot, to just do one more run in

hope that maybe this time it'll generate

a solution and now I don't have to learn

the thing. And I think other people just

don't have the same willpower. And I

don't think that is that exceptional a

thing. I don't think it was even

necessary before. But your your ability

to say no as a developer has never

mattered more than now. And your

willingness to feel stupid, to go

through the details and not let the AI

bail you out is a superpower.

Personally, I have been learning a lot

more than I've ever learned because of

this. Both because I'm learning all

about AI and the business side

especially, but also because I'm finding

more fun in things that I felt too dumb

in before. Like I'm getting way deeper

in cryptography. I'm making cryptography

challenges. I never thought I'd be able

to do that. I was always fascinated by

it. Now I'm doing it and I'm asking

questions about it and I'm having back

and forth with the agents and now I

don't feel as bad bothering my friends

about it because I'll exhaust the AI's

capability to answer my questions first

and now when I bug a friend that is

deeper in the space I'm asking better

questions. Then there's also the aspect

of fear here and I have a feeling we'll

talk about that later so I'm not going

to dive into that just yet. Let's get

back to the article cuz it's already

making me talk too much. The next

section is called not just another

abstraction. Common refrain we hear in

the community is that programmers are

just quote moving up the stack and into

a different type of abstraction. Whether

or not these tools really are an

abstraction layer in the first place is

not a settled matter. A high level of

ambiguity is not a higher level of

abstraction. Woof bars. What he's

referring to here is the idea that we've

already done abstractions. Like we used

to do punch cards and then assembly made

it so we didn't have to poke the holes

in the cards. Then C happened and it was

much easier to write and then generate

code that was assembly for different

systems. Then we got C++ which would

include a lot of the things that you

would have to build yourself previously

in C. Then we got languages like Python

and JavaScript that didn't even have to

be compiled. They just ran in a virtual

layer, a runtime that was built in these

other languages. We kept abstracting

higher and higher up. And let's be real,

how many JavaScript developers can read

assembly? I mean, let's be real. How

many JavaScript devs can even read

JavaScript at this point? But you get

the idea. These abstractions would keep

you from knowing as much about the

layers below. But the best engineers had

strong incentives to learn at least one

layer above and below where they were.

All the best C++ devs I know are very

familiar with V8, the JS runtime. All

the best JavaScript devs I know are very

familiar with V8 and its quirks. The mid

ones don't understand the things above

and below them. But the great ones tend

to be at least one layer, maybe two or

three, above and below where they tend

to live. But is natural language another

one of these abstractions? Is markdown

to JavaScript what JavaScript is to C++?

I used to think it might be, but I'm

learning now the answer is probably no.

Let's see what Lars has to say about

this. If we put the abstraction

conversation to the side, it is true

that programmers tend to be weary of new

languages and new ways of programming.

When Fortrren was released, programmers

were skeptical of it as well. They had

similar claims. It was likely to

introduce more bugs and instability.

Writing assembly more directly was more

efficient. Later, there would be

discourse around the integration of

compilers, introducing too much magic

into the process. These were normative

arguments around the fear of what might

be lost if these new technologies were

embraced. The difference with what is

happening today is that those previous

fears were speculative and theoretical.

In just the short few years that AI

tooling has existed, we've already seen

significant impacts. These aren't just

junior devs, but even those with a

decade or more of experience. Here are

some posts that he grabbed from Reddit.

Losing my ability to code due to AI.

Hello everyone. I don't see it come up a

lot, but even after a few years of

coding, using AI on a regular basis for

over a year has made me feel a lot more

insecure about my coding abilities. I

feel like my skills are really

deteriorating while simultaneously

feeling like there might be no need to

know how to code at all. Handling

feeling dumber or like losing skills due

to the need of using AI. Recently, my

company started enforcing using only AI

for all software dev. That's a terrible

idea. Erase the code. I love that this

dev is so deep that code autocorrects to

codeex. It writes the code, then agents

review the code, etc. We're supposed to

be architects who only look at outcomes

and not the code. For context, I have 9

years of experience. I'm 31, a father of

a 1-year-old, so let's agree that a side

project after hours is not an option.

Every time I use AI to do everything, I

feel like I'm losing my skills, that I'm

becoming a worse professional, etc.

Especially that if you want to get a new

job, you're mainly and mostly graded

based on your technical skills. Letting

AI do 100% coding fried my brain. Help.

AI reliance and cognitive decline. I

find myself using more and more AI to

speed my efficiency. Whether it's

organizing a schedule or a quick

screening of code to actually writing

small snippets. There are definitely

people experiencing this. I was afraid I

would experience this and somehow

haven't. I I know I keep making the same

comparison over and over again. I think

the fact that my job wasn't just coding

and hasn't been for a while prepped me

better for this. I've had a team of

engineers for the better part of a

decade at this point. And realizing my

best use of my time isn't being in the

weeds writing the code. It's helping the

team execute more effectively while

understanding the system well enough to

help them debug when things go wrong. I

write less than 5% of the code across

our products, but I solve over half the

outages. And I'm really proud of that.

My understanding of the system has gone

up, not down over time. And the AI tools

are helping me maintain that

understanding and guide my team better

as we architect our systems. I would bet

my ass that every single one of these

four people has never had to manage a

team before. I also see Chris Titus

Techch in chat with a similar experience

here. He's coming from a CIS admin and

infra background. Most of his coding

abilities used to revolve around

scripting and now with AI, it's really

opened so many doors. He could jump into

low-level languages he would have never

had time to before. And that's what I

experienced too. There's a lot of things

that weren't worth me learning because

the friction of going through the long

window of dumb and the burden I would be

to other people asking questions was too

high. AI has lowered that to the floor.

So the right mindset here can make you

way more productive and way more capable

of learning in a way that's really cool.

I'll say that less experienced engineers

like junior engineers, career

transitioners or people that just didn't

get it before, they're getting a little

more screwed here. My chat sent me this

tweet from Austin Kennedy who's 22 years

old. He thinks Claude Co is

deteriorating his brain. Every single

day for the last six months, he's had

six to eight quad code terminals open,

waiting for a response to so he can hit

enter 75% of the time. It's done

something to him. Apparently, his

friends bring it up pretty frequently.

None of them feel as sharp as they used

to. Don't know if it's just us or others

in their 20s who are feeling the same

thing, but something he's been thinking

about. Yeah, if you didn't get through

the years of friction to really

understand these things, you're going to

get addicted to the slot machine. I've

seen a lot of people falling for this in

particular. Also, the the worst ones are

the ones who have always been really

insecure. The people who I'll I'll be

real crude here. The people who don't

have imposttor syndrome. They are just

imposters. And I've seen some horrifying

examples of this. People who have been

like working at Google for four years

that don't know how to use SSH. Like

I've seen this a lot. And those people

are now addicted to the slot machine.

And they went from being kind of bad,

but like at least they could write some

Python here and there to just a net

negative on the team. Funny enough, I've

seen that same person instinctively go

to chat GPT and ask where they left

their keys because they're so used to

asking it everything. This archetype of

person, I would argue, was never

particularly useful. And the AI is just

continuing to erode their already eroded

brain. The gap between the great and not

great engineers has grown massively and

AI has accelerated that. And again,

examples from people in the industry

saying that the juniors on their team

are shipping really fast, but they don't

know how to debug anything they didn't

actually write the code for. This dev

hired a junior who learned to code with

AI. He can't debug without it. Don't

know how to help him. AI debugging

underrated. It's a specific skill

separate from building with AI. I don't

think you should be debugging without AI

at this point because if you have a bug

and it's affecting users, everything you

can do to increase the likelihood that

you solve the problem is something you

should be doing. So, when I had an

outage a few days ago on Ping, our video

product, I haven't touched that codebase

in 4 years minus like testing agents

upgrading it every once in a while, but

it was built on the OGT3 stack, a stack

that I invented. I know the layers very

well. I know where the failures can be.

So, I grabbed the first error I hit. I

pasted it into a codeex instance and

immediately went back to the browser to

try and get more info and debug it. I

ended up figuring out roughly what it

was. It was Prisma getting a null for an

ID when it was trying to do a

referential integrity check to get data

for a join that it was doing and it just

got a null and failed as a result. By

the time I had figured this out, the

agent that was running had its own

entirely different theory, but I didn't

care. I opened up another tab in T3 code

and asked a different question. Which of

these table referential integrity checks

is the most likely to have a problem and

I switched over to fast mode. While it

was running, I was going through the

code and going through our error logs. I

saw the notification that the request

was done. I went and checked and it said

that it was very likely to be the link

between user table and the join for

which users are in rooms. I knew what I

had to do at this point. I had to remove

all of the links between the rooms and

the user that were for this dead user. I

didn't want to write the SQL query

wrong. So I told it what our schema was

and asked it to write the query to

remove all the rows that match this

particular pattern. And then it worked

and then I was done. So I did around

three AI agent requests while I was

doing this debugging. I don't even know

what the first one output. I just had it

run in the background while I was

debugging. found a much more likely root

cause, asked a second agent about that.

It correctly identified what table the

problem would be from. I asked it to

write a query to figure out what row was

affected. It did. I pasted it. I got the

right result. I pasted the results back

into my agent. It told me what query to

run to clean it up and then it was

fixed. This was me and the AI going back

and forth sharing our understanding of

the capabilities of my system and what

we were experiencing in order to debug

more effectively. Note that this would

not have worked at all if I didn't know

the system already. I also would have

taken much longer to solve this if I

didn't have AI and I would have been

more scared about my solutions because I

didn't want to go write the [ __ ] SQL

for this when I was at an event in

Miami. Yeah. So, I am very okay with

using AI in the debugging process.

Anybody who says otherwise is either

stupid or bad faith. The problem is

people leaning on AI because they don't

understand the system and their refusal

to learn the system because it makes

them feel dumb results in them only

getting anything done with AI. Different

problems and I want to be very clear

with the distinction here because again

these tools are really useful when you

know what you're [ __ ] doing. Back to

the article, Lars says it is actually

different this time and I agree. This is

different from a C++ dev moving to

Python or Java because as he says, they

didn't complain about brain fog when

they made the move. They complained

about the awful object-oriented

programming patterns that they had to

adopt in Java. When a CIS admin moves to

AWS, they don't feel like they're losing

their ability to understand networking.

On that note, there's a lot of people

who would argue Verscell cost them their

networking understanding, but different

conversation for a different time. A

senior engineer losing their coding edge

and becoming rusty over time as they

move into managerial roles and practice

coding less often is not a new

phenomenon. This was the natural

progression of expertise. An engineer

would put in decades to coding

experience lots of friction and their

experience would be logged and that

would result in them having the time and

experience necessary to solidify their

skills and wisdom and they could apply

that wisdom when their job became less

about syntax and more about higher level

architectural decision. Those

individuals are not only exceedingly

rare, but you won't get the next wave of

seniors if we're all abdicating the

friction of writing, problem solving,

and debugging. Ding, ding, [ __ ] ding.

This is the concern I have. I am

predisposed to being good with this [ __ ]

because I already coded in a way that

relates to this. And then when I moved

to leadership positions and I was

advising at many different teams while

also coding and being in the weeds, too,

I got to build these skills really

early. And I'm super thankful for the

people I worked with for letting a

stupid [ __ ] 22year-old step way

outside of their role to start steering

architectural decisions and helping in

outages that they shouldn't be near.

Being involved in like P1 instances that

they should have nothing to do with and

learning not just how things work, but

more importantly how they fail. I'm

really [ __ ] proud of my debugging

skills. My team's almost annoyed that

like I can come into a codebase I've

barely touched in years because there's

some outage and say, "Oh, it's probably

that." And I'm right like 70% of the

time. And if I'm not, I get it right

within the next three tries. Usually my

systems understanding and my ability to

like link one, two, and three to form

the picture. That's what I'm good at.

And I wasn't initially. I had to build

that skill up because I was doing too

many things at any given time. and I was

lucky enough to be surrounded with

people that were cool with me stepping

way outside of what I should have been

doing. I will say that with the right

mindset and focus, I do think the skills

I built can be built independently now

if you build a big enough system and put

the effort into understanding where it

fails. On the other hand, the incentives

for that are going down and the interest

in building your fundamentals is going

down with it. I used to be the person

that would push back on learning like

fundamental CS. Like I didn't think you

needed to go memorize all of the

different sorting algorithms and all of

the different like big O notations for

different solutions to various problems.

Like I don't think most devs should need

to know how to inverse a binary tree.

But the moment you have to, you should

be able to figure it [ __ ] out. And

this is always my take. The fundamentals

don't matter until they do. And you

should be in the right mindset to learn

them when it makes sense to. when you

have a problem that benefits from it. If

something is slower than it should be

and you notice that your sort algorithm

takes too long, it's time to learn

better sort algorithms. I don't know if

that take of mine will carry over to

this era. I would hope that when you're

running into problems because you're

fetching all of your data through use

effects that you'll look into how other

people do it and you'll find React

Query, but I think it's more likely the

agent just does it for you and you never

learn the difference. I suspect that

because I've already seen a lot of

engineers do that even before AI. The

number of engineers I saw making their

code comically worse by fetching all of

their data in these weird patterns that

were super inconsistent and unreliable

across their codebase that wouldn't use

React Query because they don't want to

learn another new thing. [ __ ]

you're basically unlearning. It is less

code and less effort. It is a simple

wrapper for async functions. It couldn't

be easier. But the idea of another thing

to learn was enough of a turnoff for the

average low IQ dev that they wouldn't

[ __ ] bother. And now that person's

been given a lever they can pull to make

it matter even less. That sucks. AI is

going to take bad devs and make them

atrocious. But I do still hold a little

bit of hope that the devs who love this,

who really care about how things work,

not just the feeling of them working,

will take advantage of these tools to

accelerate how quickly they learn and

grow. And I have already seen this. It's

a small number of people, but I have

them in my community. People who are

doing way more than they should be at

their young age without any real career

experience yet because they're building

things bigger than they have any right

to and they're curious about why they're

breaking and how to solve the problems

at fundamental levels that I love. I

like this framing here, too. What's

happening now is a trend where devs who

have never had the longevity or the 30

plus years of friction that lead to the

deep understanding are being moved to

higher level workflows requiring those

same skills to manage the AI agents that

the senior engineers took decades to

obtain. Yep. I'll go a step further. You

had to be a good engineer to have a big

code base. Either you were hired to help

in that big codebase or you built it

yourself. There was a intelligence and

competence requirement like a a friction

that was necessary like a you have to be

this tall to come in type thing. You had

to be this competent and this experience

to build real work before. Now Claude

can get you into a position where you're

maintaining a code base that is bigger

than any engineer with 5 years of

experience would be comfortable with and

you learned how to code a month ago if

you even actually learned. That is the

biggest issue is there's devs who are

way out of bound for where their

capabilities are and they're not using

the tools to learn to better their

capabilities. They're using the tools to

reach past their capabilities and then

just throw up their hands when things

break. Another great point from Chris

Titus Tech. He's on fire. He'd expand

this and say that if you do open source

and have contributors, it will help

point out the mistakes. I'll go even

further than you are here, Chris. Open

source maintainers are massively

outperforming average devs in the AI

world because they're used to slinging

slop and dealing with random [ __ ]

from various capabilities and levels of

engineers, many of which know better

than them, many of which know less than

them, all of which are opportunities to

learn. And this is actually why I think

you're an exceptional dev despite not

being a dev because you're doing

something way harder. You're trying to

fix Windows, but aside from that, you're

also trying to like maintain these real

legitimate open- source projects people

rely on every day. I say as a person who

relies on win till every time I do a new

Windows install, which is far too often.

That puts you in a position where you

learn so much more and those details

matter so much more. You've effectively

let yourself do 5 years of real world

experience every year with the stuff

that you do, even though you're not an

engineer in the traditional sense, which

is silly and dumb. and one of the many

reasons I want to help you get make more

[ __ ] money. So yeah, if you're doing

real open source stuff that people rely

on and use, whether you're a contributor

or even better a maintainer that is

helping go through stuff, your level of

experience for where you're at in your

career will be significantly higher than

you would otherwise expect. Like I know

people who have one year of experience

that is mostly open source work that

runs circles around somebody with five

years of experience at Microsoft. The

author does remind us that senior

engineers aren't immune. Simon Willis,

the creator of Django, good friend of

the channel, one of the best people in

the AI developer space for talking about

how this actually affects us as devs. He

has 30 years of experience. He's been

coding since I was born. He reported

that he doesn't have a firm mental model

of what the applications he builds can

do and how they work, which means each

additional feature becomes harder to

reason about. And I can absolutely

understand that. The skilled

orchestrator problem buried in a recent

study by Anthropic was a surprisingly

honest moment when speaking about the

risks of engaging with coding agents on

a regular basis. One reason that the

atrophy of coding skills is concerning

is the paradox of supervision.

Effectively using Claude requires

supervision and supervising Claude

requires the very coding skills that may

atrophy from overusing AI. A director of

software engineering at LinkedIn who has

50 engineers reporting to them has

noticed it proliferating throughout the

organization and requested his team to

not use them for quote tasks that

require critical thinking or problem

solving. To grow skills, people need to

go through hardship. They need to

develop the muscle to think through

problems. How would someone question if

AI is accurate if they don't have

critical thinking? Yep. I don't know

what it looks like to build these skills

now. It's very different from how it

used to be. I'm sure there are new ways

to and I'm sure they're even more

effective using these tools, but I don't

know what that looks like because I

already have the skills. I can't

properly reset to my brain before I knew

all of these things. There's also the

question of what constitutes this

overuse. We already have evidence, both

datadriven and anecdotal, that these

skills can atrophy and dissipate rather

quickly, sometimes even within months.

This is the contradiction that has many

AI boosters talking out of both sides of

their mouths. The use of coding agents

is actively diminishing the very skills

needed to effectively manage the same

coding agents. LMS accelerate the wrong

parts. Oh boy, this is going to be a fun

section. Contrary to the current

narrative that is being espoused, we

didn't necessarily need to write code

faster, especially code that we didn't

fully understand, and particularly in

huge swaths that we couldn't review in

reasonable time frames. Before AI, a

good dev's priority list might look like

the following. First, understanding of

the code and its relation to the

codebase. Second, if the code is aligned

with the documented and efficient

standards. Three, as few lines of code

as needed to accomplish the goal while

maintaining readability, and four,

turnaround time. I don't agree. Depends

on what type of good dev you're

referring to here, because there's a lot

of things that make a dev good, and

everyone will disagree on what those

are. Some people think a good dev is

somebody who writes meticulously

detailed specs and writes five unit

tests per line of code. Others might

think a good dev is the person who

understands the user and the codebase

well enough to make the two meet. Others

might think the best dev is the one who

comes up with a novel solution that is

far outside of the way anyone else

thinks that no one understands until 5

years later and then we're all using it.

I think good devs are people who solve

real problems. I like working with devs

that understand the code base, that are

writing code that is well aligned and

standard, that are writing as few lines

of code as possible, which is actually

very rare. or there's a lot of great

devs that don't even do this and have

good turnaround time. But I have found

that any one of these skills at the

upper end is novel enough that it makes

you unique. Like if you write really

efficient code, that is a thing you're

known for. Like I know Mark, my CTO, is

the code golfer. One of his favorite

things is to see if he can do a whole

advent of code problem in one line of

JavaScript. And then turnaround time, as

I mentioned before, was one of my

skills. And it was enough that it

boosted my career meaningfully that I

could come in, find the things that made

the road map unnecessarily complex,

helped trim and get like really locked

into the thing we actually wanted to

build. So we weren't distracted by all

the things that took most of the time

and brought none of the value. So I

would say a great dev has all of these

skills, but a good dev is somebody who

has the right compromise between them.

The problem is that agentic coding and

LMS in general are inverting this list.

Yeah, most devs should not be allowed to

code fast. That I agree with. As

somebody who coded fast a lot, watching

others try to keep up resulted in a lot

of pain. And the solution was often for

me to slow down, not because my code was

getting buggy, but to get everybody

around me to stop trying to keep pace

because when they did, everything fell

apart. And AI now has everyone trying to

keep pace, and now everything is falling

apart. Their capabilities and usage tend

to focus on speed by increasing the

amount of code that can be generated in

a specified time frame. Speed's a

natural byproduct of high aptitude. When

it's forced, it always leads to lower

accuracy. Okay, I do love this framing.

Actually, this is perfect. I earned my

right to the speed. Y'all haven't yet.

Okay, many of you have. I'm actually

really impressed with how competent so

much of my audience is when I meet you

guys at events and things. I'm blown

away with the [ __ ] so many of you are

doing. Your annoying ass co-workers have

not earned the right to ship fast yet.

And the result is slump. Julius on my

team has absolutely earned the right to

ship fast. He's shipping faster than I

ever have and is pushing the limits of

what agents can do, but also is very

meticulous about how things are

structured more than almost anybody. And

as the author says, the integration of

AI tools does not tend to focus much on

deeper understanding or conciseness. And

I want to be really clear because every

time I mention something like this, the

response is, "Oh, we need better tools

that do that. Those should make a lot of

money." And then I get five people

coming up to me at the OpenAI GBT 5.5

event trying to get me to invest in

their company making AI education

products to help people learn better

with AI instead of just use the AI. Who

do you think makes more money, casinos

or people selling books about casinos?

There's pretty obviously one that does

much better. I have been burned on so

many education investments, even the

ones that were doing revenue, that I

just don't believe that people want this

at all. Given the option of a slot that

makes you feel good and a lesson that

makes you feel bad, 99% of people are

going to pick the prior, there is no

business building this, which sucks that

human nature in capitalism prevent tools

that educate you from being successful.

But that's your guys's fault as users,

not business's fault. Doesn't matter how

good the business does. If users don't

want it, it won't work. Believe me, I'm

speaking from a lot of experience here.

It is absolutely possible to use these

tools if you're determined enough in a

way that will actually make you learn

more and understand systems better. But

that's not how they're being used. Lots

of companies have force mandates that

you have to be doing more with AI and

they have crazy leaderboards and stuff

that are incentivizing bad usage. And

all the hype around that is

demonstrating just how bad things are

getting. Coding equals planning. This is

going to be a fun section. There's a

divide between devs that isn't

highlighted as much. Some of us plan and

think better with code. Thinking and

working in code isn't just meaningless

drudgery. It forces you to think about

things on a technical level that

involves everything from security to

performance to user experience to

maintainability. I very much agree here.

I like planning in code. A thing I talk

about a lot is what got coined at

Twitch's theo method. Instead of writing

a spec, assuming we know how everything

works, that is super long and tedious,

and then building the product and

realizing the spec doesn't make any

sense, I would start with a really

simple, minimal implementation that was

the minimum viable shape of the idea.

And in building that in just a few days,

often I would learn a ton. Sometimes it

would even be good enough we could ship

that as is. Other times I would find all

of the things that make it annoying to

implement and then I can write a good

spec based on what I learn. Death Fudge

put it perfectly in chat. Write once,

throw it away and then build it. Right.

Absolutely. And if AI helps you do that,

awesome. I did this so much it got

coined under my name at my last company

that I worked at traditionally. It is

really powerful to get in the weeds

first. You can't really do that in

coding without coding. I write much

worse plans when I'm not in the

codebase. That's just reality. And when

I'm working with my team, I'll often do

a first pass before proposing the thing

to the team so I have like my roots to

base my proposals on. And guess what?

Plan mode is not that. Plan mode is not

that at all. In a recent interview

discussing specri development, Dax, the

creator of Open Code, which is an open

source coding agent, no less, is quoted

as such. It's also worth noting Dax

isn't the creator of Open Code. He's a

devril at Open Code. Here's what he had

to say. When working on something new or

something challenging, me typing out

code is the process by which I figure

out what we should even be doing. I have

a really tough time just sitting there

writing out a giant spec on exactly how

the feature should work. I like writing

out types. I like writing out how some

of the functions might play together. I

like playing with the folder structure

to see what the different concepts

should be. And this is all stuff I think

most people, most programmers have

always done. I don't agree there. You

would be amazed how many programmers

don't do any of this. They just wait

till the ticket is cut properly and then

they spend way too long writing a

document and then hope they can get

promoted before they even finish the

feature. Most devs don't do this because

most devs are roughly average or worse.

Good devs do this, but most devs don't.

I do agree with him that we shouldn't

necessarily stop doing this. There's no

good reason to, and it's how we figure

out what to do and how to do it right.

The one big part I'll disagree with

here, though, is that when you get it

wrong, it's never been cheaper to fix

it. I always had a sense of dread when I

would commit to a new folder structure

or a new way to do type systems or a new

way to do data fetching because if I'm

wrong, getting it out as hell. Now I can

get it out in a for loop and that's

awesome. It has made my willingness to

experiment with these things go up a ton

and I'm trying patterns I never would

have tried before cuz they had way too

high a risk of being [ __ ] But they

turned out to work really well and I'm

surprised, but it never was worth the

effort before. So again, there's two

sides here. Back to the article. what

you say is often not what you mean and

LLMs fill in ambiguity with assumptions

or even worse hallucinations which leads

to more review, more agent revisions,

more tokens burned and more

disconnection from what is being

created. Inversely, you can marvel at

the most beautiful unambiguous perfectly

structured prompt you ever written and

the LM can still output a hallucinated

method because it's fundamentally a next

token prediction engine, not a compiler.

You cannot replace a deterministic

system with a probabilistic one and

expect zero ambiguity. As a JavaScript

dev, I am offended. Oh boy, this will be

a fun section. Vendor lockin. When I was

browsing LinkedIn during the cloud

outage that occurred a bit ago, I

noticed numerous posts highlighting that

certain devs and engineering teams were

at a standstill. Their workflows, their

own coding abilities, had already

reached a point where they were largely

dependent on these vendors. What used to

be a skill that they could execute with

just a keyboard and text editor suddenly

required a subscription to an AI model

provider. I haven't selfplugged in a

bit, so please permit me to do it this

one time. If you're experiencing vendor

lock in right now, that is your fault.

There are lots of great tools, and I

will obviously plug my own with T3 code,

that don't just give you the ability to

switch between models. They give you the

ability to switch between subscriptions

and providers. There is no world in

which claude, codecs, cursor, and open

code are all down at the same time. And

it's actually quite valuable to hop

between these things. I can't tell you

how many times I've had GBT 5.5 debug

Opus slop and how many times I've had

Opus come in and make a slightly better

UI for some GPT 5.5 code. A lot of devs

are doing this wrong. They are relying

on one thing way too hard. The same way

that a lot of devs rely on US East1 too

hard. The difference is that somehow

Anthropic is less reliable than US

East1, but it's the same problem. And

there's lots of good open-source

solutions to this problem. Again, T3

Code is a fully open-source desktop app

and web app now, too, that you can use

to run all of your agents on your

existing subscriptions and hop between

them at a moment's notice. I have had

times where Claude was down and I wanted

to use it, but I hopped over to GPT 5.5

and was fine or even hopped over to

Cursor where they were using Opus models

through other providers and also were

fine. You can also deploy Claude on

things like Amazon Bedrock, which has

way more reliability and better uptime

than you would get out of using Claude

directly. So, I don't love this vendor

lockin point. I think like all things,

reliability is your concern as a dev.

The problem here isn't that we're all

stuck relying on one thing. It's that

stupid devs have nothing else to do when

their thing goes down, so they complain

about it online. An interesting point

here is that you can't predict your

token cost. Model providers are heavily

subsidized and the models themselves are

built on shifting sands. Every new model

released follows the same pattern of

high benchmarks followed by hype

followed by the reality of usage and

everyone complaining about them being

nerfed and burning through 2x or 3x as

many tokens to get the same job done.

This is a cloud complaint. This is

absolutely a cloud complaint. Like this

is not how it works at open land. You

guys are just so deep on cla code that

your brains are falling out. everyone,

whatever side you're on, if you're a

Claude Code Dieard or a Claude Code

hater, Claude Code specifically has

ruined the discourse about so many of

these things. Oh, don't quote that. That

Primagen video, not that video. Not the

one I had to tear to pieces cuz it was

so wrong. Oh, no. Don't quote that. This

article was so good up until this point.

You know how much your employees cost,

but you have no idea how much your token

costs will be dayto-day, monthtomonth,

year to year. If all of your costs are

fixed, you don't have a real [ __ ]

business. I've never worked with a

company that is doing well that had

entirely fixed costs. Everything is

flexible. Everything fluctuates.

Computer costs skyrocketed because of

tariffs and RAM being more expensive.

Egg costs skyrocketed for restaurants. A

fixed cost business is a failing

business. Generally speaking, I'm just

going to skip this paragraph because I

don't agree. To be frank, I generally

think vendor lockin arguments are

competence failures. Good vendors make

it easier to do less work and the move

out of a given vendor is just the

adoption of the work you avoided doing.

So the example I often give is Verscell.

Moving off of Versell is easy. You just

have to write the code you hadn't

written yet. I don't write code that

only works on Verscell. I write code

that works on Versel that is missing

pieces that I didn't have to write

because I was using Verscell and

Verscell handles it. When I leave

Verscell, I have to go add those pieces

back in. Using cloud code means I don't

have to write the code by hand. Leaving

cloud code doesn't mean I can't write

code anymore. It means I have to go

write it myself again or use any of the

15 other providers. Like there's so many

options. I just I don't like this

argument. Vendor lockin is not the right

framing for all of this. So let's go to

the last section here. Demoting AI's

role and certainly not advocating for

typing all code out manually.

Programmers have always been looking for

ways to create code without having to

write it. That's why we have things like

emit the autocomplete system that is in

VS Code for shorthand. I always hated

EMTT personally but each their own. They

also have traditional autocomplete

snippets as well. I used to be like the

biggest anti-nippid and template guy. AI

means I don't have to care anymore,

which is great. Even Cobalt was designed

to encapsulate more instructions with

less writing by using English-like words

such as move and write. BigQuery's motto

was write less, do more. LMS are another

addition to this array of codegen tools.

What I'm advocating for, though, is

leveraging LM's and coding agents as a

secondary process, a way that doesn't

sacrifice the individual skill at the

alter productivity. You can flip the

script and lean on them to brainstorm

the planning parts of the process while

staying actively engaged throughout

implementation. Delegating to them on an

asneeded basis. You can leverage the

productivity gains and mitigate the

comprehension debt. I'm going to go

through his workflow and then I'm going

to discuss mine and my framing that

might be a little different. He uses LLM

to help generate specs and plans while

he facilitates the implementation.

It's an inversion of the orchestration

flow. He's still manually coding

anywhere from 20% to 100% depending on

the task. I use LMS to investigate but

not to write the plan. That's

interesting. I very often am writing

pseudo code when I do engage with the

models. Closing the distance between the

request and generate code. Yep,

absolutely. I love writing pseudo code.

I like doing it back and forth on pseudo

code too where I'll have the model

generate the pseudo code. I'll make

recommendations. We'll go back and

forth. I'll be like, "Okay, that's good.

What does it look like in my codebase?"

He also uses the models as delegation

utilities for ad hoc code generation and

interactive documentation as well as

research tools so that he can constantly

ask questions, iterate, refactor, and

gain clarity. Okay, now we're cooking.

We'll go back there in a sec. He never

generates more than he can review in a

given sitting. If it's too much to

review, he slows down and splits the

task up, manually refactoring when

needed to ensure a comprehensive

understanding of the end result. And

he'll never ask an LLM or agent to

implement something that he's never done

before or couldn't do on his own, except

perhaps purely for educational or

tutorial purposes and often discarded

afterwards. Okay, he's dancing around a

concept here that I don't even know if

he has embraced yet. The harsh reality

is that most code wasn't worth writing

before if it wouldn't be run thousands

of times. Any task that code can solve,

a human can too, just not necessarily as

efficiently. But if I only have to do

the thing once and it would take a

thousand lines of code, it wasn't worth

writing that code. I would just do the

thing by hand. The important thing to do

is to think about how important is each

function that you're writing. Is the

code that you're writing code that's

going to be run thousands of times a day

by your users? Or is it code that's

going to be one once in a migration? Or

maybe you're doing some data analysis

and you want to like dig something out

of 500,000 rows in a CSV and you're only

going to run the code once. you just

want to get this info. Understanding how

frequently a piece of code is going to

run is essential in understanding how

important that code is and how important

it is to understand that code. And once

you've internalized this, you can go

further with it. When you realize

there's a lot of code where the quality

doesn't matter because you're just

running the thing one time and not

thinking about it again, you're going to

start writing code for things you

wouldn't have before. I have written so

much code for [ __ ] stuff like oneoff

calculators for checking numbers from

one specific task I did or writing a

2000 line of code JS file to manage

assets on my NAS when I'm in the middle

of transferring a bunch of files between

[ __ ] Those things were never worth

writing code for before cuz it would be

faster to just sit there and do the task

yourself. Now all of a sudden it is way

more valuable to write code for those

things. And that has been the biggest

shift for me is using the AI to write

code that otherwise wouldn't have been

worth writing and at the same time using

AI to better understand the code that is

worth writing. The harsh reality is that

most people who are working with agents

can't tell you which code is running at

all, much less which code is running a

lot and which code is run once. And if

you don't have that level of

understanding, you need to fix that. But

once you have this understanding and you

can think through the work you're doing

in this range, you're going to find more

value on both ends of that spectrum. On

the end where you're writing code to run

personally just a couple times, you'll

be doing way more in solving way more

interesting problems in more interesting

ways. And on the other side, the most

complex code can be explained to you

with an agent and you can find the hot

paths and learn more about how it's

architected. And if there's something

wrong with it, you can use the agent to

adjust things at massive scales like you

couldn't before. And I have found that I

use AI entirely differently for the code

that is run a lot and is shipping to

users versus the code that I'm using for

one-off tasks. And realizing this and

realizing you can do better in both

areas with AI is the powerful unlock

I've been trying to help more of you

have. The author titles the next

section, I'm not going faster, but I'm

doing better quality work. Why not both

is my challenge. Faster for the one-off

things, faster to solve problems, faster

to do stuff that wasn't even worth doing

before, but improving the quality in

things that required too much manpower,

improving the quality in things that you

didn't understand fully and now can.

Getting more versions of a thing out

before solidifying the one you want to

commit to. The code that matters should

be better quality because of AI. And the

code that doesn't should be 10 times

more prolific because of AI. We should

get both. And when those two get

confused with each other, everything

falls apart. Let's wrap this up because

this was an awesome article. I'll be

real. I want to let him have the last

word. The productivity gains from these

models are real. And so is the friction

and understanding that came from

engaging with the work on a tangible and

frequent basis. Despite countless failed

attempts at trying to democratize coding

while not understanding coding, we're

faced with the reality that you cannot

understand code without engaging with

it. It's also become clear that if you

don't keep engaging in writing it, you

can lose touch with that understanding,

which will in turn make you a less

capable orchestrator in the first place,

rendering this phase of AI coding a

strange and needlessly stressful

interlude. Perhaps I am worrying too

much, but history contains lessons. This

all feels similar, though, like another

large experiment we're running on

ourselves. We've been through a similar

period with the introduction of social

media without understanding the

long-term implications, and we're now

faced with attention deficit amongst

many other issues on a wide scale. This

time we're gambling with something much

riskier. He ends with a quote from

Jeremy Howard. People who go all in on

AI agents now are guaranteeing their own

obsolescence. If you outsource all your

thinking to computers, you stop

upskilling, learning, and becoming more

competent. I absolutely agree. This is a

phenomenal article from Lars. Definitely

recommend checking out his blog. It'll

be linked in the description if you want

to see his other posts. This is far from

his only great blog post. Definitely

check out his indispensable value in AI

era post as well as everyone can

delegate now just from this year alone.

Very thankful to Lars for writing this.

This is an awesome read and I hope you

learn something from it. Don't let the

AI take away your thinking. Let it

advance your thinking and you can build

better, smarter things as you learn more

and solve more problems. If AI isn't

making you smarter, you are using it

wrong. And I highly recommend you

reflect before you lose those valuable

skills. It's a really important time to

be on top of these things now more than

ever. and letting those skills atrophy

will hurt your career long term. That's

all I have to say on this for now.