Hacker News new | ask | show | jobs
by roncesvalles 39 days ago
These days nobody bangs their heads over typos.

LLMs evaporated 90% of the "moments of despair" when you have an error and googling it isn't helping, or googling it made you realize you have to read 30min of documentation.

Coding is a joy now. LLMs shaved off all the rough edges.

7 comments

They created other kinds of despair.

A year ago I would've told my boss “can't be done” about my work today. I'd tell him to get me the right person to talk to (our partner, not an alien) who could give me some insight into what the hell I'm supposed to be doing to consume their API. Or to at least explain why it is that this can't be done.

Nowadays, I spent a couple of weeks reverse engineering their terrible ideas. Yeah, it worked. But it's a complete waste of my time, and tokens, energy, chips and RAM. And worst of all, it will lead to a terrible design.

That will work, but will eventually colapse under its own weight, as we use our increased power to increase our sloppiness and take it a little further. Because we can manage it. For now.

LLMs moved the moments of despair to PR reviews for me. It used to be that you could check on a junior dev occassionally throughout the day to make sure they're on the right track. Now you step away for 2 hours and they're raising a PR of bad code smell spaghetti and moving on to repeat their AI slopfest on the next task.

It's getting hard to keep up with trying to teach new devs what bad code looks like. And I swear sometimes they just copy my PR comments into their AI tool to fix the mistakes without any of the learning.

At some point there needs to be an uncomfortable conversation about how if all they’re doing is copy pasting everything they get from you into ChatGPT, you can do it yourself for much much cheaper.
how? management in most Tech companies are incentivizing them to do just that, so if you bring it up, they'll happily trot over to your manager to complain and then the uncomfortable conversation is you with management about why you're getting in the way of AI uptake by the team.
Don’t allow juniors to use AI. It’s like university exams: no programmable calculators allowed. Review assistants or senior who know what’s going on should though, it does help when used correctly
Write a damn good automated review agent that runs against their PRs before even looking at them… works well for me!
I've tried this without much luck. In my experience they get too bogged down on surface things and don't have the necessary business requirements/context to understand and find actual bugs.

How have you set yours up that works well for you?

So create a context document that explains the business context, and add that to the agent.

Take the bad result that you're getting, and pretend it's coming from an enthusiastic junior. What would you tell them to make them do this task better? Add that explanation to the agent (or explain that to the LLM and get it to add that to the agent, I have found this to work as well).

When you create a task for the LLM, get it to create a requirements document that lists all the requirements. Feed that into the review agent so it understands what the code agent was trying to do.

The LLM will do what you tell it to do. It doesn't magically understand what you want it to do. You have to tell it what to do.

You can't possibly believe this, or you and me (and many others) are doing something different. LLMs have created an entire new - huge - set of bang-your-head moments, as they go off half-cocked in a million simultaneous directions, chasing their tail, or just making shit up. And since the vast majority of work is on existing - often ancient - codebases, let's find out if you feel the same way in 18 months.
LLMs are great for anyone who isn't responsible for the consequences of what they code.
Maybe I'm weird, but my usage has been very conservative. As in, I treat the LLM like a junior dev that I have to micromanage and handhold.

I am terrified of allowing these things to complete tasks end-to-end with nothing intervening. Maybe that's why I don't run into many of these issues. I mostly delegate grunt work and manual tedium, not reasoning or design choices to the LLM. I may consult the LLM and ask for criticism, but there is no way I'm going to allow it to quietly make design decisions that I don't know about.

That's only if you do agentic coding.

I use LLMs in the following ways:

1. Copy-pasting code into the web chat UI and asking for something (bugfix, add a feature, refactor, explain, review it etc), including entire source code files. A $20/mo Gemini subscription goes a long way (never been rate-limited). I only use the highest model. I often just copy-paste the entire source file between 3 backticks.

2. Cursor Tab. I do have hotkeys to enable and disable it; it's disabled most of the time otherwise it gets annoying.

