17 ms·

LLM-powered tools amplify developer capabilities rather than replacing them

• skydhash 1y ago
  > Traditionally, coding involves three distinct “time buckets”: > Why am I doing this? Understanding the business problem and value > What do I need to do? Designing the solution conceptually > How am I going to do it? Actually writing the code > For decades, that last bucket consumed enormous amounts of our time. We’d spend hours, days or weeks writing, debugging, and refining. With Claude, that time cost has plummeted to nearly zero. That last part is actually the easiest, and if you're spending inordinate amount of time there, that usually means the first two were not done well or you're not familiar with the tooling (language, library, IDE, test runner,...). There's some drudgery involved in manual code editing (renaming variable, extracting functions,...) but those are already solved in many languages with IDEs and indexers that automate them. And so many editors have programmable snippets support. I can genuinely say in all of my programming projects, I spent more time understanding the problem than writing code. I even spent more time reading libraries code than writing my own. The few roadblocks I have when writing code was solved by configuring my editor.
  • jstanley 1y ago
    How do you understand the problem without writing any code? It's possible that people's experiences are different to yours because you work on a specific type of software and other people work on other specific types of software.
    • vlovich123 1y ago
      By building a high level abstract understanding of how things operate & then understanding how that abstractions need to be expressed. Writing code certainly is more concrete and can highlight mistakes like when there's a gap in your understanding vs spots where details matter more specifically. At many big tech companies I've worked out, an abstract design proposal precedes any actual coding for many tasks. These design proposals are not about how you lay out code or name variables, but a high level description of the problem and the general approach to solve the problem. Expressing that abstract thinking requires writing code but that's the "how" - you can write that same code many ways.
      • codr7 1y ago
        If you haven't solved exactly the same problem before, specifying a solution before writing code is a bad idea imo. More often than not, it turns out that the prematurely defined general approach isn't very optimal. Which points at a pretty substantial limitation of LLM coding...
        • skydhash 1y ago
          The solution is always out there. The code is just an automated way to get it without the error prone way of humans doing manual calculations. But sometimes, your understanding is flawed, so the code you write is not the correct way to have the solution. Which is why you have to get actual correct answers (specs) before writing code. Correctness is not embedded in software. It's embedded in the real world.
        • vlovich123 1y ago
          Typically I find a novel problem domain requires roughly about 3 attempts from scratch to get a maintainable longer-term solution. However, that still requires having some idea in mind to try before just writing code. Of course you might also do some prototyping on certain subparts of the problem but there’s only so much of that that can be done and you’re still trying out what expressing high level ideas looks like / how it works. I don’t think there’s anything where the first step is writing code. It’s like saying the first step of solving a math problem is writing down equations.
      • skydhash 1y ago
        > By building a high level abstract understanding of how things operate & then understanding how that abstractions need to be expressed. Writing code certainly is more concrete and can highlight mistakes like when there's a gap in your understanding vs spots where details matter more specifically. The whole argument behind TDD is that it's easier to write code that verify something than actually implement the code. Because it only have the answer, not the algorithm to solve the question. So for any code you will be writing, find the answers first (expected behavior). Then add tests. The you write the code for the algorithm to come up with the answer. Static typing is just another form of these. You tell the checker: This is the shape of this data, and it warns you of any code that does not respect that.
    • carlmr 1y ago
      >How do you understand the problem without writing any code? Not OP, but I find this a very good question. I've always found that playing with the problem in code is how I refined my understanding of the problem. Kind of like how Richard Feynman describes his problem solving. Only by tinkering with the hard problem do you really learn about it. I always found it strange when people said they would plan out the whole thing in great detail and code later. That never worked for me, and I've also rarely seen it work for those proposing it. It may be because I studied control systems, but I've always found you need the feedback from actually working with the problem to course correct, and it's faster, too. Don't be scared to touch some code. Play with it, find out where your mental model is deficient, find better abstractions than what you originally envisioned before wrestling with the actual problems.
      • mixmastamyk 1y ago
        This is true when breaking new ground, but it’s a rare occurrence. Most business problems are a few thousand years old. Yes, there were taxes paid in the ancient world.
        • Espressosaurus 1y ago
          They weren't solving hard realtime nonlinear control for hardware running on a custom ASIC in a domain only a literal handful of companies even operate in. Not everything has been solved for ten thousand years.
          • mixmastamyk 1y ago
            You misread. Also, that tech has been around for decades.
        • gitremote 1y ago
          Most solutions to business problems are proprietary, not open source. Tax rules depend on an interaction between national and local laws that can change from year to year based on the ruling government. You can't just take tax rules from ancient Rome to generate 2024 tax software for Quebec, Canada.
  • vlovich123 1y ago
    And the article is overstating it as well. My confidence in the LLM's ability to reduce the "how" part is primarily based on "am I doing something the LLM is good at?". If I'm doing HTML React where there's a million examples of existing stuff, then great. The more novel what I'm asking is, the less useful the LLM becomes and the more stuff I need to handcode is. Just as with self-driving cars, this is a challenge because switching from "the LLM is generating the code" to "I'm hand-tweaking things" is equivalent to self-driving disconnecting randomly and telling you "you drive" in the middle of the highway. Oh and I've caught the LLM randomly inserting vulnerabilities for absolutely no reason (e.g. adding permissions to the iframe sandbox attribute when I complained about UI layout issues). It's a useful tool that can accelerate certain tasks, but it has a lot of sharp edges.
    • bluefirebrand 1y ago
      > If I'm doing HTML React where there's a million examples of existing stuff, then great I do quite a bit of this and even here LLMs seem extremely hit and miss, leaning towards the miss side more often than not
      • ijk 1y ago
        I think React is one of those areas where consistency is more important than individual decisions. With a lot of front-end webdev there's many right answers, but they're only right if they are aligned with the other design decisions. If you've ever had to edit a web page with three different approaches to laying out the CSS you know what I mean. LLMs _can_ do consistency, they're pretty good continuing a pattern...if they can see it. Which can be hard if it's scattered around the codebase.
        • bluefirebrand 1y ago
          > one of those areas where consistency is more important than individual decisions This describes any codebase in any programming language This is why "programming patterns" exist as a concept The fact that LLMs are bad at this is a pretty big mark against them
  • hiAndrewQuinn 1y ago
    >That last part is actually the easiest If it were, the median e.g. business analyst should be getting paid significantly more than the median software engineer. That's not what the data shows, however. >I can genuinely say in all of my programming projects, I spent more time understanding the problem than writing code. This is almost trivially true for anyone who understands the problem via writing code, though.
    • jimbokun 1y ago
      > If it were, the median e.g. business analyst should be getting paid significantly more than the median software engineer. What if you replace "business analyst" with "software architect"?
      • skydhash 1y ago
        Or tech lead and senior engineer. Because they spend more time doing the first two than that last one.
        • Snuggly73 1y ago
          I spend most of my time talking to stakeholders and BAs to help them better understand what their actual problem is instead of coming to me with "we want this" :/ Writing the code is the trivial part.
          • danielbln 1y ago
            Writing code is the trivial part, yet it can be quite time consuming. I know what I want, so I don't want to care about the trivial minutae, same as I care very little what machine code falls out of my compiler. LLMs aren't capable yet to enable this easily and reliably, but they present a (often useful) glimpse.
    • otabdeveloper4 1y ago
      "Business analyst" is not a real job and problem domain analysis is done by software engineers in 100 percent of the workplaces I know.
  • corytheboyd 1y ago
    I agree, they are very much exaggerating both time spent writing code, as well as the amount of time LLMs shave off. LLM coding very much does NOT take “near zero time,” I would argue that sometimes it can take the same amount of time or longer, compared against simply knowing what you are doing, with tools you know how to use, referring to documentation you know how to interpret, understanding the systems around, the business around, what team A and C need in two quarters so we better keep it in mind… etc.
    • Snuggly73 1y ago
      I had the weirdest experience the other day. I wanted to write an Expo React Native application - something I have zero experience with (I’ve been writing code non-stop since I was a kid, starting with 6502 assembly). I’ve leaned heavily on Sonnet 3.7 and off we went. By the end of the day (10-ish hours) all I got to show was about 3 screens with few buttons each… Something a normal React developer probably would’ve spat out in about a hour. On top of that, I can’t remember shit about the application itself - and I can practically recite most of the codebases that I’ve spent time on. And here I read about people casually generating and erasing 20k lines of code. I dunno, I guess I am either holding it wrong, or most of the time developing software isn’t spent vomiting code.
      • Graphon1 1y ago
        Interesting. I had the exact opposite experience recently. I've also been writing code for a long time, did the 6502 assembly thing way back when, and lots since then. For this current project I wanted to build a web app with a frontend in Angular and a backend in Java 21 relying on javalin.io for the services layer. It had a few other integrations as well - into a remote service requiring OAuth and also into subtlecrypto. After less than 10 hours I had a fully functioning MVP that was far superior to anything I could have created without an assistant. It gave me build files, even a test skeleton. Restyling the UI or reflowing the UX to include confirmations, additional steps, modals, ... was really easy. I just had to type it, and those changes would get made. It felt like I was "director of development" for a day. I used Aider, plugged into Gemini 2.5.
  • jandrese 1y ago
    I have a feeling that people who got bogged down in step 3 were the kind of people who write a lot of wordy corporate boilerplate with multiple levels of abstraction for every single thing. AKA "best practices" type coding. For me the most important part of a project is working out the data structures and how they are accessed. That's where the rubber meets the road, and is something that AI struggles with. It requires a bit too high a level of abstract thinking and whole problem conceptualization for existing LLMs. Once the data structures are set the coding is easy.
    • exe34 1y ago
      same, the amount of work I have to put into thinking of what to say to the llm is the same or more work than just telling the compiler or interpreter what I want (in a language I'm familiar with), and the actual coding is the trivial part. in fact I get instant feedback with the code, which helps change my thinking. with the llm, there's an awkward translating for the llm, getting the code, checking that it might do what I want, and then still having to run it and find the bugs. the balance only shifts with a language/framework I'm not familiar with.
      • lherron 1y ago
        I agree for method-level changes, but the more you’re willing to cede control for larger changes, even in a familiar language, the more an LLM accelerates you. For me, I give Gemini the full context of my repo, tell it the sweeping changes I want to make, and let it do the zero to one planning step. Then I modify (mostly prune) the output and let Cursor get to work.
        • AdieuToLogic 1y ago
          > I agree for method-level changes, but the more you’re willing to cede control for larger changes, even in a familiar language, the more an LLM accelerates you. Another way to phrase this is: I agree for method-level changes, but the more you’re willing to cede *understanding* for larger changes, even in a familiar language, the more an LLM accelerates you *to an opaque change set*. Without understanding, the probability of a code generation tool introducing significant defects approaches 1.
  • alooPotato 1y ago
    I think you're overly painting that process as a waterfall method. In reality, i think its more of a loop. You do the loop a bunch of times and the solution gets better and better. The act of coding sometimes exposes a lot more of the requirement questions you didn't even know to ask in the first few steps. So anything that can let you iterate the loop faster is good. The analogy is kind of like if you can make your compile and tests faster, its way easier to code. Because you don't just code and test at the very end, you do it as part of a thinking loop.
    • skydhash 1y ago
      You can get a lot of stuff designed before having to start the loop, just like you can get the boilerplate code written (or use a framework), before writing any business logic. Writing code to find specs is brute-forcing the solution. Which is only useful when there's no answer or data (kinda rare in most domains). Taking some time to plan and do research can resolve a lot of inconsistency in your starting design. If you have written the code before, then you'll have to refactor even if the program is correct, because it will be a pain to maintain. In painting, even sketching is a lot of work. Which is why artists will collect references instead, mentally select the part they will extract. Once you start sketching, the end goal is always a final painting, even if you stop and redo midway. Actual prototyping is called a study and it's a separate activity.
    • walleeee 1y ago
      > So anything that can let you iterate the loop faster is good. I think the major objection is that you only want to automate real tedium, not valuable deliberation. Letting an llm drive too much of your development loop guarantees you don't discover the things you need to unless the model does by accident, and in that case it has still trained you to be a tiny bit lazier and stolen an insight you would have otherwise had yourself, so are you really better off?
      • alooPotato 1y ago
        This is a confusion that comes up often - 100% agree with chat-in-the-loop style interfaces. That slows me down way too much and its too hard to fix when it inevitably gets something wrong. I'm mostly talking about Cursor Tab - the souped up autocomplete. I think its the perfect interface, it monitors what I type and guesses my intention (multiline autocomplete, and guessing which line I'm going to next). It lets me easily parse if the LLM is heading in the right direction, in which case pressing tab speeds up the tedium. If its wrong, I just keep typing till it understands what I'm trying to do. It works really really well for me. I went back to using a non-LLM editor for a bit and I was shocked at how much I had become dependent on it. It was like having an editor that didn't understand types and didn't autocomplete function names. I guess if you're a purist and never used any IDE functionality, then this also wouldn't be for you. But for me, its so much better of an experience.
  • bufferoverflow 1y ago
    For many developers the first couple of items isn't a thing, we're just given requirements and the designs. At most, you can point out issues and do time estimates. For my current job coding is 90% of my time. The rest is meetings, deployments, ticket management. Most of the time coding isn't particularly hard, but it sure consumes lots of time. I've had many days with 1000+ line diffs.
    • sanderjd 1y ago
      How common is this, really? I've never had a job like this, since about my first year or so at the entry level.
      • sitzkrieg 1y ago
        over 15 yrs of embedded dev here and 1/2 is 90% the problem every project
      • oytis 1y ago
        Sounds like what people would do in a consultancy / project company. Or a conservative industry like automotive.
  • hdjjhhvvhga 1y ago
    > That last part is actually the easiest, and if you're spending inordinate amount of time there, that usually means the first two were not done well or you're not familiar with the tooling (language, library, IDE, test runner,...). I'm not sure if you're familiar with modern JS frameworks.
  • apwell23 1y ago
    > With Claude, that time cost has plummeted to nearly zero. not sure if anyone knows. how good would a bigquery-sql to scala parser generated code would be? can i use it without having to dig into generated code?
    • matthewsinclair 1y ago
      Now I am at a point with it where I’m watching just about every line of code it generates, at least to the extent that I’m reading it to ensure that it’s following the required patterns and not doing something crazy. I made the mistake of letting it go off on its own in the first few iterations before I realised just how crazy it could get if left unattended. Once I stopped doing that and held the yoke more frequently, I got much better results. It was generating far _less_ code but the code it generated was far _more_ useful. I think I threw away about 40% of the code it generated over the course of the exercise. Which is where the realisation came from that it is sometimes easier to just throw stuff away and start again with a better question than it is to try and iterate garbage into something that works.
      • apwell23 1y ago
        then why does everyone keep saying 'cost has plummeted to zero' . am i crazy or is this some emperor has no clothes type situation.
        • matthewsinclair 1y ago
          I think you might be misunderstanding what I’m saying, or I’m not being clear enough (apologies). The simple fact is that yes, I’m watching it, but it’s way faster at typing than me. So it’s often easier for me to tell it to just throw away a whole chunk of code and rewrite it than it would be for me to rewrite it on my own.
  • gen220 1y ago
    I'm somebody who used to think your way until very recently (long-time vim user, fast typer, etc.). I'd recommend you give `aider` specifically a try. It's slowly taken over more and more of the "what" and "how" buckets outlined in the article, especially for large-surface-area code bases. It turns out, for me at least, there is a big mental activation hurdle between "what" and "how". I need a lot of focus time to pivot between "what" and "how" efficiently, especially for work that spans large parts of the codebase, and work that I'm not super excited about doing. Using `aider` has lowered this activation threshold dramatically. It's made "writing code" about as simple as talking about a technical solution with an intelligent colleague. I usually follow the format (1) describe the context of the app / problem you're trying to solve (2) describe what you know the solution will look like (3) ask it for clarifying questions / if it needs any examples or context to know the problem space better, and if the solution makes sense / do they see any issues with it? (4) ask it to outline the solution in greater detail, do not write code (5) add any clarifications, now do the thing. i.e. it's kind of similar to interacting with a super fast, eager, indefatigable junior engineer. Sometimes it misses things or misunderstands, but not nearly enough to make the juice not worth the squeeze. These days, I'd say I spend more time reading/editing claude-generated code, writing commit messages, and managing deployments than I do writing code. It's a higher level of abstraction and I get way more leverage out of the deal. The code I'm writing is, on balance, better than the code I wrote before. It took maybe a few months to get here, but I'm happier for giving it a shot.
    • matthewsinclair 1y ago
      This more or less describes my experience exactly. There’s obviously going to be a range of views and experiences, but as someone who’s been writing code on and off for nearly 30 years, there’s definitely something in this, notwithstanding the obvious footguns, many of which have been faithfully called out here.
  • valenterry 1y ago
    > That last part is actually the easiest The last part is wrong, unless it's purely greenfield. Instead, you first need to read and then modify existing code and ensure it can later be still understood and easily/safely changed by whoever works on it. That is the hard part that is totally missed here.
    • jongjong 1y ago
      That's correct. Writing code isn't like building a house. It's not like you just add one brick on top of another and every brick you added stays in its place forever. It's much more complex. As requirements change, you may have to pull out some bricks, sometimes redo entire floors. I've worked with low-code platforms and also built my own low-code platform which allows me to assemble CRUD apps quickly and avoid/bypass a huge range of possible bugs, but even then, it's still not quite like laying bricks... What happens is that the bottleneck becomes UX decision-fatigue. Translating complex business requirements into a working product is rife with conflicts at the level of requirements engineering and UX. You can attain a certain level of software complexity much faster but the requirements also evolve faster to the point where you're constantly thinking about how to make different parts of the UX work well together in a way that's not confusing.
  • raducu 1y ago
    > With Claude, that time cost has plummeted to nearly zero Only for short code you want to throw away. If you care about the quality of the code -- how it is organized, naming things, meaningful tests it's not. LLMs have gotten so much better at code that I'm surprised I still don't vibe code, but it's just laughable at how bad they are stil -- test cases that just add fluff and just how "autistic" they seem and how much they miss in context that a human would not miss. I recently changed some code where a null was returned previously and what I really needed was sort of a java Optional but with a Reason for why the value returned was not present -- I called it AdviseDecision -- it had 2 constructors -- either the value returned or the reason a value could not be computed. I then asked Gemini 2.5 to refactor a piece of code that dealt with the null previously. Gemini 2.5 could not jump to the conclusion that it was not possible for both the computation result or the failure to compute could not be null at the same time. Anyway, the examples of when LLMs fail are becoming the exception and it shows how good they have gotten, but I would never says cost time plummeted to nearly zero. For me the biggest advantage is that even though I only get about a 30% programming speed boost, I get a 300% productivity boost because I procrastinate much less, because for me it's easier to fix/modify the LLMs tasteless code than getting over the initial bump of starting from scratch. It probably is a contradiction then that I say LLMs are so bad and so good at the same time.
  • marginalia_nu 1y ago
    I expect this is fairly domain dependent. Not all programming is CRUD endpoints, some of it is genuinely finicky. At least for me, one example of such programming is low-level database adjacent systems programming, it can take an extreme amount of fiddling to get it to work as you intended, even if you have a clear idea of what you want to implement. Though, in the cases where the last part is hard and time consuming, LLM-based tools are not going to be of particularly big help (and in fact, is personally where I tend to disable CoPilot because it is more likely to be a distraction than useful).
  • netdevphoenix 1y ago
    > Traditionally, coding involves three distinct “time buckets”: > Why am I doing this? Understanding the business problem and value > What do I need to do? Designing the solution conceptually > How am I going to do it? Actually writing the code This is why when people call programmers coders it feels wrong imo
  • intelVISA 1y ago
    The final piece (writing code) eating more than 10% of your dev time "for decades" is a good indicator to find a new career imo.
    • osigurdson 1y ago
      Writing code is design, not mere assembly. I can only imagine the kind of solutions created by someone who whiteboards for 7 hours a day and codes for one.
  • sdeframond 1y ago
    > I spent more time understanding the problem than writing code. This. Yet more often than I would like the challenge is not understanding the business side of the side problem but dealing with the existing code... Overall I find that each one of the three time buckets are equally important and I strive to iterate quickly between them. Pretty often the existing code somehow challenges the assumptions I made in the two previous steps, both business-wise and design-wise.
  • trollbridge 1y ago
    I'll second this. The last part is the easiest and the one I spend the least around of time on. If someone thinks the last part is the most difficult, then they probably aren't an actual programmer.
  • codelion 1y ago
    I think you've nailed the key point. A lot of "coding" isn't actually writing code, but understanding the problem space and designing a good solution. If I'm spending too long wrestling with the implementation, it's usually a sign that I didn't fully grasp the problem upfront or my design is flawed. Good tooling helps, for sure, but it's no substitute for solid problem analysis.
  • bgwalter 1y ago
    [Replying to the quoted part.] So when it is convenient, the waterfall model is suddenly modern again? The waterfall model didn't work, because many inefficiencies and wrong assumptions are found when writing code. This is also the advantage of Lisp and other languages that are malleable and not like a block of concrete. LLMs are like a block of concrete in that they spit out the same (plagiarized) solutions over and over again. They remove you from the code, they impede flow state due to the constant interactions and outsource your thinking to some GPUs in California. This waterfall rationalization is just one of the latest absurdities in the LLM blogging industrial complex.
    • hedora 1y ago
      I watched extreme programming, and then agile morph into "waterfall, but on a one week cycle!" (For extreme programming, two weeks for agile.) "Modern" software development is based on the idea that waterfall doesn't work, but that you can fix it by only allowing projects that take either one week (dot com boom) or two weeks (web 2.0 boom). Personally, I avoid all this stuff as much as possible, since I've never seen any of it work. I have had good luck with LLMs, for what it's worth. I've found for step 4, writing an informal spec at the top of the source file works well: // $ curl https://api.com/foo/bar?baz // { json: "response", goes: "here" } along with instructions like "implement the interface defined in some other file", and "look at some other existing file for guidance" works well, as does "implement some trivial data structure from scratch". Then I have to read what it wrote and fix the inevitable 2-3 bugs + compilation errors. It usually gets the boilerplate right, but misunderstands fundamental things. This maybe saves me 50% of coding time, since my first draft usually has bugs + doesn't compile on the first attempt either. This really shines in step 5 (not listed above): Writing tests. I generally end up with more thorough tests than I'd write from scratch in maybe 20% of the time. Anyway, LLM's let me get about 10-20% more done per week. Most time is still spent designing stuff and evaluating solutions. The above workflow doesn't work for non-trivial modules. It just saves time on boilerplate. It's plagiarism the same way IDE auto-complete and copy / paste (from the same codebase) are.
    • ebiester 1y ago
      So, while I've written about it before (see https://www.ebiester.com/agile/2023/04/22/what-agile-alternative.html https://www.ebiester.com/agile/2023/04/22/what-agile-alterna... ), all methodologies are based on the constraints of the time. Consider that The Pragmatic Programmer (and Andrew Hunt and Dave Thomas are original signatories to the manifesto) suggested in Pragmatic Programmer, “Build One to Throw Away (You will anyway)” And Fred Brooks said the same thing in the Mythical Man Month. The new constraint is that we can build a prototype much quicker for user testing. If it takes a week to build a trash version to throw away by vibe coding, you should build the trash version and get it in front of users to try out. Then, you can throw it away or do it again. If you can hammer out a prototype in 2 days (or two or three even) then that's pretty agile. If I can hammer out that prototype apart from the larger system, even better, because the cost of that prototype is cheap. And so I can totally choose to build it in larger chunks. I can think of an 18 month project - with a team - back in the day that I could bang out today in a prototype in a month. And I could have gotten it into the customer's hands screen by screen rather than a slow increment every two weeks. (This was an agile project.) I could have built a mock server with mock data. Some of the project would have taken just as long, but that would have been a hell of a lot more agile. And this project needed 20% novel solution and 80% best practices. Like most software.
  • damnever 1y ago
    I can imagine that those who prefer a hands-on approach might spend more time understanding the problem, as they need to read through the code and debug to identify what is wrong.
