I still use LLMs heavily. However, I now follow two rules:
* Do not delegate any deep thought to them. For example, when thinking through a difficult design problem, I do it myself.
* Deeply review and modify any code they generate. I go through it line-by-line and edit it thoroughly. I have to do this because I find that much of what they generate is verbose, overly defensive, etc. I don't care if you can fix this through prompting; I take ownership over future maintainability.
"Vibe coding" (not caring about the generated code) gives me a bad feeling. The above approach leaves me with a good feeling. And, to repeat, I am still using them a lot and coding a lot faster because of it.
(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 delegate all kinds of deep analysis to the AI, but it's to create detailed plans with specific implementation steps and validation criteria, backed by data in reproducible reports (i.e. "generate a script to generate this json data and another to render this data"). Plans have a specific goal that is reflected in the report ("migrated total should be 100%"). It's still an iterative process, the generators and plans have to be refined as it misses edge cases, but that's plans in general, AI or no.
It takes a good hour or two to draw up the plans, but it's the kind of thing that would take me all day to do, possibly several as my ADHD brain rebels against the tedium. AI can do yeomans work when it just wings it, and sometimes I have just pointed at a task and did it in one shot, but they work best when they have detailed plans. Plus it's really satisfying to be able to point at the plan doc and literally just say "make it so".
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.
It's known that OpenAI tweaked ChatGPT output so it's very agreeable and flattering no matter what the input is. Which turns out to be a problem because even the most schizophrenic paranoid rant will get an enthusiastic response praising how the user isn't a sheep and doesn't blindly conform to societal norms etc.
And why did they make this change? Because it makes users spend more time on the platform. ChatGPT wasn't just one of the fastest-growing web services ever, it's now also speedrunning enshittification.
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.
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.
1) I do a lot of scraping, and Go concurrency + Colly has better performance
2) My DB size is exploding and I have limited budget, and it looks like CH is so much better at compressing data. I recently did a test and for the same table with same exact data, MySQL was using 11GB, ClickHouse 500MB
That's pretty typical best case size for weblogs and other time ordered data where column data correlate with time values. You do have to tweak the schema a bit to get there. (Specifically a "good" sort order, codecs, ZSTD instead of LZ4 compression, etc.)
> When it was time to start coding, I asked Claude to give me a big and complicated markdown file outlining my existing infrastructure, my desired new infrastructure, what I’m trying to achieve, why I'm doing it, etc.
Yes, imo, too many people believe current LLMs are capable of doing this well, They aren't. Perhaps soon! But not today, so you shouldn't try to use LLMs to do this for serious projects. Writing that MDN file sounds like a wonderful way to get your own head around the infrastructure and chat with other devs / mentors about it though, that's a great exercise, I'm going to steal it.
Anyway, LLMs are, as we all know, really good text predictors. Asking a text predictor to predict too much will be stretching the predictions too thin: give it one file, one function, and very specific instructions, and an LLM is a great way to increase your productivity and reducing mental overload on menial tasks (e.g., swap out all uses of "Button" in @ExperimentModal.tsx with @components/CustomButton.tsx). I think LLM usage in this sense is basically necessary to stay competitively productive unless you're already a super-genius in which case you probably don't read HN comments anyway so who cares. For the rest of us mortals, I argue that getting good at using LLM co-pilots is as important as learning the key bindings in your IDE and OS of choice. Peel away another layer of mental friction between you and accomplishing your tasks!
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-60 min to implement depending on complexity, now it takes 5.
I also use it for building things like app landing pages. I hate web development, and LLMs are pretty good at it because I'd guess that is 90% of their training data related to software development. For that I make larger changes, review them manually, and commit them to git, like any other project. It's crazy to me that people will just go completely off the rails for multiple hours and run into a major issue, then just start over when instead you can use a measured approach and always continue forward momentum.
Exactly my thoughts. It seems there’s a lot of all-or-nothing thinking around this.
What makes it valuable to me is its ability to simplify and automate mundane, repetitive tasks. Things like implementing small functions and interfaces I’ve designed, or even building something like a linting tool to keep docs and tests up to date.
All of this has saved me countless hours and a good deal of sanity.
>I don't get the whole "all-in" mentality around LLMs
To be uncharitable and cynical for a moment (and talking generally rather than about this specific post), it yields content. It gives people something to talk about. Defining their personality by their absolutes, when in reality the world is an infinite shades of gradients.
Go "all in" on something and write about how amazing it is. In a month you can write your "why I'm giving up" the thing you went all in on and write about how relieved/better it is. It's such an incredibly tired gimmick.
"Why I dumped SQL for NoSQL and am never looking back"
"Why NoSQL failed me"
"Why we at FlakeyCo are all in on this new JavaScript framework!"
"Why we dumped that new JavaScript framework"
This same incredibly boring cycle is seen on here over and over and over again, and somehow people fall for it. Like, it's a huge indicator that the writer more than likely has bad judgment and probably shouldn't be the person to listen to about much.
Like most rational people that use decent judgement (rather than feeling I need to "all in" on something, as if the more I commit the more real the thing I'm committing to is), I leverage LLMs many, many times in my day to day. Yet somehow it has authored approximately zero percentage of my actual code, yet is still a spectacular resource.
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 product, no room for move fast, break things)
THEN: LLMs aren't going to 10x you. An IDE like Cursor will likely make you slower for a very long time until you've learned to use it.
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.
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.
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.
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.
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.
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.
>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.
no they didn't, no one said that
i know that because i was around then and everyone was doing the same thing
also, maybe there's a difference between searching and collating answers and just copy and pasting a solution _without thinking_ at all
You're right, probably hallucinated memory of much more senior people telling me exactly that.
> i know that because i was around then and everyone was doing the same thing
Damn, we worked together in the same company at that time? Nice to meet you again after all these years. Still thinking of picking up farming once you get out of prison?
Why would that be the case? If anything, each successive generation of AI tools gets easier to use and requires less prompt fiddling. I picked up Cursor and was comfortable with it in 20 minutes.
I'm not sure there's much of a skillset to speak of for these tools, beyond model-specific tricks that evaporate after a few updates.
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.
Taking your "to 10x you" as hyperbole and to actually mean "more productive", if you replace "Python" with "Programming" and "IDE" with Neovim, that's basically me. And I'm way more productive with LLMs than without them. Granted, I stay far away from "vibe coding", only use LLMs for some parts and don't use "agentic LLMs" or whatever, just my own programmed "Human creates issue on GitHub, receive N PRs back with implementations" bot.
Basically, use LLMs as a tool for specific things, don't let them do whatever and everything.
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 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.
> 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 usability issues as an LLM you'd never use it. Yet for some reason the bar is so low for LLMs. It's insane to me how much people have indulged in the hype koolaid around these tools.
My compiler doesn’t write a complete function to visualize a DataFrame based on a vague prompt. It also doesn’t revise that function as I refine the requirements. LLMs can.
There’s definitely hype out there, but dismissing all AI use as “koolaid” is as lazy as the Medium posts you’re criticizing. It’s not perfect tech, but some of us are integrating it into real production workflows and seeing tangible gains, more code shipped, less fatigue, same standards. If that’s a “low bar,” maybe your expectations have shifted.
> Yes, but these lax expectation s are what I don't understand.
It's pretty a really, really simple concept.
If I have a crazy Typescript error, for instance, I can throw it in and get a much better idea of what's happening. Just because that's not perfect, doesn't mean it isn't helpful. Even if it works 90% of the time, it's still better than 0% of the time (Which is where I was at before).
It's like google search without ads and with the ability to compose different resources together. If that's not useful to you, then I don't know what to tell you.
Hell, AI is probably -1x for me because I refuse to give up and do it myself instead of trying to get the robots to do it. I mean, writing code is for the monkeys, right?
Anyhoo... I find that there are times where you have to really get in there and question the robot's assumptions as they will keep making the same mistake over and over until you truly understand what it is they are actually trying to accomplish. A lot of times the desired goal and their goal are different enough to cause extreme frustration as one tends to think the robot's goal should perfectly align with the prompt. Once it fails a couple times then the interrogation begins since we're not making any further progress, obviously.
Case in point, I have this "Operational Semantics" document, which is correct, and a peg VM, which is tested to be correct, but if you combine the two one of the operators was being compiled incorrectly due to the way backtracking works in the VM. After Claude's many failed attempts we had a long discussion and finally tracked down the problem to be something outside of its creative boundaries and it needed one of those "why don't you do it this way..." moments. Sure, I shouldn't have to do this but that's the reality of the tools and, like they say, "a good craftsman never blames his tools".
People are way too quick to defend LLMs here, because it's exactly on point.
In an era where an LLM can hallucinate (present you a defect) with 100% conviction, and vibe coders can ship code of completely unknown quality with 100% conviction, the bar by definition has to have been set lower.
Someone with experience will still bring something more than just LLM-written code to the table, and that bar will stay where it is. The people who don't have experience won't even feel the shortcomings of AI because they won't know what it's getting wrong.
> 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?
Your made up stories are not convincing. You are coming off as one of the block-chain bros desperately trying to claim “you just don’t get it because I’m smarter than you”
> What other tools in software sometimes work and sometimes don't that you find remotely acceptable?
Searching for relevant info on the Internet can take several attempts, and occasionally I end up not finding anything useful.
My ide intellisense tries to guess what identifier I want and put it at the top of the list, sometimes it guesses wrong.
I've heard that the various package repositories will sometimes deliberately refuse to work for a while because of some nonsense called "rate limiting".
Cloud deployments can fail due to resource availability.
There were always lots of code generation tools that people expected to review and fix the output.
Anyway, code generation tools almost always are born unreliable, then improve piecewise into almost reliable, and finally get replaced by something with a mature and robust architecture that is actually reliable. I can't imagine how LLMs could traverse this, but I don't think it's an extraordinary idea.
> What other tools in software sometimes work and sometimes don't that you find remotely acceptable?
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.
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.
You say your stance isn’t all-or-nothing, but your original comment drew a pretty hard line, junior devs who start from scratch and have a high tolerance for bugs get 10x productivity, while experienced devs with high standards and mature setups will likely be slowed down. That framing is exactly the kind of binary thinking that’s making these conversations so unproductive.
I wouldn’t classify this as binary thinking - isnt the comment you are replying just defining boundary conditions? Then those two points don’t define the entire space, but the output there does at least let us infer (but not prove) something about the nature of the “function” between those two points? Where the function f is something like f: experience -> productivity increase?
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.
no, those are two examples of many many possible circumstances. I intentionally made it two very specific examples so that was clear. Seems it wasn't so clear.
Fair enough but if you have to show up in the comments clarifying that your clearly delineated “IF this THEN that” post wasn’t meant to be read as a hard divide, maybe the examples weren’t doing the work you thought they were. You can’t sketch a two-point graph and then be surprised people assume it’s linear.
Again I think the high level premise is correct as I already said, the delivery falls flat though. Your more junior devs have larger opportunity of extracting value.
The guy was nice enough to explain his post that you got confused about. Rather than be thankful you used that as evidence that he was not clear and lectured him on it.
I gently suggested that the problem may have not been with his post but with your understanding. Apparently you missed the point again.
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.
> 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.
That feels like the opposite of being true. Juniors have, by definition, little experience - the LLM is effectively smarter than them and much better at programming, so they're going to be learning programming skills from LLMs, all while futzing about not sure what they're trying to express.
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.
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).
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.
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.
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.
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.
You have cmdk mode which you need to prompt and seems to he a lobotomized version of chat. I find putting comments and waiting for the copilot mode to kick in better as then the way we got there is saved.
Then there is agentic editing chat: that is the timewaster you speak off I believe, but what is there to learn? Sometimes it generates a metric ton of code, including in legacy massive code bases, that help, and often it just cannot do whatever.
I don't think these cases you make, or at least, when the second one goes beyond the basics, are different. There is nothing to learn except that you need read all the code, decide what you want in tech detail and ask that of the agentic chat. Anything else fails beyond the basics and 'learning to use it' will be that but if you didn't know that after 5 minutes you definitely didn't do any 'fine tuned pycharm ide', ever.
It is a tool that customizes code it ingested for your case specifically, if it can. That is it. If it never saw a case, it won't solve it, no matter what you 'learn to use'. And I am fine doing that in public: we use LLMs a lot and I can give you very simple cases that, besides (and often even that doesn't work) typing up the exact code, it will never fix with the current models. It just gets stuck doing meaningless changes with confidence.
> 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.
Recently I tried getting ChatGPT to help me build a Wordpress site (which I know nothing about), starting from an Adobe design file. It spent hours thinking, being confused and eventually failed completely.
However it's great for simple "write a function that does X", which I could do myself but it would take longer, be boring and require several iterations to get it right.
Having said that, blindly copying a few lines of ChatGPT code did lead to automated newsletters being sent out with the wrong content.
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.
I use Aider, and I was already quite good at working with AI before that so there wasn't much of a learning curve other than figuring out how to configure it to automatically do the ruff/mypy/tests loop I'd already been doing manually.
They key is that I've always had that prompt/edit/verify loop, and I've always leaned heavily on git to be able to roll back bad AI changes. Those are the skills that let me blow past my peers.
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.
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 use that 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.
> 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.
I wouldn't waste your time, if someone wants to stick their head in the sand rather than reconsider what's possible because it personally threatens their ego and world view, nothing's going to change their mind. If I were to share the code he'd probably grasp at smoke trying to find ways to discredit it rather than try to understand my workflow and replicate my results.
I use AI every day. But 5-10k loc is a huge claim, ai or not. It’s just too bad you can’t back it up - nobody ever can because sorry “closed source” (ironic considering these llms having been trained on open source…) Let me guess, it’s an AI product?
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.
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.
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.
> I also use it for building things like app landing pages.
This is a reasonable usage of LLMs up to a certain point, and especially if you're in full control of all the requirements as the dev. If you don't mind missing details related to sales and marketing such as SEO and analytics, I think those are not really "landing pages", but rather just basic web pages.
> I hate web development, and LLMs are pretty good at it because I'd guess that is 90% of their training data related to software development.
Your previous sentence does not support this at all since web development is a much more broad topic than your perception of landing pages. Anything can be a web app, so most things are nowadays.
Overshooting the capabilities of LLMs is pretty natural when you're exploring them. I've been using them to partially replace stack overflow or get short snippets of code for ~2 years. When Claude code came out, I gave it increased responsibility until I made a mess with it, and now I understand where it doesn't work and am back to using LLMs more for ideas and advice. I think this arc is pretty common.
I do a variety of things, including iOS and web. Like you mentioned, LLM results between the two are very different. I can't trust LLM output to even compile, much less work. Just last night, it told me to use an API called `CMVideoFormatDescriptionGetCameraIntrinsicMatrix`. That API is very interesting because it doesn't exist. It also did a great job of digging some deep holes when dealing with some tricky Swift 6 concurrency stuff. Meanwhile it generated an entire nextjs app that worked great on the first shot. It's all about that training data baby
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).
> `CMVideoFormatDescriptionGetCameraIntrinsicMatrix`. That API is very interesting because it doesn't exist.
same experience, and its been not great for juniors around me cause they have no idea why its not compiling or that the thing it wrote doesn't even exist...
Similar to my experience, it works well for small tasks, replacing search (most of the time) and doing alot of boilerplate work.
I have one project that is very complex and for this I can't and don't use LLMs for.
I've also found it's better if you can get it code generate everything in the one session, if you try other LLMs or sessions it will quickly degrade.
That's when you will see duplicate functions and dead end code.
The AI-Assist tools (Cursor, Windsurf, Claude Code, etc) want you to be "all-in" and that's why so many people end up fighting them. A delicate balance is hard to achieve when you're discarding 80% of the suggestions for 20% of the productivity boosts.
I don't get the whole "all-in" mentality around LLMs.
They are being marketed a virtual assistants that will literally do all the work for you. If they become marketed truthfully, however, people will probably realize that they aren't worth the cost and it's largely more beneficial to search the web and/or crowdsource answers.
As a previous iOS dev I was able to spin up a moderately complex app in a weekend, something that would have taken me probably at least a couple of weeks in the past. I have no idea what you’re on about. I don’t even use cursor and windsurf etc, I’m having chatGPT and Gemini just dump all their outputs into single files and manually breaking them up.
I've found LLMs are extremely hit or miss with iOS development. I think part of that might be how quickly Swift and SwiftUI is changing coupled with how bad Apple documentation is. I have loved using them to generate quick views and such for scaffolding purposes and quick iterations, but they tend to break down quickly around asynchronous coding and non-trivial business logic. I will say they're still incredibly useful to point you in a direction, but can be very misleading and send you down a hallucination rabbit hole easily.
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.
I tend to agree with this. These days I usually use LLMs to learn about something new or to help me generate client code for common APIs (especially boto3 these days). I tried Windsurf to help me make basic changes to my docker compose files, but when it couldn't even do that correctly, I lost a little enthusiasm. I'm sure it can build a working prototype of a small web app but that's not enough for me.
For me LLMs are a game changer for devops (API knowledge is way less important now that it's even been) but I'm still doing copy pasting from ChatGPT, however primitive it may seem.
Fundamentally I don't think it's a good idea to outsource your thinking to a bot unless it's truly better than you at long term decision making. If you're still the decision maker, then you probably want to make the final call as to what the interfaces should look like. I've definitely had good experiences carefully defining object oriented interfaces (eg for interfacing with AWS) and having LLMs fill in the implementation details but I'm not sure that's "vibe coding" per se.
I had a similar experience as the author. I've found found that cursor / copilot are FANTASTIC at "smart autocomplete", or "write a (small function that does this)" and quick viral prototypes.
But after I got a week into my LLM-led code base, it became clear it was all spaghetti code and progress ground to a halt.
This article is a perfect snapshot of the state of the art. It might improve in the future, but this is where it is in May 2025.
I get it and I see the same problems as the author.
I'm working on a few toy projects and I am using LLM for 90% of it.
The result is 10x faster than if I coded it "by hand", but the architecture is worse and somewhat alien.
I'm still keeping at it, because I'm convinced that LLM driven code is where things are headed, inevitably. These tools are just crazy powerful, but we will have to learn how to use them in a way that does not create a huge mess.
Currently I'm repeatedly prompting it to improve the architecture this way or that way, with mixed results. Maybe better prompt engineering is the answer? Writing down the architecture and guidelines more explicitly?
Imagine how the whole experience will be if the latency was 1/10th of what it is right now and the tools are 10x better.
I hope we get to that "10x better" point. I think the problem right now is people advertising LLMs as if we're there already. And it's not just the providers, it's also the enthusiasts on X/Reddit/etc that think they have found the perfect workflow or prompt.
Just like you're mentioning "maybe better prompt engineering", I feel like we're being conditioned to think "I'm just not using it right" where maybe the tool is just not that good yet.
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.
This is where they shine, for prototyping greenfield projects, but as the project gets closer to production that 10x erodes. You have to be really intentional about the architecture, fixing core design issues later can turn 10x into 0.1x.
At least currently, the only use pattern that can withstand complex codebases is as advanced speech-to-text, but without the speech if that makes sense. The main issue with that is phrasing things in English is often far more verbose, so without the speech, it's very often faster to just do it by hand.
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.
One thing you can do is to define the classes and methods that you want to have, and have the LLM implement them. For tricky things, you can leave additional notes in the empty method body as to how things should be implemented.
This way you're doing the big picture thinking while having the LLM do what's it's good at, generating code within the limits of its context window and ability to reason about larger software design.
I mostly treat the LLM as an overly eager to please junior engineer that types very quickly, who can read the documentation really quickly, but also tends to write too much code and implement features that weren't asked for.
One of the good things is that the code that's generated is so low effort to generate that you can afford to throw away large chunks of it and regenerate it. With LLM assistance, I wrote some code to process a dataset, and when it was too screwy, I just deleted all of it and rewrote it a few times using different approaches until I got something that worked and was performant enough. If I had to type all of that I would've been disappointed at having to start over, and probably more hesitant to do so even if it's the right thing to do.
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.
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.
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.
> One morning, I decide to actually inspect closely what’s all this code that Cursor has been writing.
You can't abdicate your responsibility as a builder to the LLM. You are still responsible for the architecture, for the integrity, for the quality. In the same way you wouldn't abdicate your responsibility if you hired a more junior engineer.
> So I do a “coding review” session. And the horror ensues.
Yup. I've spoken about this on here before. I was a Cursor user for a few months. Whatever efficiency gains I "achieved" were instantly erased in review, as we uncovered all the subtle and not-so-subtle bugs it produced.
Went back to vanilla VSCode and still use copilot but only when I prompt it to do something specific (scaffold a test, write a migration with these columns, etc).
Cursor's tab complete feels like magic at first, but the shine wore off for me.
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?
Coding and writing is like arithmetic and algebra, use it or lose it. You don’t gain fluency by throwing everything into Mathematica.
Of course the real question is, is there any reason to be good at coding and writing, if LLMs can just do it instead? Of course it’s hard to sell that we should know arithmetic when calculators are ubiquitous.
Personally, I value being skilled, even if everyone is telling me my skills will be obsolete. I simply think it is inherently good to be a skilled human
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.
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 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.
You're right and I will still use it, but only for more limited scopes.
I've also cancelled my Claude subscription recently, but for different reasons - it doesn't have the "memory" feature that makes ChatGPT so much more worth it at the moment.
paid for a year of claude all at once and deeply regret it the last month or so. seems like it just tries to do so much extra lately. feel like half of my prompts lately are just reiterating that i dont want it to try to do more than i ask...
if i dont do that it always seems to throw out 3 fresh files ill need to add to make their crazy implementation work.
ive pretty much swapped to using it just for asking for minor syntax stuff i forget. ill take my slower progress in favor of fully grasping everything ive made.
i have one utility that was largely helped by claude in my current project. it drives me nuts, it works but im so terrified of it and its so daunting to change now.
Go to AI Studio, select Gemini Pro, give it your code, or describe a problem you want to solve, and then tell it that you want to --> discuss <-- the code. That you don't want it to generate code for you, but that you want to discuss it, that you want it to comment on your code or on how to solve the problem.
This is the best way to get Gemini to be a really good assistant, unless you want to add System Instructions which precisely describe how it should behave.
Because if you just say it should solve some problem for you, it eagerly will generate a lot of code for you, or add a lot of code to the clean code which you provided.
Yeah my current approach is to generate a plan with Gemini Pro, with plenty of back and forths, and then have it write the plan to a markdown file. Afterwards I get either it or another model to follow the plan step by step. Without doing this the results are questionable and often require going back and fixing a lot.
Even limiting its scope can be risky, if it's a complex problem in a niche that's not well-represented in the training data. Been learning Gleam lately, and yesterday when wrapping my head around recursion was starting to give me a headache, I tried to ask Gemini Pro to write a function. It needed to recurse down a tree, perform a function on each child that requires information accumulated from each of its ancestors, and return all nodes in the tree as a flat list.
It returned over 600 lines of code across 3 code blocks, almost all of them commented out for some reason, each with an accompanying essay, and each stuffed with hallucinated and unnecessary helper functions. Apparently Gemini Pro struggles to wrap its weights around recursion more than I do. I just wrote it myself and only needed 26 lines. It's not using tail calls, but hey, my target platform still doesn't support tail call optimization in 2025 anyway.
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.
Personally, I use LLMs to write code that I would have never bothered writing in the first place. For example, I hate web front-end development. I'm not a web dev, but sometimes it's cool to show visual demos or websites. Without LLMs, I wouldn't have bothered creating those, because I wouldn't have had the time anyway, so in that case, it's a net positive.
I don't use LLMs for my main pieces of work exactly due to the issues described by the author of the blogpost.
228 comments
[ 40.5 ms ] story [ 4170 ms ] threadI still use LLMs heavily. However, I now follow two rules:
* Do not delegate any deep thought to them. For example, when thinking through a difficult design problem, I do it myself.
* Deeply review and modify any code they generate. I go through it line-by-line and edit it thoroughly. I have to do this because I find that much of what they generate is verbose, overly defensive, etc. I don't care if you can fix this through prompting; I take ownership over future maintainability.
"Vibe coding" (not caring about the generated code) gives me a bad feeling. The above approach leaves me with a good feeling. And, to repeat, I am still using them a lot and coding a lot faster because of it.
This is the issue, right? If you have to do this, are you saving any time?
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 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!
It takes a good hour or two to draw up the plans, but it's the kind of thing that would take me all day to do, possibly several as my ADHD brain rebels against the tedium. AI can do yeomans work when it just wings it, and sometimes I have just pointed at a task and did it in one shot, but they work best when they have detailed plans. Plus it's really satisfying to be able to point at the plan doc and literally just say "make it so".
And why did they make this change? Because it makes users spend more time on the platform. ChatGPT wasn't just one of the fastest-growing web services ever, it's now also speedrunning enshittification.
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.
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.
1) I do a lot of scraping, and Go concurrency + Colly has better performance
2) My DB size is exploding and I have limited budget, and it looks like CH is so much better at compressing data. I recently did a test and for the same table with same exact data, MySQL was using 11GB, ClickHouse 500MB
That's pretty impressive
That's pretty typical best case size for weblogs and other time ordered data where column data correlate with time values. You do have to tweak the schema a bit to get there. (Specifically a "good" sort order, codecs, ZSTD instead of LZ4 compression, etc.)
Yes, imo, too many people believe current LLMs are capable of doing this well, They aren't. Perhaps soon! But not today, so you shouldn't try to use LLMs to do this for serious projects. Writing that MDN file sounds like a wonderful way to get your own head around the infrastructure and chat with other devs / mentors about it though, that's a great exercise, I'm going to steal it.
Anyway, LLMs are, as we all know, really good text predictors. Asking a text predictor to predict too much will be stretching the predictions too thin: give it one file, one function, and very specific instructions, and an LLM is a great way to increase your productivity and reducing mental overload on menial tasks (e.g., swap out all uses of "Button" in @ExperimentModal.tsx with @components/CustomButton.tsx). I think LLM usage in this sense is basically necessary to stay competitively productive unless you're already a super-genius in which case you probably don't read HN comments anyway so who cares. For the rest of us mortals, I argue that getting good at using LLM co-pilots is as important as learning the key bindings in your IDE and OS of choice. Peel away another layer of mental friction between you and accomplishing your tasks!
I also use it for building things like app landing pages. I hate web development, and LLMs are pretty good at it because I'd guess that is 90% of their training data related to software development. For that I make larger changes, review them manually, and commit them to git, like any other project. It's crazy to me that people will just go completely off the rails for multiple hours and run into a major issue, then just start over when instead you can use a measured approach and always continue forward momentum.
To be uncharitable and cynical for a moment (and talking generally rather than about this specific post), it yields content. It gives people something to talk about. Defining their personality by their absolutes, when in reality the world is an infinite shades of gradients.
Go "all in" on something and write about how amazing it is. In a month you can write your "why I'm giving up" the thing you went all in on and write about how relieved/better it is. It's such an incredibly tired gimmick.
"Why I dumped SQL for NoSQL and am never looking back" "Why NoSQL failed me"
"Why we at FlakeyCo are all in on this new JavaScript framework!" "Why we dumped that new JavaScript framework"
This same incredibly boring cycle is seen on here over and over and over again, and somehow people fall for it. Like, it's a huge indicator that the writer more than likely has bad judgment and probably shouldn't be the person to listen to about much.
Like most rational people that use decent judgement (rather than feeling I need to "all in" on something, as if the more I commit the more real the thing I'm committing to is), I leverage LLMs many, many times in my day to day. Yet somehow it has authored approximately zero percentage of my actual code, yet is still a spectacular resource.
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 product, no room for move fast, break things)
THEN: LLMs aren't going to 10x you. An IDE like Cursor will likely make you slower for a very long time until you've learned to use it.
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.
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.
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'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.
~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.
no they didn't, no one said that
i know that because i was around then and everyone was doing the same thing
also, maybe there's a difference between searching and collating answers and just copy and pasting a solution _without thinking_ at all
You're right, probably hallucinated memory of much more senior people telling me exactly that.
> i know that because i was around then and everyone was doing the same thing
Damn, we worked together in the same company at that time? Nice to meet you again after all these years. Still thinking of picking up farming once you get out of prison?
I'm not sure there's much of a skillset to speak of for these tools, beyond model-specific tricks that evaporate after a few updates.
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.
they will make you clueless about what the code does and your code will be unmaintanable.
Basically, use LLMs as a tool for specific things, don't let them do whatever and everything.
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.
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.
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 usability issues as an LLM you'd never use it. Yet for some reason the bar is so low for LLMs. It's insane to me how much people have indulged in the hype koolaid around these tools.
There’s definitely hype out there, but dismissing all AI use as “koolaid” is as lazy as the Medium posts you’re criticizing. It’s not perfect tech, but some of us are integrating it into real production workflows and seeing tangible gains, more code shipped, less fatigue, same standards. If that’s a “low bar,” maybe your expectations have shifted.
It's pretty a really, really simple concept.
If I have a crazy Typescript error, for instance, I can throw it in and get a much better idea of what's happening. Just because that's not perfect, doesn't mean it isn't helpful. Even if it works 90% of the time, it's still better than 0% of the time (Which is where I was at before).
It's like google search without ads and with the ability to compose different resources together. If that's not useful to you, then I don't know what to tell you.
Anyhoo... I find that there are times where you have to really get in there and question the robot's assumptions as they will keep making the same mistake over and over until you truly understand what it is they are actually trying to accomplish. A lot of times the desired goal and their goal are different enough to cause extreme frustration as one tends to think the robot's goal should perfectly align with the prompt. Once it fails a couple times then the interrogation begins since we're not making any further progress, obviously.
Case in point, I have this "Operational Semantics" document, which is correct, and a peg VM, which is tested to be correct, but if you combine the two one of the operators was being compiled incorrectly due to the way backtracking works in the VM. After Claude's many failed attempts we had a long discussion and finally tracked down the problem to be something outside of its creative boundaries and it needed one of those "why don't you do it this way..." moments. Sure, I shouldn't have to do this but that's the reality of the tools and, like they say, "a good craftsman never blames his tools".
In an era where an LLM can hallucinate (present you a defect) with 100% conviction, and vibe coders can ship code of completely unknown quality with 100% conviction, the bar by definition has to have been set lower.
Someone with experience will still bring something more than just LLM-written code to the table, and that bar will stay where it is. The people who don't have experience won't even feel the shortcomings of AI because they won't know what it's getting wrong.
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?
Searching for relevant info on the Internet can take several attempts, and occasionally I end up not finding anything useful.
My ide intellisense tries to guess what identifier I want and put it at the top of the list, sometimes it guesses wrong.
I've heard that the various package repositories will sometimes deliberately refuse to work for a while because of some nonsense called "rate limiting".
Cloud deployments can fail due to resource availability.
Anyway, code generation tools almost always are born unreliable, then improve piecewise into almost reliable, and finally get replaced by something with a mature and robust architecture that is actually reliable. I can't imagine how LLMs could traverse this, but I don't think it's an extraordinary idea.
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.
It's not all or nothing. What you get value out of immediately will vary based on circumstance.
But they drew boundaries with very specific conditions that lead the reader. It’s a common theme in these AI discussions.
Again I think the high level premise is correct as I already said, the delivery falls flat though. Your more junior devs have larger opportunity of extracting value.
I gently suggested that the problem may have not been with his post but with your understanding. Apparently you missed the point again.
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.
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.
* 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.
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.
You have cmdk mode which you need to prompt and seems to he a lobotomized version of chat. I find putting comments and waiting for the copilot mode to kick in better as then the way we got there is saved.
Then there is agentic editing chat: that is the timewaster you speak off I believe, but what is there to learn? Sometimes it generates a metric ton of code, including in legacy massive code bases, that help, and often it just cannot do whatever.
I don't think these cases you make, or at least, when the second one goes beyond the basics, are different. There is nothing to learn except that you need read all the code, decide what you want in tech detail and ask that of the agentic chat. Anything else fails beyond the basics and 'learning to use it' will be that but if you didn't know that after 5 minutes you definitely didn't do any 'fine tuned pycharm ide', ever.
It is a tool that customizes code it ingested for your case specifically, if it can. That is it. If it never saw a case, it won't solve it, no matter what you 'learn to use'. And I am fine doing that in public: we use LLMs a lot and I can give you very simple cases that, besides (and often even that doesn't work) typing up the exact code, it will never fix with the current models. It just gets stuck doing meaningless changes with confidence.
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.
However it's great for simple "write a function that does X", which I could do myself but it would take longer, be boring and require several iterations to get it right.
Having said that, blindly copying a few lines of ChatGPT code did lead to automated newsletters being sent out with the wrong content.
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.
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.
They key is that I've always had that prompt/edit/verify loop, and I've always leaned heavily on git to be able to roll back bad AI changes. Those are the skills that let me blow past my peers.
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.
[1]https://deepmind.google/discover/blog/alphaevolve-a-gemini-p...
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.
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.
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 -------------------------------------------------------------------------------
Note this project also has 199 test cases.
Initial commit for cred:
commit caff2ce26225542cd4ada8e15246c25176a4dc41 Author: redacted <redacted> Date: Thu May 15 11:32:45 2025 +0800
And when I say easy, I was playing the bass while working on this project for ~3 hours.The container images also have significant logic for interfacing securely with the private company network and upstream services given on-prem or edge deployment.
Yikes. But also lol.
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.
LOL
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.
> * 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...
This is a reasonable usage of LLMs up to a certain point, and especially if you're in full control of all the requirements as the dev. If you don't mind missing details related to sales and marketing such as SEO and analytics, I think those are not really "landing pages", but rather just basic web pages.
> I hate web development, and LLMs are pretty good at it because I'd guess that is 90% of their training data related to software development.
Your previous sentence does not support this at all since web development is a much more broad topic than your perception of landing pages. Anything can be a web app, so most things are nowadays.
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).
there's MCP servers now that should theoretically help with that, but that's its own can of worms.
Most code out there is glue. So there’s a lot of trainning data on integrating/composing stuff.
If you take this as a whole, you could do that 30-60 min into 5 min for most dev work.
I have one project that is very complex and for this I can't and don't use LLMs for.
I've also found it's better if you can get it code generate everything in the one session, if you try other LLMs or sessions it will quickly degrade. That's when you will see duplicate functions and dead end code.
They are being marketed a virtual assistants that will literally do all the work for you. If they become marketed truthfully, however, people will probably realize that they aren't worth the cost and it's largely more beneficial to search the web and/or crowdsource answers.
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.
For me LLMs are a game changer for devops (API knowledge is way less important now that it's even been) but I'm still doing copy pasting from ChatGPT, however primitive it may seem.
Fundamentally I don't think it's a good idea to outsource your thinking to a bot unless it's truly better than you at long term decision making. If you're still the decision maker, then you probably want to make the final call as to what the interfaces should look like. I've definitely had good experiences carefully defining object oriented interfaces (eg for interfacing with AWS) and having LLMs fill in the implementation details but I'm not sure that's "vibe coding" per se.
But after I got a week into my LLM-led code base, it became clear it was all spaghetti code and progress ground to a halt.
This article is a perfect snapshot of the state of the art. It might improve in the future, but this is where it is in May 2025.
I'm working on a few toy projects and I am using LLM for 90% of it.
The result is 10x faster than if I coded it "by hand", but the architecture is worse and somewhat alien.
I'm still keeping at it, because I'm convinced that LLM driven code is where things are headed, inevitably. These tools are just crazy powerful, but we will have to learn how to use them in a way that does not create a huge mess.
Currently I'm repeatedly prompting it to improve the architecture this way or that way, with mixed results. Maybe better prompt engineering is the answer? Writing down the architecture and guidelines more explicitly?
Imagine how the whole experience will be if the latency was 1/10th of what it is right now and the tools are 10x better.
Just like you're mentioning "maybe better prompt engineering", I feel like we're being conditioned to think "I'm just not using it right" where maybe the tool is just not that good yet.
Yes, very explicit like “if (condition) do (action)” and get more explicit when… oh wait!
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.
This way you're doing the big picture thinking while having the LLM do what's it's good at, generating code within the limits of its context window and ability to reason about larger software design.
I mostly treat the LLM as an overly eager to please junior engineer that types very quickly, who can read the documentation really quickly, but also tends to write too much code and implement features that weren't asked for.
One of the good things is that the code that's generated is so low effort to generate that you can afford to throw away large chunks of it and regenerate it. With LLM assistance, I wrote some code to process a dataset, and when it was too screwy, I just deleted all of it and rewrote it a few times using different approaches until I got something that worked and was performant enough. If I had to type all of that I would've been disappointed at having to start over, and probably more hesitant to do so even if it's the right thing to do.
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.
Unfortunately ceo manager types cannot distinguish between bad and good enginners
You can't abdicate your responsibility as a builder to the LLM. You are still responsible for the architecture, for the integrity, for the quality. In the same way you wouldn't abdicate your responsibility if you hired a more junior engineer.
Yup. I've spoken about this on here before. I was a Cursor user for a few months. Whatever efficiency gains I "achieved" were instantly erased in review, as we uncovered all the subtle and not-so-subtle bugs it produced.
Went back to vanilla VSCode and still use copilot but only when I prompt it to do something specific (scaffold a test, write a migration with these columns, etc).
Cursor's tab complete feels like magic at first, but the shine wore off for me.
My favorite thing here watching a co-worker is when Cursor tries to tab complete what he just removed, and sometimes he does it by reflex.
Of course the real question is, is there any reason to be good at coding and writing, if LLMs can just do it instead? Of course it’s hard to sell that we should know arithmetic when calculators are ubiquitous.
Personally, I value being skilled, even if everyone is telling me my skills will be obsolete. I simply think it is inherently good to be a skilled human
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.
if i dont do that it always seems to throw out 3 fresh files ill need to add to make their crazy implementation work.
ive pretty much swapped to using it just for asking for minor syntax stuff i forget. ill take my slower progress in favor of fully grasping everything ive made.
i have one utility that was largely helped by claude in my current project. it drives me nuts, it works but im so terrified of it and its so daunting to change now.
This is the best way to get Gemini to be a really good assistant, unless you want to add System Instructions which precisely describe how it should behave.
Because if you just say it should solve some problem for you, it eagerly will generate a lot of code for you, or add a lot of code to the clean code which you provided.
It returned over 600 lines of code across 3 code blocks, almost all of them commented out for some reason, each with an accompanying essay, and each stuffed with hallucinated and unnecessary helper functions. Apparently Gemini Pro struggles to wrap its weights around recursion more than I do. I just wrote it myself and only needed 26 lines. It's not using tail calls, but hey, my target platform still doesn't support tail call optimization in 2025 anyway.
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 don't use LLMs for my main pieces of work exactly due to the issues described by the author of the blogpost.