6 ms·

> Traditionally, coding involves three distinct “time buckets”: > Why am I doing this? Understanding the business problem and value > What do I need to

> 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y ago
        You misread. Also, that tech has been around for decades.
    - gitremote 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y ago
    Or tech lead and senior engineer. Because they spend more time doing the first two than that last one.
    - Snuggly73 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y ago
    over 15 yrs of embedded dev here and 1/2 is 90% the problem every project
  - oytis 2y ago
    Sounds like what people would do in a consultancy / project company. Or a conservative industry like automotive.
hdjjhhvvhga 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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.

jstanley 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y ago
      You misread. Also, that tech has been around for decades.
  - gitremote 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y ago
  Or tech lead and senior engineer. Because they spend more time doing the first two than that last one.
  - Snuggly73 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y ago
  over 15 yrs of embedded dev here and 1/2 is 90% the problem every project
- oytis 2y ago
  Sounds like what people would do in a consultancy / project company. Or a conservative industry like automotive.

hdjjhhvvhga 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y ago

intelVISA 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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 2y 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.