• ivape 1y ago
  If we go with this analogy, we don't have advanced mech suits yet for this. To think an IDE is going to be the "visor", and to think copy-and-pasting is going to be jury-rigged weapons on the Mech is probably not it. The future really needs to be Jarvis and that Iron Man suit, whatever the programming equivalent is. "Hey I need a quick UI for a storefront", can be done with voice. I got pretty far with just doing this, but given my experience I don't feel fully comfortable in building the mech-suit yet because I still want to do things by hand. Think about how wonky you would feel inside of a Mech, trying to acclimate your mind to the reality that your hand movements are in unity with the mech's arm movements. Going to need a leap of faith here to trust the Mech. We've already started attacking the future by mocking it as "vibe coding". Calling it a "Mech" is so much more inspiring, and probably the truth. If I say it, I should see it. Complete instant feedback, like pen to paper.
  • Tijdreiziger 1y ago
    > We've already started attacking the future by mocking it as "vibe coding". The term ‘vibe coding’ was coined by OpenAI’s co-founder. https://x.com/karpathy/status/1886192184808149383 https://x.com/karpathy/status/1886192184808149383
    • throwaway314155 1y ago
      It's pretty clearly outgrown its original definition, as often happens with this sort of "urban dictionary"/term-of-art type of phrase.
  • codr7 1y ago
    Copy/paste coding isn't exactly a new idea, it just got a lot easier and more popular.
