[singpolyma3]

I mostly like this article but

> Those who refuse to use an LLM will fall behind because they won't be able to produce as much

Seems like a silly and needlessly aggressive take.

Fall behind what? Able to produce "as much" what? I've never been evaluated on volume in my life. Nor have co workers who were severely "behind" ever feared for their jobs.

[marginalia_nu]

Just about every professional coding job I've ever had has had programmers eager to code more, complaining about how much rigmarole there is around making changes, complaining about constant meetings and endless bureaucracy around change management and requirements. Meanwhile business mostly saw programmer velocity and output as a problem and a business risk, as they struggled to keep up with the rate of change and kept stepping on the brakes.

Like realistically even without LLMs I output probably around 10x as much code working alone, self-employed with zero meetings or bureaucracy, than I've ever done as a professional programmer. My output sometimes rivals that of entire teams' I've been part of, mostly because I get to just code to my heart's content.

[WJW]

> My output sometimes rivals that of entire teams' I've been part of

That's not very hard with many of the teams I've seen, with or without LLMs. Though the old adage of "If you want to go fast, go alone. If you want to go far, go together" still applies.

[KronisLV]

> If you want to go far, go together

Unless you encounter circumstances where it's death by committee (or something similarly bad), but overall I agree! It's just that you don't have the bad environment risk/problem when it's just you.

[skydhash]

> My output sometimes rivals that of entire teams' I've been part of, mostly because I get to just code to my heart's content.

The fact is that often I code less than most of my peers. Because I prefer spending some time to design suitable data structures/algorithms for the problem at hand. I don't aim for perfection, just that it align with the business domain (and/or the interface) so that future works are proportional with the scope of change requests. This has reflected in small commits because the fundamental core of the business domain rarely changes (when they do, we have bigger problems than my writing speed).

So I've never seen the need to increase my writing speed, because there's never any need to do so. What I'd like to increase is the speed the Product team get back to me with answers to my questions. Because that's often the real bottleneck.

[echelon]

> I prefer spending some time to design suitable data structures/algorithms for the problem at hand.

I'm doing this at LLM speed now.

I feel like I'm doing the work of two whole teams and designing rock-solid software.

Rust, strong types, enums, fantastic interfaces, brevity.

[skydhash]

> Rust, strong types, enums, fantastic interfaces, brevity.

That's not what suitable data structures/algorithms mean. What you stated are mere helpers and still pertains to the realms of coding, not design.

Coding isn't and never was the issue. It is a tool and not the intent. Think about what would stand universally true whether you use Go, C, JavaScript, Assembly,... The organization of data (information), and the process of transforming it (computation).

Those do not depends on code. We already have basic ones like the list, the map, the stack, the queue, the binary tree, the graphs,... But for any business domain, you can create more specific ones. And like the basic one, they do not depends on code. The code depends on them.

So writing code faster does not make the design better.

[fragmede]

No but it lets you iterate faster. Who hasn't come up wit the most perfect elegant design, only to come up against three reality of implement and an "oh we forgot about that" aspect. Except by then, it's too late to change, so you march on. Writing code faster lets you find the things you didn't think of faster so then you get to design it again but better this time.

[skydhash]

> Who hasn't come up wit the most perfect elegant design, only to come up against three reality of implement and an "oh we forgot about that" aspect

The mistake here is trying to come up with the most elegant design. You solve for what’s needed with the knowledge that you’ve most likely not captured the full situation, and make allowance for future changes.

I don’t want faster code. What I want is flexibility in evolving my design and there’s plenty of good tools and practices for that. From ensuring your code is testable to ensuring there are easy ways to experiment with parts of it.

I’ve never been in a situation that says “We’ve not think of that, we need to get back to the drawing board”, It’s been mostly “We need a new version of this module to support this feature”

[marginalia_nu]

That sort of trial and error design seems like a really unprofessional way of working.

[stickfigure]

> Fall behind what? Able to produce "as much" what?

Customer meaningful features that move the needle on the business.

I think this is strictly true. And not because LLMs can write code faster. I think it's true even if you're still writing most of your code by hand and using the LLM as an assistant.

