I promise you do not need to "use your brain"

Use the tool when it makes sense or when someone shows you how to use it more effectively. This is exactly like the calculator "ruining people's ability to do arithmetic" when the vast majority of the population has been innumerate for hundreds of thousands of years up til the IR where suddenly dead white european nobility are cool.

There is nothing fun nor interesting about long division as well as software development.

If LLMs don't work for your usecase (yet) then of course you have to stick with the old method, but the "I could have written this script myself, I can feel my brain getting slower" spiel is dreadfully boring.

I've come to mostly use ai to bounce ideas off of. Even that has gotten less useful these last few months for some reason. Now it either wants to do the work for me or just spit out a complete agreement without being any bit critical.

Kinda blows my mind that people do this with technology they’ve never used.

If I want to learn something new I won’t vibe code it. And if I vibe code I’ll go with tech I have at least some familiarity with so that I can fix the inevitable issues

So the end game for this is, to a certain extent, does the code quality matter if it does what it is needed?

In the past the quality mattered because maintenance and tech-debt was something that we had to spend time and resources to resolve and it would ultimately slow us down as a result.

But if we have LLMs do we even have "resources" any more? Should we even care if the quality is bad if it is only ever LLMs that touch the code? So long as it works, who cares?

I've heard this positioned in two different ways, from two different directions, but I think they both work as analogies to bring this home:

- do engineers care what machine code a compiler generates, so long as it works? (no, or at least very, very, very rarely does a human look at the machine code output)

- does a CEO care what code their engineers generate, so long as it works? (no)

Its a very very interesting inflection point.

The knee jerk reaction is "yes we care! of course we care about code quality!" but my intuition is that caring about code quality is based on the assumption that bad code = more human engineer time later (bugs, maintenance, refactoring etc).

If we can use a LLM to effectively get an unlimited number of engineer resources whenever we need them, does code quality matter provided it works? Instead of a team of say 5 engineers and having to pick what to prioritise etc, you can just click a button and get the equivalent of 500 engineers work on your feature for 15 minutes and churn out what you need and it works and everyone is happy, should we care about the quality of the code?

We're not there yet - I think the models we have today kinda work for smaller tasks but are still limited with fairly small context windows even for Gemini (I think we'll need at least a 20x-50x increase in context before any meaningfully complex code can be handled, not just ToDo or CRUD etc), but we'll get there one day (and probably sooner than we think)

It’s wild how fast we outsourced thinking to LLMs without realizing the cost.

I only use LLMs later in the development stage to review my code and check if I’ve missed anything. I don’t use them for implementing features, that just feels like a waste of time.

I think LLMs are for manufacturing the bricks, not the house.

As exemplified by the comments on this HN submission, whether LLMs are — to borrow a phrase from "Blade Runner" — a benefit or a hazard seems unresolvable for now.

You weren't doing any code reviews? What did you expect?

To me, LLM coding is done best when it's used as a bicycle. You still have to pedal, know where you're going, not get run over by a car.

To be honest, the influencers selling this tools are not also helping. I guess to scale adoption you need to over promise in this case

We ahve numerous, well-doocumented cases of LLMs being just plain wrong and/or hallucinating. There is an epidemic of LLM usage in college (and even high school) to the point where lack of critical thinking is becoming a massive problem and will only get worse.

This represents a huge security threat too if code is uncritically applied to code bases. We've seen many examples where people try and influence LLM output (eg [1][2]). These attempts have generally varied from crude to laughably bad but they'll get better.

Is it so hard to imagine prompt injection being a serious security threat to a code base?

That aside, I just don't understand being "all in" on LLMs for coding. Is this really productive? How much boilerplate do you actually write? With good knowledge of a language or framework, that tends to be stuff you can spit out really quickly anyway.

[1]: https://www.theguardian.com/technology/2025/may/16/elon-musk...

[2]: https://www.theguardian.com/technology/2025/jan/28/we-tried-...

After months of using a hammer, I'm back to using my hands.