• scrlk 1y ago
  > The developers who thrive in this new environment won’t be those who fear or resist AI tools, but those who master them—who understand both their extraordinary potential and their very real limitations. They’ll recognise that the goal isn’t to remove humans from the equation but to enhance what humans can accomplish. I feel like LLMs are just the next step on the Jobs analogy of "computers are bicycles for the mind" [0]. And if these tools are powerful bicycles available to everyone, what happens competitively? It reminds me of a Substack post I read recently: > If everyone has AI, then competitively no one has AI, because that means you are what drives the differences. What happens if you and LeBron start juicing? Do you both get as strong? Can you inject your way to Steph’s jumpshot? What’s the differentiator? This answer is inescapable in any contested domain. The unconventionally gifted will always be ascendant, and any device that’s available to everyone manifests in pronounced power laws in their favor. The strong get stronger. The fast get faster. Disproportionately so. [1] [0] https://youtu.be/ob_GX50Za6c?t=25 https://youtu.be/ob_GX50Za6c?t=25 [1] https://thedosagemakesitso.substack.com/p/trashbags-of-facts-and-insipid-oceans https://thedosagemakesitso.substack.com/p/trashbags-of-facts...
  • iugtmkbdfil834 1y ago
    I don't think bicycle analogy is adequate. It seems that they are more like cars. And if we follow that analogy, it suggests that the direction of the evolution will depend on whether we make our society dependent on being able to drive cars and grow fat from lack of activity or use them in a more mindful 'for purpose intended' way.
  • jrk 1y ago
    Simon Willison nailed exactly this 2 years ago: > I've been thinking about generative AI tools as "bicycles for the mind" (to borrow an old Steve Jobs line), but I think "electric bicycles for the mind" might be more appropriate. > They can accelerate your natural abilities, you have to learn how to use them, they can give you a significant boost that some people might feel is a bit of a cheat, and they're also quite dangerous if you're not careful with them! https://simonwillison.net/2023/Feb/13/ebikes/ https://simonwillison.net/2023/Feb/13/ebikes/