My anecdotal but decades-long observation is that most of the time=cost of a project comes not from writing code, but from dealing with "issues". Weird bugs, surprising behaviors, spec ambiguities, library defects, mysterious test failures, etc. Stuff that requires intense debugging and building out a mental map of code that might not even be yours. LLMs excel at this kind of thing, freeing you up to spend most of your time working on business logic.

This has certainly been my experience.

[overgard]

I think people are making a bad assumption that features = profit, and that we're going to be trapped in a red-queen race to move in place while shipping features at an astonishing rate. I don't think this is going to happen.

Before subscription services, you needed to add features because you had to justify to people why they should buy an upgrade. So yeah, it made sense to make as many features as possible to try to cast a wide net.

I think with software as a service, making features is not really the most important thing. Realistically, people buy software for what it does right now, not its future potential. Further, changing things out from underneath users tends to annoy them (pretty much EVERY time a service introduces a redesign, even if it's a good one, people initially hate it -- you're asking them to relearn a thing that was working perfectly fine).

Anyway, I think new software is going to win the same way it's always won, based on its utility, not based on shipping features at some sort of frantic rate.

[nkrisc]

Realistically, has the volume of code that can be produced ever been the bottleneck? In every job I’ve ever had, it was never that the devs couldn’t write enough code fast enough, it was everything else that slowed them down, mostly other people.

[jamesfinlayson]

7 years ago my biggest bottle-neck was waiting for a tester to test my code. Fast forward to now, my biggest bottle-neck is waiting for a tester, and my team-mates using AI to generate mega-patches that they don't bother testing is just making it worse.

[andrekandre]

n=1 but every job i've ever been at was time to code was like 10 or 15% of available time; its all the useless meetings/busywork caused by corporate structure and bad specs etc

llm's cant solve your organization issues...

[Fordec]

And I am gradually coming to the conclusion that "needle" isn't even features. In a world where everyone has AI access, moving the needle in an existing product space can readily be done by whoever. The real game changers will be those who redefine their market segment entirely rendering existing offering completely out of customer demand. And the only way to migrate the business to the new model from the ground up in say four to six months will only economically be able to be done by AI.

My hobby AI projects feature wise match existing company offerings in about a week of turn around. But this alone is valueless. The new thing that didn't exist before 2026 will remain the hard moat. But these moats will dissolve as fast as OpenAI can scrape your public marketing. It's going to be like releasing Meccha Chameleon as a break out hit but a month later the clones on Roblox having greater player numbers. This is the turn around times we're going to have to live with in general for business pivots to the "next" business logic that makes sense in the market.

Closer to the AI world it's going to be as fast as the transition from prompt engineering and MCPs to loop engineering and harnesses. I'm pretty confident popular commentators will see "loops" as old hat by December by raw function of what speed of evolution we're dealing with here now.

[archagon]

> My hobby AI projects feature wise match existing company offerings in about a week of turn around.

Another thing that LLMs are particularly good at is instilling their users with a false sense of confidence.

[TacticalCoder]

> Weird bugs, surprising behaviors, spec ambiguities, library defects, mysterious test failures, etc. Stuff that requires intense debugging and building out a mental map of code that might not even be yours. LLMs excel at this kind of thing

I've noticed that too. And I think it's no surprise we see lots of "728 security exploits found by LLMs in project X" posts.

They excel at what you mention.

I also think that, as of 2026, they suck fat balls at writing code.

[skydhash]

> Weird bugs, surprising behaviors, spec ambiguities, library defects, mysterious test failures, etc. Stuff that requires intense debugging and building out a mental map of code that might not even be yours

And those issues often appears because no one had the "time" to properly design a solution before rushing to code. Saving one hour of planning by spending weeks on debugging.

[Krssst]

Yes, I dislike this kind of take so much. It keeps being repeated as a truthism and a way of putting down people that don't do what the speaker wants. It's fine to disagree, but there's no need to get such a threatening tone.

A lot of tech jobs seem to be only about sheer output volume, with quality (maintenability, availability, security, generally understanding what the thing is doing) not mattering much. In that case sure, LLM all the way and whatever happens happens. But not all jobs are like that.

[inglor_cz]

My experience with regard to quality is quite the opposite.

