Has anyone else found a similarity between how you feel at the end of a long AI coding session, and getting off of a long haul flight? I think the reasons are similar.
On the flight, it's not exactly like you directly feel the wind going through your hair as you travel 1000km/hr, but your body still knows that you did. You feel the lag immediately, not really due to a time zone difference but due to how unnatural it is to move so far in so short a time.
I feel the same way after a highly productive AI coding session. I used to anecdotally mention to others that I liked to maintain and use older machines because it felt nice to get little breaks here and there while the machine took longer to open a browser/app, return search results, render a file, etc. This is the opposite of that. Everything is happening so fast, your mind is taxed differently than if you are responsible for typing everything yourself... no matter how fast you could type code.
That said, I don't think it's entirely my increased cognitive load that makes me feel drained after a session, it's as though you can somehow feel the token burn, the water/electricity use, just as you somehow felt the wind shear on the airplane you were just in for many hours.
>but due to how unnatural it is to move so far in so short a time.
Your body literally can't tell whether it's traveling at 500mph or still. After all, the earth is rotating around the sun at 70,000 mph. Of course, there might be plenty of other reasons why crossing continents in a metal tube might be exhausting (eg. jet lag, uncomfortable seats, noise/vibration), but pesudoscientific reasons like "unnatural it is to move so far" is certainly not one of them.
I love how the "pseudoscientific" word gets busted out anytime an understudied area of research is presented. Keep in mind that the state of science in 1000 years from now will prove all sorts of things that hyper-rationalists might scoff at today.
I'd say this is a bit akin to whether people can feel the weather in their bones - biometeorology. The only difference is that the airplane creates a temporary, highly artificial "weather" environment. But I think it's important to include the physical interactions between that environment and the one outside of it, and not only account for interior conditions like air pressure, etc.
We'll probably learn a lot more about this if we ever make it far enough as a civilization to have a shot at long distance space travel, i.e. to Mars.
>I love how the "pseudoscientific" word gets busted out anytime an understudied area of research is presented. Keep in mind that the state of science in 1000 years from now will prove all sorts of things that hyper-rationalists might scoff at today.
"But the fact that some geniuses were laughed at does not imply that all who are laughed at are geniuses. They laughed at Columbus, they laughed at Fulton, they laughed at the Wright brothers. But they also laughed at Bozo the Clown"
>The only difference is that the airplane creates a temporary, highly artificial "weather" environment. But I think it's important to include the physical interactions between that environment and the one outside of it, and not only account for interior conditions like air pressure, etc.
In other words, even you don't think it's "due to how unnatural it is to move so far in so short a time", and instead think it's something to do with the cabin conditions?
So it feels just like in college where we had to learn these languages, syntaxes, semantics, before the term ends, and cram and exhaust ourselves before the test.
Cognitive researchers argue late teens to early 20s is the zeitgeist that is the hardest to shake.
That seems to explain the obsession with Reagan era economics and politics of the >50 crowd
Millennials have been in "learn new abstraction" mode for a couple decades regardless such output doesn't really move science forward. Is just learning a new state storage and state mutation syntax
End of the day its labeling some math with some biz edge case
I like the idea of such not being in the code at all. Taking anti-oop to the extreme; code need just be geometric functions to draw on the screen be it text shapes or video game entities
Then we can label on the presentation layer the human context
Maybe a system running a local model is not so bad. The tokens per second will allow for that break?
Also, at what point does AI take over for all the thinking and white board planning?
AI should be a rubber duckie one can use to posit and assist when hit a brick wall. But if using it for all code generation, planning and troubleshooting then one is not in control; they’re just prompt drones…
This gets into how advanced the prompt engineering actually is. I anticipate discussion around what "state-of-the-art" prompts look like, since, as the OpenClaw founder suggested, Prompt Requests may well replace Pull Requests when a set of small tweaks to the prompt may yield vastly improved output.
This of course needs to be coupled with actually staying accountable for what the entirety of the codebase looks like. I imagine many people are unwilling to slow down enough to actually do that accounting/review, and the architecture might gradually shift towards entropy.
Just started at a company and the amount of irresponsible AI use is appalling. I asked an employee whose job involves AI adoption/training how large their diffs are for pull requests. They told me that their diffs are "As much as the model can produce given its reasoning level".
In the end, this is going to create unmaintainable code that no one understands. It also discourages reviewing the code because no dev can meaningfully review 1000s of lines of code in a day while also accomplishing their tasks.
NOTE: I am still pro AI, just like I am pro heavy machinery. I just don't want people to cut off their legs...
Not OP, but I think it's not about producing value now, but how much it will cost in the long term. If you have unmaintaable code that is N times larger than a hand-written codebase, what is the cost to be?
Its about the team being able to review the code to tell if its slop or not. It's hard to meaningfully review huge changes to a codebase for one PR. Just imagine if there are 5 PRs a day with 1000+ insertions. It leads to the production codebase being somewhat of a black box imo
The problem with articles like this one is, they give ways to become efficient at handling more addiction, at the individual level. Nothing for others part of this, companies developing the software and organizations employing these tools.
Summary of the addiction management tips from the article.
1. Time-box your AI coding sessions with a clear goal and a hard end time.
2. Separate exploration (testing ideas) from execution (shipping code) to avoid losing focus.
3. Prioritize sleep, hard stops, and actual recovery as essential maintenance, not just wellness.
4. Invest in structured training to move from basic usage to advanced multi-agent workflows.
5. Personalize your AI workflow to fit your needs while actively avoiding common anti-patterns.
-
When a developer stops writing code and starts using Claude to handle multiple projects at once, they are essentially managing the outcomes.
They have become 10x engineering managers. The context strain and emotional strain is overwhelming.
Same; the most infuriating parts - Claude caused the issue and Claude misdiagnosed the issue, making me spend more time than if I was debugging it myself.
This happens all the time to me. The model emits thousands of lines of high-quality code, making vast progress very quickly, but on the way does a few very, very stupid things a human being would never have been silly enough to do.
Then it takes hours or days - sometimes weeks - to find and fix the AI-induced problems. If you very, very tightly constrain the AI by using structured processes and unit tests you can work wonders with it, but you do start to wonder to what extent this is better than if you had simply coded it yourself.
I think the issue is that obtaining empirical proof of AI or manual coding being more efficient is very difficult, since true costs and outcomes aren’t known for months and often years. AI _is_ faster at producing short term results though, so naturally, given the state of the industry, everyone is piling both money and time into AI driven workflows and manual work is met with suspicion, if not outright discouragement. Engineers might hate AI, but they need their paychecks.
You may be wise beyond your years and are sitting on a goldmine of consulting opportunity if you can actually get tasks done faster without ai given the exact same inputs
> AI is keeping engineers at their desks longer, not freeing them up. Random rewards, dopamine hits, and no natural stopping points create a loop comparable to casino gambling.
> The fix is deliberate habits, not restricted tools. Time-box sessions, separate exploration from execution, and treat recovery as maintenance.
agentic coding is a soft drug, so taking 'the only way out is through' approach is pretty viable. once you figure out how to swim and have claude running for an hour+ at a time and only bugging you with either high-level taste decisions or 'done, how's it look?' it's pretty low stress
if you're overloaded with PRs, build LLM-based systems to take the load off. don't be a senior engineer, be an engineering manager.
Or "paying the price" literally. I'm returning after a small break and into new GitHub Copilot prices. A simple question / request / analysis on Sonnet - that will be 29 cents, please. I can't imagine how much it will cost to do actual development with it.
What type of AI coding? I do not have the attention span to sit there and let these LLMs just churn away. I have to be the one doing the typing or nothing will be accomplished. I tried playing Claude Code and Codex a bit. While impressive in their outputs (at times), I just find the workflow to be so dissatisfying.
One other aspect of LLMs that I do not enjoy when it comes to development is the fact that LLMs minimize my contributions. I do not feel like I can take credit for anything I create if I technically did not create it.
However, I absolutely adore LLMs for learning new concepts and for troubleshooting. To me, that is where they shine the brightest.
Yeah I feel much the same way, though I think LLMs suck ass at troubleshooting. They are almost always going down wrong paths and making bad guesses that I waste time disproving, or suggesting solutions that don't wind up lining up with the symptoms I'm having.
Where I do get value out of LLMs is in two main areas. One is generating short bits of code that I can more or less instantly recognize as correct. Bash scripts are a good example - I can read bash well enough but I'm not great at writing it, so Claude can generate a 20-line script very quickly and I can equally quickly understand the generated code. Writing such scripts would probably take me 15-20 minutes, so I'm not saving huge time, but it's there. The other use case I have is asking the LLM for code review on my personal projects. I don't let it write code (that would destroy the whole fun of the personal project, for one thing), but sometimes I have some code I'm pretty sure sucks and I'll ask ChatGPT to suggest better ways to accomplish the same thing. I learn a lot reviewing its suggestions.
Has anyone else found a similarity between how you feel at the end of a long AI coding session, and getting off of a long haul flight? I think the reasons are similar.
On the flight, it's not exactly like you directly feel the wind going through your hair as you travel 1000km/hr, but your body still knows that you did. You feel the lag immediately, not really due to a time zone difference but due to how unnatural it is to move so far in so short a time.
I feel the same way after a highly productive AI coding session. I used to anecdotally mention to others that I liked to maintain and use older machines because it felt nice to get little breaks here and there while the machine took longer to open a browser/app, return search results, render a file, etc. This is the opposite of that. Everything is happening so fast, your mind is taxed differently than if you are responsible for typing everything yourself... no matter how fast you could type code.
That said, I don't think it's entirely my increased cognitive load that makes me feel drained after a session, it's as though you can somehow feel the token burn, the water/electricity use, just as you somehow felt the wind shear on the airplane you were just in for many hours.
Except airplanes have lower oxygen pressure. So it is physically much more demanding. Coding on the plane is harder than coding on the ground.
>but due to how unnatural it is to move so far in so short a time.
Your body literally can't tell whether it's traveling at 500mph or still. After all, the earth is rotating around the sun at 70,000 mph. Of course, there might be plenty of other reasons why crossing continents in a metal tube might be exhausting (eg. jet lag, uncomfortable seats, noise/vibration), but pesudoscientific reasons like "unnatural it is to move so far" is certainly not one of them.
I love how the "pseudoscientific" word gets busted out anytime an understudied area of research is presented. Keep in mind that the state of science in 1000 years from now will prove all sorts of things that hyper-rationalists might scoff at today.
I'd say this is a bit akin to whether people can feel the weather in their bones - biometeorology. The only difference is that the airplane creates a temporary, highly artificial "weather" environment. But I think it's important to include the physical interactions between that environment and the one outside of it, and not only account for interior conditions like air pressure, etc.
We'll probably learn a lot more about this if we ever make it far enough as a civilization to have a shot at long distance space travel, i.e. to Mars.
>I love how the "pseudoscientific" word gets busted out anytime an understudied area of research is presented. Keep in mind that the state of science in 1000 years from now will prove all sorts of things that hyper-rationalists might scoff at today.
"But the fact that some geniuses were laughed at does not imply that all who are laughed at are geniuses. They laughed at Columbus, they laughed at Fulton, they laughed at the Wright brothers. But they also laughed at Bozo the Clown"
>The only difference is that the airplane creates a temporary, highly artificial "weather" environment. But I think it's important to include the physical interactions between that environment and the one outside of it, and not only account for interior conditions like air pressure, etc.
In other words, even you don't think it's "due to how unnatural it is to move so far in so short a time", and instead think it's something to do with the cabin conditions?
So it feels just like in college where we had to learn these languages, syntaxes, semantics, before the term ends, and cram and exhaust ourselves before the test.
Cognitive researchers argue late teens to early 20s is the zeitgeist that is the hardest to shake.
That seems to explain the obsession with Reagan era economics and politics of the >50 crowd
Millennials have been in "learn new abstraction" mode for a couple decades regardless such output doesn't really move science forward. Is just learning a new state storage and state mutation syntax
End of the day its labeling some math with some biz edge case
I like the idea of such not being in the code at all. Taking anti-oop to the extreme; code need just be geometric functions to draw on the screen be it text shapes or video game entities
Then we can label on the presentation layer the human context
Then programming can go away.
Maybe a system running a local model is not so bad. The tokens per second will allow for that break?
Also, at what point does AI take over for all the thinking and white board planning?
AI should be a rubber duckie one can use to posit and assist when hit a brick wall. But if using it for all code generation, planning and troubleshooting then one is not in control; they’re just prompt drones…
This gets into how advanced the prompt engineering actually is. I anticipate discussion around what "state-of-the-art" prompts look like, since, as the OpenClaw founder suggested, Prompt Requests may well replace Pull Requests when a set of small tweaks to the prompt may yield vastly improved output.
This of course needs to be coupled with actually staying accountable for what the entirety of the codebase looks like. I imagine many people are unwilling to slow down enough to actually do that accounting/review, and the architecture might gradually shift towards entropy.
>not really due to a time zone difference but due to how unnatural it is to move so far in so short a time.
I'm fairly certain it's the loudness and constant cabin vibration; not temporal mechanics.
Just started at a company and the amount of irresponsible AI use is appalling. I asked an employee whose job involves AI adoption/training how large their diffs are for pull requests. They told me that their diffs are "As much as the model can produce given its reasoning level".
In the end, this is going to create unmaintainable code that no one understands. It also discourages reviewing the code because no dev can meaningfully review 1000s of lines of code in a day while also accomplishing their tasks.
NOTE: I am still pro AI, just like I am pro heavy machinery. I just don't want people to cut off their legs...
Yeah, I dread going back to work as my position has transformed from full stack dev to Ai code unfucker...
why do you care how large the diffs are. isnt there any other way to measure if ai is producing value?
Not OP, but I think it's not about producing value now, but how much it will cost in the long term. If you have unmaintaable code that is N times larger than a hand-written codebase, what is the cost to be?
Its about the team being able to review the code to tell if its slop or not. It's hard to meaningfully review huge changes to a codebase for one PR. Just imagine if there are 5 PRs a day with 1000+ insertions. It leads to the production codebase being somewhat of a black box imo
The problem with articles like this one is, they give ways to become efficient at handling more addiction, at the individual level. Nothing for others part of this, companies developing the software and organizations employing these tools.
Summary of the addiction management tips from the article.
1. Time-box your AI coding sessions with a clear goal and a hard end time.
2. Separate exploration (testing ideas) from execution (shipping code) to avoid losing focus.
3. Prioritize sleep, hard stops, and actual recovery as essential maintenance, not just wellness.
4. Invest in structured training to move from basic usage to advanced multi-agent workflows.
5. Personalize your AI workflow to fit your needs while actively avoiding common anti-patterns.
-
When a developer stops writing code and starts using Claude to handle multiple projects at once, they are essentially managing the outcomes.
They have become 10x engineering managers. The context strain and emotional strain is overwhelming.
I can't agree more. I spent 4 hours debugging an issue with Claude from 10PM to 2AM which I will never do - before Claude.
Same; the most infuriating parts - Claude caused the issue and Claude misdiagnosed the issue, making me spend more time than if I was debugging it myself.
This happens all the time to me. The model emits thousands of lines of high-quality code, making vast progress very quickly, but on the way does a few very, very stupid things a human being would never have been silly enough to do.
Then it takes hours or days - sometimes weeks - to find and fix the AI-induced problems. If you very, very tightly constrain the AI by using structured processes and unit tests you can work wonders with it, but you do start to wonder to what extent this is better than if you had simply coded it yourself.
I basically generate and then remove 80% manually. Way overbuilt and doesn't follow my thinking that well.
That's been my experience. LLMs cost me time, they don't save it.
Then why tf are you using it? I mean, seriously. Truly sounds like addiction.
I think the issue is that obtaining empirical proof of AI or manual coding being more efficient is very difficult, since true costs and outcomes aren’t known for months and often years. AI _is_ faster at producing short term results though, so naturally, given the state of the industry, everyone is piling both money and time into AI driven workflows and manual work is met with suspicion, if not outright discouragement. Engineers might hate AI, but they need their paychecks.
You may be wise beyond your years and are sitting on a goldmine of consulting opportunity if you can actually get tasks done faster without ai given the exact same inputs
Glad to hear that. Gives some hope for the future.
> AI is keeping engineers at their desks longer, not freeing them up. Random rewards, dopamine hits, and no natural stopping points create a loop comparable to casino gambling.
> The fix is deliberate habits, not restricted tools. Time-box sessions, separate exploration from execution, and treat recovery as maintenance.
Getting tired of AI slop telling me about AI.
Yeah do people not know how to do deep knowledge work? Look up Cal Newport habits
agentic coding is a soft drug, so taking 'the only way out is through' approach is pretty viable. once you figure out how to swim and have claude running for an hour+ at a time and only bugging you with either high-level taste decisions or 'done, how's it look?' it's pretty low stress
if you're overloaded with PRs, build LLM-based systems to take the load off. don't be a senior engineer, be an engineering manager.
Or "paying the price" literally. I'm returning after a small break and into new GitHub Copilot prices. A simple question / request / analysis on Sonnet - that will be 29 cents, please. I can't imagine how much it will cost to do actual development with it.
https://archive.is/2pKhN
What type of AI coding? I do not have the attention span to sit there and let these LLMs just churn away. I have to be the one doing the typing or nothing will be accomplished. I tried playing Claude Code and Codex a bit. While impressive in their outputs (at times), I just find the workflow to be so dissatisfying.
One other aspect of LLMs that I do not enjoy when it comes to development is the fact that LLMs minimize my contributions. I do not feel like I can take credit for anything I create if I technically did not create it.
However, I absolutely adore LLMs for learning new concepts and for troubleshooting. To me, that is where they shine the brightest.
Yeah I feel much the same way, though I think LLMs suck ass at troubleshooting. They are almost always going down wrong paths and making bad guesses that I waste time disproving, or suggesting solutions that don't wind up lining up with the symptoms I'm having.
Where I do get value out of LLMs is in two main areas. One is generating short bits of code that I can more or less instantly recognize as correct. Bash scripts are a good example - I can read bash well enough but I'm not great at writing it, so Claude can generate a 20-line script very quickly and I can equally quickly understand the generated code. Writing such scripts would probably take me 15-20 minutes, so I'm not saving huge time, but it's there. The other use case I have is asking the LLM for code review on my personal projects. I don't let it write code (that would destroy the whole fun of the personal project, for one thing), but sometimes I have some code I'm pretty sure sucks and I'll ask ChatGPT to suggest better ways to accomplish the same thing. I learn a lot reviewing its suggestions.