6 ms·

I think AI is just a massive force multiplier. If your codebase has bad foundation and going in the wrong direction with lots of hacks, it will just write code

I think AI is just a massive force multiplier. If your codebase has bad foundation and going in the wrong direction with lots of hacks, it will just write code which mirrors the existing style... And you get exactly was OP is suggesting. If however, your code foundations are good and highly consistent and never allow hacks, then the AI will maintain that clean style and it becomes shockingly good; in this case, the prompting barely even matters. The code foundation is everything. But I understand why a lot of people are still having a poor experience. Most codebases are bad. They work (within very rigid constraints, in very specific environments) but they're unmaintainable and very difficult to extend; require hacks on top of hacks. Each new feature essentially requires a minor or major refactoring; requiring more and more scattered code changes as everything is interdependent (tight coupling, low cohesion). Productivity just grinds to a slow crawl and you need 100 engineers to do what previously could have been done with just 1. This is not a new effect. It's just much more obvious now with AI. I've been saying this for years but I think too few engineers had actually built complex projects on their own to understand this effect. There's a parallel with building architecture; you are constrained by the foundation of the building. If you designed the foundation for a regular single storey house, you can't change your mind half-way through the construction process to build a 20-storey skyscraper. That said, if your foundation is good enough to support a 100 storey skyscraper, then you can build almost anything you want on top. My perspective is if you want to empower people to vibe code, you need to give them really strong foundations to work on top of. There will still be limitations but they'll be able to go much further. My experience is; the more planning and intelligence goes into the foundation, the less intelligence and planning is required for the actual construction.

isodev 8mo ago
And what if the foundation was made by the AI itself? What’s the excuse then?
- Qworg 8mo ago
  Your responsibility as a developer in this new world is design and validation. A poor foundation is a design problem. Throw it away and start again.
  - isodev 8mo ago
    We’ve always been responsible for design and validation. Nothing has changed there. It’s funny how the vibe coding story insists we shouldn’t look at the code details but when it’s pointed out the bots can’t deal with a “messy” (but validated) foundation, the story changes that we have to refactor that.
  - ares623 8mo ago
    But how will new developers learn to design and validate in the future?
- 0000000000100 8mo ago
  Then you are boned unless it was architected well. LLMs tend to stack a lot of complexity at local scopes, especially if the neighboring pages are also built poorly. E.g pumping out a ton of logic to convert one data structure to another. Like a poorly structured form with random form control names that don’t match to the DTO. Or single properties for each form control which are then individually plugged into the request DTO.
  - isodev 8mo ago
    > Then you are boned Must be my lucky day! Too bad my dream of being that while the bots are taking care of the coding is still sort of fiction. I love a future when this is possible but what we have today is more of a proof of concept. A transformative leap is required for this technology before it can be as useful as advertised.
    - 0000000000100 8mo ago
      Yep, it’s still a bit off from being a true developer. But good news for existing software devs who will need to be hired to fix LLM balls of mud that will inevitably fall apart. In my mind it’s not too much different than cheap contractor code that I already have to deal with on a regular basis…
  - 8note 8mo ago
    you could also use some code styling agent scripts that make todo lists of everywhere where there's bad architecture, and have it run through fixing those issues until its to your liking. theyre reasomable audit tools for finding issues, if you have ways to make sure they dont give up early, and you force them to output proof of what they did
    - Jensson 8mo ago
      And that is harder than just doing it manually, hence saying that hard parts are harder. If you have a clear picture of what you want it to do then its harder to vibe code than to code it yourself.
0000000000100 8mo ago
This is what I’ve discovered as well. I’ve been working on refactoring a massive hunk of really poor quality contractor code, and Codex originally made poor and very local fixes/changes. After rearchitecting the foundations (dumping bootstrap, building easy-to-use form fields, fixing hardcoded role references 1,2,3…, consolidating typescript types, etc.) it makes much better choices without needing specific guidance. Codex/Claude Code won’t solve all your problems though. You really need to take some time to understand the codebase and fixing the core abstractions before you set it loose. Otherwise, it just stacks garbage on garbage and gets stuck patching and won’t actually fix the core issues unless instructed.
ekidd 8mo ago
The wrinkle is that the AI doesn't have a truly global view, and so it slowly degrades even good structure, especially if run without human feedback and review. But you're right that good structure really helps.
- redox99 8mo ago
  AGENTS.md is for that global view.
  - isodev 8mo ago
    That’s not what Claude and Codex put there when you ask them to init it. Also, the global view is most definitely bigger than their tiny, loremipsum-on-steroids, context so what do you do then?
    - redox99 8mo ago
      You know you can put anything there, not just what they init, right? And you can reference other doc files. I should probably stop commenting on AI posts because when I try to help others get the most out of agents I usually just get down voted like now. People want to hate on AI, not learn how to use it.
      - deleted 8mo ago
        [deleted]
  - deleted 8mo ago
    [deleted]
  - hyperadvanced 8mo ago
    Am I stupid or do these agents regularly not read what’s in the agents.md file?
    - redox99 8mo ago
      Each agent uses a different file, like claude.md etc (maybe you already knew that). And it requires a bit of prompt engineering like using caps for some stuff (ALWAYS), etc.