With LLM at my disposal, I had the time- and effort-budget to expand test suites considerably, I was even able to attack a somewhat thorny question of reproducible builds on MSVC, which is not exactly friendly towards determinism.

These tasks would take me personally so much time that I would have to set them aside, at the cost of output quality.

[saghm]

Sure, but this is not at all uniform in how people use these tools any more than there was uniformity in how people balanced quality and speed before LLMs entered the picture. There was already a lot of variety in how some developers moved fast and broke things, others moved slow and fixed things, some would prototype new crazy ideas and others would spent time on the long tail of getting something from working adequately to being robust and polished.

This isn't to say that LLMs aren't impactful, but that there's an argument for viewing them less as being a fundamental shift in how our profession works and more as another tool we can use to pursue essentially the same goals more efficiently than before. Like any other tool that's worth having, they can do things our existing tools couldn't do as well, or else we wouldn't have added it to our toolbox, but you still need to be able to recognize when to use it and when not to (and potentially how to use it when you do).

I think that part of why these tools are so polarizing is that there was already some assymetry in how much longer it takes to clean up things than to create things that need to be cleaned up, so a new tool that makes everyone more productive has a lot of potential to exacerbate the existing imbalance. To make up some numbers for illustrative purposes, if someone introduced four new flaky tests in the time it took to fully diagnose and clean up one, and then LLMs came and made everybody twice as productive, now in the same amount of time someone might introduce eight flaky tests while you fixed two, so you're falling behind twice as fast. Unless the productivity gain disproportionately speeds up the people working on making things more robust and polished (which I find dubious; if anything I think the opposite seems more likely) or LLMs suddenly make everyone who didn't care about quality when rushing things out take it more seriously (which seems even more dubious), then LLMs don't improve the situation for people who already felt that the balance was slanted too heavily towards speed over quality.

[jamesfinlayson]

Yep, none of my current team-mates test their work especially thoroughly... so now we have even more bugs being found in testing in production. Not a net win.

[marssaxman]

Likewise - it's not just about generating production code faster; it's now feasible to create all kinds of experiments, test fixtures, visualizers, analyzers, and support software you never would have had time for before, which you can use to improve your process and create a better product.

I recently had to evaluate some data one of my coworkers had produced, to decide whether some process was going to be feasible. It would have taken probably a couple of weeks for me to dig through it all by hand, so he whipped up a quick little interactive web app that let me explore the data with all the connections and context visible, and I reviewed it much more quickly. A single-use application for a single user - what a luxury! - and it took less time to create than the time I saved by using it.

I will check in Monday morning on the result of an A/B test I set running over the weekend, comparing a reimplementation of a certain tool with its original. The test spins up AWS boxes, pulls code repos, compiles them, runs analysis, recovers from errors and maintains a retry queue, etc., etc., and ultimately collates the results and generates a report. I didn't write a line of this! I wouldn't have written anything nearly so sophisticated, and the results I'd have gotten would have been far less useful. But here we are: I tell the computer "make it so", and I get a really valuable test which runs itself while I enjoy my life, and we'll be able to switch to the new tool with confidence.

[inglor_cz]

"it's now feasible to create all kinds of experiments, test fixtures, visualizers, analyzers, and support software you never would have had time for before, which you can use to improve your process and create a better product."

Yes, yes, yes, so much yes. Log analyzers, consistency checkers, performance evaluators, all sorts of hooks and helpers, precisely of the "single-use application for a single user - what a luxury!" sort, which made the entire development process so much more secure and comfortable. Most of the tedious moments (looking for a single bad value in a heap of logs etc.) went away.

The scaffolding I have now is a castle. The scaffolding I had a year ago was a log cabin. Nothing against log cabins in general, but castles are a lot harder to break into and have fewer holes for problems to sneak in.

[zdragnar]

This is very much an N=1 anecdote from a friend, but his manager has basically doubled velocity expectations for the team at his company over the last year. Everyone has to use Claude code because that's the only model they're allowed to use, and not using it means not hitting the arbitrary expectations.

Conversely, the company I am at has no such expectations, and we've got a legacy code base that LLMs aren't very handy in anyway.

[CamperBob2]

we've got a legacy code base that LLMs aren't very handy in anyway

So do I. What I'm finding is that they are now.