LLM is a tool. I think we still need to learn how to use it, and in different areas it can do either more or less stuff for you. Personally I don't it for most of everyday coding, but if I have something tedious to write, the LLM is the first place I go for a code draft. That works for me and for the LLM I use.

Sadly, the employers (CEOs, managers etc.) don't think like that.

discern when to delegate to the llm and give it enough context and guardrails to simply save you the keystrokes by coding exactly what you were thinking

This tracks for me. Its tempting to see LLMs as a superpower that makes it possible to use any programming language or platform, but I have much better results in platforms I know intimately...and I think this is largely because I'm using them in much more limited ways. When I've tried to pick up new tools and frameworks and heavily use LLMs to do early scaffolding, I have experiences similar to the author.

So someone could come along and say "well don't do that then, duh". But actually a lot of people are doing this, and many of them have far fewer fucks to give than the author and I, and I don't want to inherit their shitty slop in the future.

I kind of miss figuring things out by myself. I am unwilling to use anything it generates that I don't completely understand so often I spend just as much time figuring out why the code it created works as I would have just writing it myself.

My job has changed from writing code to code reviewing a psychopathic baby.

it works great for bad engineers who don't abstract and churn out repetitive widgets.

Unfortunately ceo manager types cannot distinguish between bad and good enginners

Spot on.

> Some days I feel like we’re also being gaslit by LLM providers. Just look at any AI related subreddit, and you’ll see people having completely opposite experiences, with the same exact model, with the same prompt, on the same day. If you code with AI long enough you’ll be able to relate. One day it’s amazing, the next day it’s incredibly stupid.

> Are they throttling the GPUs? Are these tools just impossible to control? What the fuck is going on?

Money and dreams. As everyone knows there’s an obscene amount of money invested in these tools of course. The capitalist class is optimistic their money can finally do the work for them directly instead of having to hire workers.

But more than that, AI is something that’s been alluring to humans forever. I’m not talking about cyberpunk fantasies I’m talking about The Mechanical Turk, Automata in the Middle Ages, Talos[0]. The desire to create an artificial mind is, if not hardwired into us, at least culturally a strong driver for many. We’re at a point where the test of the computer age for determining if we built AI was so utterly destroyed it’s unclear how to go about judging what comes next.

The hype is understandable if you view if you step back and view it through that lens. Maybe we are at an inflection point and just a bit more scaling will bring us the singularity. Maybe we’ve seen a burst of progress that’ll mostly stall from a consumer perspective for another 5-10 years, like all of the major AI moments before.

If you want to use them effectively it’s the same as any tool. Understand what they are good at and where they flounder. Don’t give up your craft, use them to elevate it.

[0]: https://news.stanford.edu/stories/2019/02/ancient-myths-reve...

Not quite a source but it’s a fun read from 2019 about this.

Tldr is ai will not replace anyone.

We're at the point where I'm starting to hear this exact "backlash" sentiment from a lot of people. While I never went that far out of discomfort (I like understanding things) I do kind of respect the "effort" of willing to let go a bit. One reason probably also is that I tend up working in large Unity projects which are as incompatible for letting AI "take the wheel" as projects come.

That aside, I wonder if the OP would have had all the same issues with Grok? In several uses I've seen it surprisingly outperform the competition.

I agree with this and matches my thinking (however - the fact that this is even an option is an incredible breakthrough that I did not expect to happen preLLMs - potentially in decades).

I have basically given up on "in IDE" AI for now. I simply have a web interface on my 2nd monitor of whatever the "best" LLM (currently Gemini, was Claude) is and copy paste snippets of code back and forth or ask questions.

This way I have to physically copy and paste everything back - or just redo it "my way", which seems to be enough of an overhead that I have to mentally understand it. When it's in an IDE and I just have to tick accept I just end up getting over eager with it, over accepting things and then wishing I hadn't, and spend more time reverting stuff when the penny drops later this is actually a bad way to do things.

It's really more a UX/psychology problem at the moment. I don't think the 'git diff' view of suggested changes is the right one that many IDEs use for it - I'm psychologically conditioned to review these like pull requests and it seems my critique of these is just not aligned to critiquing LLM code. 99% of PR reviews I do are finding edge cases and clarifying things. They're not looking at very plausible yet subtly completely wrong code (in the most part).