zozbot234 8mo ago
Can the AI help with refactoring a poor codebase? Can it at least provide good suggestions for improvement if asked to broadly survey a design that happens to be substandard? Most codebases are quite bad as you say, so this is a rather critical area.
jim180 8mo ago
my exact experience, and AI is especially fragile when you are starting new project from scratch. Right know I'm building NNTP client for macOS (with AppKit), because why not, and initially I had to very carefully plan and prompt what AI has to do, otherwise it would go insane (integration tests are must). Right know I have read-only mode ready and its very easy to build stuff on top of it. Also, I had to provide a lot of SKILLS to GPT5.3
adithyassekhar 8mo ago
A tangent, I keep hearing this good base, but I've never seen one, not in the real world. No projects, unless it's only you working on it, only yourself as the client, and is so rigid in it's scope, it's frankly useless, will have this mythical base. Over time the needs change, there's no sticking to the plan. Often it's a change that requires rethinking a major part. What we loathe as tight coupling was just efficient code with the original requirements. Then it becomes a time/opportunity cost vs quality loss comparison. Time and opportunity always wins. Why? Because we live in a world run by humans, who are messy and never sticks to the plan. Our real world systems (bureaucracy , government process, the list goes on) are never fully automated and always leaves gaps for humans to intervene. There's always a special case, an exception. Perfectly architected code vs code that does the thing have no real world difference. Long term maintainability? Your code doesn't run in a vaccum, it depends on other things, it's output is depended on by other things. Change is real, entropy is real. Even you yourself, you perfect programmer who writes perfect code will succumb eventually and think back on all this with regret. Because you yourself had to choose between time/opportunity vs your ideals and you chose wrong. Thanks for reading my blog-in-hn comment.
- zozbot234 8mo ago
  Well-architected code should actually be easy to change wrt. new requirements. The point of keeping the architecture clean while you do this (which will typically require refactoring) is to make future changes similarly viable. In a world run by messy humans, accumulating technical debt is even more of a liability.
- dwallin 8mo ago
  A important point though is that llm code generation changes that tradeoff. The time/opportunity cost goes way down while the productivity penalty starts accumulating very fast. Outcomes can diverge very quickly.
- mattgreenrocks 8mo ago
  It’s not about perfectly architected code. It’s more about code that is factored in such a way that you can extend/tweak it without needing to keep the whole of the system in your head at all times. It’s fascinating watching the sudden resurgence of interest in software architecture after people are finding it helps LLMs move quickly. It has been similarly beneficial for humans as well. It’s not rocket science. It got maligned because it couldn’t be reduced to an npm package/discrete process that anyone could follow.
dustingetz 8mo ago
how do you know there is such thing as good code foundations, and how do you know you have it? this is an argument from ego
- kingraoul 8mo ago
  Induction always sneaks in!
napierzaza 8mo ago
[dead]
Avshalom 8mo ago
When you say multiplier, what kind of number are you talking about. Like what multiple of features shipped that don't require immediate fixes have you experienced.
- echelon 8mo ago
  It's coding at 10-20x speed, but tangibly this is at 1.5-2x the overall productivity. The coding speed up doesn't translate completely to overall velocity yet. I am beginning to build a high degree of trust in the code Claude emits. I'm having to step in with corrections less and less, and it's single shotting entire modules 500-1k LOC, multiple files touched, without any trouble. It can understand how frontend API translates to middleware, internal API service calls, and database queries (with a high degree of schema understanding, including joins). (This is in a Rust/Actix/Sqlx/Typescript/nx monorepo, fwiw.)
  - Avshalom 8mo ago
    Okay but again what multiplier of features have you actually shipped.
