Discussion
If you thought the speed of writing code was your problem - you have bigger problems
Legend2440: Highly motivated opinions by someone who just doesn't want AI to take his job.
furyofantares: [delayed]
luxuryballs: It’s definitely going to create a lot of problems in orgs that already have an incomplete or understaffed dev pipeline, which happen to often be the ones where executive leadership is already disconnected and not aware of what the true bottlenecks are, which also happen to often be the ones that get hooked by vendor slide decks…
gammalost: Seems easy to address with a simple rule. Push one PR; review one PR
petcat: As human developers, I think we're struggling with "letting go" of the code. The code we write (or agents write) is really just an intermediate representation (IR) of the solution.For instance, GCC will inline functions, unroll loops, and myriad other optimizations that we don't care about. But when we review the ASM that GCC generates (we don't) we are not concerned with the "spaghetti" and the "high coupling" and "low cohesion". We care that it works, and is correct for what it is supposed to do. And that it is a faithful representation of the solution that we are trying to achieve.Source code in a higher-level language is not really different anymore. Agents write the code, maybe we guide them on patterns and correct them when they are obviously wrong, but the code is merely the work-item artifact that comes out of extensive specification, discussion, proposal review, and more review of the reviews.A well-guided, iterative process and problem/solution description should be able to generate an equivalent implementation whether a human is writing the code or an agent.
felipellrocha: If you truly believe that, why don’t you just transform code directly to assembly? Skip the middleman, and get a ton of performance!
renewiltord: Understanding the problem is easier for me experienced with engaging with solutions to the problem and seeing what form they fail in. LLMs allow me to concretize solutions so that pre-work simply becomes work. This allows me to search through the space of solutions more effectively.
hathawsh: Also add a PR reviewer bot. Give it authority to reject the PR, but no authority to merge it. Let the AIs fight until the implementation AI and the reviewer AI come to an agreement. Also limit the number of rounds they're permitted to engage in, to avoid wasting resources. I haven't done this myself, but my naive brain thinks it's probably a good idea.
dmitrygr: > I haven't done this myself, but my naive brain thinks it's probably a good idea.Many a disaster started this way
hathawsh: Yep, we're on the same wavelength.
6stringmerc: Because the way the world is currently and this is trending, let me jump in and save you a lot of time:Expedience is the enemy of quality.Want proof? Everyone as a result of “move fast and break things” from 5-10 years ago is a pile of malfunctioning trash. This is not up for debate.This is simply an observation. I do not make the rules. See my last submission for some CONSTRUCTIVE reading.Bye for now.
bob1029: > Why can't we figure out the right thing faster by building the wrong thing faster?Because usually the customer can only tolerate so many failed attempts per unit of time. Running your fitness function is often very expensive in terms of other people's time.This is easily the biggest bottleneck in B2B/SaaS stuff for banking. You can iterate maybe once a week if you have a really, really good client.
furyofantares: That's fair. I'm usually my own customer.
nyeah: [delayed]
cdrnsf: Because you're working on the implementation before you understand the problem?
p-o: > Why can't we figure out the right thing faster by building the wrong thing faster?Why can't we figure out the right thing faster by talking about the wrong thing faster?
krackers: >Source code in a higher-level language is not really different anymoreSource code is a formal language, in a way that natural language isn't.
jrop: Right? That's the only reason that "coding with LLMs" works at all (believe me, all at the same time, I am wowed by LLMs, and carry a healthy level of skepticism with respect to their ability as well). You can prompt all you want, let an Agent spin in a Ralph loop, or whatever, but at the end of the day, what you're checking into Git is not the prompts, but the formalized, codified artifact that is the bi-product of all of that process.
bdcravens: I assume you're being cynical, but there's a lot of truth in what you say: LLMs allow me to build software to fit my architecture and business needs, even if it's not a language I'm familiar with.
zer00eyz: The problem is most of the people we have spent the last 20 years hiring are bad at code review.Do you think the leet code, brain teaser show me how smart you are and how much you can memorize is optimized to hire the people who can read code at speed and hold architecture (not code but systems) in their head? How many of your co-workers are set up and use a debugger to step through a change when looking at it?Most code review was bike shedding before we upped the volume. And from what I have seen it hasn't gotten better.
tovej: Is this a copypasted response? I've seen the exact same bs in other AI threads on this site.
doix: Pretty much, the article assumes people didn't build the wrong thing before AI. Except that did happen all the time and it just happened slower, took longer to realize that it was the wrong thing and then building the right thing took longer.It's funny, because you could actually take that story and use it to market AI.> I once watched a team spend six weeks building a feature based on a Slack message from a sales rep who paraphrased what a prospect maybe said on a call. Six weeks.Except now with AI it takes one engineer 6 hours, people realize it's the wrong thing and move on. If anything, I would say it helps prove the point that typing faster _does_ help.
Terr_: [delayed]
exceptione: None of the comparisons make any sense. In short, these concepts are essential to understand:- determinism vs non-determinism- conceptual integrity vs "it works somewhat, don't touch it"
n4r9: Can agents write good assembly code?
svachalek: With the complexity of modern pipelines, there are very few humans that can beat a good optimizing compiler. Considering that with an LLM you're also bloating limited context with unsemantic instructions I can't see how this is anything but an exercise in failure.
inamberclad: When you get to the really tightly controlled industries, your "formal" language becomes carefully structured English.
petcat: Legalese exists precisely because it is an attempt to remove doubt when it comes to matters of law.Maybe a dialect of legalese will emerge for software engineering?
operatingthetan: I know you're being cheeky but we are definitely heading in that direction. We will see frameworks exclusively designed for LLM use get popular.
john_strinlai: >Why not? Why can't faster typing help us understand the problem faster?do you have a example (even a toy one) where typing faster would help you understand a problem faster?
lgessler: Has everyone always nailed their implementation of every program on the first try? Of course not. Probably what happens most times is you first complete something that sorta works and then iterate from there by modifying code, executing, observing, and looping back to the beginning. You can wonder about ultimately how much of your time/energy is consumed by the "typing code" part, and there's surely a wide range of variation there by individual and situation, but it's undeniable that it is a part of the core iteration loop for building software.I don't understand why GP's comment is so controversial. GP is not denying that you should maybe think a little before a key hits the keyboard as many commenters seem to suppose. Both can be true.
nyeah: [delayed]
everdrive: Companies genuinely don't want good code. Individual teams just get measured by how many things they push around. An employee warning that something might not work very well is going to get reprimanded as "down in the weeds" or "too detail oriented," etc. I didn't understand this for a while, but internal actors inside of companies really just want to claim success.
mooreds: > Companies genuinely don't want good code.I might be more charitable. I'd say something like "Companies genuinely want good code but weigh the benefits of good code (future flexibility, lower maintenance costs) against the costs (delayed deployment, fewer features)."Each company gets to make the tradeoffs they feel are appropriate. It's on technical people to explain why and risks, just like lawyers do for their area of expertise.
tcmart14: I really hate the trying to make LLM coding sound like it's just moving up the stack and is no different from a compiler. A compiler is deterministic and has a set of rules that can be understood. I can look at the output and see patterns and know exactly what the compiler is doing and why it does and where it does it. And it will be deterministic in doing it.
petcat: > compiler is deterministic and has a set of rules that can be understood.Here are the reported miscompilation bugs in GCC so far in 2026. The ones labeled "wrong-code".https://gcc.gnu.org/bugzilla/buglist.cgi?chfield=%5BBug%20cr...I count 121 of them. It appears that code-generation is not as deterministic as you seem to think it is.
observationist: Sometimes articulating the problem is all you need to see what the solution is. Trying many things quickly can prime you to see what the viable path is going to be. Iterating fast can get you to a higher level of understanding than methodical, deliberative construction.Nevertheless, it's a tool that should be used when it's useful, just like slower consideration can be used. Frontier LLMs can help significantly in either case.
myylogic: I agree that speed isn’t the core problem — misunderstanding is.But faster iteration does change how quickly you converge toward understanding.In practice, especially with AI-assisted coding, the real issue I’ve seen isn’t just writing the wrong thing faster — it’s losing the feedback loop. When generation becomes too cheap, people stop validating assumptions and just keep stacking outputs.Building something quickly is still valuable, but only if it’s tied to tight feedback and evaluation.Otherwise, you don’t just build the wrong thing faster — you also learn the wrong mental model faster.
Bukhmanizer: I think a lot of the discourse around LLMs fails because of organizational differences.I work in science, and I’ve recently worked with a couple projects where they generated >20,000 LOC before even understanding what the project was supposed to be doing. All the scientists hated it and it didn’t do anything that it was supposed to. But I still felt like I was being “anti-ai” when criticizing it.
jmulho: I often understand problems by discussing them with AI (by typing prompts and reading the response). Typing or reading faster would make this faster.
podgorniy: Yeah, we again have a solution (LLMs) in search of problems.Proper approach to speeding things up would be to ask "What are the limiting factors which stops us from X, Y, Z".--This situation of management expecting things to become fast because of AI is "vibe management". Why to think, why to understand, why to talk to your people if you saw an excited presentation of the magic tool and the only thing you need to do is to adopt it?..
mooreds: Ding ding ding!The article talks about process flows and finding the bottleneck. That might be coding, but probably is not.
intrasight: Here's a literal toy one.Build a toy car with square wheels and one with triangular wheels and one with round wheels and see which one rolls better.The issue isn't "typing faster" it's "building faster".
skydhash: No need to build one, you just have to quickly write a proof for which shapes can roll. You'll then spend x+y units of time, where y<<x, instead of 3*x units. We have stories that highlight the importance of thinking instead of blindly doing (sharping the axe, $1 for pressing a button and $9999 for knowing which button to press).
Rapzid: I'm starting to see this. It starting to seem like a lot of the people making the most specious, yet wild AI SLDC claims are:* Hobbyist or people engaged in hobby and personal projects* Startup bros; often pre-funding and pre-team* Consultancies selling an AI SDLC as that wasn't even possible 6 months ago as "the way; proven, facts!"It's getting to the point I'd like people to disclose the size of the team and org they are applying these processes at LOL.
phillipclapham: The bottleneck I keep hitting isn't how fast the code gets written, it's whether the decisions upstream of the code were sound. You can have an agent generating at 10x speed and still burn two days on "WAIT, that's not what I meant."The real problem is that most AI coding workflows have the agent figure out the decision logic as it goes. That works until it doesn't, and when it doesn't you're debugging an opaque reasoning chain instead of a clear decision path. Been building tooling around making those decisions explicit before generation. The productivity gains aren't in generation speed. They're in eliminating the back-and-forth rounds that end up eating all your productivity.
_under_scores_: For me it's also in generating output that I know is right when I see it, but don't necessarily know every intricate detail of up front.
ohyoutravel: You’re engaging with an LLM.
larsnystrom: I can really relate to this. At the same time I’m not convinced cycle time always trumps throughput. Context switching is bad, and one solution to it is time boxing, which basically means there will be some wait time until the next box of time where the work is picked up. Doing time boxing properly lowers context switching, increases throughput but also increases latency (cycle time). It’s a trade-off. But of course maybe time boxing isn’t the best solution to the problem of context switching, maybe it’s possible to figure out a way to have the cookie and eat it. And maybe different circumstances require a different balance between latency and throughput.
725686: The work typing is wrong.It is not about the speed of typing code.Its about the speed of "creating" code: the boilerplate code, the code patterns, the framework version specific code, etc.
tcmart14: I commented elsewhere, but that doesn't mean it's not deterministic. Deterministic means given the same input it gives the same output. Compilers can still have bugs and generate the wrong code. But so long as given the same input it generates the same wrong output, it is still deterministic.
vidarh: The customer doesn't need to be shown every "wrong thing".
m463: > The Goal ... it's also the most useful business book you'll ever read that's technically fictionfactorio ... it's also the most useful engineering homework that's technically a game
metalrain: I think it's more abstraction problem.You could write more code, but you also could abstract code more if you know what/how/why.This same idea abstracts to business, you can perform more service or you can try to provide more value with same amount of work.
cess11: One of the main reasons I like vim is that it enables me to navigate code very fast, that the edits are also quick when I've decided on them is a nice convenience but not particularly important.Same goes for the terminal, I like that it allows me to use a large directory tree with many assorted file types as if it was a database. I.e. ad hoc, immediate access to search, filter, bulk edits and so on. This is why one of the first things I try to learn in a new language is how to shell out, so I can program against the OS environment through terminal tooling.Deciding what and how to edit is typically an important bottleneck, as are the feedback loops. It doesn't matter that I can generate a million lines of code, unless I can also with confidence say that they are good ones, i.e. they will make or save money if it is in a commercial organisation. Then the organisation also needs to be informed of what I do, it needs to give me feedback and have a sound basis to make decisions.Decision making is hard. This is why many bosses suck. They're bad at identifying what they need to make a good decision, and just can't help their underlings figure out how to supply it. I think most developers who have spent time in "BI" would recognise this, and a lot of the rest of us have been in worthless estimation meetings, retrospectives and whatnot where we ruminate a lot of useless information and watch other people do guesswork.A neat visualisation of what a system actually contains and how it works is likely of much bigger business value than code generated fast. It's not like big SaaS ERP consultancy shops have historically worried much about how quickly the application code is generated, they worry about the interfaces and correctness so that customers or their consultants can make adequate unambiguous decisions with as little friction as possible.
andrewstuart: These “LLM programming ain’t nothing special” posts are becoming embarrassing for the authors who - due to their anti AI dogmatism - have no idea how truly incredibly fast and powerful it’s become.Please stop making fools of yourselves and go use Claude for a month before writing that “AI coding ain’t nothing special” post.Ignorance of what Claude can actually do means your arguments have no standing at all.
senko: > Why can't we figure out the right thing faster by building the wrong thing faster?> Because usually the customer can only tolerate so many failed attempts per unit of time. Running your fitness function is often very expensive in terms of other people's time.Heh, depends on what you do. Many times the stakeholders can't explain what they want but can clearly articulate what they don't want when they see it.Generate a few alternatives, have them pick, is a tried and true method in design. It was way too expensive when coding was manual, so often you need multiple rounds of meetings and emails to align.If you don't think coding was the bottleneck, you're not thinking creatively about what's only now possible.It's not what you can do faster (well, it is, up to a point), but also what can you now, do that would have been positively insane and out of the question before.
skydhash: > Generate a few alternatives, have them pick, is a tried and true method in design. It was way too expensive when coding was manual, so often you need multiple rounds of meetings and emails to align.Why do you need coding for those. You can doodle on a whiteboard for a lot of those discussions. I use Balsamiq[0] and I can produce a wireframe for a whole screen in minutes. Even faster than prompting.> If you don't think coding was the bottleneck, you're not thinking creatively about what's only now possible.If you think coding was a bottleneck, that means you spent too much time doing when you should have been thinking.[0]: https://balsamiq.com/product/desktop/
pbasista: > review the ASM that GCC generates (we don't)Of course we do not. Because there is no need. The process of compiling higher order language to assembly is deterministic and well-tested. There is no need to continue reviewing something that always yields the same result.> We care that it works, and is correct for what it is supposed to do.Exactly. Which is something we do not have with an output of an LLM. Because it can misunderstand or hallucinate.Therefore, we always have to review it.That is the difference between the output of compilers and the output of LLMs.
doctorpangloss: You have it completely backwards.Most Enterprise IT projects fail. Including at banks. They are extremely saleable though. They don't see things that are failures as failures. The metrics are not real. Contract renewals do not focus on objective metrics.This is why you make "$1" with all your banking relationships and actually valuable tacit knowledge, until Accenture notices and makes bajillions, and now Anthropic makes bajillions. Look, I agree that you know a lot. That's not what I'm saying. I'm saying the thing you are describing as a bottleneck is actually the foundation of the business of the IT industry.Another POV is, yeah, listen, the code speed matters a fucking lot. Everyone says it does, and it does. Jesus Christ.
Kilenaitor: Having bugs is not the same as being non-deterministic.I get the point that the compiler is not some pure, perfect transformation of the high-level code to the low level code, but it is a deterministic one, no?
Rapzid: The semantics described in the high-level language are absolutely maintained deterministically.With agentic coding the semantics are not deterministically maintained. They are expanded, compressed, changed, and even just lost; non-deterministically..
hrmtst93837: Fast prototyping helps when the prototype forces contact with the problem, like users saying "nope" or the spec collapsing under a demo. If the loop is only you typing, debugging, and polishing, you're mostly making a bigger mess in the repo and convincing yourself that the mess taught you something.Code is one way to ask a question, not proof that you asked a good one. Sometimes the best move is an annoying hour with the PM, the customer, or whoever wrote the ticket.
onlyrealcuzzo: AI is really good when:1. you want something that's literally been done tons of times before, and it can literally just find it inside its compressed dataset2. you want something and as long as it roughly is what you wanted, it's fineIt turns out, this is not the majority of software people are paying engineers to write.And it turns out that actually writing the code is only part of what you're paying for - much smaller than most people think.You are not paying your surgeon only to cut things.You are not paying your engineer only to write code.
closewith: > It turns out, this is not the majority of software people are paying engineers to write.The above are definitely the majority of software people are paying developers to write. By an order of magnitude.The novel problems for customers who specifically care about code quality is probably under 1% of software written.If you don't recognise this, you simple don't understand the industry you work in.
slopinthebag: What makes you think they haven't? I agree with them and I've been heavily using Claude / Codex for a while now. And I'm slowly trying to use AI more selectively because of these concerns.
skydhash: Everyone has its own set of novel problems. And they use libraries and framework for things that are outside it. The average SaaS provider will not write its own OS, database, network protocols,... But it will have its own features and while it may be similar to others, they're evolving in different environments and encounter different issues that need different solutions.
k1rd: > That's the part most people get. Here's the part they don't, and it's the part that should scare you: > When you optimise a step that is not the bottleneck, you don't get a faster system. You get a more broken one.if you ever played factorio this is pretty clear.
golergka: attempt != release to customerwhen you're building a feature and have different ideas how to go about it, it's incredibly valuable to build them all, compare, and then build another, clean implementation based on all the insightsI used to do it before, but pretty rarely, only for the most important stuff. now I do it for basically everything. and while 2-4 agents are working on building these options, I have time to work on something else.
dannersy: They don't care about good code, but they do pay people a lot of money to care about good code. If the people you hired didn't care, our software quality would be worse than it is. And since people are caring less in the face of AI, it is getting worse.
onlyrealcuzzo: As it turns out - "just make this button green" - is not the majority of what people at FAANG are doing...But, sure...
nicbou: I'm a solo dev. In fact I'm hardly a dev; it's just a helpful skill. Code writing speed IS a problem, because it takes valuable time away from other tasks. A bit like doing the dishes.I just set up Claude Code tonight. I still read and understand every line, but I don't need to Google things, move things around and write tests myself. I state my low-level intent and it does the grunt work.I'm not going to 10x my productivity, but it'll free up some time. It's just a labour-saving technology, not a panacea. Just like a dishwasher.
mooreds: This is the way.
qalmakka: This. The comparison between compilers and LLMs is so utterly incorrect, and yet I've heard it multiple times already in the span of a few weeks. The people suggesting this are probably unaware of the fact that Turing complete languages follow mathematical properties not just vibes, you can trust the output of your compiler because it was thoroughly tested to ensure it acts as a Turing machine that converts one Turing complete language (C, C++, whatever) into another Turing complete language (ASM). LLMs are probabilistic machines and it's grossly inappropriate to put them in the same category as compilers - it would be like saying that car tires and pizzas are similar because they're both round and have edges.
slopinthebag: Ai generated comments are against the rules of HN.@dang this bot is spamming
slopinthebag: Actually the surgeon analogy is really good. Saying AI will replace programming is like saying an electric saw will replace surgeons because the hospital director can use it to cut into flesh.
duskdozer: It's so much faster too! How many meters of flesh have you cut this month, and how are you working toward increasing that number?
Supermancho: > quickly write a proof for which shapes can roll.Writing the 3 are the proofs.
slibhb: The idea that LLMs don't significantly increase productivity has become ridiculous. You have to start questioning the psychology that's leading people to write stuff like this.
bvirb: When we (the engineering team I work on) started using agents more seriously we were worried about this: that we'd speed up coding time but slow down review time and just end up increasing cycle time.So far there's no obvious change one way or the other, but it hasn't been very long and everyone is in various states of figuring out their new workflows, so I don't think we have enough data for things to average out yet.We're finding cases where fast coding really does seem to be super helpful though:* Experimenting with ideas/refactors to see how they'll play out (often the agent can just tell you how it's going to play out)* Complex tedious replacements (the kind of stuff you can't find/replace because it's contextual)* Times where the path forward is simple but also a lot of work (tedious stuff)* Dealing with edge cases after building the happy pathThe single biggest potential productivity gain though I think is being able to do something else while the agent is coding, like you can go review a PR and then when you come back check out what the agent produced.I would say we've gone from being extremely skeptical to cautiously excited. I think it's far fetched that we'll see any order of magnitude differences, we're hoping for 2x (which would be huge!).
ianberdin: I don’t agree. I have built Replit clone alone in months. They have hundreds of millions of funding…Btw: https://playcode.io
slopinthebag: It is deterministic, unless GCC is now including a random statistical process inside its compiler to generate machine code. You've copied this same comment repeatedly, it doesn't become more correct the more you spam it.
webdood90: > The single biggest potential productivity gain though I think is being able to do something else while the agent is coding, like you can go review a PR and then when you come back check out what the agent producedUgh, sounds awful. Constantly context switching and juggling multiple tasks is a sure-fire way to burn me out.The human element in all of this never seems to be discussed. Maybe this will weed out those that are unworthy of the new process but I simply don't want to be "on" all the time. I don't want to be optimized like this.
whateverboat: Often when you are solving a problem, you are never solving a single problem at a time. Even in a single task, there are 4-5 tasks hidden. you could easily put agent to do one task while you do another.Ask it to implement a simple http put get with some authentication and interface and logs for example, while you work out the protocol.
copperx: [delayed]
raw_anon_1111: This is categorically not true. For almost all of my 30 years it’s been1. Talk to the business, solve XYProblems, deal with organization complexity, learn the business and there needs.2. Design the architecture not just “the code”, the code has to run on something.3. Get the design approve and agree on the holy trinity - time/cost/budget4. Do the implementation5. Test it for the known requirements6. Get stakeholder approval or probably go back to #47. Move it into production8. Maintenance.Out of all those, #4 is what I always considered the necessary grunt work and for the most part even before AI especially in enterprise development where most developers work has been being commoditized in over a decade. Even in BigTech and adjacent codez real gud* will keep you as a mid level developer if you can’t handle the other steps and lead larger/more impactful/more ambiguous projects.As far as #5 much of that can and should be done with automated tests that can be written by AI and should be reviewed. Of course you need humans for UI and UX testingThe LLMs can do a lot of the grunt work now.
zelphirkalt: I see step 4 as interwoven with other steps. The implementation ideally takes into consideration the domain and while implementing, potentials for flexibility are potentially revealed, to be taken advantage of, "without programming ourselves into a corner". Implementation also is of course related to maintenance. Maintenance already needs to be taken into account. How easy is it to adapt the system we are building later?This all happens while we are at the implementation stage and impacts all other aspects of the whole thing. It is a grunt work, but we need elite grunts, who see more than just the minimal requirements.
raw_anon_1111: I’ve been going on about this in another thread in a separate post. That’s where modularity comes in. From code I write to teams (or multiple teams back in the day). I always enforce micro services. Not always separately deployable micro service, they could be separate packages with namespace/public/private accessibility.Even if you do have not so good developers, they can ramp up quickly on one specific isolated service and you can contain the blast radius.This isn’t a new idea. This was the entire “API mandate” that Bezos had in 2002. s3 alone is made up of 200+ micro services
mirsadm: I don't know if I agree with that. It's a struggle to get a modern compiler to vectorize a basic loop.
brailsafe: [delayed]
leptons: >For instance, GCC will inline functions, unroll loops, and myriad other optimizations that we don't care about. But when we review the ASM that GCC generates (we don't) we are not concerned with the "spaghetti" and the "high coupling" and "low cohesion". We care that it works, and is correct for what it is supposed to do. And that it is a faithful representation of the solution that we are trying to achieve.The more complex the code becomes, iteration after iteration by the AI, it keeps adding more and more code to fix simple problems, way more than is reasonably necessary in many cases. The amount of entropy you end up with using AI is astonishing, and it can generate a lot of it quickly.The AI is going to do whatever it needs to do to get the prompt to stop prompting. That's really its only motivation in its non-deterministic "life".A compiler is going to translate the input code to a typically deterministic output, and that's all it really does. It is a lot more predictable than AI ever will be. I just need it to translate my explicit instructions into a deterministic output, and it satisfies that goal rather well.I'll trust the compiler over the AI every single day.
riskable: Great big difference though: A dishwasher is a water-saving and energy-saving technology.Not saying LLMs are all bad, just that comparing them to dishwashers is probably not the best idea.
johnsmith1840: How much energy does a human + work enviroment cost vs an LLM call?Human driving into work? Heating/cooling?Wonder why big AI hasn't sold it as an enviromental SAVING technology.
hollerith: Eventually after AI tech gets mature enough, we will be able to save EVEN MORE energy by getting rid of all the people.
danilocesar: I'm here just for the comments...
antonvs: These discussions remind me of two quotes:“This is just a moment in time. Step aside and let it happen.” - Inara Serra, Firefly."Your effort to remain what you are is what limits you." Puppet Master, Ghost in the Shell.
hintymad: How do people ensure that AI don't produce subtle and stupid mistakes that humans usually don't make, like the one in Amazon that deleted the entire production deployment?When a person writes code, the person reasons out the code multiple times, step by step, so that they don't make at least stupid or obvious mistakes. This level of close examination is not covered in code review. And arguably this is why we can trust more on human-written code than AI-produced, even though AI can probably write better code at smaller scale.In contrast, Amazon asked senior engineers to review AI-generated code before merging them. But the purpose of code review was never about capturing all the bugs -- that is the job of test cases, right? Besides, the more senior an engineer is in Amazon, the more meetings they go to, and the less context they have about code. How can they be effective in code review?
giancarlostoro: > How do people ensure that AI don't produce subtle and stupid mistakes that humans usually don't make, like the one in Amazon that deleted the entire production deployment?Right... Because Humans have never ever accidentally rm -rf'd a production system in the wrong spot?GitLab has entered the chat.Or that time an S3 developer purged more than intended, causing internet outages.All the above are from 2017.Then there was a deployment goof by Knight Capital Group, they lost 440 million in 45 minutes. The company went poof back in 2012 as a result.MySpace back in 2019 deleted a ton of prod data from users during a botched migration (oops).Humans make mistakes. Anyone arrogant enough to think they only write perfect code is delusional.We are holding AI to higher standards than we hold humans, who are just as fallible if not worse.QA your software, stop letting developers test changes.
amarant: I think one of the biggest gains of AI is the second order effects. And maybe a bit in the third order as well. When coding with Claude, I can focus on the architecture, the big picture of the implementation, while Claude takes care of the details. Every function for which I don't have to remember the order of the arguments anymore, is a little bit extra brain power I can dedicate to thinking about the solution. I can focus on what matters, and I can focus for longer. I find that remembering argument order is much more tiresome than thinking through complex interactions(because the latter is fun, while the former is boring)Then there's the speedup. A smaller team can now achieve what a larger team was needed for before. This means less communication overhead, in theory fewer and/or shorter meetings. Which all translates to me spending more time and more energy on thinking about the solution. Which is what matters.
petcat: > The process of compiling higher order language to assembly is deterministic and well-tested.Here are the reported miscompilation bugs in GCC so far in 2026. The ones labeled "wrong-code".https://gcc.gnu.org/bugzilla/buglist.cgi?chfield=%5BBug%20cr...I count 121 of them.I've posted this 3 times now. Code-generation by compilers written by experts is not deterministic in the way that you think it is.
perlgeek: In the 12+ years I've been a professional developer, I can only remember two bugs that were caused by the compiler / interpreter, everything else were logic bugs, oversights, 3rd-party libraries, misunderstanding of the requirements, internal contradictions in the requirements etc.So that's maybe 0.1% of all the bugs I've touched.In that sense, code generation isn't really an interesting source of bugs for the discussion at hand.