To give a more concrete example; if someone is doing something incredibly wrong in 'human PRs' they will tend to name the variables wrong because they clearly don't understand the concept, at which point the red flag goes off in my head.

In LLM PRs the variables are named often perfectly - but just don't do what they say they will. This means my 'red flag' doesn't fire as quickly.

It's very fustrating when you end up spending more time tracking down bugs and cleaning up inconsistent code then it would have taken to do it right yourself in the first place. It's an important lesson. That said, there are still massive productivity gains available. If you let the model mess with your existing code base, or if it get's past a small size, it will shit all over it. The LLM needs limited scope. I find it's great for frontend work, which is what I hate doing myself. I've been having it build webcomponents, paired with targeted backend functions that wrap internal libraries that I wrote for db and API calls. Then I compose things. Careful instructions, internal documentaion for the model and well contained isolated tasks are best. The models get confused and distracted by existing code, it's ofen better to document function interfaces and use rather than showing it the source. If the code is going into production you have to read it line by line and clean it up. I've been using Aider, mostly.

In order to convey all of the ways that Gemini, Claude, O4-mini and many other LLMs have worked aggressively to sabotage my systems would take an unreasonable amount of time to describe. Among the more ridiculous occurrences have been actively ignoring instructions to read my comprehensive docs, the system spec and coding principles documents. These LLMs will rewrite your architecture when you have only provided an instruction to make a simple change. The fact that some individuals are supposedly experiencing LLM euphoria leads me to one conclusion. They aren't producing anything that is complex and they probably don't have a large codebase. Furthermore, I wonder if the so-called vibe coders are actually looking at and understanding the code at all.

My rule with Cursor is that unless I know exactly what I want it to do, I have it stay out of my way. If I have a general idea, I may turn on auto-complete. I reserve the agent for things like tests, UX, and rote programming that saves me time.

When I do use the agent, I inspect its output ruthlessly. The idea that pages of code can be written before being inspected is horrifying to me.

Oof this is a very limited take.

The fundamental issue is that agents / LLMs at present are not engineers or system architects. You cannot sit back and play product manager yet. If you go in with this expectation, you will certainly have a poor experience.

LLM-powered coding agents are not comparable to any existing human role or tool and therefore cannot be used interchangeably. They are a fundamentally new and novel type of tool that enable incredible productivity IF and only if you use them effectively. The tool is not the problem, the user is.

I’m also building a non-trivial SaaS platform and the cursor agent has written 90%+ of the code in the codebase. It has architected ~0% of the codebase. It has modeled ~0% of the data layer in the codebase. It has enabled me to move at least 10x the speed of implementation and debugging (yes, it is incredible at debugging if you use the right techniques).

I use the word implementation because that is almost exclusively what I use it for. I do the planning, design, architecture, engineering. Then, I communicate those specifications to it in digestible chunks, and it implements them incredibly fast. It makes mistakes sometimes, comes up with poor naming conventions, fails to reuse existing modules in the codebase, etc. But that’s fine - I simply give it feedback, point it in the right direction, and within seconds it’s back on course.

I own the codebase, it’s just my super fast implementation minion. If it gets something wrong - that’s my fault. I failed to communicate my expectations clearly. I’m heavily using my brain while working with the LLM - I’m just reserving those mental cycles for higher-level decision making than the actual tokens to type into the editor.

The power is in your ability to steer it and communicate in clear terms what you want, and maintain the right level of abstraction in your instructions. Too specific and you lose some of the benefit beyond just writing the code by hand, too vague / high-level and it will over-engineer something totally different than what you intended.

You’re the engineer, it’s just a really smart semantic code generator. That might change in the future, but for now, if you use it in this way, the productivity benefit is very clear.

I’ve been using cursor with 3.7 sonnet max (now sonnet 4) and I already can’t imagine a world without coding agents - it is so deeply rooted into my workflow.

Well yes, right now you really need to understand and closely supervise what the LLM is generating. On the other hand, every couple of weeks there’s a new model, that is noticeably better than everything before it. So any strong conclusions may be outdated by the end of the week.