3. Single-file changes directly from Cursor's AI sidebar. I only do this for simple, predictable stuff because even their auto-routing "Premium" setting is not as good as pasting stuff into Gemini 3.1 Pro.

That means I have only two $20/mo subscriptions: Gemini and Cursor.

I don't use Claude Code, it's really for people who don't know how to code. I don't use Plan Mode; I make and track the plan myself (if at all). I only tell the LLM granular tasks to execute. I don't use `claude.md` or `agents.md` or anything like that. If I don't like a particular output, I reset everything, modify my prompt and try again.

I believe this is the only way to fully leverage LLMs without losing any product quality. If you're trading off quality for "speed" (in quotes because over the long term, a low quality codebase is a massive drag on productivity) then there's no point.

I _think_ what you’ve said is “go shallow, not deep”. That is, don’t let the walk you make inside the latent space a long one. Twenty-five short and peppered steps, from de novo, is better than one long, protracted stew.

Is that accurate?

Well yeah. If you know what you're doing, why would you let the AI take control?
Well, if it works on step one, then why not step two? Where would different folks draw the line? My grandparents might continue on a while, whereas I would not. But if it also “works” on step two for me, should I take a third?

What counts as “works” is the important bit, I think.

Yes, if you're using them to write large chunks of code or entire features. If you just use them to clear up some trivial problem in an unfamiliar technology that you used to spend 30 minutes googling with 50 tabs open, or stuff like write a method to filter, map and reduce an array based on specific criteria, they're a godsend.
Give them work in smaller chunks.
You are in charge of what the LLM does. If it's running off half-cocked in a million simultaneous directions, that's on you. Write better skills. Tell it not to do that. Break into its loop and ask it wtf it thinks it's doing. If it's making shit up, force it to test more.

The LLM will do what you tell it to do. Manage it.

Languages have been reporting compile and runtime errors for decades. Additionally very few senior developers don't already have their minds wired to spot typos the way copy editors spot bad punctuation. Typos were only really a problem for students.
I've been writing C++ for almost 20 years at this point and I do still benefit from how good Claude is at gnarly Template error messages.
> LLMs evaporated 90% of the "moments of despair"

And then condensed an equal quantity of despair out of the ether via confident confabulations.

Equal? No, no no no. Upper management is making PoCs that promise to solve longstanding multi year learnings of tradeoffs and solution balancing, and setting goals based on that. We are heading to a cliff and everyone is going to learn what happens when you replace already vulnerable foundation pillars with pig iron.
100%. Googling when you don't even know enough to ask the right questions, with 50 tabs open and trying to read down to the 3rd or 4th Stack Overflow answer (which is usually the best for some inexplicable reason), was my least favorite part of development.

I don't miss wasting an hour on a problem in a technology I'm not familiar with, where it's not like a big conceptual thing but something I could clear up in 5 seconds if I just had an expert in the room.

LLMs create typos in the code they create all the time. Claude 4.7. Maybe you are using some next-gen super-AI nobody else has? Or you're just lucky.
So get the LLM to test and fix those typos. Why are you letting it mis-spell things?
Maybe you aren't familiar with how AI works. It writes the code for you. Nobody is "letting it mis-spell things". You run the code it wrote, it fails. You look through the code the AI wrote and find the typo it put in there, or give the AI the error for it to fix - but it still created the typo, and that is the main point here. AI often ignores the rest of the document and does what-ever-the-fuck it wants to make you stop prompting it, without any real concern for correctness.
No, that's not how it works.

It writes the code for you. Then it runs the tests. Then it runs the linter. Then it runs the static analysis tool. If any of those fail, then it rewrites the code and runs them all again.

You only look at the code once it has done all of that.

If AI is ignoring the rest of the document and doing whatever it wants then you need to improve your document-writing skills. You can ask it why it did something, that helps discover how to improve. It's a process of refinement and discovery, just like learning how to use any new tool.

Maybe you aren't familiar with all the ways AI can be used.

I use AI in two ways. In the way you describe, and also in the text editor as AI autocomplete. It works great until it doesn't. It inserts typos all the fucking time.

Also, don't assume you know it all.