> Now it's weird if an agent isn't writing 99% of your code.
It is?
Are you sure that this is a representative reading that applies to more than just a tiny bubble?
It is?
Are you sure that this is a representative reading that applies to more than just a tiny bubble?
The tradgedy is that HN used to be a great place to get honest and well argued opinion and anecdotes about new technologies and the different tradeoffs etc.
I recently saw a video where one of these founders showed their “programming” setup, and it was a cashier’s microphone wherein he whispers sweet nothings to the LLM, because of course he doesn’t write code anymore (who even reads code nowadays, am I right?!). I think this is the type of individual who’s lost in the bubble sauce that ends up writing the most absurd comments around here.
But I do feel, to reply to you, that crypto was a lot more critically received on HN than AI is right now. We're too busy debating humanity's end rather than if this crap actually works.
For those of us who actually work with technology (not product managers, executives or salespeople, this stuff doesn't work well at scale. It might in a research department at Google or a hedge fund, less so in the messy corporate world.
and LLMs are, in turn, trained on reddit content..
I don't think I could find a job in my industry if I tried that didn't want me to write code using coding agents.
Obviously I can't prove any of this, so try emailing a recruiter and test it for yourself.
From what I can tell, a lot of newly registered users are equally as vehemently against AI as there are those that are pro. I guess we see things through our own personal filter.
I admit, there is/was a certain element of enjoying the zone during development sessions. But mostly, it was the problems, not the tool.
I happened to become good at coding, and good at doing it in a corporate setting, so I adapted my habits, learned to write the best sort of code that keeps a production system solid and fast. But as I say, typing the characters was never really the point. Now a very fast assistant helps me type the characters. I guide it very closely. A lot of the time I have to correct it. Often if I know it is going to probably take a wrong direction I'll write the skeleton of the code I want, write the skeleton of the tests to prove it, and give it this as a "spec". This gets fantastic results.
I haven't lost my trade at all.
It's the same category of "artisan code" like "artisan cheese": you can do it if you have a ton of free time as a hobby but other than a hobby? Not worth it.
How are people getting this "waste of time not to use AI" and "generates 99% of my code" level of code quality?
I know people's response will likely be something, something, "add instructions to memory to not use n+1", etc. But if the Ai wants to generate code this bad, then it represents an overall quality risk that would require an infinite memory file.
They don't know what n+1 problem is and they don't know about long-term maintainability.
overall software quality seems largely unchanged
OTOH, if someone insists on writing bad code—even after being advised otherwise—then they should expect to be out of a job.
Doesn't seem like "terminated junior developer" is the level of quality we should be accepting or promoting for AI.
In any case, the point is that low quality code shouldn't be promoted as the acceptable goal for AI.
For context, I've set up harnesses with recursive automated review loops, spec driven development, explicit lists, better models, better harnesses, formal methods tooling, etc. All of it helps, but they don't eliminate output issues. Those become very apparent when I go through the slow, manual work of deeply comprehending / validating LLM code.
And that leads me to one of three conclusions. Either my standards are achievable only by hyperintelligent programming gods, I have a skill issue using LLMs, or others aren't applying the same level of attention.
The first is obviously untrue. I meet my own standards and I'm an idiot. The second seems unlikely because I can see my competent coworkers and well-regarded people in the community discussing the same issues. So that leaves the third.
You could only argue about it when an engineer was in charge and even so when they're high up enough the pressures and incentives are to just ship fast and break stuff. Not every company can afford to be a NASA making uncrashable code that runs for 100 years and goes to pluto and all.
a) puts be ahead of those people who don't, yes b) but also diminishes my technical skills if I don't actively try to engage about what I'm "vibecoding" and proactively trying to understand it.
The big AI tech companies are still interviewing people on manual coding tasks and deep understand, which when you're vibe coding a lot, you tend to diverge from those skills, because it's just easier to use AI to "help" you a lot.
People are vibecoding to do without learning, and that's their problem, but doesn't have to be ours.
They'd still be mindlessly copying and pasting from Stack Overflow without learning if they didn't have AI.
If you have an aversion to reading code and learning from it, human or AI generated, you shouldn't be in this industry.
If you're not using AI to teach yourself new things, you're not holding it right.
If you already had a hand crafted codebase, a ton of miles on it, no real issue for a long time and customers who value some metric of quality then it might be worth crafting things by hand — if only for the bragging.
99% means I write 1 line for every 100 AI lines. It's probably 1 human line for every 10,000 AI lines right now.
There are still people who ride horses.
I do think a better programmer will be a better prompter just like a better compiler engineer will be a better programmer (when performance matters at least).
Because 100 lines of (debugged, reviewed) code per day is a good speed for seasoned software engineer. I assume that you can produce more than 100 lines of something per day as a prompt.
So, what is the problem domain that requires one to write several thousands of lines of code per day?
If they write 2 (two) lines of code, the combined output of them with LLM, as I read it now, is 20K SLOC. This is yearly output of human programmer.
It is very much possible to write 100 lines of (debugged, reviewed) code per day for human. And these 100 lines of code would result, if we apply their LLM multiplication factor, in 50 (fifty) man-years of work!
Even if they write very little code, say, one line per month, after a year of work they will get result of about 6 (six) years of human programmer. SQLite is 155K SLOC, about 8 man-years.
And that what raised my question: what is the problem domain that requires so much code?
The two people I know who don’t use coding agents work in government, and in a data science company working with government.
I’d say if you work at a tech company and agents aren’t writing the majority of your code, that is weird. But if you work at a traditional company that doesn’t have Claude or Codex subscriptions, there it might be pretty normal to still be writing code by hand.
"Weird" is a social concept. It's an artifact that has its roots in social cohesion and friction induced by individual nodes to glue the group together.
Software development otoh is an engineering discipline (or.. it should be). And Engineering does not use the local social consensus algorithm for determining correctness. (or.. it should not)
Arguably engineering is something AI should be really good at since you're just trying to compute a working product given constraints, formulas, resources.
Where in the comment tree is this supposed to sit?
But, regardless, what is interesting I think is the scenario chosen there. Because a "dinner party" is not where engineering happens; and that's kinda the point I was getting at. That's pulled from the pool of "social consensus" and not "math" or "physics" or whatever.
It's interesting, isn't it? Just like how specific tokens in the context window of LLMs pull probabilities towards specific clusters of ideas (and tokens); with humans, you see similar things happen.
(This comment is more coherent than it might look at at first sight.)
___
Anyway, point (and to the point) is: Don't get hacked by the current thing fraudsters/grifters.
They don't respect you or me or really anyone the slightest. They're just in it to get rich quick (or simply just inflict psychological damage for sadistic reasons), and they will use any means necessary to do so.
This comment chain only exists because some hype guy is trying to induce FOMO into people for not doing more AI. Why is unclear, but it's clearly malicious. Whether they consciously know that they are doing that doesn't matter for that assessment.
Let me try another analogy: AI-related comment sections are like a watering hole for both get-rich-quick grifters, but also bad people wanting to hurt others.
The technology is so disruptive that there are all sorts of opportunities while stuff is still developing, things aren't regulated, and people themselves have not yet learned how to self-regulate.
So if you're looking to make money or to just inflict pain onto others, you're pulled towards this stuff.
This is what I am seeing in this specific comment sub-tree. A troll.
But in current year, you cannot just call people trolls, so instead you get these elaborate meta comments that bypass the anti-anti-troll defenses, but get so abstract, people just go "what".
My advice would be to view any of these comment sections through a zero-trust lens.
Godspeed. We will all eventually get through this.
It was not about that. Thank you.
I definitely wouldn't put it at 99% of developers, but I'd say it is the norm among developers I know that agents are their primary mode of writing code now (still using IDEs and GitHub to review changes).
Pick an industry where you can stop learning new things once you're out of school, because the computer industry is not one of them and never has been.
My fucking job used to be writing 6502 assembly language on an Apple ][, and I loved it, but I hope I've forgotten enough of it to have room to learn new things. If only I could forget all those hex I/O and peripheral addresses from $C000-$CFFF and the Monitor ROM routines from $F800-$FFFF, without forgetting how brilliantly beautiful Woz and and Allen Baum's code is.
https://6502disassembly.com/a2-rom/OrigF8ROM.html
Forgetting old stuff to make room for new stuff is one of the most valuable skills you can have in this industry.
The next most important skill is persistence ;) -- writing stuff down before you forget it, in a way that won't make future-you hate present-you when you need to learn it again.
I saw this idea from elsewhere that the things AI helps with was never the "profit bottleneck" of companies. 10x engineering productivity gain does not translate to 10x more revenue if your profit bottleneck is customer acquisition and retention. In other words, your profit is limited by how many people are willing to give you money for your services and AI can't really affect that.
And even the productivity gains per individual is a generous assumption. An individual can only prompt (and check! You guys check right?) so much. Sooner or later the pendulum is gonna swing in the other direction and it will be cheaper to build a team than equip individuals with AI _to deliver the same value_. I'm also assuming that AI is still in the VC-subsidized pricing stage.
Hence why I think the job in the future is gonna be pretty similar to the job four years ago.
> The next most important skill is persistence ;) -- writing stuff down before you forget it, in a way that won't make future-you hate present-you when you need to learn it again.
Huge amen. Another thing I've found Claude very useful for is writing documentation for legacy systems and cleaning up my own notes on it. I only need Claude to be 70-80% correct because from there I can take it. That error margin is no different from moderately-outdated-but-still-useful documentation.
When that pendulum swings, I will have a documentation binder that I will print money with.
I am very convinced that today's SOTA level will be accessible 3 years from now, but you might be right about the SOTA accessibility at that point in time.
Still with today's SOTA you need to know much less details to be able to write code than without it.
People neglecting this side will inevitably become less proficient at their job and become rather helpless without AI, that's all I'm saying.
You put a number on it at the top of the thread: three years until people relying on agents have forgotten how to do the job. Copilot's technical preview was 2021, ChatGPT was November 2022, and agents that write the majority of the code are a 2024-2025 thing. So the window you're predicting is roughly the entire span in which these tools have existed, and the atrophy hasn't shown up in it.
For scale, the last ARM I wrote was for a Sony Clié and the last PowerPC for a Mac, both more than two decades ago. If I needed to write ARM for my Mac now, I could brush up about as fast as I could on the 6502 I mentioned upthread, most of whose opcodes, $C000 I/O addresses and monitor ROM entry points I genuinely cannot recall any more. Two to four decades of not touching an instruction set didn't cost me the fundamentals, and it hasn't made me less proficient in Python and TypeScript or helpless without AI. Three years of using a good tool is not going to do it either.
There's also a distinction buried in your last line, because "people neglecting this side will inevitably become less proficient" bundles two different things. Losing a skill you had is not the same as never acquiring one, and only the second is an argument about tools.
So take acquisition. I've been learning PDP-7 assembly in order to recover, OCR, and analyze 128 pages of PIXIE assembly source and octal machine code that Heinz Lemke wrote at Cambridge in the late 1960s, and get it running in an emulator. A language I never knew, with custom instructions for bespoke networking hardware, no Stack Overflow, and almost nobody left to ask except Heinz himself. AI has been extremely helpful for exactly that, and the understanding is still mine to build: I have to predict what the machine will do, and catch the explanations that are wrong.
https://www.youtube.com/watch?v=jDrqR9XssJI
On feeling like a fraud: the test isn't whether you typed it, it's whether you can predict what it does and fix it when it breaks. Plenty of hand-typed code fails that test and plenty of carefully reviewed generated code passes it. Your reasons 1 and 3 are good reasons to hand-code, since problem solving is genuinely fun and nobody is waiting on your free time, but reason 2 is measurable, so measure it instead of trusting the feeling.
The atrophy you're worried about is real. It just isn't caused by the tool. It happens to people who stopped wanting to learn, and that predates AI by decades, even millennia. I watched it happen back when much of the industry ran on assembly language.
If you're not using AI to teach yourself new things, you're not holding it right.
Personally the tools have simply gotten too good to ignore so I have been thinking about how to write skills and prompts in a way that enable me to keep learning, overcoming friction and challenges and not simply using the tool for hand holding and jumping straight to the end result.
For me personally, what matters is the process of learning and mastery, my self esteem depends on it, and enriching that with AI instead of AI eradicating that process for the sake of efficiency is my current challenge.