What I witness is that many people pick a random model and expect a prompt they wrote in 10 seconds to replace an hour of coding. And then are disappointed and go back to coding manually.

For me, the magic of LLMs is that I already get an hour of coding via 30 minutes of prompting and finetuning the generated code. And I know that the ratio will constantly improve as LLMs become better and as I finetune my prompts to define the code style I prefer. I have been coding for pretty much all my life and I never felt more excited about it than I do now.

It would be cool if people shared their prompts and the resuling commits. If someone here is disappointed by the commits LLMs make, I would love to see the prompt, the commit, and which model made it.

I prefer to ask LLMs to help me to create highly cohesive functions, and absolutely abhor using agents with their overly verbose code, their tendency to do shotgun surgery and the inevitable regressions.

So I kind of do a top-down design and use the LLM to help me with toil or with unfamiliar things that would require me finding the right documentation, code examples, bug reports, etc, etc... LLMs with web search are great for this kind of toil elimination.

LLMs are useful tools, but they have no notion of hierarchy, of causal relationships, or any other relationship, actually. Any time they seem to have those capabilities in the code they generate, it is merely a coincidence, a very probably coincidence, but still, it is not intentional.

When you have a hammer in your hand everything looks like a nail.

Developing without the knowledge what LLM writes is dangerous. For me having LLM as a tool is like having a few Junior Developers around, that I can advise and work with. If I have a complicated logic that I need to write - I write it. After I wrote it, I can ask LLM to review it, it might be good to find some corner cases in some places. When I need to "move things from one bucket to another", like call API and save to DB - that is a perfect task for LLM, that I can easily review after.

At the same time, LLM is able to write pretty good complicated logic as well for my side projects. I might need to give it a few hints, but the results are amazing.

> but I was optimizing for speed and I hadn’t actually sat down just to review the code

There, there's your problem. The problem is not LLMs, the problem is people not using their brain. Can't we use LLMs and our brains as well? Both are amazing tools!

I think LLMs are great for generating the structure of your code. The only issue is that these models are amazing when you are navigating in very well documented, talked about, etc. subjects, and start to go off the rail when you are using somewhat esoteric things. The speed boost I get by generating Terraform and HTML, CSS, JS with Deepseek and Grok (sometimes asking one to review the others code) is pretty significant. My biggest disappointment is Claude. I have purchased a subscription from them but I need to cancel it. The usual ouput from 3.7 is horrenndous. I am not even sure why. The same prompt works very well with Deepseek and fails miserably with Claude.

Over the past few months, I have read numerous articles on this topic. Some are in favor, some are against, and others fall somewhere in between. However, they all share a common shortcoming: the absence of code. There are no codebases, no commit histories—nothing that allows readers to track how the codebase evolves, gets refactored, or how new features are integrated.

Without access to the code, it's challenging to verify the authors' claims and form an independent opinion. In my view, we should be cautious about trusting articles that lack examples or sources. As someone wiser than me once said:

> Articles without sources are merely the opinions of the author.

I love using LLMs with my debugging but also helping me to get started. Grok has been helpful in giving it a rubric and having it come up with the framework and headers, which saves some time. Unfortunately in my humble and limited experience, asking it to then improve upon that code is where it runs into mistakes. If you give it a perfect rubric of what you want, I think an LLM can give you some very good code, but it can't think ..beyond that like a human can.

Something I do very much love about LLMs is that I can feed it my server logs and get back an analysis of the latest intrusion attempts, etc. That has taught me so much on its own.

Off-topic: may I ask, why PHP + MySQL is no longer considered suitable to you?

It's hard to say without specifics, but simply upgrading from MySQL to PostgreSQL without rewriting the PHP codebase in Go might resolve most of the potential issues.

Let's take a step back and think about how LLMs are trained.

Think about when chat gpt gives you the side-by-side answers and asks you to rate which is "better".

Now consider the consequence of this at scale with different humans with different needs all weighing in on what "better" looks like.

