348 points by tjohnell 8 days ago | 213 comments on HN
| Neutral High agreement (3 models)
Editorial · v3.7· 2026-03-16 00:04:43 0
Summary Labor Rights & Digital Wellness Advocates
This technical blog post advocates for sustainable work practices with AI tools, emphasizing worker agency, rest, and mental health awareness. The author frames technical skill development through ethics of self-care, fatigue recognition, and deliberate problem-solving—implicitly advancing rights to fair labor conditions (Article 23), rest and leisure (Article 24), health and wellbeing (Article 25), and education (Article 26). However, the site implements privacy-invasive analytics tracking without visible consent mechanisms, creating a structural tension between the content's wellness advocacy and platform practices that monitor user behavior.
Rights Tensions2 pairs
Art 12 ↔ Art 19 —Content advocates free expression while site infrastructure implements tracking that collects user behavior data without visible consent, subordinating privacy rights to engagement monitoring practices.
Art 23 ↔ Art 12 —Content advocates fair labor and rest rights while site analytics track user engagement patterns, potentially enabling exploitative labor surveillance practices the article argues against.
I wanna say that it is indeed a “skill issue” when it comes to debugging and getting the agent in your editor of choice to move forward. Sometimes it takes an instruction to step back and evaluate the current state and others it’s about establishing the test cases.
I think the exhausting part is more probably more tied to the evaluation of the work the agent is doing, understanding its thought process and catching the hang up can be tedious in the current state of AI reasoning.
I find LLMs so much more exhausting than manual coding. It’s interesting. I think you quickly bump into how much a single human can feasibly keep track of pretty fast with modern LLMs.
I assume until LLMs are 100% better than humans in all cases, as long as I have to be in the loop there will be a pretty hard upper bound on what I can do and it seems like we’ve roughly hit that limit.
Funny enough, I get this feeling with a lot of modern technology. iPhones, all the modern messaging apps, etc make it much too easy to fragment your attention across a million different things. It’s draining. Much more draining than the old days
I wonder if it's more or less tiring to work with LLMs in YOLO/--dangerously-skip-permissions mode.
I mostly use YOLO mode which means I'm not constantly watching them and approving things they want to do... but also means I'm much more likely to have 2-3 agent sessions running in parallel, resulting in constant switching which is very mentally taxing.
In agent-mode mode, IMO, the sweet spot is 2-3 concurrent tasks/sessions. You don’t want to sit waiting for it, but you don’t want to context-switch across more than a couple contexts yourself.
I have always enjoyed the feeling of aporia during coding. Learning to embrace the confusion and the eventual frustration is part of the job. So I don’t mind running in a loop alongside an agent.
But I absolutely loathe reviewing these generated PRs - more so when I know the submitter themselves has barely looked at the code. Now corporate has mandated AI usage and is asking people to do 10k LOC PRs every day. Reviewing this junk has become exhausting.
I don’t want to read your code if you haven’t bothered to read it yourselves. My stance is: reviewing this junk is far more exhausting. Coding is actually the fun part.
Most people reading this have probably had the experience of wasting hours debugging when exhausted, only to find it was a silly issue you’ve seen multiple times, or maybe you solve it in a few minutes the next morning.
Working with an agent coding all day can be exhilarating but also exhausting - maybe it’s because consequential decisions are packed more tightly together. And yes cognition still matters for now.
It looks like Stockholm syndrome or a traditional abusive relationship 100 years ago where the woman tries to figure out how to best prompt her husband to do something.
You know you can leave abusive relationships. Ditch the clanker and free your mind.
Of course. Any scenario where you are expected to deliver results using non-deterministic tooling is going to be painful and exhausting. Imagine driving a car that might dive one way or the other of its own accord, with controls that frequently changed how they worked. At the end of any decently sized journey you would be an emotional wreck - perhaps even an actual wreck.
LLMs do not actually make anything better for anyone. You have to constantly correct them. It's like having a junior coder under your wing that never learns from its mistakes. I can't imagine anyone actually feeling productive using one to work.
I find working more asynchronous with the agents help. I've disabled the in-your-face agent-is-done/need-input notifications [1]. I work across a few different tasks at my own pace. It works quite well, and when/if I find a rhythm to it, it's absolutely less intense than normal programming.
You might think that the "constant" task switching is draining, but I don't switch that frequently. Often I keep the main focus on one task and use the waiting time to draft some related ideas/thoughts/next prompt. Or browse through the code for light review/understanding. It also helps to have one big/complex task and a few simpler things concurrently. And since the number of details required to keep "loaded" in your head per task is fewer, switching has less cost I think. You can also "reload" much quicker by simply chatting with the agent for a minute or two, if some detail have faded.
I think a key thing is to NOT chase after keeping the agents running at max efficiency. It's ok to let them be idle while you finish up what your doing. (perhaps bad of KV cache efficiency though - I'm not sure how long they keep the cache)
(And obviously you should run the agent in a sandbox to limit how many approvals you need to consider)
[1] I use the urgent-window hint to get a subtle hint of which workspace contain an agent ready for input.
EDIT: disclaimer - I'm relative new to using them, and have so far not used them for super complex tasks.
I am rewriting an agent framework from scratch because another agent framework, combined with my prompting, led to 2023-level regressions in alignment (completely faking tests, echoing "completed" then validating the test by grepping for the string "completed", when it was supposed to bootstrap a udp tunnel over ssh for that test...).
Many top labs [1] [2] already have heavily automated code review already and it's not slowing down. That doesn't mean I'm trusting everything blindly, but yes, over time, it should handle less and less "lower level" tasks and it's a good thing if it can.
- You are allowed to complain about anything, while not improving things yourself.
I think the mid 2010s really popularized self improvement in a way that you can't really argue with (if you disagree with "put in more effort and be more focused", you're obviously just lazy!). It's funny because the point of engineering is to find better solutions, but technically yes, an always valid solution is just "suck it up".
But moreover, if you do not allow these two premises, what ends up happening in practice for a lot of people, is that basically you can just interpret any slightly pushback as "oh they're just a whiner", and if they're not doing something to fix their problem this instant, that "obviously" validates your claim (and even if they are, it doesn't count, they should still not be a "debbie downer", etc.).
Sometimes a premise can sound extreme, but people forget that premises are not in a complete logical vaccuum, you actually live out and believe said premises, and by taking on a certain position, it's often more about what follows downstream from the behavior than the actual words themselves.
One way to help, I think, is to take advantage of prompt libraries. Claude makes this easy via Skills (which can be augmented via Plugins). Since skills themselves are just plain text with some front matter, they're easy to update and improve, and you can reuse them as much as you like.
There's probably a Codex equivalent, but I don't know what it is.
The article frames this as a skill issue, but there's a more structural problem underneath: LLMs fundamentally shift work from generation to verification, and those two activities have very different cognitive profiles.
Writing code is flow-state compatible. You build up a mental model, hold it in working memory, and produce output in a continuous stream. Reviewing LLM output requires constant context-switching between "what does this code do" and "is this what I actually wanted." That's cognitively expensive in a way that no amount of prompt engineering fixes.
The exhaustion isn't primarily from bad prompts or slow feedback loops. It's that the LLM turned you from a writer into a full-time reviewer, and reviewing is harder work per unit of output than writing. The productivity gain is real, but the effort doesn't feel lower because you traded one kind of cognitive effort for a more draining one. The task-switching cost between "understanding intent" and "verifying implementation" is well-studied in cognitive science and it's not something you can optimize away with better technique.
Your human context also needs compacting at some point. After hours of working with an LLM, your prompts tend to become less detailed, you tend to trust the LLM more, and it's easier to go down a solution that is not necessarily the best one. It becomes more of a brute forcing LLM assisted "solve this issue flow". What's funny is that it sometimes feels that the LLM itself is exhausted as well as the human and then the context compacting makes it even worse.
It's like with regular non-llm assisted coding. Sometimes you gotta sleep on it and make a new /plan with a fresh direction.
This is exactly what was needed. Seamlessly transitioning from manual inspection in the Elements/Network panels to agent-led investigation is going to save so much 'context-setting' time.
I learned years ago that I when I write code after 10 PM, I'm go backward instead of forward. It was easy to see, because the test just wouldn't pass, or I'd introduce several bugs that each took 30 minutes to fix.
I'm learning now that it's no different, working with agents.
The shift from creation to verification is real, but I think the bigger
issue is people treating LLM output as a black box to review. What works
better: write specs and tests first, then let the LLM implement against
them. You're no longer "reviewing code" — you're checking if tests pass.
The cognitive load drops dramatically when verification is automated
rather than manual.
I think the upper limit is your ability to decide what to build among infinite possibilities. How should it work, what should it be like to use it, what makes the most sense, etc.
The code part is trivial and a waste of time in some ways compared to time spent making decisions about what to build. And sometimes even a procrastination to avoid thinking about what to build, like how people who polish their game engine (easy) to avoid putting in the work to plan a fun game (hard).
The more clarity you have about what you’re building, then the larger blocks of work you can delegate / outsource.
So I think one overwhelming part of LLMs is that you don’t get the downtime of working on implementation since that’s now trivial; you are stuck doing the hard part of steering and planning. But that’s also a good thing.
I imagine code reviewing is a very different sort of skill than coding.
When you vibe code (assuming you're reading teh code that is written for you) you become a coder reviewer... I suspect you're learning a new skill.
If you care at code quality of course it is exhausting. It's supposed to be. Now there is more code for you to assure quality in the same length of time.
I always wonder where HNers worked or work; we do ERP and troubleshooting on legacy systems for medium to large corps; PRs by humans were always pretty random and barely looked at as well, even though the human wrote it (copy/pasted from SO and changed it somewhat); if you ask what it does they cannot tell you. This is not an exception, this is the norm as far as I can see outside HN. People who talk a lot, don't understand anything and write code that is almost alien. LLMs, for us, are a huge step up. There is a 40 nested if with a loop to prevent it from failing on a missing case in a critical Shell (the company) ERP system. LLMs would not do that. It is a nightmare but makes us a lot of money for keeping things like that running.
I don't know what to think about comments like this. So many of them come from accounts that are days or at most weeks old. I don't know if this is astroturfing, or you really are just a new account and this is your experience.
As somebody who has been coding for just shy of 40 years and has gone through the actual pain on learning to run a high level and productive dev team, your experience does not match mine. Even great devs will forget some of the basics and make mistakes and I wish every junior (hell even seniors) were as effective as the LLMs are turning out to be. Put the LLM in the hands of a seasoned engineer who also has the skills to manage projects and mentor junior devs and you have a powerful accelerator. I'm seeing the outcome of that every day on my team. The velocity is up AND the quality is up.
Yes, I briefly felt like I needed to keep agents busy but got over it. The point of having multiple things going on is so you have a another task to work on.
You used to be a Formula 1 driver. Now you are an instructor for a Formula 1 autopilot. You have to watch it at all times with full attention for it's a fast and reckless driver.
> Now corporate has mandated AI usage and is asking people to do 10k LOC PRs every day.
That's a big red flag if I ever saw one. Corporate should be empowering the engineering team to use AI tooling to improve their own process organically. Is this true or exaggeration? If it's true I'd start looking for a more balanced position at more disciplined org.
I've always preferred brownfield work. In the past I've said "it's easier to be an editor than an author" to describe why. I think you're on to something. For me the new structure's cognitively easier, but it's not faster. Might even be slightly slower.
It's orthogonal IMO. YOLO or not is simply a sign of trust for the harness or not. Trust slightly affects cognition, but not much. My working hypothesis: exhaustion is the residue of use of cognition.
What impacts cognition for me, and IMO for a lot of folks, is how well we end up defining our outcomes. Agents are tremendous at working towards the outcome (hence by TDD red-green works wonderfully), but if you point them to a goal slightly off, then you'll have to do the work of getting them on track, demanding cognition.
So the better you're at your initial research/plan phase, where you document all of your direction and constraints, the lesser effort is needed in the review.
The other thing impacting cognition is how many parallel threads you're running. I have defaulted to major/minor system - at any time I have 1 major project (higher cognition) and 1 minor agent (lower cognition) going. It's where managing this is comfortable.
Article expresses opinion and reflective commentary on LLM use without fear of interference. Author freely shares personal technical perspectives and problem-solving approaches.
FW Ratio: 50%
Observable Facts
Content expresses personal perspective on LLM workflow challenges, fatigue management, and problem-solving strategies without disclaimers or restrictions.
Page displays no access barriers; full article text renders without login or subscription requirement.
Inferences
The author freely communicates reflective analysis of technical practices, demonstrating uninhibited expression of opinion on tools and methods.
Open access structure supports reader freedom to seek, receive, and impart information about AI development practices.
Author reflects on work practices and feedback cycles in AI-assisted development. Discusses craft pride and the value of thoughtful problem-solving, implicitly affirming the dignity of meaningful work.
FW Ratio: 50%
Observable Facts
Article emphasizes the importance of 'enjoying the act of writing the perfect prompt' and seeking fulfillment in problem-solving work.
Author contrasts rushed, low-quality work ('half-assing it') with deliberate, crafted approaches to AI collaboration.
Inferences
The emphasis on meaningful work, metacognition, and the need to 'throw in the towel' when losing joy in the craft suggests implicit valuation of work dignity and appropriate working conditions.
Discussion of feedback loops and iteration rhythm reflects concern for sustainable work practices.
Content does not explicitly discuss privacy, but the author reflects on personal fatigue and mental processes in technical work, which implicitly touches on the integrity of personal thought and rest.
FW Ratio: 50%
Observable Facts
Page contains embedded JavaScript that sends engagement data to /hit/ endpoint with referrer, title, and score parameters on page load or user interaction.
Upvote system queries /upvote-info/ endpoint to track user engagement state.
Inferences
The tracking mechanisms operate without visible privacy consent banner or notice on the article page, suggesting limited transparency about data collection practices.
Analytics tracking combined with engagement monitoring creates a profile of reader behavior without explicit informed consent.
Content does not directly address health, food, housing, or medical care rights.
FW Ratio: 60%
Observable Facts
Page includes ARIA labels on interactive elements (upvote button displays 'ariaLabel' property).
CSS includes media query for dark mode preference: '@media (prefers-color-scheme: dark)'.
Responsive image sizing and mobile layout support (@media max-width: 600px) ensures readability across devices.
Inferences
Accessibility features (ARIA labels, dark mode, responsive design) support equitable access for users with visual sensitivities or varying device capabilities.
These structural affordances support broader participation in the digital information environment.
Site implements tracking via image beacon for analytics and upvote/engagement monitoring without explicit privacy notice visible in content. Tracking occurs on page load via fetch and pixel tracking.
Terms of Service
—
No Terms of Service document found on-domain or linked from visible content.
Identity & Mission
Mission
—
No explicit mission statement found. Site appears to be a personal technical blog focused on software engineering practices and AI development.
Editorial Code
—
No editorial standards document or code of conduct visible on-domain.
Ownership
—
Single author (Tom Johnell) identified; appears to be independent personal blog.
Access & Distribution
Access Model
+0.05
Article 19 Article 26
Content is freely accessible with no paywall. Email and RSS subscription options provided, expanding access methods.
Ad/Tracking
-0.05
Article 12
Analytics tracking via custom pixel endpoint (/hit/) collects referrer data and engagement metrics without explicit opt-in consent visible.
Accessibility
+0.10
Article 25 Article 26
Site includes semantic HTML (article schema.org markup), ARIA labels on interactive elements, supports dark mode preference detection, and responsive design for mobile access.
Site provides free, unrestricted access to published content with no paywall or registration requirement blocking readership. RSS and email subscription options expand access methods.
Site implements analytics pixel tracking (/hit/) and upvote engagement monitoring that collects referrer data without explicit opt-in consent or prominent privacy notice.
Author reflects on work practices and feedback cycles in AI-assisted development. Discusses craft pride and the value of thoughtful problem-solving, implicitly affirming the dignity of meaningful work.
Site implements responsive design, dark mode preference detection, semantic HTML, and ARIA labels that expand access for users with varying abilities and device preferences.
Free access model with multiple subscription options (email, RSS) supports knowledge access. Semantic HTML and accessible design enhance usability for learners with diverse needs.