raw_anon_1111 8mo ago
I agree completely. I just did my first “AI native coding project”. Both because for now I haven’t run into any quotas using Codex CLI with my $20/month ChatGPT subscription and the company just gave everyone an $800/month Claude allowance. Before I even started the implementation I: 1. Put the initial sales contract with the business requirements. 2. Notes I got from talking to sales 3. The transcript of the initial discovery calls 4. My design diagrams that were well labeled (cloud architecture and what each lambda does) 5. The transcript of the design review and my explanations and answering questions. 6. My ChatGPT assisted breakdown of the Epics/stories and tasks I had to do for the PMO I then told ChatGPT to give a detailed breakdown of everything during the session as Markdown That was the start of my AGENTS.md file. While working through everything task by task and having Codex/Claude code do the coding, I told it to update a separate md file with what it did and when I told it to do something differently and why. Any developer coming in after me will have complete context of the project from the first git init and they and the agents will know the why behind every decision that was made. Can you say that about any project that was done before GenAI?
- dijksterhuis 8mo ago
  > Can you say that about any project that was done before GenAI? yes. the linux kernel and it's extensive mailing lists come to mind. in fact, any decent project which was/is built in a remote-only scenario tends to have extensive documentation along these lines, something like gitlab comes to mind there. personally i've included design documents with extensive notes, contracts, meeting summaries etc etc in our docs area / repo hosting at $PREVIOUS_COMPANY. only thing from your list we didn't have was transcripts because they're often less useful than a summary of "this is what we actually decided and why". edit -- there were some video/meeting audio recordings we kept around though. at least one was a tutoring session i did. maybe this is the first time you've felt able to do something like this in a short amount of time because of these GenAI tools? i don't know your story. but i was doing a lot of this by hand before GenAI. it took time, energy and effort to do. but your project is definitely not the first to have this level of detailed contextual information associated with it. i will, however, concede that these tools can make it it easier/faster to get there.
anupamchugh 8mo ago
[flagged]
RataNova 8mo ago
AI doesn't fix design debt, it amplifies it
nananana9 8mo ago
This does not track with my experience, trying agents out in a ~100K LOC codebase written exclusively by me. I can't tell you whether nor not it has a good foundation by your standards, but I find the outputs to be tasteless, and there should be more than enough context for what the style of the code is. Given how adamant some people I respect a lot are about how good these models are, I was frankly shocked to see SOA models do transformations like BEFORE: // 20 lines AFTER if (something) // the 20 lines else // the same 20 lines, one boolean changed in the middle When I point this out, it extracts said 20 lines into a function that takes in the entire context used in the block as arguments: AFTER 2: if (something) function_that_will_never_be_used_anywhere_else(a, b, c, &d, &e, &f, true); else function_that_will_never_be_used_anywhere_else(a, b, c, &d, &e, &f, false); It also tends to add these comments that don't document anything, but rather just describe the latest change it did to the code: // Extracted repeating code into a function: void function_that_will_never_be_used_anywhere_else(...) { ... } and to top it off it has the audacity to tell me "The code is much cleaner now. Happy building! (rocketship emoji)"

isodev 8mo ago

And what if the foundation was made by the AI itself? What’s the excuse then?

Qworg 8mo ago
Your responsibility as a developer in this new world is design and validation. A poor foundation is a design problem. Throw it away and start again.
- isodev 8mo ago
  We’ve always been responsible for design and validation. Nothing has changed there. It’s funny how the vibe coding story insists we shouldn’t look at the code details but when it’s pointed out the bots can’t deal with a “messy” (but validated) foundation, the story changes that we have to refactor that.
- ares623 8mo ago
  But how will new developers learn to design and validate in the future?
0000000000100 8mo ago
Then you are boned unless it was architected well. LLMs tend to stack a lot of complexity at local scopes, especially if the neighboring pages are also built poorly. E.g pumping out a ton of logic to convert one data structure to another. Like a poorly structured form with random form control names that don’t match to the DTO. Or single properties for each form control which are then individually plugged into the request DTO.
- isodev 8mo ago
  > Then you are boned Must be my lucky day! Too bad my dream of being that while the bots are taking care of the coding is still sort of fiction. I love a future when this is possible but what we have today is more of a proof of concept. A transformative leap is required for this technology before it can be as useful as advertised.
  - 0000000000100 8mo ago
    Yep, it’s still a bit off from being a true developer. But good news for existing software devs who will need to be hired to fix LLM balls of mud that will inevitably fall apart. In my mind it’s not too much different than cheap contractor code that I already have to deal with on a regular basis…