• bionhoward 1y ago
  sounds great as long as you don’t make any product or service that competes with Claude. Can anyone name something in that category?
• ttul 1y ago
  I started my career as a developer in the 1990s and cut my teeth in C++, moving on to Python, Perl, Java, etc. in the early-2000s. Then I did management roles for about 20 years and was no longer working at the “coal face” despite having learned some solid software engineering discipline in my early days. As an old geezer, I appreciate very much how LLMs enable me skip the steep part of the learning curve you have to scale to get into any unfamiliar language or framework. For instance, LLMs enabled me to get up to speed on using Pandas for data analysis. Pandas is very tough to get used to unless you emerged from the primordial swamp of data science along with it. So much of programming is just learning a new API or framework. LLMs absolutely excel at helping you understand how to apply concept X to framework Y. And this is what makes them useful. Each new LLM release makes things substantially better, which makes me substantially more productive, unearthing software engineering talent that was long ago buried in the accumulating dust pile of language and framework changes. To new devs, I highly encourage focusing on the big picture software engineering skills. Learn how to think about problems and what a good solution looks like. And use the LLM to help you achieve that focus.
  • luckylion 1y ago
    > So much of programming is just learning a new API or framework. Once you're good at it in general. I recently witnessed what happens when a junior developer just uses AI for everything, and I found it worse than if a non-developer used AI: at least they wouldn't confuse the model with their half-understood ideas and wouldn't think they could "just write some glue code", break things in the process, and then confidently state they solved the problem by adding some jargon they've picked up. It feels more like an excavator: useful in the right hands, dangerous in the wrong hands. (I'd say excavators are super useful and extremely dangerous, I think AI is not as extreme in either direction)
    • alabastervlog 1y ago
      It used to (pre-'08 or so) be possible to be "good at Google". Most people were not. Most tech people were not, even. Using LLMs feels a ton like working with Google back then, to me. I would therefore expect most people to be pretty bad at it. (it didn't stop being possible to be "good at Google" because Google Search improved and made everyone good at Google, incidentally—it's because they tuned it to make being "bad at Google" somewhat better, but eliminated much of the behavior that made it possible to be "good at Google" in the process)
• bcrosby95 1y ago
  This may depend upon every individual, but for me "How am I going to do it" is not actually writing code. It's about knowing how I'm going to do it before I write the code. After that point, its an exercise in typing speed. If I'm not 100% sure something will work, then I'll still just code it. If it doesn't work, I can throw it away and update my mental model and set out on a new typing adventure.
  • codr7 1y ago
    And the only way to be 100% sure is to have written exactly the same thing before, which makes zero sense.
    • Hyperlisk 1y ago
      That's not true. I just wrote a similar comment about design coming first. If you've written software for awhile you just know what it looks like and which design patterns will be useful. Then when you see what your LLM says is the right code you can glance at it and see if it is even on the right track. If you're trying to LLM your way to a new social site you're going to need to know what entities make up that site and the relationships they have ahead of time. If you have no concept of an idea then of course the LLM will be "correct" because there were no requirements! Software design is important today and will be even more important in the future. Many companies do not require design docs for changes and I think it is a misstep. Software design is a skill that needs to be maintained.
• strict9 1y ago
  A lot of good points here which I agree with. Another way to think about it is SWE agents. About a year ago Devin was billed as a dev replacement, with the now common reaction that it's over for SWEs and it's no longer a useful to learn software engineering. A year later there have been large amounts of layoffs that impacted sw devs. There have also been a lot of fluff statements attributing layoffs to increased efficiency as a result of AI adoption. But is there a link? I have my doubts and think it's more related to interest rates and the business cycle. I've also yet to see any AI solutions that negate the need for developers. Only promises from CEOs and investors. However, I have seen how powerful it can be in the hands of people that know how to leverage it. I guess time will tell. In my experience the current trajectory is LLMs making tasks easier and more efficient for people. And hypefluencers, investors, CEOs, and others will continue promising that just around the corner is a future in which human software developers are obsolete.
  • apwell23 1y ago
    ceos found AI as escape hatch for their over hiring during pandemic boom year. they were just playing to this market reaction layoffs = bad layoffs because of AI = good
    • namaria 1y ago
      Yup. Also I am excited for the bump in my rates when the cycle inverts and there's a dearth of people who can code without the then defunct LLMs.
  • throw1235435 1y ago
    On my side we've refrained from hiring people/training people due to AI. Its mostly been a good decision especially at the frontend layer where those teams are starting to do more with less. Don't get me wrong - I don't like the path the SWE profession is going and I'm not an AI fan for a variety of reasons. But at the same time I don't want to over hire and have no work for the people to do (i.e. the bottleneck being business ideas, regulation, ability to iterate in our domain, etc rather than tech). I can't just "work faster" and "ship more" - you start hitting other bottlenecks. Over hiring is not a great problem to manage either; morale at the very least decreases as people have no work to do. The people in those bottlenecks anecdotally are seeing pay increases btw which goes to show - the inefficient get the spoils.
• antirez 1y ago
  I agree that AI powered programming can give you a boost, and the points made in the post I would agree with if they were not made about Claude Code or other "agentic" coding tools. The human-LLM boosting interaction exists particularly when you use the LLM in its chat form, where you inspect and reshape with both editing the code and explaining with words what the LLM produced, and where (this is my golden rule) you can only move code from the LLM environment to your environment after inspecting and manually cut & pasting stuff. Claude Code and other similar systems have a different goal: to allow somebody to create a project without much coding at all, and the direction is to mostly observe more the result itself of the code, that how it is written and the design decisions. This is fine with me, I don't tell people what to do, and many people can't code, and with systems like that they can build a certain degree of systems. But: I believe that tody, 21 April 2025 (tomorrow it may change) the human+LLM strict collaboration on the code, where the LLM is mostly a tool, is what produces the best results possible, assuming the human is a good coder. So I would say there are three categories of programmers: 1. Programmers that just want to prompt, using AI agents to write the code. 2. Programmers, like me, that use LLM as tools, writing code by hand, letting the LLM write some code too, inspecting it, incorporating what makes sense, using the LLM to explore the frontier of programming and math topics that are relevant to the task at hand, to write better code. 3. Programmers that refuse to use AI. I believe that today category "2" is what has a real advantage over the other two. If you are interested in this perspective, a longer form of this comment is contained in this video in my YouTube channel. Enable the English subtitles if you can't understand Italian. https://www.youtube.com/watch?v=N5pX2T72-hM https://www.youtube.com/watch?v=N5pX2T72-hM
  • Hyperlisk 1y ago
    This is my experience as well. I've been skeptical for a long time, but recent releases have changed my mind (it's important to try new things even if skeptical). Large context windows are game-changers. I can't copy/paste fast enough. The future is coming, but you still need fundamentals to make sure the generated code has been properly setup for growth. That means you need to know what you expect your codebase to look like before or during your prompting so you can promote the right design patterns and direct the generation towards the proper architecture. So software design is not going away. Or it shouldn't for software that expects to grow.
• Workaccount2 1y ago
  I question how much code and what kind of code is actually going to be needed when the world is composed entirely of junior engineers who can write 100 LOC a second? Will it just be these functional cores that are the product, and users will just use an LLM to mediate all interaction with it? The most complex stuff, the actual product, will be written by those skilled in mech suits, but what will it look like when it is written for a world where everyone else has a mech suit (albeit less capable) on too? Think like your mother running a headless linux install with an LLM layer on top, and it being the least frustrating and most enjoyable computing experience she has ever had. I'm sure some are already thinking like this, and really it represents a massive paradigm shift in how software is written on the whole (and will ironically resemble the early days of programming).
  • daxfohl 1y ago
    I doubt it will come to that. Most interactions are always going to be much easier with a dedicated UI than with a chatbot. In fact, I can't think of anything I use regularly that I'd rather replace the UI with chat.
    • istjohn 1y ago
      The UI will be a thin, flexible facade over a chatbot.
• otabdeveloper4 1y ago
  More a halloween costume than mech suit. Like a toy policeman costume so you can pretend you have authority and you know what you're doing.
• deleted 1y ago
  [deleted]
• sebastiennight 1y ago
  In the current state of things, it's maybe more of a Justin Hammer mech suit than a Tony Stark mech suit.
• marstall 1y ago
  guessing the introduction of the mech suit reduced headcount on the loading deck ...
• sheepscreek 1y ago
  Yep. It’s the ultimate one person team. With the human playing the role of a team lead AND manager. Sometimes even the PM. You want to earn big bucks? Well, this is the way now. Or earn little bucks and lead a small but content life. Choice is yours.
  • akra 1y ago
    Agree with most of what you said except for the "big bucks" part. Why would I pay for your product when I can ask the AI to do it? To be honest I think I would rather use that money for anything else if I can spend a little bit of time and get the AI to do it. This is quite deflationary for programming in general and inflationary for domains not disrupted all else being equal. There's a point where Jevon's Paradox fails - after all there's only so much software most normal people want and at that point tech workers value relative to other sectors will decline assuming unequal disruption. The ability to earn the big bucks as you state is not a function of the value delivered/produced, but the scarcity and difficulty in acquiring said value. That is capitalism. An extreme example is clear air that we breathe - it is currently free, but extremely valuable to most living things. If we made it scarce (e.g. pollution) eventually people would start charging for it; potentially at extortionary prices depending on how rare it becomes. The only exception I see is if the software encodes a domain that isn't as accessible to people and is kept secret/under wraps, has natural protections (e.g. a government system that is mandatory to use), or is complex and still requires co-ordination and understanding. This does happen, but then I would argue the value is in the adjacent domain knowledge - not in the software itself.
    • miklosz 1y ago
      In fact, in many spa towns you have already local taxes, e.g. "climate surcharge" where you actually pay as a tourist for the clean air. Usually it's a local tax that is added on top of your hotel bill.
• gyrovagueGeist 1y ago
  How many people still play centaur chess?
• Aperocky 1y ago
  > Experience Still Matters My personal opinion is that now experience matters a lot more. A lot of times, the subtle mistakes that LLM makes or wrong direction that it takes can only be corrected by experience. LLM also don't tend to question its own decisions in the past, and will stick with them unless explicitly told. This means LLM based project accumulate subtle bugs unless there is a human in the loop who can rip them out, and once a project accumulated enough subtle bugs it generally becomes unrecoverable spaghetti.
  • diggan 1y ago
    > LLM also don't tend to question its own decisions in the past, and will stick with them unless explicitly told. Dangerous as well, is that LLMs won't (unless aggressively prompted to) question your own decisions either, in contrast to something like a mentor which would help you discover a better way, if there is one.
    • Aperocky 1y ago
      That part didn't change with or without LLMs though. At least LLM is one more set of eye on my own decisions.
    • warkdarrior 1y ago
      I've never seen anyone claim that coding LLMs are mentors, but rather junior devs there to help you. Taking them as mentors changes the task completely. LLM-as-junior-dev definitely requires you to know what you want the code to do and what you expect as quality output.
  • onefreecomputer 1y ago
    [dead]
  • MetaWhirledPeas 1y ago
    > LLM also don't tend to question its own decisions in the past An attribute I would like to see is the ability for an LLM to express justified self-doubt. Likewise (and perhaps directly related) would be the ability to self-critique prior to providing an answer. It's possible they are already steered to do this; if so I would like to see more of that dialogue surfaced to the user.
• pjmlp 1y ago
  Keep believing it is augmentation. The end game is outsourcing, instead of team mates doing the actual programing from the other side of the planet, it will be from inside the computer. Sure the LLMs and Agents are rather limited today, just like optimizating compilers were still a far dream in the 1960's.
  • sly010 1y ago
    And just like optimizing compilers LLMs also emit code that is difficult to verify and no-one really understands, so when the shit hits the fan you have no idea what's going on.
    • Aperocky 1y ago
      Is it though? Most code that LLM emits are easier to understand than equivalent code by humans in my experience, helped by overt amount of comment added at every single step. That's not to say the output is correct, there are usually bugs and unnecessary stuff if the logic generated isn't trivial, but reading it isn't the biggest hurdle. I think you are referring to the situation where people just don't read the code generated at all.. in that case it's not really LLM's fault.
      • bluefirebrand 1y ago
        > Most code that LLM emits are easier to understand than equivalent code by humans in my experience Even if this were true, which I strongly disagree with, it actually doesn't matter if the code is easier to understand > I think you are referring to the situation where people just don't read the code generated at all.. in that case it's not really LLM's fault It may not be the LLM's "fault", but the LLM has enabled this behavior and therefore the LLM is the root cause of the problem
  • gregMN 1y ago
    [dead]
  • deleted 1y ago
    [deleted]
• alganet 1y ago
  Expectation: mech suit with developer inside. Reality: a saddle on the developer's back. They really want a faster horse.
• submeta 1y ago
  > How LLM-powered programming tools amplify developer capabilities rather than replace them This is my experience as well. You have to know what you want, how to interfere if things go in the wrong direction, and what to do with the result as well. What I did years ago with a team of 3-5 developers I can do now alone using Claude Code or Cursor. But I need to write a PRD, break it down into features, epics and user stories, let the llm write code, review the results. Vibe coding tools feel like half a dozen junior to mid level developers for a fraction of the cost.
• causal 1y ago
  The article is correct about the current state of using LLMs, but I didn't see an explanation WHY they are like this; just more "how". I'm curious about the fundamental reason why LLMs and their agents struggle with executive function over time.
  • namaria 1y ago
    Theoretical limitations of multi-layer Transformer https://arxiv.org/abs/2412.02975 https://arxiv.org/abs/2412.02975 On Limitations of the Transformer Architecture https://arxiv.org/abs/2402.08164 https://arxiv.org/abs/2402.08164 Limits of Deep Learning: Sequence Modeling through the Lens of Complexity Theory https://arxiv.org/abs/2405.16674 https://arxiv.org/abs/2405.16674 TL;DR transformers are inherently limited with tasks requiring composition of sequential steps
• dist-epoch 1y ago
  > Chess provides a useful parallel here. “Centaur chess” pairs humans with AI chess engines, creating teams that outperform both solo humans and solo AI systems playing on their own. What’s fascinating is that even when AI chess engines can easily defeat grandmasters, the human-AI combination still produces superior results to the AI alone. The human provides strategic direction and creative problem-solving; the machine offers computational power and tactical precision. Can we stop saying this? It hasn't been true for more than 15 years.
  • Der_Einzige 1y ago
    Yup! Anyone who is in AI right now and didn't follow the chess engine world from 15 years ago is basically a fraud. Centaurs are WORSE than chess engine alone for literally at least 15 years now. We had all the same shit that's going on with LLM labs. Benchmarks with elo scores, leading model providers cheating (Rybka), big companies jumping in (DeepBlue), even a fucking equivalent to RAG (pre-made opening books) and I guess an analogy to prompt optimization (end game tablebases?) It's all a repeat of shit I saw in 2009.
• yobananaboy 1y ago
  https://web.archive.org/web/20250421182808/https://matthewsinclair.com/blog/0178-why-llm-powered-programming-is-more-mech-suit-than-artificial-human https://web.archive.org/web/20250421182808/https://matthewsi... Site got hugged
• AlexCoventry 1y ago
  Archive.org link (site is down, for me.) https://web.archive.org/web/20250421152532/https://matthewsinclair.com/blog/0178-why-llm-powered-programming-is-more-mech-suit-than-artificial-human https://web.archive.org/web/20250421152532/https://matthewsi...
• gigel82 1y ago
  When working in mature codebases and coordinating across teams, I'd say the time I spend "coding" is less than 5%. I do use GitHub Copilot to make coding faster, and sometimes to shoot ideas around for debugging, but overall its impact on my productivity has been in the lower single digits. I'm wondering if I'm "holding it wrong", or all of these anecdotes of 10x productivity are coming from folks building prototypes or simple tools for a living.
  • throwawayb299 1y ago
    Have you considered, you may be working in a dysfunctional organization, spending only 5% on the activity that translates into actual value to the end user? That's why these AI companies are racing to build a replacement for you and me, something that will spend 100% of its time actually building out functionality the customer is looking forward to. I know, I know, spending 100% of our day coding is ridiculous because that all-hands conference call to get everyone onboard with which microservice is responsible for storing button colors absolutely has to happen first.
    • bluefirebrand 1y ago
      > spending only 5% on the activity that translates into actual value to the end user You must be a junior coder if you think that typing the code into the computer is the activity that should take up most of your time Writing code is the last step, the shortest step, and the easiest step of building software
      • throwawayb299 1y ago
        20 years and counting. Maybe you're the person at the middle point of that bell curve meme, while I'm the one to the right? I used to drink the kool aid too: writing code is the last step, the shortest and the easiest one... Over time I came to believe, this is what people in dysfunctional organizations say to justify endless political back and forth over painfully trivial matters and constant turf wars. Anyone speaking up about it is of course getting shamed as inexperienced or incompetent. It's no surprise, people who are holding these bullshit jobs have their livelihood on the line if the bullshit gets called out. By the way, I'm not saying there's no need to plan things out at least just a little bit or that communication does not come with a certain overhead. Not 95% though, not even anything close to that. Especially if you aren't breaking any new grounds, which the overwhelming majority of devs aren't. No, a LOB reporting app on microservices is not it. No, another AI-enabled social network on blockchain is not it either. Coding isn't the shortest step either, go ahead have a look into a serious codebase such as Chromium then come back and tell me with a straight face developing that codebase was the shortest step.
• nopinsight 1y ago
  One way to think of this is as the Baumol effect* within software development. Expert humans are still quite a bit better than LLMs at nuanced requirements understanding and architectural design for now. Actual coding will increasingly become a smaller and cheaper part of the process, while the parts where human input cannot be reduced as much will take up a larger proportion of time and cost. * Not everything here applies, but many will be. https://en.m.wikipedia.org/wiki/Baumol_effect https://en.m.wikipedia.org/wiki/Baumol_effect
  • nopinsight 1y ago
    The SWE-bench verified score for frontier LLMs will probably reach/surpass 90% by the end of the year. Agentic AI will learn to complete a larger and larger chunk of the practical software development process without much human input.
• meander_water 1y ago
  There's one point missing here - the speed at which code can be generated and code can be read and understood. You can't skim/speed read code. You may be able to generate an entire codebase in minutes, but it takes significantly longer than that to work within a large codebase to understand it's intricacies to be able to refactor it and add new features. This is why you see vibe coded codebase with tons of dead code, inefficient/unsafe use of functions etc. I think when you're working with LLMs the temptation is to go as fast as it allows, but this is a trap.
• rpmisms 1y ago
  I'm not great at actually writing code. I am a damn good software architect, though. Being able to pseudocode and make real code out of it has been amazing for me. It takes a lot of the friction out of writing really nice code. I love working in Ruby and Perl, but now I can write pseudo-Ruby and get excellent JS out of my input.
• m3kw9 1y ago
  Except if you few shot todo streak exercise apps apps and calories counters.
• api 1y ago
  That’s been my experience too. It’s like super autocomplete. Good for unit tests and boilerplate, but it does not do high level reasoning for you. It also can’t do the all important thing: telling you what to build.
• yuweiloopy2 1y ago
  [dead]
• interpol_p 1y ago
  > Why am I doing this? Understanding the business problem and value > What do I need to do? Designing the solution conceptually > How am I going to do it? Actually writing the code This article claims that LLMs accelerate the last step in the above process, but that is not how I have been using them. Writing the code is not a huge time sink — and sometimes LLMs write it. But in my experience, LLMs have assisted partially with all three areas of development outlined in the article. For me, I often dump a lot of context into Claude or ChatGPT and ask "what are some potential refactorings of this codebase if I want to add feature X + here are the requirements." This leads to a back-and-forth session where I get some inspiration about possible ways to implement a large scale change to introduce a feature that may be tricky to fit into an existing architecture. The LLM here serves as a notepad or sketchbook of ideas, one that can quickly read existing API that I may have written a decade ago. I also often use LLMs at the very start to identify problems and come up with feature ideas. Something like "I would really like to do X in my product, but here's a screenshot of my UI and I'm at a bit of a loss for how to do this without redesigning from scratch. Can you think of intuitive ways to integrate this? Or are there other things I am not thinking of that may solve the same problem." The times when I get LLMs to write code are the times when the problem is tightly defined and it is an insular component. When I let LLMs introduce changes into an existing, complex system, no matter how much context I give, I always end up having to go in and fix things by hand (with the risk that something I don't understand slips through).
  • jes5199 1y ago
    yeah he's really underselling the recent models' ability to do the "Designing the solution conceptually" part. I still have to be in dialogue with the AI - I ask a lot of questions, we iterate towards something - but I cover conceptual ground much more quickly this way. and then I still have to be the glue between "design" and "writing" steps, and have to manage that carefully or I get slop. if you look at the change in capability over time, it looks like the AI are climbing this hierarchy. "Centaur" seems to already be giving way towards "research assistant". I hesitate to make predictions but I would not place money on things stabilizing here.
    • 1y ago
• throwawayb299 1y ago
  [flagged]
• deleted 1y ago
  [deleted]
• xbmcuser 1y ago
  The biggest problem I have with all these articles about what LLM are and are not is that LLM are still improving rapidly 1000s if not 100000s are working on doing that. As LLM pass a new threshold we get another round denial, anger, bargaining, depression, and acceptance from another group of writers.
• therebase 1y ago
  I call BS. The way it is set up now akins to digital dementia. https://dev.to/sebs/agentic-dementia-5hdc https://dev.to/sebs/agentic-dementia-5hdc
• crvdgc 1y ago
  > The Centaur Effect > even when AI chess engines can easily defeat grandmasters, the human-AI combination still produces superior results to the AI alone. Is this still the case? I didn't find a conclusive answer, but intuitively it's hard to believe. With limitless resources, AI can perform exhaustive search and is thus not possible to lose. Even with resource limits, something like AlphaZero can be very strong. Would AlphaZero+human beat pure AlphaZero?
  • jaccola 1y ago
    Doesn't seem true to me either, but AI can absolutely not perform an exhaustive search of the game space, there are far too many possibilities.
    • crvdgc 1y ago
      Thank you for pointing this out. Apparently I underestimated exponential growth rate.
  • rgoulter 1y ago
    With chess, there are some pathological cases where humans outperform the computers. I recall seeing an example where the position was almost completely deadlocked. With the weaker engines that run on browsers, you'll still catch cases where GMs have a good understanding of the position, and it takes the engine some time before the engine's understanding catches up. -- e.g. the GM will be explaining "this position is good", but the computer eval shows +1 before then climbing to +5 after some time. Similarly, I recall a popular technique in videos where GMs play cheaters is for the GM to then adopt a solid, defensive structure. The engines then just shuffle pieces around. (Again, I suspect that's with the weaker engines running on the computer). Though, some of the "engine vs engine" games I've seen have involved wild and inhuman play. -- In those cases, that's where I'd doubt humans would be of much help. I don't think AlphaZero+human would beat standalone AlphaZero.
• _ink_ 1y ago
  First it was Dev. Than it was DevOps. Soon it'll be DevOpsManQa.
• th0ma5 1y ago
  I've tried every way I can think of to get an LLM to generate valid code to do this, but everything seems to require manual intervention. I've tried giving it explicit examples, I've tried begging, I've tried bribing, and I've tried agreeing on the prompt first, and there doesn't seem to be a way for me to get valid code out for this simple idea from any of Claude, Gemini, Chat GPT, etc. > Write a concise Python function `generate_scale(root: int, scale_type: str) -> list[int]` that returns a list of MIDI note numbers (0-127 inclusive) for the given `root` note and `scale_type` ("major", "minor", or "major7"). The function should generate all notes of the specified scale across all octaves, and finally filter the results to include only notes within the valid MIDI range. ... So I typed all of the above in and it basically said don't ever try to use an LLM for this, it doesn't know anything about music and is especially tripped up by it. And then it gave me an example that should actually work and then didn't. It's wild because it gets the actual scale patterns correct.
• Meneth 1y ago
  Anything that amplifies a worker's speed will cause some layoffs if the amount of work needed doesn't change.
• mohsen1 1y ago
  I’ve had the opposite experience from some of the skepticism in this thread—I’ve been massively productive with LLMs. But the key is not jumping straight into code generation. Instead, I use LLMs for high-level thinking first: writing detailed system design documents, reasoning about architecture, and even planning out entire features as a series of smaller tasks. I ask the LLM to break work down for me, suggest test plans, and help track step-by-step progress. This workflow has been a game changer. As for the argument that LLMs can’t deal with large codebases—I think that critique is a bit off. Frankly, humans can’t deal with large codebases in full either. We navigate them incrementally, build mental models, and work within scoped contexts. LLMs can do the same if you guide them: ask them to summarize the structure, explain modules, or narrow focus. Once scoped properly, the model can be incredibly effective at navigating and working within complex systems. So while there are still limitations, dismissing LLMs based on “context window size” misses the bigger picture. It’s not about dumping an entire codebase into the prompt—it’s about smart tooling, scoped interactions, and using the LLM as a thinking partner across the full dev lifecycle. Used this way, it’s been faster and more powerful than anything else I’ve tried.
  • throwup238 1y ago
    > But the key is not jumping straight into code generation. That's a bingo! My workflow is to attach my entire codebase (or just the src folder + auxiliary files like sql schemas) to a Gemini 2.5 pro chat and ask it to write an implementation plan in phases for whatever feature I need, along with a list of assumptions, types, function signatures, documentation, and tests. I then spend a few minutes iterating to make sure it uses the right libraries, patterns, and endpoints. I copy paste the plan into plan.md and instruct Cursor/Windsurf/Aider/etc to implement phase 1 of the plan, saving implementation notes to plan-notes.md (both markdown files are explicitly included in the context). Keep telling it to "continue" and "keep going with the next phase" as needed. The implementation notes keep the LLM "grounded" in each step and allows creating a new chat context when it grows too long or messes up, requiring a git reset. The alternative first step - when I'm working on an isolated module that doesn't need to know about the rest of the codebase but is otherwise quite complicated - is to have Gemini Deep Research write a report about how to implement that feature and feed that report into the planner. The other important part is what I call "self reflection." Give the plan or research report to an LLM and ask it about improvements, pitfalls, tradeoffs, etc. and incorporate that feedback back into the plan. It helps to mix them up, so i.e. Claude and GPT review a Gemini plan and vice versa.
• jillesvangurp 1y ago
  Like all tool improvements in software engineering do, LLMs simply increase the demand for software as fast as software engineers can step up to use the new capabilities provided by tools. This is not a closed world and it's nothing new. It's not like we're all going to sit on our hands now. Improvements in tools (like LLMs) enable individuals to do more and more complicated things. So the complexity of what is acceptable as a minimum simply goes up along wit that. And this will allow a wider group of individuals to start messing around with software. When the cost for something goes down, demand for that thing goes up. That fancy app that you never had time to build is now something that you are expected to ship. And that niche feature that wasn't really worth your time before, completely different story now that you can get that done in 30 minutes instead of 1 week. Individual software engineers will simply be expected to be able to do a lot more than they can do currently without LLMs. And somebody that understands what they are doing will have a better chance of delivering good results than somebody that just asks "build me a thingy conforming to my vague and naive musings/expectations that I just articulated in a brief sentence". You can waste a lot of time if you don't know your tools. That too is nothing new. In short everything changes and that will generate more work, not less.
  • scellus 1y ago
    Yes, price elasticity increases the demand for software work in total, including LLMs and humans. But to me at least, it is not clear that humans will increase their total amount of work as LLMs obviously do. Is it possible that LLM coding grows faster than the total, so that the human piece of cake actually shrinks?
• agentultra 1y ago
  I just like to know things and learn them. If I’m encountering a new framework I want to spend time learning it. Every problem I overcome on my own improves my skills. And I like that. GenAI takes that away. Makes me a passive observer. Tempts me to accept convenience with a mask of improved productivity. When, in the long term, it doesn’t do anything for me except rob me of my skills. The real productivity gains for me would come from better programming languages.
  • _heimdall 1y ago
    We've collectively spent decades trading almost anything in favor of convenience. LLMs will be the same, and AI if we get there. I'm of the opinion that we'd be a lot better off if convenience was a lot further down our priority list.
  • furyofantares 1y ago
    > GenAI takes that away. Not for me. Put me at a company with a codebase in technology Z and I can learn it MUCH faster than starting from the docs. I will still read the docs, but everything goes far, far faster if you start me out in an existing codebase. You can use GenAI the same way. Get a codebase that's doing a thing you're interested in immediately and dive right in. You do not HAVE to be tempted into being a passive observer, you can use it as a kickstart instead.
• deleted 1y ago
  [deleted]
• yieldcrv 1y ago
  Although I hear that the junior level market is in shambles, what I've seen so far is more demand for developers. (This isn't data driven, like maybe layoffs and headcounts aren't growing, my niche isn't having a problem at the moment) Basically a lot of projects that simply wouldn't have happened are now getting complex MVPs done by non-technical people, which gets them just enough buy-in to move it forward, and that's when they need developers.
• sdeframond 1y ago
  Questions: How far can you go with the free tiers? Do I need to invest much in order to develop a good feeling of what is possible and what is not? Also, if experience matters, how to help junior developers get the coding experience needed to master LLMs? While, as TFA says, this might not replace developers, it does seem like it will make things harder for unexperienced people. (Edit: typos)