I've spent the last week tracking down bugs using Fable that have gone undiagnosed for several years. And this is a damned obscure legacy code base that runs on a proprietary 8051 variant. Guaranteed to be nothing like it in-distribution.

[fragmede]

Damn, that must be fascinating to watch.

[overgard]

It reminds me of people that get upset when other people aren't drinking as much as them at a party. It's like they need other people to consume the thing because they suspect that maybe their consumption will look a little problematic if other people aren't doing it to the same degree.

[GolfPopper]

Those who do not transform themselves into paperclip maximizers will become paperclips.

[greenavocado]

  127. A technological advance that appears not to threaten freedom often turns out to threaten it very seriously later on. For example, consider motorized transport. A walking man formerly could go where he pleased, go at his own pace without observing any traffic regulations, and was independent of technological support-systems. When motor vehicles were introduced they appeared to increase man’s freedom. They took no freedom away from the walking man, no one had to have an automobile if he didn’t want one, and anyone who did choose to buy an automobile could travel much faster and farther than a walking man. But the introduction of motorized transport soon changed society in such a way as to restrict greatly man’s freedom of locomotion. When automobiles became numerous, it became necessary to regulate their use extensively. In a car, especially in densely populated areas, one cannot just go where one likes at one’s own pace one’s movement is governed by the flow of traffic and by various traffic laws. One is tied down by various obligations: license requirements, driver test, renewing registration, insurance, maintenance required for safety, monthly payments on purchase price. Moreover, the use of motorized transport is no longer optional. Since the introduction of motorized transport the arrangement of our cities has changed in such a way that the majority of people no longer live within walking distance of their place of employment, shopping areas and recreational opportunities, so that they HAVE TO depend on the automobile for transportation. Or else they must use public transportation, in which case they have even less control over their own movement than when driving a car. Even the walker’s freedom is now greatly restricted. In the city he continually has to stop to wait for traffic lights that are designed mainly to serve auto traffic. In the country, motor traffic makes it dangerous and unpleasant to walk along the highway. (Note this important point that we have just illustrated with the case of motorized transport: When a new item of technology is introduced as an option that an individual can accept or not as he chooses, it does not necessarily REMAIN optional. In many cases the new technology changes society in such a way that people eventually find themselves FORCED to use it.)

Ted explained this clearly https://www.washingtonpost.com/wp-srv/national/longterm/unab...

[piokoch]

Yup, that is called progress. One freedom to live in a cave with his 6 spouses and hunting animals all day was indeed taken away. In exchange you don't need to hunt all day, you can go to groceries, you don't need six spouses and 20 kids, as kids death rate is not 80% but 0.001%.

One can, obviously, romanticize the times of cave live, that's fine with me, but I doubt that would be a common choice.

[schoen]

I really believe in technological progress and would strongly defend and advocate for it. I'm also very distressed by the idea that we have an absolute ratchet of more surveillance (and registration, monitoring, and licensing of people and their daily activities) over time.

My intuition has always been that these things don't have to go together, but it's often sounded like a number of people who've thought about it a lot expect that they do! (One reason is that technological advances create new technical means of surveillance and new technical means of data analysis which can include more storage and analysis of personal data. Another reason is more like Kaczynski's account above, that people are afraid of bigger or more frequent harms that can be caused by more-empowered individuals, so they put in place more restrictions or surveillance to try to mitigate or deter some of those harms.) Can anyone reassure me about this? Is there a future in which people have greater capability, and there are also fewer institutions or mechanisms proactively monitoring us?

I'm aware of portions of the history of that conversation but would love to hear your take or the take of other HN members.

[rnewme]

Those times are passing and you'll sooner or later meet with new reality.

[citizenpaul]

I think a lot of HN'ers are in denial. I was an LLM skeptic check my history if you like. At the beginning of 2026 LLMs shifted over the hump to as good or better than most devs and are continuing to get better. I don't think we've even begun to see how this is going to affect the industry. People in charge don't and never have cared about code quality, tech debt, maintainability. Now they will not only not care but cease to listen to devs that insist on it.

People on HN will drop what they think is their trump card. Ie The computer spitting out incorrect info. However, I've worked in banking finance where data was wrong and people in charge just shrugged when I showed them and said something like, accounting will catch it. And here's the worst thing. They were right.

