I don't get the whole "all-in" mentality around LLMs. I'm an iOS dev by trade, I continue to do that as I always have. The difference now is I'll use an LLM to quickly generate a one-off view based on a design. This isn't a core view of an app, the core functionality, or really anything of importance. It's a view that promotes a new feature, or how to install widgets, or random things. This would normally take me 30-…
After months of coding with LLMs, I'm going back to using my brain
191–200 of 229 posts
Re: After months of coding with LLMs, I'm going back to using my brain
#192Earlier quoted context omitted.
What kind of guardrails did you give the agent? Like following SOLID, linting, 100% code coverage, templates, architectural documents before implementing, architectural rules, DRY cleanup cycles, code review guidelines (incl strict rules around consistency), review by another LLM etc?
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.
Re: After months of coding with LLMs, I'm going back to using my brain
#193Earlier quoted context omitted.
How useful the various tools will be depends on the person and the problem. Take two hypothetical people working on different problems and consider if, for example, Cursor would be useful. IF you're a: * 10 year python dev * work almost entirely on a very large, complex python code base * have a pycharm IDE fine tuned over many years to work perfectly on that code base * have very low tolerance for bugs (stable produ…
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…
Yikes. But also lol.
Re: After months of coding with LLMs, I'm going back to using my brain
#194Earlier quoted context omitted.
If Google's AlphaEvolve is any indication, they already have LLM's writing faster algorithms than humans have discovered.[1] [1] https://deepmind.google/discover/blog/alphaevolve-a-gemini-p...
I'm not thinking algorithms. Let's say someone write a new web framework. If there is no code samples available, I don't think whatever is going to be in the documentation will be enough data, then the LLMs doesn't have the training data and won't be able to utilize it. Would you ever be able to tell e.g. CoPilot: I need a web framework with these specs, go create that framework for me. The later have Claude actually…
Sure, why not?
The "magic sauce" of LLMs is that they understand what you mean. They've ingested all the thinking biases and conceptual associations humans have through their training on the entire training corpus, not just code and technical documentation. When Copilot cobbles together a framework for you, it's going to name the functions and modules and variables using domain terms. For Claude reading it, those symbols aren't just meaningless tokens with identity - they're also words that mean something in English in general, as well as in the web framework domain specifically; between that and code itself having common, cross-language pattern, there's more than enough information for an LLM to use a completely new framework mostly right.
Sure, if your thing is unusual enough, LLMs won't handle it as well as something that's over-represented in their training set, but then the same is true of humans, and both benefit from being provided some guidelines and allowed to keep notes.
(Also, in practice, most code is very much same-ish. Every now and then, someone comes up with something conceptually new, but most of the time, any new framework or library is very likely to be reinventing something done by another library, possibly in different language. Improvements, if any, tend to be incremental. Now, the authors of libraries and frameworks may not be aware they're retracing prior art, but SOTA LLMs very likely seen it all, across most programming languages ever used, and can connect the dots.)
And in the odd case someone really invents some unusual, new, groundbreaking pattern, it's just a matter of months between it getting popular and LLMs being trained on it.
Re: After months of coding with LLMs, I'm going back to using my brain
#195Earlier quoted context omitted.
Like anything else with learning, that will be heavily dependent on the individual's level of motivation. Based on the classmates I had in college who were paying to get a CS degree, I'd be surprised if many junior devs already working a paid job put much effort into learning rather than producing.
I wouldn't dismiss the implicit/subconscious aspect of learning by example that occurs when you are "just" producing.
I'd still expect most junior Deva that use an LLM to get their job done won't be motivated to study the generated code enough to really learn it.
A student is also only as good as the teacher, though that's a whole other can of works with LLMs.
Re: After months of coding with LLMs, I'm going back to using my brain
#196Earlier quoted context omitted.
You’re right that it’s possible to read the original comment as just laying out two boundary conditions—but I think we have to acknowledge how narrative framing shapes the takeaway. The way it’s written leads the reader toward a conclusion: “LLMs are great for junior, fast-shipping devs; less so for experienced, meticulous engineers.” Even if that wasn’t the intent, that’s the message most will walk away with. But th…
> LLMs are great for junior, fast-shipping devs; less so for experienced, meticulous engineers Is that not true? That feels sufficiently nuanced and gives a spectrum of utility, not binary one and zero but "10x" on one side and perhaps 1.1x at the other extrema. The reality is slightly different - "10x" is SLoC, not necessarily good code - but the direction and scale are about right.
People with many years or even decades of hands-on programming experience, have the deep understanding and tacit knowledge that allows them to tell LLMs clearly what they want, quickly evaluate generated code, guide the LLM out of any rut or rabbit hole it dug itself into, and generally are able to wield LLMs as DWIM tools - because again, unlike juniors, they actually know what they mean.
Re: After months of coding with LLMs, I'm going back to using my brain
#197Earlier quoted context omitted.
> 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. Amen. Seriously. They're tools. Sometimes they work wonderfully. Sometimes, not so much. But I have DEFI…
> Amen. Seriously. They're tools. Sometimes they work wonderfully. Sometimes, not so much. But I have DEFINITELY found value. And I've been building stuff for over 15 years as well. Yes, but these lax expectation s are what I don't understand. What other tools in software sometimes work and sometimes don't that you find remotely acceptable? Sure all tools have bugs, but if your compiler had the same failure rate and…
Other people.
Seriously, all that advice about not anthropomorphizing computers is taken way too seriously now, and is doing a number on the industry. LLMs are not a replacement for compilers or other "classical" tools - they're replacement for people. The whole thing that makes LLMs useful is their ability to understand what some text means - whether or not it's written in natural language or code. But that task is inherently unreliable because the problem itself is ill-specified; the theoretically optimal solution boils down to "be a simulated equivalent of a contemporary human", and that still wouldn't be perfectly reliable.
LLMs are able to trivially do tasks in programming that no "classical" tools can, tasks that defy theoretical/formal specification, because they're trained to mimic humans. Plenty of such tasks cannot be done to the standards you and many others expect of software, because they're NP-complete or even equivalent to halting problem. LLMs look at those and go, "sure, this may be provably not solvable, but actually the user meant X therefore the result is Y", and succeed with that reliably enough to be useful.
Like, take automated refactoring in dynamic languages. Any nontrivial ones are not doable "classically", because you can't guarantee there aren't references to the thing you're moving/renaming that are generated on the fly by eval() + string concatenation, etc. As a programmer, you may know the correct result, because you can understand the meaning and intent behind the code, the conceptual patterns underpinning its design. DAG walkers and SAT solvers don't. But LLMs do.
Re: After months of coding with LLMs, I'm going back to using my brain
#198The thing most LLM maximalists don't realize is that the bottleneck for most people is not code generation, it's code understanding. You may have doubled the speed at which you created something, but you need to pay double that time back in code review, testing and building a mental model of the codebase in your head. And you _need_ to do this if you want to have any chance of maintaining the codebase (i.e. bugfixes,…
This is not true. It may be bad practice, but consider that the median developer does not care at all about the internals of the dependencies that they are using. They care about the interface and about whether they work or not. They usually do not care about the implementation. Code generated by LLM is not that different than pulling in a random npm package or rust crate. We all understand the downsides, but there i…
Re: After months of coding with LLMs, I'm going back to using my brain
#199I don't get the whole "all-in" mentality around LLMs. I'm an iOS dev by trade, I continue to do that as I always have. The difference now is I'll use an LLM to quickly generate a one-off view based on a design. This isn't a core view of an app, the core functionality, or really anything of importance. It's a view that promotes a new feature, or how to install widgets, or random things. This would normally take me 30-…
How useful the various tools will be depends on the person and the problem. Take two hypothetical people working on different problems and consider if, for example, Cursor would be useful. IF you're a: * 10 year python dev * work almost entirely on a very large, complex python code base * have a pycharm IDE fine tuned over many years to work perfectly on that code base * have very low tolerance for bugs (stable produ…
> * 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...