This is probably why LLM generated code tends to have excessive comments. Those comments would probably get it a higher rating but you as a developer may not want that. It also hints at why there's inconsistency in coding styles.

In my opinion, the most important skill for developers today is not in writing the code but in being able to critically evaluate it.

I think getting the initial domain modeling, structure and opinions that build up a code base is more of an art than science. It’s highly opinionated. Sure you have SOLID but in my experience no one follows it to the book.

Once the code base structure and opinions are in place, I think LLMs are decent at writing code that are bounded to a single concern and not cross cutting.

LLM generated code bases work initially but so will code written by college kids for an initial set of requirements. Even a staff+ level engineer will struggle in contributing to a code base that is a mess. Things will break randomly. Don’t see how LLMs are any different.

I also tried to go as hard as I could with agents and I ran into a ton of problems. The core issue I found is that inferring "intent" from existing code is hard and it makes errors that accumulate and build up. This ends up wrecking the software project by adding tons of complexity and duplicate ways of doing things and changing assumptions depending on which part of the code base you are in.

I think that the solution is to somehow move towards an "intent" layer that sits above the code.

I still use Cursor, but I use AI judiciously so that I don't wreck the project and it is only acts as an aid.

If and when LLMs are able to complete software development projects autonomously, the first sign probably won't be that your own software development job gets easier. Almost certainly, Google AI, DeepSeek, or OpenAI will notice before you do, and that's when their further progress will be limited only by how fast their GPUs can develop AI software instead of how fast their human SWEs can develop AI software.

Eric Schmidt gave a TED interview about the subject this week. He predicts the US and China bombing each other's data centers.

LLMs are a good tool for certain purposes and that's it. Unfortunately, the vendors are obviously interested in inflating their stated capabilities to get the most returns on investment ...

I've been experimenting with LLMs for coding / "agentic" editing using Zed over the past month or so. It's another tool in the toolbox, good for prototyping, also good for rote tasks (like upgrading a legacy code base, converting one call to another.) So far I've been most impressed by Claude Sonnet. The jury is still out... I haven't used it for any "work" tasks, only hobby projects, because I don't feel comfortable doing that yet.

LLMs are pretty similar in concept to site builders. They can do the basics reasonably well but if you want anything custom they show their weaknesses.

I have been building a gallery for my site with custom zoom/panning UX to be exactly how I want it (which by the way does not already exist as a library). Figuring out the equations for it is simply impossible for an LLM to do.

I wouldn't be surprised if after the LLM hype we go back to site/app builders being the entry level option.

In my case, LLMs just replaced time wasted in stackoverflow fighting the cocky gatekeepers. Otherwise, I code as usual and it’s a great addition to my repertoire.

IMO the mistake was not knowing what he was doing. He basically (at a macro scale) copy-pasted stack overflow code without understanding what it does... We've all been there.

I don't think LLMs are at blame here, it is a tool and it can be used poorly. However, I do wonder what's the long term effects on someone who uses them to work on things they are knowledgeable about. Unfortunately this is not explored in the article.

This isn’t so much about coding as it is about architecting code. As I wrote this week, it’s all about planning and a critical viewpoint:

https://taoofmac.com/space/blog/2025/05/13/2230

After spending 1000s of dollars on 3 projects that I thought I could finish in a weeks :) with agents with cline, I reached similar conclusion. Best use cases I have seen it work is for good commit messages, templated documentation and cursory understanding existing code base. Shine wore off on me too.

> Meanwhile, the people who say it's done nothing for them are writing against [proprietary in-house library from 2005].

there's MCP servers now that should theoretically help with that, but that's its own can of worms.

Depends on the LLM, recent Gemini models are quite good in this regard.

Don't disagree at all. It was never promised that LLMs could do what he's trying to do. But just because he's holding it wrong doesn't mean that he's not holding it.

That isn't my experience at all.

> You have the copilot mode which takes no learning at all which might give you some speedup, especially if you are doing repetitive stuff, it might even 10x+ you.

I have some grey hair and I've been programming since I was a kid. Using CoPilot autocompletion roughly doubles my productivity while cutting my code quality by 10%.