[My_Name]

I agree. Denial only takes you so far. At some point, the devs that insist on outdated working practices (at least ones the boss regards as such) will be replaced by younger people who either don't know about them, or like their boss, don't care.

They will just generate code that passes the tests also written by the AI, ask the AI to find any bugs, and so long as the code runs without obvious issues, that will get released.

[citizenpaul]

I think we are heading towards an AI apocalypse of disengagement. Like in that Idiocracy movie where the computer lays off the entire company because profits are down and not even the CEO can undo it because he got laid off too.

[rnewme]

Company I work with laid off half of workere based on claudes advice, complete strategy is AI based, all presentations, decks, plans, every document and communication coming from the higher ups. New CEO and CTO were brought in to improve the situation and their decision was to lean on AI as much as possible. They started with internal employees then contractors, now are refactoring services to new APM, there's a plan to refactor codebase to third Lang (after it historically already changed stack)...

[ErroneousBosh]

I don't understand why LLMs are supposed to be able to do things more quickly anyway.

I've tried a couple of times to use Claude to help write stuff, and it sits there for a couple of minutes "thinking" before returning some grossly incorrect code.

What's the bit that's supposed to be faster?

[dcuthbertson]

I worked for a company that measures developer's output in number of commits, PRs created and approved, and Jira tickets per sprint. Management doesn't even insist on that the tickets have any kind of an effort estimate.

It can be pretty depressing, until you learn how to game the system - create tickets for yourself that are tiny amounts of work. I hear that it's getting harder to do that, because management is looking more carefully at tickets generated and it looks like they'll start having developers assign points to their tickets before the tickets are added to the sprint

[bitwize]

No, he is correct. LLMs have much larger working memories for the kind of details you work with in programming tasks. You are at an objective cognitive deficit by not taking advantage of this. Everybody knows what he means by left behind. When you program, you do so with a goal in mind, and you will not be able to reach that goal as quickly without LLMs. You will be outcompeted by those who use them, and this means that opportunities to contribute professionally, in open source, etc. will be closed to you.

This is the future. Adapt or die.

[lelanthran]

> This is the future. Adapt or die.

I'm curious about what adaptation you have in mind.

You use LLMs to write specific functions? The person who uses it in an agent loop will leave you behind to die.

You use LLMs in an agent loop? The person who uses LLMs to supervise loops will leave you behind to die.

You use LLMS to supervise agent loops? The person who uses LLMs to determine product offering and automatically start supervision on producing the product will leave you behind to die.

You use LLMs to determine product offering and kick off the supervision? The person who uses LLMs to clone your product without the initial product research will leave you behind to die.

You use LLMs to clone products gaining traction? The person who runs a cluster 100x the size of yours will leave you behind to die.

I am trying to understand where you think you fit in, in this Brave New World.

You obviously think that you're adapting, but if you're correct, anything you do now can be replaced by an LLM in the near future.

Just where were you going with "Adapt or die".

[liveoneggs]

I use the 1M token opus claude for two days to build a dashboard and it forgets how to run the build script it wrote at the start of the project.

Man can it put together a react app lickety split, though

[DangitBobby]

The Claude file, documentation, and memories you leave in the project are part of the harness. Most of Claude's forgetfulness can be eliminated with strategic placement of documentation. After you've got that figured out, you'll have to compact the session long before it forgets because it starts getting sloppy and slow at high context. With your guidance it will basically keep its own harness updated for you as the project progresses.

And it also helps to give it better tools than grep and find to explore, because it can waste lots of tokens and pollute the context with the defaults.

[KronisLV]

I'd suggest CLAUDE.md or README.md (and just write in CLAUDE.md that instructions are in README.md, if they're also supposed to be used by human devs) for scripts and other operative instructions.

Ideally also the PLAN MODE for any long form work within the same session, possibly with sub-agents or dynamic workflows to not pollute the main context too quickly.

It also has a memory mechanism but holy shit is it annoying when it saves meaningless stuff that quickly becomes outdated.

[ctrlkctrls]

Exactly, it's pretty obvious, and definitely as you sail, not aggressive (someone melts a little too easily) The comment was naive to the point of denial.

