3 ms·

The problem is that this approach is not sustainable. Errors compound. The cost to fix one issue might seem small at first, but over a stretch of time all these

The problem is that this approach is not sustainable. Errors compound. The cost to fix one issue might seem small at first, but over a stretch of time all these "oopsies" become architectural spaghetti that can only be fixed with a complete rewrite, which will certainly become more expensive than getting the code "organically" developed. The only way I see AI coding working in the long run is if we go back to a Waterfall/BDUF process and having actual engineering. Let engineers really own the architecture. Enforce that any new feature - no matter how small - to be specced out with complete sequence diagrams. Ensure that every new software package needs to be put on an UML component diagram for the team to review and see each addition interacts with the whole system, etc. If we do that, then we can just give all the documents to a coding agent and say "go ahead and implement this" with a minimal amount of confidence. But in doing this, I bet we will realize the following: - the "effort" has never been about writing code itself. The code is just the material manifest of all the thought that went to think over a solution into the problems that the product is attempting to solve. - we will likely be better off by using code generation tools (i.e, UML-to-code) and a "weak" LLM (than can run locally) than by playing the token lottery at the Anthropic Casino.

eithed 4mo ago
I mirror your thoughts. I think we'll end up with "perfect map" paradox = you cannot be vague or indecisive on what you want (and if you are then these decisions don't matter) and you're creating a 1:1 representation of what the code needs to be. I'd substitute "owner" for the team and in that sense the owner will not need to be human. We're at this state where Claude is great at doing the "middle" part of work, but it's crap at gathering requirements and verification of what it has done. I also don't see people caring about these aspects of software development as shown in the article
locknitpicker 4mo ago
> The problem is that this approach is not sustainable. Errors compound. The cost to fix one issue might seem small at first, but over a stretch of time all these "oopsies" become architectural spaghetti that can only be fixed with a complete rewrite, which will certainly become more expensive than getting the code "organically" developed. That's so far been called software development. All software developed by people suffers from this issue. Where exactly is the novelty? > The only way I see AI coding working in the long run is if we go back to a Waterfall/BDUF process and having actual engineering. Nonsense. The problem is exactly the same. With agents iterations are much faster, and this can mean things can get messier faster but can get in shape just as fast. Ironically, agents improve the quality of the deliverable as well. Approaches such as spec-driven development do a far better job delivering features up to spec than manual coding by flesh and blood developers. There's an awful lot of baseless scaremongering in your post. You make it sound like with AI assisted coding developers stopped paying any attention to quality.
- rglullis 4mo ago
  [dead]
- skydhash 4mo ago
  > All software developed by people suffers from this issue. And that’s pretty much where you are wrong. Take any long running open source project and you can see the craftsmanship that goes into it. It may not be perfect, but hacks are clearly marked as such.
  - locknitpicker 4mo ago
    > And that’s pretty much where you are wrong. Take any long running open source project and (...) I think you are demonstrating a clear lack of insight and experience in software development settings, including FLOSS projects. I can name you a dozen of fairly known FLOSS projects which are a big ball of mud. Just go to the likes of GitHub, check out the list of popular projects, and peek at their code. You will get a very mixed set of results.
- shakna 4mo ago
  > Where exactly is the novelty? The compounding speed. Your devs might reach a point where they have to rewrite and refactor, in a decade. Your LLM, with its higher throughput, may put you in that game breaking situation next week.
  - locknitpicker 4mo ago
    > The compounding speed. Your devs might reach a point where they have to rewrite and refactor, in a decade. I think that this is exactly why this scaremongering breaks down. If you believe the compounding speed is that greater, wouldn't you be compelled to accept that refactoring and cleaning things up is just as fast and effortless? I mean, you have a tool that writes software for you following your commands. If you are that concerned with maintainability then what can possibly compell you to not invest any effort in it?
    - 4mo ago

eithed 4mo ago

I mirror your thoughts. I think we'll end up with "perfect map" paradox = you cannot be vague or indecisive on what you want (and if you are then these decisions don't matter) and you're creating a 1:1 representation of what the code needs to be. I'd substitute "owner" for the team and in that sense the owner will not need to be human. We're at this state where Claude is great at doing the "middle" part of work, but it's crap at gathering requirements and verification of what it has done. I also don't see people caring about these aspects of software development as shown in the article

locknitpicker 4mo ago

> The problem is that this approach is not sustainable. Errors compound. The cost to fix one issue might seem small at first, but over a stretch of time all these "oopsies" become architectural spaghetti that can only be fixed with a complete rewrite, which will certainly become more expensive than getting the code "organically" developed. That's so far been called software development. All software developed by people suffers from this issue. Where exactly is the novelty? > The only way I see AI coding working in the long run is if we go back to a Waterfall/BDUF process and having actual engineering. Nonsense. The problem is exactly the same. With agents iterations are much faster, and this can mean things can get messier faster but can get in shape just as fast. Ironically, agents improve the quality of the deliverable as well. Approaches such as spec-driven development do a far better job delivering features up to spec than manual coding by flesh and blood developers. There's an awful lot of baseless scaremongering in your post. You make it sound like with AI assisted coding developers stopped paying any attention to quality.

rglullis 4mo ago
[dead]
skydhash 4mo ago
> All software developed by people suffers from this issue. And that’s pretty much where you are wrong. Take any long running open source project and you can see the craftsmanship that goes into it. It may not be perfect, but hacks are clearly marked as such.
- locknitpicker 4mo ago
  > And that’s pretty much where you are wrong. Take any long running open source project and (...) I think you are demonstrating a clear lack of insight and experience in software development settings, including FLOSS projects. I can name you a dozen of fairly known FLOSS projects which are a big ball of mud. Just go to the likes of GitHub, check out the list of popular projects, and peek at their code. You will get a very mixed set of results.
shakna 4mo ago
> Where exactly is the novelty? The compounding speed. Your devs might reach a point where they have to rewrite and refactor, in a decade. Your LLM, with its higher throughput, may put you in that game breaking situation next week.
- locknitpicker 4mo ago
  > The compounding speed. Your devs might reach a point where they have to rewrite and refactor, in a decade. I think that this is exactly why this scaremongering breaks down. If you believe the compounding speed is that greater, wouldn't you be compelled to accept that refactoring and cleaning things up is just as fast and effortless? I mean, you have a tool that writes software for you following your commands. If you are that concerned with maintainability then what can possibly compell you to not invest any effort in it?
  - 4mo ago