101–110 of 334 posts
I agree with the article and recognize the fatigue, but I have never experienced that the industry is "aggressively pretending it does not exist". It feels like a straw man, but maybe you have examples of this happening.
Code and feature still need to experience time and stability in order to achieve maturity. We need to give our end users time to try stuff, to shape their opinions and habits. We need to let everyone on the dev team take the time to update their mental model of the project as patches are merged. Heck, I've seen too many Product Owners incapable of telling you clearly what went in and out of the code over the previous 2 releases, and those are usually a few weeks apart.
Making individual tasks faster should give us more time to think in terms of quality and stability. Instead, people want to add more features more often.
For me the fatigue is a little different— it’s the constant switching between doing a little bit of work/coding/reviewing and then stopping to wait for the llm to generate something. The waits are unpredictable length, so you never know if you should wait or switch to a new task. So you just do something to kill a little time while the machine thinks. You never get into a flow state and you feel worn down from this c…
Seriously and beyond productivity, flow state was what I liked most about the job. A cup of coffee and noise cancelling headphones and a 2 hour locked in session were when I felt most in love with programming.
For me the fatigue is a little different— it’s the constant switching between doing a little bit of work/coding/reviewing and then stopping to wait for the llm to generate something. The waits are unpredictable length, so you never know if you should wait or switch to a new task. So you just do something to kill a little time while the machine thinks. You never get into a flow state and you feel worn down from this c…
But ... but ... your productivity as an engineer shoots up! You can take on more tasks and ship more! -- Dumbass Engineering Director who has never written a line of code in their life. Unfortunately, with these types of software simpleton's making decisions we are going to see way more push for AI usage and thus higher productivity expectations. They cannot wrap their heads around the fact (for starters) that AI is…
I know more than most there is some baseline productivity we are always trying to be at, that can sometimes be a target more than a current state. But the way people talk about their AI workflows is different. It's like everyone has become tyranical factory floor managers, pushing ever further for productive gains.
Leave this kind of productivity to the bosses I say! Life is a broader surface than this. We can/should focus on be productive together, but leave your actual life for finer, more sustainable ventures.
Earlier quoted context omitted.
I know, hence the emoticon.
I'm somewhat new to HN, but most times I am inclined to add an emoji to a comment, it turns out that neither the tone or content are up to community standards. My other comments probably aren't any better, but those escape my notice!
Some people thrive in more stressful situations, because they don't get as aroused in calmness, but everybody has a threshold velocity at which discomfort starts, higher or lower. AI puts us closer to that threshold, for sure.
This write-up has good ideas but gives me the "AI-generated reading fatigue." Things that can cleanly be expressed in 1-2 sentences are whole paragraphs, often with examples that seem unnecessary or unrealistic. There are also some wrong claims like below: > The Hacker News front page alone is enough to give you whiplash. One day it's "Show HN: Autonomous Research Swarm" and the next it's "Ask HN: How will AI swarms…
The headline is clickbait-y but I think the article is well articulated. I found the "What actually helped" helpful too.
> Time-boxing AI sessions.
Unless you are a full-time vibe coder, you already wouldn't be using AI all the time. But time boxing it feels artificial, if it's able to make good and real progress (not unmaintainable slop).
> Separating AI time from thinking time.
My usage of AI involves doing a lot of thinking, either collaboratively within a chat, or by myself while it's doing some agentic loop.
> Accepting 70% from AI.
This is a confusing statement. 70% what? What does 70% usable even mean? If it means around 70% of features work and other 30% is broken, perhaps AI shouldn't be used for those 30% in the first place.
> Being strategic about the hype cycle.
Hype cycles have always been a thing. It's good for mind in general to avoid them.
> Logging where AI helps and where it doesn't.
I do most of this logging in my agent md files instead of a separate log. Also after a bit my memory picks it up really quickly what AI can do and what it can't. I assume this is a natural process for many fellow engineers.
> Not reviewing everything AI produces.
If you are shipping in an insane speed, this is just an expected outcome, not an advice you can follow.