After months of coding with LLMs, I'm going back to using my brain

These all-or-nothing takes on LLMs are getting tiresome.

I get the point you’re trying to make, LLMs can be a force multiplier for less experienced devs, but the sweeping generalizations don’t hold up. If you’re okay with a higher tolerance for bugs or loose guardrails, sure, LLMs can feel magical. But that doesn’t mean they’re less valuable to experienced developers.

I’ve been writing Python and Java professionally for 15+ years. I’ve lived through JetBrains IDEs, and switching to VS Code took me days. If you’re coming from a heavily customized Vim setup, the adjustment will be harder. I don’t tolerate flaky output, and I work on a mix of greenfield and legacy systems. Yes, greenfield is more LLM-friendly, but I still get plenty of value from LLMs when navigating and extending mature codebases.

What frustrates me is how polarized these conversations are. There are valid insights on both sides, but too many posts frame their take as gospel. The reality is more nuanced: LLMs are a tool, not a revolution, and their value depends on how you integrate them into your workflow, regardless of experience level.

I've got over 30 years of professional development experience, and I've found LLMs most useful for

* Figuring out how to write small functions (10 lines) in canonical form in a language that I don't have much experience with. This is so I don't end up writing Rust code as if it were Java.

* Writing small shell pipelines that rely on obscure command line arguments, regexes, etc.

I’ve found the biggest thing LLMs and agents let me do are build the things that I really suck at to a prototype level. I’m not a frontend engineer, and pitching feature prototypes without a fronted is tough.

But with aider/claude/bolt/whatever your tool of choice is, I can give it a handful of instructions and get a working page to demo my feature. It’s the difference between me pitching the feature or not, as opposed to pitching it with or without the frontend.

> IF you're a:

> * 1 year JS (react, nextjs, etc.) dev

> * start mostly from scratch on new ideas

> * have little prior IDE preference

> * have high tolerance for bugs and just want to ship and try stuff

> THEN: LLMs will to 10x you. An IDE like Cursor will immediately make you way faster.

And also probably dead-end you, and you'll stay the bug-tolerate 1 year JS dev for the next 10 years of your career.

It's like eating your seed corn. Sure you'll be fat and have it easy for a little while, but then next year...

16 year python dev who's done all that, lead multiple projects from inception to success, and I rarely manually code anymore. I can specify precisely what I want, and how I want it built (this is the key part), stub out a few files and create a few directories, and let an agent run wild but configured for static analysis tools/test suite to run after every iteration with the instructions to fix their mistakes before moving on.

I can deliver 5k LoC in a day easily on a greenfield project and 10k if I sweat or there's a lot of boilerplate. I can do code reviews of massive multi-thousand line PRs in a few minutes that are better than most of the ones done by engineers I've worked with throughout a long career, the list just goes on and on. I only manually code stuff if there's a small issue that I see the LLM isn't understanding that I can edit faster than I can run another round of the agent, which isn't often.

LLMs are a force multiplier for everyone, really senior devs just need to learn to use them as well as they've learned to use their current tools. It's like saying that a master archer proves bows are as good as guns because the archer doesn't know how to aim a rifle.

20+ years dev here, started coding with AI when Javis was still a thing (before it became Jasper, and way before Copilot or ChatGPT).

Back then, Javis wasn’t built for code, but it was a surprisingly great coding companion. Yes. It only gave you 80% working code, but because you had to get your hands dirty, you actually understand what was happening. It didn't give me 10x but I'm happy with 2x with good understanding on what's going on.

Fast-forward to now: Copilot, Cursor, roo code, windsurf and the rest are shockingly good at output, but sometimes the more fluent the AI, the sneakier the bugs. They hand you big chunks of code, and I bet most of us don't have a clear picture of what's going on at ground 0 but just an overall idea. It's just too tempting to blindly "accept all" the changes.

It’s still the old wisdom — good devs are the ones not getting paged at 3am to fix bugs. I'm with the OP. I'm more happy with my 2x than waking up at 3am.

Agreed but the 1 year JS dev should know they're making a deal with the devil in terms of building their skillset long term.

Even a single person may do different things that will change whether using an LLM helps or not.

Much of the time I spend writing code, not thinking about the general overview etc but about the code I am about to write itself, and if I actually care about the actual code (eg I am not gonna throw it away anyway by the end of the day) it is about how to make it as concise and understandable to others (incl future me) as possible, what cases to care about, what choices to make so that my code remain maintainable after a few days. It may be about refactoring previous code and all the decisions that go with that. LLM generated code, imo, is too bloated; them putting stuff like asserts is always a hit or miss about what they will think is important or not. Their comments tend to be completely trivial, instead of stating the intention of stuff, and though I have put some effort in getting them use a coding style similar to mine, they often fail there too. In such cases, I only use them if the code they write can be isolated enough, eg write a straightforward, auxiliary function here and there that will be called in some places but does not matter as much what happens in there. There are just too many decisions at each step that LLMs are not great at resolving ime.

