My mental model is that coding by hand is similar to horseback riding, sail boating, etc. These skills are still enjoyed by people and in some circumstances they are invaluable.
It isn't much different to how it works with a team. You have an architecture who understands the broader landscape, you have developers who implement certain subsystems, you have a testing strategy, you have communication, teaching, management. The only difference now is that I can do all this with my team being LLMs/agents, while I focus on the leadership stuff: docs, designs, tests, direction, vision.
I do miss coding, but it just isn't worth it anymore.
Imagine somebody writes a blog post "why I bike to work". They detail that they love it, the fresh air, nature experience biking through a forest, yes sometimes it's raining but that's just part of the experience, and they get fit along the way. You respond with "well I take the car, it's just easier". Well, good for you, but not engaging with what they wrote.
Except the post has nothing to do with “better results” of the generated output, it concerns itself with the effect it has on the user’s learning. That’s the theme which is relevant to the discussion.
And we already know LLMs impact your learning. How could it not? If you don’t use your brain for a task, it gets worse at that task. We’ve know that, with studies, since before LLMs.
I actually think *more* than I used to, because I only get the hardest problems to solve. I mostly work on architectural documents these days.
So do you review all that code your LLM generates for you?
If this is the price to pay to unlock this productivity boost, so be it but let’s keep in mind that:
- we need to be more careful not to burnout since our job became de facto harder (if done at the maximum potential);
- we always need to control and have a way to verify what LLMs are doing on the easiest tasks, because even if rarely, they can fail even there (...but we had to do this anyway with Junior devs, or didn’t you?)
A junior dev is accountable, but an LLM subscription is not.
We are trading the long term benefits for truth and correctness for the short term benefits of immediate productivity and money. This is like how some cultures have valued cheating and quick fixes because it's "not worth it" to do things correctly. The damage of this will continue to compound and bubble up.
LLMs have come a long way since ChatGPT 4.
The idea that they’ll always value quick answers, and always be prone to hallucination seems short-sighted, given how much the technology has advanced.
I’ve seen Claude do iterative problem solving, spot bad architectural patterns in human written code, and solve very complex challenges across multiple services.
All of this capability emerging from a company (Anthropic) that’s just five years old. Imagine what Claude will be capable of in 2030.
I don't believe VC-backed companies see monotonic user-facing improvement as a general rule. The nature of VC means you have to do a lot of unmaintainable cool things for cheap, and then slowly heat the water to boil. See google, reddit, facebook, etc...
For all we know, Claude today is the best it will ever be.
It’s not shortsighted, hallucinations still happen all the time with the current models. Maybe not as much if you’re only asking it to do the umpteenth React template or whatever that should’ve already been a snippet, but if you’re doing anything interesting with low level APIS, they still make shit up constantly.
Wait.. are we talking about LLMs or humans here?
It’s the Eternal September of software (lack of) quality.
codex
“run my dev server”
I only hope that when you do, you don’t take anyone else with you.
It’s one thing to be careless and delete all your own email; quite another to be careless and screw the lives of people using something you worked on and who had no idea you were YOLOing with their data.
The only thing I do that I’d consider remotely lazy is put my API keys in my AGENTS.md so I don’t have to keep pasting it in my chat.
Maybe you aren’t, but there are definitely people who are and do exactly what you described, including senior staff at companies like Meta and Microsoft, so the point stands.
This pretty much sums up my current mood with AI. I also like to think, but it just isn't worth it anymore as a SE at bigCorp. Just ask AI to do it and think for you and the result only has to be "good enough" (=> works, passes tests). Makes sense business wise, but it breaks me, personally.
That's partly an illusion. Try doing everything manually. After only using inline suggestions for six months a few years ago, I've noticed that my skills have gotten way worse. I became way slower. You have to constantly exercise your brain.
This reminds me of people who watch tens of video courses about programming, but can't code anything when it comes to a real job. They have an illusion of understanding how to code.
For AI companies, that's a good thing. People's skills can atrophy to the point that they can't code without LLMs.
I would suggest practicing it from time to time. It helps with code review and keeping the codebase at a decent level. We just can't afford to vibecode important software.
LLMs produce average code, and when you see it all day long, you get used to it. After getting used to it, you start to merge bad code because suddenly it looks good to you.
I cant imagine how it is for people tha try to manually write after years of heavy llm usage
Can you get any fadd-ier than that? Of course they love AI.
This will without a doubt become a problem if the whole AI thing somehow collapses or becomes very expensive!
But it’s probably the correct adaptation if not.
YMMV, but I'm not seeing this at all. You might get foggy around things like the particular syntax for some advanced features, but I'll never forget what a for loop is, how binary search works, or how to analyze time complexity. That's just not how human cognition works, assuming you had solid understanding before.
I still do puzzles like Advent of Code or problems from competitive programming from time to time because I don't want to "lose it," but even if you're doing something interesting, a lot of practical programming boils down to the digital equivalent of "file this file into this filing," mind-numbingly boring, forgettable code that still has to be written to a reasonable standard of quality because otherwise everything collapses.
If you don't code ofc you won't be as good at coding, that's a practical fact. Sure, beyond a certain skill level your decline may not be noticeable early because of the years of built-in practice and knowledge.
But considering every year there is so much more interesting technology if you don't keep improving in both hands-on learning and slow down to take stock, you won't be capable of anything more than delusional thinking about how awesome your skill level is.
To what extent is Claude configuring these servers? Is this baremetal deployment with OS configuration and service management? Or is it abstracted by defining Terraform files to use pre-created images offered by a hosting service?
Onion articles really write themselves these days. I for one would still rather keep the money and write 25% of it myself.
There's some tasks where it's pretty clear what you want though and are just boring jobs that are totally not worth speccing well and an LLM will blaze through.
Things like:
- add oauth support to this API
- add a language switcher in this menu, an API endpoint, save it to the UserSettings table
- make a 404 pageThe difference is that with other people, you are training somebody else in your team who will eventually internalize what you taught them and then be able to carry the philosophy forward. Even if it took exactly the same amount of time for you to explain (+ code review etc), it's a clear net benefit in the long run. Not so with an LLM. There it's just lost time.
Have a large LLM-written change set that works but that you’re not sure you fully understand? Make the coding agent quiz you on the design and implementation decisions. This can be a lot more engaging than trying to do a normal code review. And you might even learn something from it. Probably not the same amount as if you did this yourself fully. But that’s just a question of how much effort you want to invest in the understanding?
Explaining the problem to an LLM and having it ask pointed questions is helpful IMHO, as well as being able to iterate fast (output new versions fast).
As an example, I'm currently making simple Windows utilities with the help of AI. Parsing config files in C is something the AI does perfectly. But an interesting part of the process is: what should go into a config file, or not, what are the best defaults, what should not be configurable: questions that don't have a perfect answer and that can only be solved by using each program for weeks, on different machines / in different contexts.
I'd dispute "the whole point" - there's a whole bunch of problems I can understand but would struggle to implement effectively in code (which is another big point - there's little use in a solution that takes, e.g., two months to calculate last week's numbers when your revenue/profit/planning depends on those numbers.)
At a minimum, for me, the difficulties of programming are many stepped: understanding the problem -> converting that understanding to algorithms/whatnot -> implementing that understanding -> making it efficient (if required) -> verifying the solution.
Trying to boil it down to "ONE COOL TRICK!" that justifies vibe-coding is daft.
[There's also a whole bunch of things I can implement but don't really understand (business logic, sales/tax rules, that kind of thing) but that's why we have project managers, domain experts, etc.]
Edit macros and awk+grep solved that.
Im ready to get downvotes again for my takes, but as a person who writes and trains DL models, I will die on the hill: “people need to produce high quality data” it can be code it can be art, but we can’t rely on those models and trust in the things that they provide.
At this point it's worth considering a permanent, pinned "HN Flamewar: Will LLMs turn you into the next Ken Thompson or are you just a poser who can't write code" thread. We're having this same discussion, constantly, on 5 different threads on the frontpage.
I wish I could have a HN frontpage with everything but AI news. Both postive or negative.
Unfortunately people need to experience a 1 million line codebase a dynamic language to figure out that types are actually pretty nice, and they need to write getters and setters for every field for a few years to figure out OOP is stupid, and they need to do 10 HTTP requests for something that could be 10 function calls to figure out microservices are stupid.
In none of these trends did the industry pause to evaluate if what's being written is completely idiotic, it's only with a few decades of hindsight, after a lot of money is lost that we learn the lesson.
I wanted to change it from 32-bit MSDOS to 64-bit Linux. But it realized that the segmented memory model cannot be implemented in large memory without massive changes which breaks everything else.
It was willing to construct new program with seemingly same functionality, but the assembly code was so incomprehensible that whole project was useless as a learning tool. And C-version would have been faster already.
Sorry to say, but less talented humans like me-myself are already totally useless in this.
Wait, I thought you said it understood everything..
I just wanted to see what it would look like. Lesson learned.
Grady Booch (co-creator of UML) has this to say about AI: this is a shift of the abstraction of software engineering up a level. It's very similar to when we moved from programming in assembly to structured languages, which abstracted away the machine. Now we're abstracting away the code itself.
That means specs and architectural understanding are now the locus of work - which is exactly what Neil is claiming to be trying to preserve. I mean, yeah you can give that up to the AI as well but then you just get vibecoded garbage with huge security/functionality holes.
I love these quotes. I got a much deeper, more elegant understanding of the grammar of a human language as I wrote a phrase generator and parser for it. Writing and refactoring it gave me an understanding of how the grammar works. (And LLMs still confidently fail at really basic tasks I ask them for in this language.)
There is nothing wrong whatsoever with just getting things done.
As the original author pointed out, the advice to jog or ride a bike because driving all the time is bad for your health is sound, but the Red Flag Act has proven to be a foolish endeavor. I believe the same phenomenon will occur.
Assuming that society hasn't been stroaded into artificially favoring cars, to the point where other options become effectively removed, even if they would otherwise have been better-suited to the use case.
The metric became lines of code, although those of us that started off coding as children when MySpace was a thing and goto was the best performing search engine, are well aware that lines of code is the stupidest metric you can come up with. But slop machines produce so much of it, it's easy to see why many people are like "see? see this? it works! And you are gonna be doing this 2 days as a caveman". Gladly, because two data pipelines that do the exact same thing take 4 days to run on slop code, whereas my caveman approach takes single digit hours and does not produce several billion rows of unusable garbage.
Not to mention the countless times when someone has asked he to help them when they are stuck and a simple question such as "where do you define the path to the output directory?" leads to 10 minutes of scrolling on project that contains a total of 10000 lines of code.
The good news for us mortals, is that this is that this approach is starting to bite people back and for the companies that manage to survive the inevitable head on collision, they will have to dig deep in their pockets to get people to clean up the mess.
baCist•2h ago