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.
The thing most LLM maximalists don't realize is that the bottleneck for most people is not code generation, it's code understanding. You may have doubled the speed at which you created something, but you need to pay double that time back in code review, testing and building a mental model of the codebase in your head. And you _need_ to do this if you want to have any chance of maintaining the codebase (i.e. bugfixes, refactoring etc.)
> 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.
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.
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.
Many places are quite literally forcing their software engineers to use LLMs. Complete with cursor/copilot is the ability to see usage statistics and surely at these companies these statistics will eventually be used as firing criteria.
I gave them a fair shake. However, I do not like them for many reasons. Code quality is one major reason. I have found that after around a month of being forced to use them I felt my skill atrophy at an accelerated rate. It became like a drug where instead of thinking through the solution and coming up with something parsimonious I would just go to the LLM and offload all my thinking. For simple things it worked okay but it’s very easy to get stuck in a loop. I don’t feel any more productive but at my company they’ve used it as justification to increase sprint load significantly.
There has been almost a religious quality associated to LLMs. This seems especially true among the worst quality developers and the non-technical morons at the top. There are significant security concerns that extend beyond simple bad code.
To me we have all the indicators of the maximum of the hype cycle. Go visit LinkedIn for confirmation. Unless the big AI companies begin to build nuclear power it will eventually become too expensive and unprofitable to run these models. They will continue to exist as turbo autocomplete but no further. The transformer model has fundamental limitations and much like neural networks in the 80s it’ll become more niche and die everywhere else. Like its cousins WYSIWIG and NoCode in 30 more years it’ll rise again like a phoenix to bring “unemployment” to developers once more. It will be interesting to see who among us was swimming without clothes when the water goes out.
This [1] is an old and brilliant article titled "On the foolishness of natural language programming" by Dijkstra relevant to this debate.
The argument is that the precision allowed by formal languages for programming, math etc were the key enabler for all of the progress made in information processing.
ie, Vibe-coding with LLMs will make coding into a black-art known only to the shamans who can prompt well.
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 have been trying LLMs in a couple of new small projects recently.
I got more success that I hoped for, but I had to adjust my usage to be effective.
First of all, treat the LLM as a less experienced programmer. Don't trust it blindly but always make code review of its changes. This gives several benefits.
1) It keeps you in touch with the code base, so when need arise you can delve into it without too much trouble
2) You catch errors (sometimes huge ones) right away, and you can have them fixed easily
3) You can catch errors on your specification right away. Sometimes I forget some detail and I realize it only when reviewing, or maybe the LLMs did actually handle it, and I can just tell it to update the documentation
4) You can adjust little by little the guidelines for the LLM, so that it won't repeat the same "mistakes" (wrong technical decisions) again.
In time you get a feeling of what it can and cannot do, where you need to be specific and where you know it will get it right, or where you don't need to go into detail. The time required will be higher than vibe coding, but decreases over time and still better than doing by myself.
There is another important benefit for me in using an LLM. I don't only write code, I do in fact many other things. Calls, writing documentation, discussing requirements etc. Going back to writing code requires a change of mental state and to recall into memory all the required knowledge (like how is the project structured, how to use some apis etc.). If I can do two hours of coding it is ok, but if the change is small, it becomes the part where I spend the majority of time and mental energy.
Or I can ask the LLM to make the changes and review them. Seeing the code already done requires less energy and will help me reminding stuff.
> LLMs are okay at coding, but at scale they build jumbled messes.
This reminds me of the day of Dreamweaver and the like. Everybody loved how quickly they could drag and drop UI components on a canvas, and the tool generated HTML code for them. It was great at the beginning, but when something didn't work correctly, you spent hours looking at spaghetti HTML code generated by the tool.
At least, back then, Dreamweaver used deterministic logic to generate the code. Now, you have AI with the capability to hallucinate...
The fundamental issue is that agents / LLMs at present are not engineers or system architects. You cannot sit back and play product manager yet. If you go in with this expectation, you will certainly have a poor experience.
LLM-powered coding agents are not comparable to any existing human role or tool and therefore cannot be used interchangeably. They are a fundamentally new and novel type of tool that enable incredible productivity IF and only if you use them effectively. The tool is not the problem, the user is.
I’m also building a non-trivial SaaS platform and the cursor agent has written 90%+ of the code in the codebase. It has architected ~0% of the codebase. It has modeled ~0% of the data layer in the codebase. It has enabled me to move at least 10x the speed of implementation and debugging (yes, it is incredible at debugging if you use the right techniques).
I use the word implementation because that is almost exclusively what I use it for. I do the planning, design, architecture, engineering. Then, I communicate those specifications to it in digestible chunks, and it implements them incredibly fast. It makes mistakes sometimes, comes up with poor naming conventions, fails to reuse existing modules in the codebase, etc. But that’s fine - I simply give it feedback, point it in the right direction, and within seconds it’s back on course.
I own the codebase, it’s just my super fast implementation minion. If it gets something wrong - that’s my fault. I failed to communicate my expectations clearly. I’m heavily using my brain while working with the LLM - I’m just reserving those mental cycles for higher-level decision making than the actual tokens to type into the editor.
The power is in your ability to steer it and communicate in clear terms what you want, and maintain the right level of abstraction in your instructions. Too specific and you lose some of the benefit beyond just writing the code by hand, too vague / high-level and it will over-engineer something totally different than what you intended.
You’re the engineer, it’s just a really smart semantic code generator. That might change in the future, but for now, if you use it in this way, the productivity benefit is very clear.
I’ve been using cursor with 3.7 sonnet max (now sonnet 4) and I already can’t imagine a world without coding agents - it is so deeply rooted into my workflow.
> 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.
> I have no concept of Go or Clickhouse best practices.
> One morning, I decide to actually inspect closely what’s all this code that Cursor has been writing. It’s not like I was blindly prompting without looking at the end result, but I was optimizing for speed and I hadn’t actually sat down just to review the code.
> I’m defaulting to coding the first draft of that function on my own.
I feel like he’s learnt the wrong lesson from this. There is a vast gulf between letting an LLM loose without oversight in a language you don’t know and starting from scratch yourself. There’s absolutely nothing wrong with having AI do the first draft. But it actually has to be a first draft, not something you blindly commit without review.
> “Vibe coding”, or whatever “coding with AI without knowing how to code” is called, is as of today a recipe for disaster, if you’re building anything that’s not a quick prototype.
But that’s what vibe coding is. It’s explicitly about quick throwaway prototypes. If you care about the code, you are not vibe coding.
> There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. […] It's not too bad for throwaway weekend projects, but still quite amusing. I'm building a project or webapp, but it's not really coding - I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.
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.
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.
I noticed a funny thing a while back after using the “bird’s eye view” capability in my car to help with parallel parking: I couldn’t parallel park without that feature anymore after a few years. It made for an awkward situation every time I visited the Bay Area and rented a car. I realized I had become so dependent on the bird’s eye view that I had lost the ability to function without it.
Luckily in this particular case, being able to parallel park unassisted isn’t all that critical in the overall scheme of things, and as soon as I turned that feature off, my parking skills came back pretty quickly.
But the lesson stuck with me, and when LLMs became capable of generating some degree of functioning code, I resolved not to use them for that purpose. I’m not trying to behave like a stodgy old-timer who increasingly resists new tech out of discomfort or unfamiliarity—it’s because I don’t want to lose that skill myself. I use LLMs for plenty of other things like teaching myself interesting new fields of mathematics or as a sounding board for ideas, but for anything where it would (ostensibly) replace some aspect of my critical thinking, I try to avoid them for those purposes.
This perspective can only come from someone who started programming in the pre-LLM era. Back in those days the code didn’t write itself and you had to think really hard about shit and bang your head in the wall. This literally requires strong and coherent mental models, because there’s no other way… there were no shortcuts.
Post-LLM era, you can use a shortcut to get a representation of what something could be. However I see a lot of folks shipping that representation straight to prod. By comparison, the mental models created are weaker and have less integrity. You might be able to feel that something is off, but you lack the faculties to express or explain why.
"Using [your] brain" is key. And your brain has to understand software engineering in the first place, before you can use it. In my project, the product manager has recently tried his hand at vibe coding. LLM produces what you would expect it to produce and as described in the article: ok but not robust code, and fast. So now he thinks he knows how fast coding should be and has gone light speed on the product, expecting engineers to produce high quality software at the speed of LLM-produced "ok code". And it's hard to keep expectations reasonable when the world is all a-hype about LLM coding.
> 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!
In order to convey all of the ways that Gemini, Claude, O4-mini and many other LLMs have worked aggressively to sabotage my systems would take an unreasonable amount of time to describe. Among the more ridiculous occurrences have been actively ignoring instructions to read my comprehensive docs, the system spec and coding principles documents. These LLMs will rewrite your architecture when you have only provided an instruction to make a simple change. The fact that some individuals are supposedly experiencing LLM euphoria leads me to one conclusion. They aren't producing anything that is complex and they probably don't have a large codebase. Furthermore, I wonder if the so-called vibe coders are actually looking at and understanding the code at all.
Hypothesis: the actual long-term impact of LLM's on coding will be that more different languages get used, because it reduces the "ugh I don't want to have to learn all that" psychological obstacle that prevents programmers experienced in one language from learning another. We should be using different languages for different tasks, but the push has always been to try to get One Language To Rule Them All. Ten years ago people tried to make Javascript their db query language and their backed language. More recently, the push is to use Python for everything. Both languages are fine in certain domains, but a poor fit in others.
Even if the idea that an LLM will help you do it is false, perhaps it is still a good idea if it convinces the experienced programmer to go ahead and use SQL for the query, Go for the async, Javascript for the frontend, etc. Right now, few if any companies would let you use the best tool for the job, if that's not one they already use. Perhaps the best use of LLMs is to convince programmers, and their bosses, to use the best tool for each job.
But, after you've gotten past that part, you will probably (like the author of this article) need to throw away the LLM-generated code and write it yourself.
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
I like having copilot suggest things < ~500 chars. I've discovered new patterns of doing things in go and Python and I've saved on a bit of typing. It really is just a better auto-complete for me. But anything longer than that and the cost of me spotting and fixing the problems in what it's suggesting starts to outweigh the benefit (unless I'm trying to write something super boilerplate).
I have also stepped back from LLM coding a bit. I still utilize LLMs for API discussions, maybe 1-off things I would stackoverflow before but I have stepped back a bit from autocomplete everywhere and even agentic flows.
And I feel more productive. I recommend that everyone gives it a try.
As a tenured SW developer in my company my measurements for success are much more than "how much code can I spit out". There are mentoring, refactoring, code readability/mantainability, and quality that are important to my job. I found that LLM generated code was not hitting the necessary bars for me in these areas (agent or code autocompletion) and so I have stepped back from them. The readability point is extra important to me. Having maintained million lines of code products, I have found that readability is more important than writing a ton of code: and LLMs just don't hit the bar here.
When I am playing with side projects that I don't have the same bar on, sure Ill have bolt or lovable generate me some code in combination with cursor or windsurf, but these are low stakes and in some ways I just want to get something on paper.
in which Windsurf is forging ahead with an agentic LLM product that endeavors to not only replace software engineers but actually take over the entire software engineering PROCESS.
We're at a very interesting point, where investors and corporate interests are crystal clear in their intent to use LLMs to replace as many expensive humans as possible, while the technology available to do so is not there yet. And depending on your own perspective, it's not clear it ever will be, or perhaps it'll eventually be "good enough" for them to downsize us anyway.
I keep thinking about compilers. The old timers had been writing assembly by hand for years. The early C compilers were producing defective garbage output that was so incredibly poor that it was faster to keep coding by hand. Then the compilers got better. And better, and better, and now pretty much nobody inspects the output, let alone questions it.
I agree with this and matches my thinking (however - the fact that this is even an option is an incredible breakthrough that I did not expect to happen preLLMs - potentially in decades).
I have basically given up on "in IDE" AI for now. I simply have a web interface on my 2nd monitor of whatever the "best" LLM (currently Gemini, was Claude) is and copy paste snippets of code back and forth or ask questions.
This way I have to physically copy and paste everything back - or just redo it "my way", which seems to be enough of an overhead that I have to mentally understand it. When it's in an IDE and I just have to tick accept I just end up getting over eager with it, over accepting things and then wishing I hadn't, and spend more time reverting stuff when the penny drops later this is actually a bad way to do things.
It's really more a UX/psychology problem at the moment. I don't think the 'git diff' view of suggested changes is the right one that many IDEs use for it - I'm psychologically conditioned to review these like pull requests and it seems my critique of these is just not aligned to critiquing LLM code. 99% of PR reviews I do are finding edge cases and clarifying things. They're not looking at very plausible yet subtly completely wrong code (in the most part).
To give a more concrete example; if someone is doing something incredibly wrong in 'human PRs' they will tend to name the variables wrong because they clearly don't understand the concept, at which point the red flag goes off in my head.
In LLM PRs the variables are named often perfectly - but just don't do what they say they will. This means my 'red flag' doesn't fire as quickly.
It's very fustrating when you end up spending more time tracking down bugs and cleaning up inconsistent code then it would have taken to do it right yourself in the first place. It's an important lesson. That said, there are still massive productivity gains available. If you let the model mess with your existing code base, or if it get's past a small size, it will shit all over it. The LLM needs limited scope. I find it's great for frontend work, which is what I hate doing myself. I've been having it build webcomponents, paired with targeted backend functions that wrap internal libraries that I wrote for db and API calls. Then I compose things. Careful instructions, internal documentaion for the model and well contained isolated tasks are best. The models get confused and distracted by existing code, it's ofen better to document function interfaces and use rather than showing it the source. If the code is going into production you have to read it line by line and clean it up. I've been using Aider, mostly.
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.
Well yes, right now you really need to understand and closely supervise what the LLM is generating. On the other hand, every couple of weeks there’s a new model, that is noticeably better than everything before it. So any strong conclusions may be outdated by the end of the week.
What I witness is that many people pick a random model and expect a prompt they wrote in 10 seconds to replace an hour of coding. And then are disappointed and go back to coding manually.
For me, the magic of LLMs is that I already get an hour of coding via 30 minutes of prompting and finetuning the generated code. And I know that the ratio will constantly improve as LLMs become better and as I finetune my prompts to define the code style I prefer. I have been coding for pretty much all my life and I never felt more excited about it than I do now.
It would be cool if people shared their prompts and the resuling commits. If someone here is disappointed by the commits LLMs make, I would love to see the prompt, the commit, and which model made it.
When you have a hammer in your hand everything looks like a nail.
Developing without the knowledge what LLM writes is dangerous. For me having LLM as a tool is like having a few Junior Developers around, that I can advise and work with. If I have a complicated logic that I need to write - I write it. After I wrote it, I can ask LLM to review it, it might be good to find some corner cases in some places. When I need to "move things from one bucket to another", like call API and save to DB - that is a perfect task for LLM, that I can easily review after.
At the same time, LLM is able to write pretty good complicated logic as well for my side projects. I might need to give it a few hints, but the results are amazing.
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.
> but I was optimizing for speed and I hadn’t actually sat down just to review the code
There, there's your problem. The problem is not LLMs, the problem is people not using their brain. Can't we use LLMs and our brains as well? Both are amazing tools!
I think LLMs are great for generating the structure of your code. The only issue is that these models are amazing when you are navigating in very well documented, talked about, etc. subjects, and start to go off the rail when you are using somewhat esoteric things. The speed boost I get by generating Terraform and HTML, CSS, JS with Deepseek and Grok (sometimes asking one to review the others code) is pretty significant. My biggest disappointment is Claude. I have purchased a subscription from them but I need to cancel it. The usual ouput from 3.7 is horrenndous. I am not even sure why. The same prompt works very well with Deepseek and fails miserably with Claude.
Over the past few months, I have read numerous articles on this topic. Some are in favor, some are against, and others fall somewhere in between. However, they all share a common shortcoming: the absence of code. There are no codebases, no commit histories—nothing that allows readers to track how the codebase evolves, gets refactored, or how new features are integrated.
Without access to the code, it's challenging to verify the authors' claims and form an independent opinion. In my view, we should be cautious about trusting articles that lack examples or sources. As someone wiser than me once said:
> Articles without sources are merely the opinions of the author.
I love using LLMs with my debugging but also helping me to get started. Grok has been helpful in giving it a rubric and having it come up with the framework and headers, which saves some time. Unfortunately in my humble and limited experience, asking it to then improve upon that code is where it runs into mistakes. If you give it a perfect rubric of what you want, I think an LLM can give you some very good code, but it can't think ..beyond that like a human can.
Something I do very much love about LLMs is that I can feed it my server logs and get back an analysis of the latest intrusion attempts, etc. That has taught me so much on its own.
Off-topic: may I ask, why PHP + MySQL is no longer considered suitable to you?
It's hard to say without specifics, but simply upgrading from MySQL to PostgreSQL without rewriting the PHP codebase in Go might resolve most of the potential issues.
Let's take a step back and think about how LLMs are trained.
Think about when chat gpt gives you the side-by-side answers and asks you to rate which is "better".
Now consider the consequence of this at scale with different humans with different needs all weighing in on what "better" looks like.
This is probably why LLM generated code tends to have excessive comments. Those comments would probably get it a higher rating but you as a developer may not want that. It also hints at why there's inconsistency in coding styles.
In my opinion, the most important skill for developers today is not in writing the code but in being able to critically evaluate it.
I think getting the initial domain modeling, structure and opinions that build up a code base is more of an art than science. It’s highly opinionated. Sure you have SOLID but in my experience no one follows it to the book.
Once the code base structure and opinions are in place, I think LLMs are decent at writing code that are bounded to a single concern and not cross cutting.
LLM generated code bases work initially but so will code written by college kids for an initial set of requirements. Even a staff+ level engineer will struggle in contributing to a code base that is a mess. Things will break randomly. Don’t see how LLMs are any different.
I also tried to go as hard as I could with agents and I ran into a ton of problems. The core issue I found is that inferring "intent" from existing code is hard and it makes errors that accumulate and build up. This ends up wrecking the software project by adding tons of complexity and duplicate ways of doing things and changing assumptions depending on which part of the code base you are in.
I think that the solution is to somehow move towards an "intent" layer that sits above the code.
I still use Cursor, but I use AI judiciously so that I don't wreck the project and it is only acts as an aid.
If and when LLMs are able to complete software development projects autonomously, the first sign probably won't be that your own software development job gets easier. Almost certainly, Google AI, DeepSeek, or OpenAI will notice before you do, and that's when their further progress will be limited only by how fast their GPUs can develop AI software instead of how fast their human SWEs can develop AI software.
Eric Schmidt gave a TED interview about the subject this week. He predicts the US and China bombing each other's data centers.
LLMs are a good tool for certain purposes and that's it. Unfortunately, the vendors are obviously interested in inflating their stated capabilities to get the most returns on investment ...
I've been experimenting with LLMs for coding / "agentic" editing using Zed over the past month or so. It's another tool in the toolbox, good for prototyping, also good for rote tasks (like upgrading a legacy code base, converting one call to another.) So far I've been most impressed by Claude Sonnet. The jury is still out... I haven't used it for any "work" tasks, only hobby projects, because I don't feel comfortable doing that yet.
LLMs are pretty similar in concept to site builders. They can do the basics reasonably well but if you want anything custom they show their weaknesses.
I have been building a gallery for my site with custom zoom/panning UX to be exactly how I want it (which by the way does not already exist as a library). Figuring out the equations for it is simply impossible for an LLM to do.
I wouldn't be surprised if after the LLM hype we go back to site/app builders being the entry level option.
In my case, LLMs just replaced time wasted in stackoverflow fighting the cocky gatekeepers. Otherwise, I code as usual and it’s a great addition to my repertoire.
IMO the mistake was not knowing what he was doing. He basically (at a macro scale) copy-pasted stack overflow code without understanding what it does... We've all been there.
I don't think LLMs are at blame here, it is a tool and it can be used poorly. However, I do wonder what's the long term effects on someone who uses them to work on things they are knowledgeable about. Unfortunately this is not explored in the article.
After spending 1000s of dollars on 3 projects that I thought I could finish in a weeks :) with agents with cline, I reached similar conclusion. Best use cases I have seen it work is for good commit messages, templated documentation and cursory understanding existing code base. Shine wore off on me too.
I've come to mostly use ai to bounce ideas off of. Even that has gotten less useful these last few months for some reason. Now it either wants to do the work for me or just spit out a complete agreement without being any bit critical.
Kinda blows my mind that people do this with technology they’ve never used.
If I want to learn something new I won’t vibe code it. And if I vibe code I’ll go with tech I have at least some familiarity with so that I can fix the inevitable issues
So the end game for this is, to a certain extent, does the code quality matter if it does what it is needed?
In the past the quality mattered because maintenance and tech-debt was something that we had to spend time and resources to resolve and it would ultimately slow us down as a result.
But if we have LLMs do we even have "resources" any more? Should we even care if the quality is bad if it is only ever LLMs that touch the code? So long as it works, who cares?
I've heard this positioned in two different ways, from two different directions, but I think they both work as analogies to bring this home:
- do engineers care what machine code a compiler generates, so long as it works? (no, or at least very, very, very rarely does a human look at the machine code output)
- does a CEO care what code their engineers generate, so long as it works? (no)
Its a very very interesting inflection point.
The knee jerk reaction is "yes we care! of course we care about code quality!" but my intuition is that caring about code quality is based on the assumption that bad code = more human engineer time later (bugs, maintenance, refactoring etc).
If we can use a LLM to effectively get an unlimited number of engineer resources whenever we need them, does code quality matter provided it works? Instead of a team of say 5 engineers and having to pick what to prioritise etc, you can just click a button and get the equivalent of 500 engineers work on your feature for 15 minutes and churn out what you need and it works and everyone is happy, should we care about the quality of the code?
We're not there yet - I think the models we have today kinda work for smaller tasks but are still limited with fairly small context windows even for Gemini (I think we'll need at least a 20x-50x increase in context before any meaningfully complex code can be handled, not just ToDo or CRUD etc), but we'll get there one day (and probably sooner than we think)
As exemplified by the comments on this HN submission, whether LLMs are — to borrow a phrase from "Blade Runner" — a benefit or a hazard seems unresolvable for now.
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.
We ahve numerous, well-doocumented cases of LLMs being just plain wrong and/or hallucinating. There is an epidemic of LLM usage in college (and even high school) to the point where lack of critical thinking is becoming a massive problem and will only get worse.
This represents a huge security threat too if code is uncritically applied to code bases. We've seen many examples where people try and influence LLM output (eg [1][2]). These attempts have generally varied from crude to laughably bad but they'll get better.
Is it so hard to imagine prompt injection being a serious security threat to a code base?
That aside, I just don't understand being "all in" on LLMs for coding. Is this really productive? How much boilerplate do you actually write? With good knowledge of a language or framework, that tends to be stuff you can spit out really quickly anyway.
After months of using a hammer, I'm back to using my hands.
LLM is a tool. I think we still need to learn how to use it, and in different areas it can do either more or less stuff for you.
Personally I don't it for most of everyday coding, but if I have something tedious to write, the LLM is the first place I go for a code draft. That works for me and for the LLM I use.
discern when to delegate to the llm and give it enough context and guardrails to simply save you the keystrokes by coding exactly what you were thinking
This tracks for me. Its tempting to see LLMs as a superpower that makes it possible to use any programming language or platform, but I have much better results in platforms I know intimately...and I think this is largely because I'm using them in much more limited ways. When I've tried to pick up new tools and frameworks and heavily use LLMs to do early scaffolding, I have experiences similar to the author.
So someone could come along and say "well don't do that then, duh". But actually a lot of people are doing this, and many of them have far fewer fucks to give than the author and I, and I don't want to inherit their shitty slop in the future.
I kind of miss figuring things out by myself. I am unwilling to use anything it generates that I don't completely understand so often I spend just as much time figuring out why the code it created works as I would have just writing it myself.
My job has changed from writing code to code reviewing a psychopathic baby.
> Some days I feel like we’re also being gaslit by LLM providers. Just look at any AI related subreddit, and you’ll see people having completely opposite experiences, with the same exact model, with the same prompt, on the same day. If you code with AI long enough you’ll be able to relate. One day it’s amazing, the next day it’s incredibly stupid.
> Are they throttling the GPUs? Are these tools just impossible to control? What the fuck is going on?
Money and dreams. As everyone knows there’s an obscene amount of money invested in these tools of course. The capitalist class is optimistic their money can finally do the work for them directly instead of having to hire workers.
But more than that, AI is something that’s been alluring to humans forever. I’m not talking about cyberpunk fantasies I’m talking about The Mechanical Turk, Automata in the Middle Ages, Talos[0]. The desire to create an artificial mind is, if not hardwired into us, at least culturally a strong driver for many. We’re at a point where the test of the computer age for determining if we built AI was so utterly destroyed it’s unclear how to go about judging what comes next.
The hype is understandable if you view if you step back and view it through that lens. Maybe we are at an inflection point and just a bit more scaling will bring us the singularity. Maybe we’ve seen a burst of progress that’ll mostly stall from a consumer perspective for another 5-10 years, like all of the major AI moments before.
If you want to use them effectively it’s the same as any tool. Understand what they are good at and where they flounder. Don’t give up your craft, use them to elevate it.
We're at the point where I'm starting to hear this exact "backlash" sentiment from a lot of people. While I never went that far out of discomfort (I like understanding things) I do kind of respect the "effort" of willing to let go a bit. One reason probably also is that I tend up working in large Unity projects which are as incompatible for letting AI "take the wheel" as projects come.
That aside, I wonder if the OP would have had all the same issues with Grok? In several uses I've seen it surprisingly outperform the competition.
Use the tool when it makes sense or when someone shows you how to use it more effectively. This is exactly like the calculator "ruining people's ability to do arithmetic" when the vast majority of the population has been innumerate for hundreds of thousands of years up til the IR where suddenly dead white european nobility are cool.
There is nothing fun nor interesting about long division as well as software development.
If LLMs don't work for your usecase (yet) then of course you have to stick with the old method, but the "I could have written this script myself, I can feel my brain getting slower" spiel is dreadfully boring.
After months of coding with LLMs, I'm going back to using my brain
(albertofortin.com)364 points by a7fort 16 May 2025 | 221 comments
Comments
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.
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.
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.
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 gave them a fair shake. However, I do not like them for many reasons. Code quality is one major reason. I have found that after around a month of being forced to use them I felt my skill atrophy at an accelerated rate. It became like a drug where instead of thinking through the solution and coming up with something parsimonious I would just go to the LLM and offload all my thinking. For simple things it worked okay but it’s very easy to get stuck in a loop. I don’t feel any more productive but at my company they’ve used it as justification to increase sprint load significantly.
There has been almost a religious quality associated to LLMs. This seems especially true among the worst quality developers and the non-technical morons at the top. There are significant security concerns that extend beyond simple bad code.
To me we have all the indicators of the maximum of the hype cycle. Go visit LinkedIn for confirmation. Unless the big AI companies begin to build nuclear power it will eventually become too expensive and unprofitable to run these models. They will continue to exist as turbo autocomplete but no further. The transformer model has fundamental limitations and much like neural networks in the 80s it’ll become more niche and die everywhere else. Like its cousins WYSIWIG and NoCode in 30 more years it’ll rise again like a phoenix to bring “unemployment” to developers once more. It will be interesting to see who among us was swimming without clothes when the water goes out.
The argument is that the precision allowed by formal languages for programming, math etc were the key enabler for all of the progress made in information processing.
ie, Vibe-coding with LLMs will make coding into a black-art known only to the shamans who can prompt well.
[1] https://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667...
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 got more success that I hoped for, but I had to adjust my usage to be effective.
First of all, treat the LLM as a less experienced programmer. Don't trust it blindly but always make code review of its changes. This gives several benefits.
1) It keeps you in touch with the code base, so when need arise you can delve into it without too much trouble
2) You catch errors (sometimes huge ones) right away, and you can have them fixed easily
3) You can catch errors on your specification right away. Sometimes I forget some detail and I realize it only when reviewing, or maybe the LLMs did actually handle it, and I can just tell it to update the documentation
4) You can adjust little by little the guidelines for the LLM, so that it won't repeat the same "mistakes" (wrong technical decisions) again.
In time you get a feeling of what it can and cannot do, where you need to be specific and where you know it will get it right, or where you don't need to go into detail. The time required will be higher than vibe coding, but decreases over time and still better than doing by myself.
There is another important benefit for me in using an LLM. I don't only write code, I do in fact many other things. Calls, writing documentation, discussing requirements etc. Going back to writing code requires a change of mental state and to recall into memory all the required knowledge (like how is the project structured, how to use some apis etc.). If I can do two hours of coding it is ok, but if the change is small, it becomes the part where I spend the majority of time and mental energy.
Or I can ask the LLM to make the changes and review them. Seeing the code already done requires less energy and will help me reminding stuff.
This reminds me of the day of Dreamweaver and the like. Everybody loved how quickly they could drag and drop UI components on a canvas, and the tool generated HTML code for them. It was great at the beginning, but when something didn't work correctly, you spent hours looking at spaghetti HTML code generated by the tool.
At least, back then, Dreamweaver used deterministic logic to generate the code. Now, you have AI with the capability to hallucinate...
The fundamental issue is that agents / LLMs at present are not engineers or system architects. You cannot sit back and play product manager yet. If you go in with this expectation, you will certainly have a poor experience.
LLM-powered coding agents are not comparable to any existing human role or tool and therefore cannot be used interchangeably. They are a fundamentally new and novel type of tool that enable incredible productivity IF and only if you use them effectively. The tool is not the problem, the user is.
I’m also building a non-trivial SaaS platform and the cursor agent has written 90%+ of the code in the codebase. It has architected ~0% of the codebase. It has modeled ~0% of the data layer in the codebase. It has enabled me to move at least 10x the speed of implementation and debugging (yes, it is incredible at debugging if you use the right techniques).
I use the word implementation because that is almost exclusively what I use it for. I do the planning, design, architecture, engineering. Then, I communicate those specifications to it in digestible chunks, and it implements them incredibly fast. It makes mistakes sometimes, comes up with poor naming conventions, fails to reuse existing modules in the codebase, etc. But that’s fine - I simply give it feedback, point it in the right direction, and within seconds it’s back on course.
I own the codebase, it’s just my super fast implementation minion. If it gets something wrong - that’s my fault. I failed to communicate my expectations clearly. I’m heavily using my brain while working with the LLM - I’m just reserving those mental cycles for higher-level decision making than the actual tokens to type into the editor.
The power is in your ability to steer it and communicate in clear terms what you want, and maintain the right level of abstraction in your instructions. Too specific and you lose some of the benefit beyond just writing the code by hand, too vague / high-level and it will over-engineer something totally different than what you intended.
You’re the engineer, it’s just a really smart semantic code generator. That might change in the future, but for now, if you use it in this way, the productivity benefit is very clear.
I’ve been using cursor with 3.7 sonnet max (now sonnet 4) and I already can’t imagine a world without coding agents - it is so deeply rooted into my workflow.
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.
> I have no concept of Go or Clickhouse best practices.
> One morning, I decide to actually inspect closely what’s all this code that Cursor has been writing. It’s not like I was blindly prompting without looking at the end result, but I was optimizing for speed and I hadn’t actually sat down just to review the code.
> I’m defaulting to coding the first draft of that function on my own.
I feel like he’s learnt the wrong lesson from this. There is a vast gulf between letting an LLM loose without oversight in a language you don’t know and starting from scratch yourself. There’s absolutely nothing wrong with having AI do the first draft. But it actually has to be a first draft, not something you blindly commit without review.
> “Vibe coding”, or whatever “coding with AI without knowing how to code” is called, is as of today a recipe for disaster, if you’re building anything that’s not a quick prototype.
But that’s what vibe coding is. It’s explicitly about quick throwaway prototypes. If you care about the code, you are not vibe coding.
> There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. […] It's not too bad for throwaway weekend projects, but still quite amusing. I'm building a project or webapp, but it's not really coding - I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.
— https://x.com/karpathy/status/1886192184808149383
He’s basically saying that vibe coding is a disaster after his experience doing something that is not vibe coding.
I don't use LLMs for my main pieces of work exactly due to the issues described by the author of the blogpost.
2. The ratio increases and programmer layoffs begin
3. Bugs appear, AI handles most but not all
4. Bug complexity increases, company hires programmers to fix
5. Programmers can't decipher AI code mess
6. Programmers quit
7. Company unable to maintain their product
> the horror ensues
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.
He lost me here. Sounds like he tried to change from a boring stack he understood, to Go and Clickhouse because it's cooler.
You're asking for trouble. LLMs are great and getting better, but you can't expect them to handle something like this right now
Luckily in this particular case, being able to parallel park unassisted isn’t all that critical in the overall scheme of things, and as soon as I turned that feature off, my parking skills came back pretty quickly.
But the lesson stuck with me, and when LLMs became capable of generating some degree of functioning code, I resolved not to use them for that purpose. I’m not trying to behave like a stodgy old-timer who increasingly resists new tech out of discomfort or unfamiliarity—it’s because I don’t want to lose that skill myself. I use LLMs for plenty of other things like teaching myself interesting new fields of mathematics or as a sounding board for ideas, but for anything where it would (ostensibly) replace some aspect of my critical thinking, I try to avoid them for those purposes.
Post-LLM era, you can use a shortcut to get a representation of what something could be. However I see a lot of folks shipping that representation straight to prod. By comparison, the mental models created are weaker and have less integrity. You might be able to feel that something is off, but you lack the faculties to express or explain why.
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!
Even if the idea that an LLM will help you do it is false, perhaps it is still a good idea if it convinces the experienced programmer to go ahead and use SQL for the query, Go for the async, Javascript for the frontend, etc. Right now, few if any companies would let you use the best tool for the job, if that's not one they already use. Perhaps the best use of LLMs is to convince programmers, and their bosses, to use the best tool for each job.
But, after you've gotten past that part, you will probably (like the author of this article) need to throw away the LLM-generated code and write it yourself.
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
And I feel more productive. I recommend that everyone gives it a try.
As a tenured SW developer in my company my measurements for success are much more than "how much code can I spit out". There are mentoring, refactoring, code readability/mantainability, and quality that are important to my job. I found that LLM generated code was not hitting the necessary bars for me in these areas (agent or code autocompletion) and so I have stepped back from them. The readability point is extra important to me. Having maintained million lines of code products, I have found that readability is more important than writing a ton of code: and LLMs just don't hit the bar here.
When I am playing with side projects that I don't have the same bar on, sure Ill have bolt or lovable generate me some code in combination with cursor or windsurf, but these are low stakes and in some ways I just want to get something on paper.
in which Windsurf is forging ahead with an agentic LLM product that endeavors to not only replace software engineers but actually take over the entire software engineering PROCESS.
We're at a very interesting point, where investors and corporate interests are crystal clear in their intent to use LLMs to replace as many expensive humans as possible, while the technology available to do so is not there yet. And depending on your own perspective, it's not clear it ever will be, or perhaps it'll eventually be "good enough" for them to downsize us anyway.
I keep thinking about compilers. The old timers had been writing assembly by hand for years. The early C compilers were producing defective garbage output that was so incredibly poor that it was faster to keep coding by hand. Then the compilers got better. And better, and better, and now pretty much nobody inspects the output, let alone questions it.
I have basically given up on "in IDE" AI for now. I simply have a web interface on my 2nd monitor of whatever the "best" LLM (currently Gemini, was Claude) is and copy paste snippets of code back and forth or ask questions.
This way I have to physically copy and paste everything back - or just redo it "my way", which seems to be enough of an overhead that I have to mentally understand it. When it's in an IDE and I just have to tick accept I just end up getting over eager with it, over accepting things and then wishing I hadn't, and spend more time reverting stuff when the penny drops later this is actually a bad way to do things.
It's really more a UX/psychology problem at the moment. I don't think the 'git diff' view of suggested changes is the right one that many IDEs use for it - I'm psychologically conditioned to review these like pull requests and it seems my critique of these is just not aligned to critiquing LLM code. 99% of PR reviews I do are finding edge cases and clarifying things. They're not looking at very plausible yet subtly completely wrong code (in the most part).
To give a more concrete example; if someone is doing something incredibly wrong in 'human PRs' they will tend to name the variables wrong because they clearly don't understand the concept, at which point the red flag goes off in my head.
In LLM PRs the variables are named often perfectly - but just don't do what they say they will. This means my 'red flag' doesn't fire as quickly.
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, 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.
Developing without the knowledge what LLM writes is dangerous. For me having LLM as a tool is like having a few Junior Developers around, that I can advise and work with. If I have a complicated logic that I need to write - I write it. After I wrote it, I can ask LLM to review it, it might be good to find some corner cases in some places. When I need to "move things from one bucket to another", like call API and save to DB - that is a perfect task for LLM, that I can easily review after.
At the same time, LLM is able to write pretty good complicated logic as well for my side projects. I might need to give it a few hints, but the results are amazing.
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.
There, there's your problem. The problem is not LLMs, the problem is people not using their brain. Can't we use LLMs and our brains as well? Both are amazing tools!
Without access to the code, it's challenging to verify the authors' claims and form an independent opinion. In my view, we should be cautious about trusting articles that lack examples or sources. As someone wiser than me once said:
> Articles without sources are merely the opinions of the author.
Something I do very much love about LLMs is that I can feed it my server logs and get back an analysis of the latest intrusion attempts, etc. That has taught me so much on its own.
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.
Think about when chat gpt gives you the side-by-side answers and asks you to rate which is "better".
Now consider the consequence of this at scale with different humans with different needs all weighing in on what "better" looks like.
This is probably why LLM generated code tends to have excessive comments. Those comments would probably get it a higher rating but you as a developer may not want that. It also hints at why there's inconsistency in coding styles.
In my opinion, the most important skill for developers today is not in writing the code but in being able to critically evaluate it.
Once the code base structure and opinions are in place, I think LLMs are decent at writing code that are bounded to a single concern and not cross cutting.
LLM generated code bases work initially but so will code written by college kids for an initial set of requirements. Even a staff+ level engineer will struggle in contributing to a code base that is a mess. Things will break randomly. Don’t see how LLMs are any different.
I 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.
Eric Schmidt gave a TED interview about the subject this week. He predicts the US and China bombing each other's data centers.
I have been building a gallery for my site with custom zoom/panning UX to be exactly how I want it (which by the way does not already exist as a library). Figuring out the equations for it is simply impossible for an LLM to do.
I wouldn't be surprised if after the LLM hype we go back to site/app builders being the entry level option.
I don't think LLMs are at blame here, it is a tool and it can be used poorly. However, I do wonder what's the long term effects on someone who uses them to work on things they are knowledgeable about. Unfortunately this is not explored in the article.
https://taoofmac.com/space/blog/2025/05/13/2230
If I want to learn something new I won’t vibe code it. And if I vibe code I’ll go with tech I have at least some familiarity with so that I can fix the inevitable issues
In the past the quality mattered because maintenance and tech-debt was something that we had to spend time and resources to resolve and it would ultimately slow us down as a result.
But if we have LLMs do we even have "resources" any more? Should we even care if the quality is bad if it is only ever LLMs that touch the code? So long as it works, who cares?
I've heard this positioned in two different ways, from two different directions, but I think they both work as analogies to bring this home:
- do engineers care what machine code a compiler generates, so long as it works? (no, or at least very, very, very rarely does a human look at the machine code output)
- does a CEO care what code their engineers generate, so long as it works? (no)
Its a very very interesting inflection point.
The knee jerk reaction is "yes we care! of course we care about code quality!" but my intuition is that caring about code quality is based on the assumption that bad code = more human engineer time later (bugs, maintenance, refactoring etc).
If we can use a LLM to effectively get an unlimited number of engineer resources whenever we need them, does code quality matter provided it works? Instead of a team of say 5 engineers and having to pick what to prioritise etc, you can just click a button and get the equivalent of 500 engineers work on your feature for 15 minutes and churn out what you need and it works and everyone is happy, should we care about the quality of the code?
We're not there yet - I think the models we have today kinda work for smaller tasks but are still limited with fairly small context windows even for Gemini (I think we'll need at least a 20x-50x increase in context before any meaningfully complex code can be handled, not just ToDo or CRUD etc), but we'll get there one day (and probably sooner than we think)
This represents a huge security threat too if code is uncritically applied to code bases. We've seen many examples where people try and influence LLM output (eg [1][2]). These attempts have generally varied from crude to laughably bad but they'll get better.
Is it so hard to imagine prompt injection being a serious security threat to a code base?
That aside, I just don't understand being "all in" on LLMs for coding. Is this really productive? How much boilerplate do you actually write? With good knowledge of a language or framework, that tends to be stuff you can spit out really quickly anyway.
[1]: https://www.theguardian.com/technology/2025/may/16/elon-musk...
[2]: https://www.theguardian.com/technology/2025/jan/28/we-tried-...
LLM is a tool. I think we still need to learn how to use it, and in different areas it can do either more or less stuff for you. Personally I don't it for most of everyday coding, but if I have something tedious to write, the LLM is the first place I go for a code draft. That works for me and for the LLM I use.
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.
My job has changed from writing code to code reviewing a psychopathic baby.
Unfortunately ceo manager types cannot distinguish between bad and good enginners
> Are they throttling the GPUs? Are these tools just impossible to control? What the fuck is going on?
Money and dreams. As everyone knows there’s an obscene amount of money invested in these tools of course. The capitalist class is optimistic their money can finally do the work for them directly instead of having to hire workers.
But more than that, AI is something that’s been alluring to humans forever. I’m not talking about cyberpunk fantasies I’m talking about The Mechanical Turk, Automata in the Middle Ages, Talos[0]. The desire to create an artificial mind is, if not hardwired into us, at least culturally a strong driver for many. We’re at a point where the test of the computer age for determining if we built AI was so utterly destroyed it’s unclear how to go about judging what comes next.
The hype is understandable if you view if you step back and view it through that lens. Maybe we are at an inflection point and just a bit more scaling will bring us the singularity. Maybe we’ve seen a burst of progress that’ll mostly stall from a consumer perspective for another 5-10 years, like all of the major AI moments before.
If you want to use them effectively it’s the same as any tool. Understand what they are good at and where they flounder. Don’t give up your craft, use them to elevate it.
[0]: https://news.stanford.edu/stories/2019/02/ancient-myths-reve...
Not quite a source but it’s a fun read from 2019 about this.
That aside, I wonder if the OP would have had all the same issues with Grok? In several uses I've seen it surprisingly outperform the competition.
Use the tool when it makes sense or when someone shows you how to use it more effectively. This is exactly like the calculator "ruining people's ability to do arithmetic" when the vast majority of the population has been innumerate for hundreds of thousands of years up til the IR where suddenly dead white european nobility are cool.
There is nothing fun nor interesting about long division as well as software development.
If LLMs don't work for your usecase (yet) then of course you have to stick with the old method, but the "I could have written this script myself, I can feel my brain getting slower" spiel is dreadfully boring.