Ask HN: Are you tired too in this AI era?
Although AI lets us do much more, I feel considerably more tired than before.
We need to keep track of many things happening in parallel and read enormous amounts of generated text. The constant guardrailing, decision making, and context switching overload me.
I am pretty sure most of you are experiencing the same as me, but: Have you found ways of using AI without increasing mental overload?
I would love to hear your tips, but still be relevant in this AI era, so my boss does not fire me.
118 comments
[ 2.6 ms ] story [ 43.2 ms ] threadClaude Web works differently than Claude Code. I use Claude Web/Chat for briefs, general overview of the project outside of code/app, for planning and handing off the work to Code, that includes prompts. Code is tasked to output a detailed view of what it found, run measurements and tests (designed both by me and Chat) and report findings back. That is fed back to Chat and I get a rough summary. Errors are categorized by their blast-radius and so on.
Eventually I do a deep dive of what changed, how well it's handling, how much it's struggling, token usage, time spent per review/test and so on. (btw, Code is tasked to run an independent review via contextless agent on the codebase, that easily costs me another 20-30 mins and ~200K tokens on my current project, each run).
It still makes architectural issues, tries bandaiding and patching instead of properly designing, overvaluing/devaluing certain cases and misallocating where most of the focus should be, but that's relatively easier to spot and propose a fix for than doing a line by line code review.
Codebase quality is ensured through mapping the flow and the output space and having a hard-pinned tests Code can't modify to green its answers, + the independent reviewer I mentioned above.
It's not as fun as going in by hand on deep technical problems, sure. But AI usage is less about fun and more about output speed, so use it for what it is for ig? :D
That your workplace, not "AI era".
More of what? I see many here using AI to build more of the same things in another language such as rewrites and then claiming that they are "productive", which is the problem of many engineers here.
Not that much risk taking if all what everyone is doing is just full blown rewrites and then abandoning it in a couple of months later and just wasting tokens for free.
If the result is to vibe code something for free and it makes no money and has no users then it is a waste of time.
Clearly there are few limits to what you can implement with AI agents today.
Depending on the complexity, you will spend a lot of time QA testing, giving feedback, and iterating.
One can take shortcuts such as porting existing software, as you mentioned. Many are just content publishing crappy novel software that they barely tested.
You don't need to do that. No one is forcing you not to QA test and iterate until you have a good product.
AI is a boon for learning, but the result will heavily depend on mental capability of the user; having a depression-induced brainrot doesn't help though.
And, in the last year clankers have started coming for us EEs.
The reality is that many people are more fucked than I am, but I can't stop the bad thoughts.
Get your practical skills in residential and commercial electricity up to speed and join the trades. The world is going for solar, heat pumps and electric vehicles no matter what corrupt politicians want (yay free market for once, lol), and that means there will be demand for people actually pulling wires and installing cabinets for decades to come.
I feel incredibly productive. I'm building in an afternoon what would've taken weeks. I spend all my time in either MR's reviewing code, or a terminal prompting.
I've moved from being a coder, to being a product-engineer-architect. I love coding -- LOVE it. But the role has morphed. And, I actually really like the new role. I love being product centric, and caring about architecture -- it suits me wel..
The code Claude produces is often clean, but terribly archictected. So I'm spending a lot of time reviewing in detail.
But the anxienty - OMG the anxiety.
I work on multple features (generally 4-5 work streams) concurrently, so am constantly context switching. I worry about how much time I'm spending on each task. Am I doing enough code review? Too much? Too little?
What about click-through testing? Our test coverage has never been higher - should I be able to just merge these features? Wasn't that always the promise of TDD - merging with confidence? But, it feels like a risk.
And, I'm moving really really fast - but I assume my competitors are too. So that drives me to move faster. Automate more. Use claude in more places. Which brings more anxiety - am I cutting too many corners? Is this all gonna crumble on me?
Also, is everything I'm working on going to become irrelevant? Will customers buy this product, or vibe code it? Do we even have a moat? Anxiety. More anxiety.
My investors are reading stuff constantly too. They're pinging me with market updates, emerging players, shifting landscapes. More anxiety. Also - productivity tools - look - internet influencer X is now producing a gajillion lines of code a second -- are we doing that? Are we token maxing? Are we feature maxing?
Are we building the right number of internal tools? Are we automating enough? Should I evaluate the market for this new tool, or just smash something out with claude? More features. Burn more tokens. Ship ship ship.
Having to explain to investors why we're not going as fast as those guys, and building enterprise products requires care and dedication -- that takes time. Time I should be shipping, coding, featuring, tokenizing. More anxiety.
I'm exhausted.
Anyway, gotta go - herdr has pinged me four times during writing this reply. Gotta ship.
Are people reviewing all the tests that have been created automatically?
What about existing tests? How do we make sure that AI does not fake them by silently (by silent changes or by faking the test output)?
Absolutely not! Some people ask a code assistant to write only integration/end-to-end tests and commit them. Unittests is only to help LLM generate correct code.
- spending more time upfront working with agent on intent of the change, then design, so agent does not try to work around issues in a way that I don't intend to
- investing in ways in which agent can verify it's own change
- giving access to as much prod telemetry, etc so it can also verify the change post-merge
- obvious stuff, like automated review loops etc
But in the end I still read the "load bearing" parts of the code. Less closely, and I've long ago stopped looking at the tests. It's better for me than couple of months ago.
I spend about 90% of at-computer time in a herdr-like tool.
It feels like playing factorio: whatever is manual needs to be automated away.
LLM writes the test. The test is crap. Update the skill. Ask an LLM to review your feedback on the last 5 PRs and write a skill for a review bot to look for similar problems and post. Now you only see PRs after they've gone through a few rounds of review.
The LLM has stopped picking up new issues. Ask an LLM to diagnose why. Ask an LLM to write a cron to regularly check if the LLM PR pipeline has halted and ping you. Get an LLM to try to diagnose it first.
I'm using a lot of LLMs! Ask an LLM to diagnose why. Write a tool to audit your usage, and produce a weekly report. Have it raise issue to reduce spending.
And like a base building game there are many competing facets, coming all at once.
In factory building games, the systems in play can be understood and are fully deterministic. You're given a set of tools and a problem, and then craft together a solution. Your reward isn't just seeing the item you want on a conveyor belt, but looking at the factory you built ticking like clockwork.
What you're describing is beating out endless nondeterministic fires. It's like you were forced to play Factorio exclusively through an algorithm that designs incomprehensible factories that don't work sometimes, but designs them much faster than you ever could. So you click the magic button and see a mass of buildings appear in front of you. They may work perfectly fine, but if they don't, you need to use the same statistical factory estimator to build an in-game factory fixer mechanism and factory tester mechanism. And then a few updates later the factory fixer breaks so you need to deploy a factory fixer fixer, and a belt clean-up machine, and so on ad infinitum. To me this doesn't seem satisfying in the slightest.
I think we (software engineers) are suffering from partial blindness to this aspect of engineering given that software has always been so extremely deterministic. We've trained ourselves that solving a problem means composing small fully deterministic parts into deterministic systems, and the prospect of having to work more with statistical confidence and managing failure modes feels scary and wrong.
a recipe for omni-disaster
I understand that faster results may be rewarding; But nothing as rewarding then refactoring some legacy application by hand and deleting 50% more LoC then adding/modifying. Or picking the exact right abstraction now which I will use in two weeks from now and happily grind on my solid, craftsmen stones layed out beforehand.
Imho our craft was not understood beforehand. Now folks think they can grasp everything one mentions on the same level - they have "built" similiar things with ai. So it is even more frustrating to argue about stuff.
It is the worst technology ever emerged imho.
Now instead I don't get to code anymore and I'm the manager of a half-dozen mid-level engineers with unflappable confidence and very, very poor long term memory.
This is something I avoid at all costs. If it's someone else's slop I just won't read it, and if it's "my" slop I prefer to interactively ask questions about it rather than reading a wall of text.
LLMs appear to be able help me get through that. I'll take the help.
BUT JEEZ! Dealing with "Rain Man"[1] LLMs week-in and week-out is wildly annoying, frustrating, and anger inducing.
If they all would just STOP sounding so authoritative when spewing nonsense!
[1] After the Dustin Hoffman character in the movie of the same name. "Ah but you know I'm an excellent d̴r̴i̴v̴e̴r̴ programmer."
Sometimes I feel please someone give me a job where I can work 12 hours a day - but the rest of the 12 hours I don't need to think about what will happen tomorrow.. It will still be less stressful.
Why do you dream about working 12h a day when 8h is pretty standard.
But then I have to repeat this lecture to so many people it’s wearing me down. I’ve mostly resorted to just not reading it and simply ignoring any AI text sent to me.
I realised how easy it is for me to build the dash.
But how hard it is to sit down for 1 hour, look at the pages, scroll through them as if I am my client, notice inconsistencies, notice where the numbers don't make sense.
Sitting down, and actually checking and comparing and thinking were already hard before AI, and they became a lot harder.
Yes, reviewing an LLM code is at times infuriating, but at least I can be brief and direct, rather than spend 2x the effort trying to make sure it won't be interpreted as harsh.
For me it's very exciting and AI has been so far a crazy enabler for me. Both in my work and my personal life.
But I also enjoy keeping up with it and reading about it etc.
FWIW, there might be a silver lining in this. A lot of dysfunction in the current state of tech can (IMO) be traced back to violation of boundaries. This might lead to a cultural shift. Though, that might also just be wishful thinking on my part.
___
> I would love to hear your tips, but still be relevant in this AI era, so my boss does not fire me.
If your boss fires you because you didn't multiply your performance by doing more work in the same time (without your compensation changing), that's not your fault but simply your employer trying to squeeze you harder and that not working out.
Always keep that in mind in these discussions.
Which isn't to say that you should not improve efficiency and all, but it needs to be organic. If something inorganic is asked, then the (moral) failure is on the asker and not the askee.