- 8note 8mo ago
  you could also use some code styling agent scripts that make todo lists of everywhere where there's bad architecture, and have it run through fixing those issues until its to your liking. theyre reasomable audit tools for finding issues, if you have ways to make sure they dont give up early, and you force them to output proof of what they did
  - Jensson 8mo ago
    And that is harder than just doing it manually, hence saying that hard parts are harder. If you have a clear picture of what you want it to do then its harder to vibe code than to code it yourself.

0000000000100 8mo ago

This is what I’ve discovered as well. I’ve been working on refactoring a massive hunk of really poor quality contractor code, and Codex originally made poor and very local fixes/changes. After rearchitecting the foundations (dumping bootstrap, building easy-to-use form fields, fixing hardcoded role references 1,2,3…, consolidating typescript types, etc.) it makes much better choices without needing specific guidance. Codex/Claude Code won’t solve all your problems though. You really need to take some time to understand the codebase and fixing the core abstractions before you set it loose. Otherwise, it just stacks garbage on garbage and gets stuck patching and won’t actually fix the core issues unless instructed.

ekidd 8mo ago

The wrinkle is that the AI doesn't have a truly global view, and so it slowly degrades even good structure, especially if run without human feedback and review. But you're right that good structure really helps.

redox99 8mo ago
AGENTS.md is for that global view.
- isodev 8mo ago
  That’s not what Claude and Codex put there when you ask them to init it. Also, the global view is most definitely bigger than their tiny, loremipsum-on-steroids, context so what do you do then?
  - redox99 8mo ago
    You know you can put anything there, not just what they init, right? And you can reference other doc files. I should probably stop commenting on AI posts because when I try to help others get the most out of agents I usually just get down voted like now. People want to hate on AI, not learn how to use it.
    - deleted 8mo ago
      [deleted]
- deleted 8mo ago
  [deleted]
- hyperadvanced 8mo ago
  Am I stupid or do these agents regularly not read what’s in the agents.md file?
  - redox99 8mo ago
    Each agent uses a different file, like claude.md etc (maybe you already knew that). And it requires a bit of prompt engineering like using caps for some stuff (ALWAYS), etc.

zozbot234 8mo ago

Can the AI help with refactoring a poor codebase? Can it at least provide good suggestions for improvement if asked to broadly survey a design that happens to be substandard? Most codebases are quite bad as you say, so this is a rather critical area.

jim180 8mo ago

my exact experience, and AI is especially fragile when you are starting new project from scratch. Right know I'm building NNTP client for macOS (with AppKit), because why not, and initially I had to very carefully plan and prompt what AI has to do, otherwise it would go insane (integration tests are must). Right know I have read-only mode ready and its very easy to build stuff on top of it. Also, I had to provide a lot of SKILLS to GPT5.3

adithyassekhar 8mo ago

A tangent, I keep hearing this good base, but I've never seen one, not in the real world. No projects, unless it's only you working on it, only yourself as the client, and is so rigid in it's scope, it's frankly useless, will have this mythical base. Over time the needs change, there's no sticking to the plan. Often it's a change that requires rethinking a major part. What we loathe as tight coupling was just efficient code with the original requirements. Then it becomes a time/opportunity cost vs quality loss comparison. Time and opportunity always wins. Why? Because we live in a world run by humans, who are messy and never sticks to the plan. Our real world systems (bureaucracy , government process, the list goes on) are never fully automated and always leaves gaps for humans to intervene. There's always a special case, an exception. Perfectly architected code vs code that does the thing have no real world difference. Long term maintainability? Your code doesn't run in a vaccum, it depends on other things, it's output is depended on by other things. Change is real, entropy is real. Even you yourself, you perfect programmer who writes perfect code will succumb eventually and think back on all this with regret. Because you yourself had to choose between time/opportunity vs your ideals and you chose wrong. Thanks for reading my blog-in-hn comment.

zozbot234 8mo ago
Well-architected code should actually be easy to change wrt. new requirements. The point of keeping the architecture clean while you do this (which will typically require refactoring) is to make future changes similarly viable. In a world run by messy humans, accumulating technical debt is even more of a liability.
dwallin 8mo ago
A important point though is that llm code generation changes that tradeoff. The time/opportunity cost goes way down while the productivity penalty starts accumulating very fast. Outcomes can diverge very quickly.
mattgreenrocks 8mo ago
It’s not about perfectly architected code. It’s more about code that is factored in such a way that you can extend/tweak it without needing to keep the whole of the system in your head at all times. It’s fascinating watching the sudden resurgence of interest in software architecture after people are finding it helps LLMs move quickly. It has been similarly beneficial for humans as well. It’s not rocket science. It got maligned because it couldn’t be reduced to an npm package/discrete process that anyone could follow.

