71–80 of 151 posts
Really? 2024? That was forever ago in LLM coding. Before tool calling, reasoning, and larger context windows.
It is like saying YouTube couldn’t exist because too many people were still on dial up.
I think that the premise is wrong (and the title is very clickbaity, but we will ignore that it doesn’t really match the article and the “conclusion”): coding agents are “solving” at least one problem, which is to massively expand the impact of senior developers _that can use them effectively_. Everything else is just hype and people “holding it wrong”.
Earlier quoted context omitted.
> I keep hearing this but I don’t understand. If inelegant code means more bugs that are harder to fix later, that translates into negative business value. That's a rather short-sighted opinion. Ask yourself how "inelegant code" find it's way into a codebase, even with working code review processes. The answer more often than not is what's typically referred to as tech debt driven development. Meaning, sometimes a ha…
You not only stumble upon a weird bug in your hacky solution that takes engineering weeks to debug, but your interfaces are fragile so feature velocity drops (bugs reproduce and unless you address reproduction rate you end up fixing bugs only) and things are so tightly coupled that every two line change is now multi-week rewrite. Look at e.g. facebook. That site has not shipped a feature in years and every time they…
I don't think you fully grasp the issue you're discussing. Things don't happen in a vacuum, and your hypothetical "fragile interfaces" that you frame as being a problem are more often than not a lauded solution to quickly deliver a major feature.
The calling card of junior developers is looking at a project and complaining it's shit. Competent engineers understand tradeoffs and the importance of creating and managing technical debt.
Hard to take it serious when it opens with this note: `48% of AI-generated code contains security vulnerabilities (Apiiro, 2024`? Really? 2024? That was forever ago in LLM coding. Before tool calling, reasoning, and larger context windows. It is like saying YouTube couldn’t exist because too many people were still on dial up.
For me, AI is an enabler for things you can't do otherwise (or that would take many weeks of learning). But you still need to know how to do things properly in general, otherwise the results are bad. E.g. I'm a software architect and developer for many years. So I know already how to build software but I'm not familiar with every language or framework. AI enabled me to write other kind of software I never learned or…
Contrast this to something you do know but can't be arsed to make; you can keep re-rolling a design until you get something you know and can confirm works. Perfect, time saved.
Earlier quoted context omitted.
I'm in the same boat. I've been taking on much more ambitious projects both at work and personally by collaborating with LLMs. There are many tasks that I know I could do myself but would require a ton of trial and error. I've found giving the LLMs the input and output interfaces really help keep them on rails, while still being involved in the overall process without just blindly "vibe coding." Having the AI also he…
100% agree with AI expanding core testing from my own edge and key tests. I agree, I write out the sketch of what I want. With a recent embedded project in C I gave it a list of function signatures and high level description and was very satisfied with what it produced. It would have taken me days to nail down the particulars of the HAL (like what kind of sleep do I want what precisely is the way to setup the WDT and…
Using Typescript works great because you can still build out the interfaces and with IDE integrations the AIs can read the language server results so they get all the type hints.
I agree that the AI code is usually a pretty good starting point and gets me up to speed for new features fast rather than starting everything from scratch. I usually end up refactoring the last 10-20% manually to give it some polish because some of the code still feels off some times.
Errrrr…. false.
I’ll stop reading right there thanks I think I know what’s coming.
"Experienced developers were 19% slower when using AI coding assistants—yet believed they were faster (METR, 2025)" Anecdotally I see this _all the time_...
Humans are notoriously bad at estimating time use with different subjective experiences and show excessive weighting of the tail ends of experiences and perceived repetitious tasks. Making something psychologically more comforting and active, particularly if you can activate speech, will distort people’s sense of time meaningfully.
The current hype around LLMs is making me think about misapplied ORMs in medium scale projects... The tool is chosen early to save hours of boring typing and a certain kind of boring maintenance, but deep into the project what do we see? Over and over days are spontaneously being lost to incidental complexity and arbitrary tool constraints. And with the schedule slipping it’s too much work to address the root issue so band-aides get put on band-aides, and we start seeing weeks slip down the drain.
Subjective time accounting and excessive aversion to specific conceptual tasks creates premature optimizations whose effects become omnipresent over time. All the devs in the room agreed they want to avoid some work day 1, but the accounting shows a big time commitment resulting from that immediate desire. Feelings aren’t stopwatches.
[Not hating on ORMs, just misusing tools for weeks to save a couple hours - every day ain’t Saturday - right tool for the job.]
For me, AI is an enabler for things you can't do otherwise (or that would take many weeks of learning). But you still need to know how to do things properly in general, otherwise the results are bad. E.g. I'm a software architect and developer for many years. So I know already how to build software but I'm not familiar with every language or framework. AI enabled me to write other kind of software I never learned or…
There are some things here that folks making statements like yours often omit and it makes me very sus about your (over)confidence. Mostly these statements talk in a business short-term results oriented mode without mentioning any introspective gains (see empirically supported understanding) or long-term gains (do you feel confident now in making further changes _without_ the AI now that you have gained new knowledge?).
1. Are you 100% sure your code changes didn't introduce unexpected bugs?
1a. If they did, would you be able to tell if they where behaviour bugs (ie. no crashing or exceptions thrown) without the AI?
2. Did you understand why the bug was happening without the AI giving you an explanation?
2a. If you didn't, did you empirically test the AI's explanation before applying the code change?
3. Has fixing the bug improved your understanding of the driver behaviour beyond what the AI told you?
3a. Have you independently verified your gained understanding or did you assume that your new views on its behaviour are axiomatically true?
Ultimately, there are 2 things here: one is understanding the code change (why it is needed, why that particular change implementation is better relative to others, what future improvements could be made to that change implementation in the future) and skill (has this experience boosted your OWN ability in this particular area? in other words, could you make further changes WITHOUT using the AI?).
This reminds me of people that get high and believe they have discovered these amazing truths. Because they FEEL it not because they have actual evidence. When asked to write down these amazing truths while high, all you get in the notes are meaningless words. While these assistants are more amenable to get empirically tested, I don't believe most of the AI hypers (including you in that category) are actually approaching this with the rigour that it entails. It is likely why people often think that none of you (people writing software for a living) are experienced in or qualified to understand and apply scientific principles to build software.
Arguably, AI hypers should lead with data not with anecdotal evidence. For all the grandiose claims, the lack of empirical data obtained under controlled conditions on this particular matter is conspicuous by its absence.