This is the future. Adapt or die.

[watwut]

If it is the future, people will actually have plenty of time to wait and start using it only later. There is no hurry and no reason to be early adopter crash test dummy. They can wait and stary using it at own pace

The "or die" part betrays insecurity and weakness. You need to scare prople into using it rihht now, because of some perceived threat.

[rdpsentinel598]

The reality is that everyone will be replaced by a cheaper alternative someday, with LLMs or not. If you depend on LLMs more and more to do your work and the costs of keeping your tokens increases, your 'left behind' co-workers will still be fine.

[overgard]

How many other technologies required death threats for adoption?

[socalgal2]

This one does not require any death threats. It's a statement of where the world is going. Maybe you disagree. Come back to this thread in 3 year and see which POV was more correct. The

* "LLMs suck, are stupid, I hate them, and I'm not using them"

or

* "LLMs are the future and if you don't adapt you'll left behind"

I'm confident it's this 2nd option. Care to wager?

People might be using hyperbole: "You'll be left behind" = "you'll be out of a job" or "you'll be unemployable" or "You'll die" but they all mean the same thing.

[overgard]

This whole you need to "adapt" to LLMs thing is bonkers to me, because there's practically no skill in using an LLM. It took me a weekend to learn how to use a coding harness, and the skill pretty much generalizes to all coding harnesses. The things that make me potentially good at using a coding harness are my preexisting engineering skills. I'm sorry, but I think if you believe that being on the cutting edge of knowing how to prompt is some sort of magical skill that's going to protect you from economic hardship, you're delusional.

Most of the "cutting edge" stuff I've seen is basically trying to scale the amount of parallel work that can be done, without any consideration to how much that costs, how much waste is generated, or if the output is even useful. Most of my coding time is spent thinking through problems. Which is exactly how I spent my time prior to LLMs.

[bitwize]

> This whole you need to "adapt" to LLMs thing is bonkers to me, because there's practically no skill in using an LLM.

False. There was a person in this thread complaining about how the LLM forgot to run the build script it itself wrote. Yet people are effectively using LLMs to tackle highly complex, unusual work.

The existence of skill issues implies that skill is needed. This is THE skill that will separate the wheat from the chaff in a software engineering context. There's a reason why Steve Yegge said you're a bad engineer if you're writing code in an editor. It's because you've punted on developing the skillset that will make you vastly more effective.

[fuckaiwriter]

Until the “adopter” themselves find them at the other end of the barrel.

[archagon]

People, generally, do not like to die. They will do various things to avoid doing so.

The Luddites were a small group; AI has the chance to turn a majority of society into loom-smashers, which will be very fun to watch.

[socalgal2]

* Those who refuse to use a calculator over a slide-rule will fall behind because they won't be able to produce as much

* Those who refuse to use a spreadsheet over calculator and paper will fall behind because they won't be able to produce as much

* Those who refuse to use a truck over horse drawn wagon will fall behind because they won't be able to carry as much

Seems pretty common sense to me, rathern than aggressive.

[archagon]

AI is not an abstraction. None of those tools are stochastic decision makers.

[BearOso]

It's marketing. The big AI companies know what they're doing and are trying to drive adoption with FOMO. Some people bought into the idea early on and feel self-important. Meanwhile, using AI is so easy that it's tantamount to pushing a button, because that's the whole point of it: to make things easy to do. You can pick it up in half an hour, so it's impossible to "fall behind," unless you're holding stock when the bubble inevitably crashes.

[jonas21]

We have general expectations on the velocity an engineer should be able to work at. If it took someone 5 weeks to deliver the exact same feature another engineer could deliver in 1 week, that would be considered "falling behind" at most places. Would you disagree?

The notion of falling behind because you refuse to adopt an advance in the field seems both uncontroversial and not aggressive at all to me.

[singpolyma3]

Yes I would disagree. I've never had a co-worker who was consistently producing output chastised in any way. No matter how far "behind" me they were.

[beepbooptheory]

It's extra weird because the Carmack quote immediately following seems to invalidate this very point!

Or at the very least: "It was never about the actual coding" and "coding more separates you from those who will fall behind" is classic kettel logic.