This happens because I can see issues in autocompleted code far faster than I can type, thanks to years of reading code and reviewing other people's code.

The 10% quality loss happens because my code is no longer lovingly hand-crafted single-author code. It effectively becomes a team project shared by me and the autocomplete. That 10% loss was inevitable as soon as I added another engineer, so it's usually a good tradeoff.

Based on observation, I think my productivity boost is usually high compared to other seniors I've paired with. I see a lot of people who gain maybe 40% from Copilot autocomplete.

But there is no world in which current AI is going to give me a 900% productivity boost when working in areas I know well.

I am also quite happy to ask Deep Research tools to look up the most popular Rust libraries for some feature, and to make me a pretty table of pros and cons to skim. It's usually only 90% accurate, but it cuts my research time.

I do know how to drive Claude Code, and I have gotten it to build a non-trivial web front-end and back-end that isn't complete garbage without writing more than a couple of dozen lines myself. This required the same skill set as working with an over-caffeinated intern with a lot of raw knowledge, but who has never written anything longer than 1,000 lines before. (Who is also a cheating cheater.) Maybe I would use it more if my job was to produce an endless succession of halfway decent 5,000-line prototypes that don't require any deep magic.

Auto-complete plus Deep Research is my sweet spot right now.

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

It absolutely is, but that is besides the point

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

The famously do not https://xkcd.com/2347/

>> They usually do not care about the implementation. > [citation needed]

Everybody agrees that e.g. `make` and autotools is a pile of garbage. It doesn't matter, it works and people use it.

> 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.

But you don't need to review every single line of LLM code just as you don't need to review every single line of dependency code. If it works, it works.

Why does it matter who wrote it?

my stance is the opposite of all-or-nothing. The note above is one example. How much value you get out of CURSOR specifically is going to vary based on person & problem. The Python dev in my example might immediately get value out of o3 in ChatGPT.

It's not all or nothing. What you get value out of immediately will vary based on circumstance.

This doesn't seem like an "all or nothing" take. This person is trying to be clear about their claims, but they're not trying to state these are the only possible takes. Add the word "probably" after each "then" and I image their intended tone becomes a little clearer.

> 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 DEFINITELY found value. And I've been building stuff for over 15 years as well.

I'm not "vibe coding", I don't use Cursor or any of the ai-based IDEs. I just use Claude and Copilot since it's integrated.

> 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 think you're trying very hard to pin LLMs as a tool for inexperienced developers. There's a hint of paternalism in them.

Back in the real world, LLMs are a tool that excels at generating and updating code based on their context and following your prompts. If you realize this fact, you'll understand that there's nothing in the description that makes them helpful exclusively to "inexperienced" developers. Do experience developers need to refactor code or write new software? Do you believe veteran software engineers are barred from writing proofs of concept? Is the job of pushing architecture changes a junior developer gig?

What exactly do you think an experienced developer does?

> 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 completely disagree: LLMs have a revolutionary impact on how software engineers do their job. Your workflows changed overnight. You can create new things faster, you can iterate faster, you can even rewrite whole applications and services in another tech stacks and frameworks in a few days. Things like TDD will become of critical importance as automates test suites are now a critical factor in providing feedback to LLMs. Things are no longer the way they were. At least to those who bothered learning.

Assuming that your workflow works, and the rest of us just need to learn to use LLMs equally effective, won't that plateau us at the current level of programming?

The LLMs learn from examples, but if everyone uses LLMs to generate code, there's no new code to learn new features, libraries or methods from. The next generation of models are just going to be trained on the code generated by it's predecessors with now new inputs.

Being an LLM maximalist is basically freeze development in the present, now and forever.

were you immediately more productive in Cursor specifically?

my point is exactly inline with your comment. The tools you get immediate value out of will vary based on circumstance. There's no silver bullet.

> we're back to counting programming projects in kloc, like it's the radical 1980's again

Yikes. But also lol.

Let’s see the GitHub project for an easy 10k line day.

    docs: Add README

> In an era where an LLM can hallucinate (present you a defect) with 100% conviction, (...)