dustingetz 8mo ago

how do you know there is such thing as good code foundations, and how do you know you have it? this is an argument from ego

kingraoul 8mo ago
Induction always sneaks in!

napierzaza 8mo ago

[dead]

Avshalom 8mo ago

When you say multiplier, what kind of number are you talking about. Like what multiple of features shipped that don't require immediate fixes have you experienced.

echelon 8mo ago
It's coding at 10-20x speed, but tangibly this is at 1.5-2x the overall productivity. The coding speed up doesn't translate completely to overall velocity yet. I am beginning to build a high degree of trust in the code Claude emits. I'm having to step in with corrections less and less, and it's single shotting entire modules 500-1k LOC, multiple files touched, without any trouble. It can understand how frontend API translates to middleware, internal API service calls, and database queries (with a high degree of schema understanding, including joins). (This is in a Rust/Actix/Sqlx/Typescript/nx monorepo, fwiw.)
- Avshalom 8mo ago
  Okay but again what multiplier of features have you actually shipped.

raw_anon_1111 8mo ago

I agree completely. I just did my first “AI native coding project”. Both because for now I haven’t run into any quotas using Codex CLI with my $20/month ChatGPT subscription and the company just gave everyone an $800/month Claude allowance. Before I even started the implementation I: 1. Put the initial sales contract with the business requirements. 2. Notes I got from talking to sales 3. The transcript of the initial discovery calls 4. My design diagrams that were well labeled (cloud architecture and what each lambda does) 5. The transcript of the design review and my explanations and answering questions. 6. My ChatGPT assisted breakdown of the Epics/stories and tasks I had to do for the PMO I then told ChatGPT to give a detailed breakdown of everything during the session as Markdown That was the start of my AGENTS.md file. While working through everything task by task and having Codex/Claude code do the coding, I told it to update a separate md file with what it did and when I told it to do something differently and why. Any developer coming in after me will have complete context of the project from the first git init and they and the agents will know the why behind every decision that was made. Can you say that about any project that was done before GenAI?

dijksterhuis 8mo ago
> Can you say that about any project that was done before GenAI? yes. the linux kernel and it's extensive mailing lists come to mind. in fact, any decent project which was/is built in a remote-only scenario tends to have extensive documentation along these lines, something like gitlab comes to mind there. personally i've included design documents with extensive notes, contracts, meeting summaries etc etc in our docs area / repo hosting at $PREVIOUS_COMPANY. only thing from your list we didn't have was transcripts because they're often less useful than a summary of "this is what we actually decided and why". edit -- there were some video/meeting audio recordings we kept around though. at least one was a tutoring session i did. maybe this is the first time you've felt able to do something like this in a short amount of time because of these GenAI tools? i don't know your story. but i was doing a lot of this by hand before GenAI. it took time, energy and effort to do. but your project is definitely not the first to have this level of detailed contextual information associated with it. i will, however, concede that these tools can make it it easier/faster to get there.

anupamchugh 8mo ago

[flagged]

RataNova 8mo ago

AI doesn't fix design debt, it amplifies it

nananana9 8mo ago

This does not track with my experience, trying agents out in a ~100K LOC codebase written exclusively by me. I can't tell you whether nor not it has a good foundation by your standards, but I find the outputs to be tasteless, and there should be more than enough context for what the style of the code is. Given how adamant some people I respect a lot are about how good these models are, I was frankly shocked to see SOA models do transformations like BEFORE: // 20 lines AFTER if (something) // the 20 lines else // the same 20 lines, one boolean changed in the middle When I point this out, it extracts said 20 lines into a function that takes in the entire context used in the block as arguments: AFTER 2: if (something) function_that_will_never_be_used_anywhere_else(a, b, c, &d, &e, &f, true); else function_that_will_never_be_used_anywhere_else(a, b, c, &d, &e, &f, false); It also tends to add these comments that don't document anything, but rather just describe the latest change it did to the code: // Extracted repeating code into a function: void function_that_will_never_be_used_anywhere_else(...) { ... } and to top it off it has the audacity to tell me "The code is much cleaner now. Happy building! (rocketship emoji)"