I depend more on LLMs if I care less about maintenability of the code itself and more about getting it done as fast as possible, or if I am just exploring and do not actually care about the code at all. For example, it can be I am in a rush to get sth done and care about the rest later (granted they can actually do the task, else I am losing time). But when I tried this for my main work, it soon became a mess that would take more time to fix even if they seem like speeding me up initially. Granted, if my field was different and the languages I was using more popular/represented in training data, I may have found more uses for them, but I still think that after some point it becomes unsustainable to leave decisions to them.

Honestly, with a lot of HN debating the merits of LLMs for generating code, I wish it were an unwritten rule that everyone states the stack they're using with it. It seems that the people who rave about it creating a whole product line in a weekend are asking it to write them a web iterface using [popular js framework] that connects to [ubiquitous database], and their app is a step or two away from being CRUD. Meanwhile, the people who say it's done nothing for them are writing against [proprietary in-house library from 2005].

The worst is the middleground of stacks that are popular enough to be known but not enough for an LLM to know them. I say worst because in these cases the facade that the LLM understands how to create your product will fall before you the software's lifecycle ends (at least, if you're vibe-coding).

For what it's worth, I've mostly been a hobbyist but I'm getting close to graduating with a CS degree. I've avoided using LLMs for classwork because I don't want to rob myself of an education, but I've occasionally used them for personal, weird projects (or tried to at least). I always give up with it because I tend to like trying out niche languages that the LLM will just start to assume work like python (ex: most LLMs struggle with zig in my experience).

Ah I got more info. Interesting concept: https://moldabledevelopment.com/

Popular packages are regularly being used and vetted by thousands of engineers and that level of usage generally leads to subtle bugs being found and fixed. Blindly copy/pasting some LLM code is the opposite of that. It might be regurgitating some well developed code, but it's at least as likely to be generating something that looks right but is completely wrong in some way.

"Code generated by LLM is not that different than pulling in a random npm package or rust crate"

So I really hope you don't pull in packages randomly. That sounds like a security risk.

Also, good packages tend have a team of people maintaining it. How is that the same exactly?

> They usually do not care about the implementation.

[citation needed]

> Code generated by LLM is not that different than pulling in a random npm package or rust crate

It's not random, there's an algorithm for picking "good" packages and it's much simpler than reviewing every single line of LLM code.

If you as a developer care so much about stuff that the software users won't care about, you should look for better tools.

Everything compounds. Good architecture makes it easy to maintain things later. Bad code will slow you down to a snail pace and will result in 1000s of bug tickets.

> Code generated by LLM is not that different than pulling in a random npm package or rust crate.

Yes, LLM code is significantly worse than even a random package as it very often doesn't even compile.

Not the OP, but in my experience LLMs are still not quite there on guardrails. They might be for 25-50% of sessions, but it’ll vary wildly.

(Usually) Yes. The LLM can generate three functions, over 100 lines of code, and I spend perhaps 15 minutes rearranging it so it pleases me aesthetically. It would've taken me an hour or two to write.

I find most benefit in writing tests for a yet-inexistent function I need, then giving the LLM the function signature, and having it implement the function. TDD in the age of LLMs is great!

I know what you’re saying, but I’m saving time by: * getting ideas for how logic etc could be implemented * boilerplate is a thing of the past

The other thing is that I have the LLM make the modifications I want.

I know how long it takes to get an extremely bad programmer to do what you want, but the LLM is far better than that, so I do come out ahead.

I believe this depends on the individual. For me, yeah, I am. But I do have colleagues who wouldn’t be.

Well "I'm just not using it right" is a perfectly reasonable thought for a new technology. Isn't this the default? When new powerful tools come along, they often fit awkwardly into existing processes.

I've found a lot of value in this approach as well, I don't delegate any architecture decisions to LLMs. I build out the high-level and I see if the LLM can fill the gaps. I've found they are good at writing pure functions, and am good at composing them and managing state.

Yeah. I never understood where people are coming with “you need guardrails, extensive architecture docs, coding rules,…”. For every software and features I wrote, I already have a good idea of the objectives before I even start to code. I do the specific part with code, going back to the whiteboard when I need to think.

It’s an iterative process, not a linear one. And the only hige commits are the scaffolding and the refactorings. It’s more like sculpture than 3d printing, a perpetual refinement of the code instead of adding huge lines of code.

This is the reason I switched to Vim, then Emacs. They allow for fast navigation, and faster editing. And so easy to add your own tool as the code is a repetitive structure. The rare cases I needed to add 10s of lines of code is with a code generator, or copy-pasting from some other file.