I think you're trying very hard to find anything at all to criticize LLMs and those who use them, but all you manage to come up with is outlandish, "grasping at straws" arguments.

Yes, it's conceivable that LLMs can hallucinate. How often do they do, though? In my experience, not that much. In the rare cases they do, it's easy to spot and another iteration costs you a couple of seconds to get around it.

So, what are you complaining about, actually? Are you complaining about LLMs or just letting the world know how competent are you at using LLMs?

> Someone with experience will still bring something more than just LLM-written code to the table, and that bar will stay where it is.

Someone with experience leverages LLMs to do the drudge work, and bump up their productivity.

I'm not sure you fully grasp the implications. You're rehashing the kind of short-sighted comments that in the past brought comically-clueless assertions such as "the kids don't know assembly, so how can they write good programs". In the process, you are failing to understand the fact that the way software is written has already changed completely. The job of a developer is no longer typing code away and googling for code references. Now we can refactor and rewrite entire modules, iterate over the design, try a few alternative approaches, pin alternatives against each other, and pick up the one we prefer to post a PR. And then go to lunch. With these tools, some of your "experienced" developers turn out to be not that great, whereas "inexperienced" ones outperform them easily. How do you deal with that?

Google search without ads... uBlock Origin

> Would you ever be able to... later have Claude actually use that framework?

Yes, subject to LLM token limitation. I've run into the second half of the problem, where the LLM doesn't know about the latest version of a library, or the new/modified API that version implements. So then the LLM isn't able to write working code for that API. However, if you add the latest docs into the context window, and ask it to generate code, the LLM is now able to generate working code that uses the new semantics.

The preceding steps to complete the example would then be for CoPilot (which is a frontend to various LLMs, including Claude) to generate the new framework, and then generate docs for this new framework.

> 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 use that framework?

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.

You can just collect the docs and stuff them in context with a few code examples that can be hand coded if needed, or you can separately get the LLM to try and code samples from the docs and keep the ones that work and look idiomatic.

I basically learned programming by ExpertSexchange, Google (and Altavista...), SourceForge and eventually StackOverflow + GitHub. Many people with more experience than me at the time always told me I was making a deal with the devil since I searched so much, didn't read manuals and asked so many questions instead of thinking for myself.

~15 years later, I don't think I'm worse off than my peers who stayed away from all those websites. Doing the right searches is probably as important as being able to read manuals properly today.

  > ExpertSexchange

The jury is still out on that one.

Having a tool that’s embedded into your workflow and shows you how things can be done based on tons of example codebases could help a junior dev quite a lot to learn, not just to produce.

From workplace perspective, they don't have a reason to care. What they'll care about is that you're productive right now - if you won't become better dev in the future? Your issue.

Maybe. But I also think that ignoring AI tools will hamper your long-term skillsets, as our profession adapts to these new tools.

it gave me a chuckle regardless lol

That still comes back to motivation in my opinion. Using an LLM to generate code and using it without studying the code and understanding it will teach you very little.

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.

Maybe better formatting would show it better to you.

    github.com/AlDanial/cloc v 2.04 T=0.05 s (666.3 files/s, 187924.3 lines/s)
    ---- Language   files blank comment code
    ---- Python        24 1505     1968 5001
    ---- Markdown       4 37          0  121
    ---- Jinja Template 3 17          2   92
    ------------- SUM: 31 1559     1970 5214

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 they drew boundaries with very specific conditions that lead the reader. It’s a common theme in these AI discussions.

Nope, it's an internal company tool to build high performance distributable container images based on a manifest of services for resource constrained edge devices with an installer that manages installing, configuring, removing, auto-updating and daemonizing the container process across a variety of OS targets.

The container images also have significant logic for interfacing securely with the private company network and upstream services given on-prem or edge deployment.

I don't think junior vs senior is actually that well defined. There are met "senior" 30 year old programmers and "junior" 30 year olds (who have also been programming for ~2 decades).

I and others understood it perfectly well. Maybe the problem wasn’t with the post.

If multiple people misread the post, clarity might be the issue, not comprehension. Dismissing that as misunderstanding doesn’t add much. Let’s keep it constructive.