Hacker News Reader

Comment by cautiouscat | Hacker News Reader

I admittedly flip-flop on this quite a bit. I use LLMs in my work and for a bunch of pet projects I don’t really care much about.

For the pet projects, it’s not really a big deal. I’m the only user, and I as the user don’t care how it works under the hood.

Work is a different story. I have never felt more disconnected from my work than in the last 6-8 months. It takes a huge mental toll to read into our code and figure stuff out, almost like I just got hired and I’m working on new code for the first time. I’m asked to read “specs” written by LLMs that are unintelligible and I find my brain disconnecting immediately. Tickets, also written by LLMs pose the same problem.

I’m asking teammates questions because I want their answer and I’m told to just ask Claude.

None of this feels good, it may be where the industry is heading but as a professional it feels wrong.

View on HN

A lot of the "none of this feels good" is that the models have been RL'd to produce longer and longer outputs. You don't start with a 1 paragraph explanation, being forced into a back-and-forth with the model so much anymore, unless you explicitly ask. Instead, it'll generate a 10 page report that you sorta-skim and the hooks of your attention skid off, and you prompt something vague like "make it shorter".

when llms write all the code, all we have left are the specs. ive found a lot of success applying software engineering discipline to spec writing and making it a human-only activity. from there hand the spec to LLM with a few guardrails around implemention and writing quality tests that prove the spec.

PRs review more quickly when you have human written spec diffs to orient you and guide (or skip) the code review.

a danger to avoid is writing specs which are basically just really bad code (prose is terrible code). you can work towards patterns to avoid this pitfall.

also, dont coflate spec with plan. spec is durable decisions. plan is execution to turn decisions into code. plan is disposable, dont check it in.

either way, find the human layer and dont use LLMs there. make all the important decisions in the spec, delegate the other decisions to the LLM.

i believe this is the new craft.

that said, i expect a small but significant exodus from software. a lotta folks came for the "programming" that is now being outsourced. were becoming so tired, just absolutely burning out.

i hope we will eventually realize its time to go, instead of giving up our souls for a fucking paycheck.

What I hate the most is people vomiting AI slop communicating with others. I have teammates who decided that an agent producing a wall of text summarizing changes in a pull request instead of a simple "LGTM" is a good idea. I have teammates who talk using AI almost exclusively (you can see a small tag "Sent using Claude" or "Sent using Cursor" under their messages)

Posing a well considered, concise and precise question only to get a wall of Claudeisms in response from a colleague is always demoralizing. Then you have to play the guessing game of 'is this detail in the response true, or did Claude make it up for them?'

> I have teammates who talk using Claude almost exclusively.

If somebody told that humans are a form of creature which can forego their most important and powerful capabilities just for convenience, I'd call the person saying that batshit insane, but here we are...

I have no more words for this.

a teammate who exclusively writes slop PRs and copy/paste LLM responses to slack has demonstrated they can be replaced by an LLM integration to slack and github.

also, take some fucking pride in your work.

If your company cares enough/will allow it, make a written policy that authors are responsible for their code and they must still meet whatever quality bar existed at your company pre-LLMs. It's awkward, but I've seen friends whose companies have started to make it normal to say "I'm not reviewing this, it was clearly written by AI" the same way pre-LLMs you could also say "I'm not reviewing this because it's 5k LoC and needs to be split up into smaller reviews".

Then if people send you slop you can either point them to the guidelines or, if they don't stop, report them for violating workplace rules and make them suffer.

I'm feeling the same, personal projects have never felt better, but work has slowly felt more miserable.

Code reviews come back with a ream of issues that I just want to scream "I don't give a fuck".

Pre-LLM no-one would have cared that if another class was configured differently ( it isn't ) and called the new class in a different way ( it doesn't ), that you'd in some race-condition occasionally leak a resource, but only on shutdown when the program is about to terminate anyway.

That's the kind of issue that claude loves to find and write up in a code review with the exact same verbiage and write up style as if it had just found a naive SQL injection from string concatenation.

Prior to LLMs I doubt anyone would even have spotted the first issue, let alone bothered to write it up.

But instead it's another round of review, another round of trying to decipher the LLM's comments to discover whether it's a meaningful problem or a nothingburger.

And it's all so tiring.

I'm absolutely not destroying my cherished "pet" projects with this shit.

Reply on news.ycombinator.com