5 ms·

Claude code is great until it isn’t. You’re going to get to a point where you need to modify something or add something… a small feature that would have been ea

Claude code is great until it isn’t. You’re going to get to a point where you need to modify something or add something… a small feature that would have been easy if you wrote everything, and now it’s impossible because the architecture is just a mishmash of vibe coded stuff you don’t understand.

lukaslalinsky 1y ago
How can you end up with code you don't understand, if you review anything it writes? I wouldn't let it deviate from the architecture I want to have for the project. I had problems with junior devs in the past, too eager to change a project, and I couldn't really tell them to stop (need to work on my communication skills). No such problem with Claude Code.
- tronikel 1y ago
  So youre telling me that reading is the same as writing? In terms of the brain actually consuming and processing the info you gave it and storing it
  - muspimerol 1y ago
    > a mishmash of vibe coded stuff you don’t understand. No, there is a difference between "I wrote this code" and "I understand this code". You don't need to write all the code in a project to understand it. Otherwise writing software in a team would not be a viable undertaking.
- ruszki 1y ago
  I don’t remember what architecture was used by PRs I reviewed a month ago. I remember what architecture I designed 15 years ago for projects I was part of.
- everforward 1y ago
  I've only used the agentic tools a bit, but I've found that they're able to generate code at a velocity that I struggle to keep in my head. The development loop also doesn't require me to interact with the code as much, so I have worse retention of things like which functions are in which file, what helper functions already exist, etc. It's less that I can't understand, and more that my context on the code is very weak.
  - ako 1y ago
    Ask it to document the code with design documents and mermaid diagrams. Much faster to review.
    - everforward 1y ago
      I might have to try this. Without having tried it, it feels like the context I think I lack is more nitty gritty than would be exposed like this. It's not like I'm unsure of how a request ends up in a database transaction, but more "do we need or already have an abstraction over paging in database queries?". It doesn't feel like mermaid diagrams or design documents would include that, but I'm open to being wrong there.
      - ako 1y ago
        If you have a question like that, just ask.
jshen 1y ago
The trick is to ask it to do more narrow tasks and design the structure of the code base yourself.
- hkt 1y ago
  This. It helps to tell it to plan and to then interrogate it about that plan, change it to specification etc. Think of it as a refinement session before a pairing session. The results are considerably better if you do it this way. I've written kubernetes operators, flask applications, Kivy applications, and a transparent ssh proxy with Claude in the last two months, all outside of work. It also helps to tell it to write tests first: I lean towards integration tests for most things but it is decent at writing good unit tests etc too. Obviously, review is paramount if TDD is going to work.
  - tiahura 1y ago
    As a hobbyist coder, the more time I spend brainstorming with all the platforms about specs and tests and architecture, the better the ultimate results.
skippyboxedhero 1y ago
Yes, the default when it does anything is to try and create. It will read my CLAUDE.md file, it will read the code that is already there, and then it will try to write it again. I have had this happen many times (today, I had to prompt 5/6 times to read the file as a feature had already been implemented). ...and if something is genuinely complex, it will (imo) generally do a bad job. It will produce something that looks like it works superficially, but as you examine it will either not work in a non-obvious way or be poorly designed. Still very useful but to really improve your productivity you have to understand when not to use it.
- bboygravity 1y ago
  How do you write complex code as a human? You create abstraction layers, right? Why wouldn't that work with an llm? It takes effort, sure, but it certainly also takes effort if you have to do it "by hand"?
  - deleted 1y ago
    [deleted]
  - sidjxjxbnxkxkkx 1y ago
    English is much less expressive compared to code. Typing the keys was never the slow part for senior developers. It does work with an LLM, but you’re reinventing the wheel with these crazy markup files. We created a family of language to express how to move bits around and replacing that with English is silly. Vibe coding is fast because you’re ok with not thinking about the code. Anytime you have to do that, an LLM is not going to be much faster.
  - skippyboxedhero 1y ago
    Because it creates the wrong layers. In theory, there is no reason why this is the case. For the same reason, there is no reason why juniors can't create perfect code first time...it is just the tickets are never detailed enough? But in reality, it doesn't work like that. The code is just bad.
    - 1y ago
cmrdporcupine 1y ago
You're not setting good enough boundaries or reviewing what it's doing closely enough. Police it, and give it explicit instructions. Then after it's done its work prompt it with something like "You're the staff engineer or team lead on this project, and I want you to go over your own git diff like it's a contribution from a junior team member. Think critically and apply judgement based on the architecture of the project describes @HERE.md and @THERE.md."
- GiorgioG 1y ago
  Ah yes…the old “you’re holding it wrong”. The problem is these goddamn things don’t learn, so you put in the effort to police it…and you have to keep doing that until the end of time. Better off training someone off the street to be a software engineer.
  - hkt 1y ago
    Not so. Adding to context files helps enormously. Having touchstone files (ARCHITECTURE.md) you can reference helps enormously. The trick is to steer, and create the guardrails. Honestly, it feels like DevOps had a kid with Product.
    - GiorgioG 1y ago
      > Honestly, it feels like DevOps had a kid with Product. You've just described a match made in hell. DevOps - let's overcomplicate things (I'm looking at you K8s) and Product - they create pretty screenshots and flows but not actually think about the product as a system (or set of systems.)
  - cmrdporcupine 1y ago
    It's just a tool, not an intelligence or a person. You use it to make your job easier. If it doesn't make your job easier, you don't use it. Anybody trying to sell you on a bill of goods that this is somehow "automating away engineers" and "replacing expensive software developers" is either stupid or lying (or both). I find it incredibly useful, but it's garbage-in, garbage-out just like anything else with computers. If your code base is well commented and documented and laid out in a consistent pattern, it will tend to follow that pattern, especially if it follows standards. And it does better in languages (like Rust) that have strict type systems and coding standards. Even better if you have rigorous tests for it to check its own work against.
rane 1y ago
Having used Claude Code extensively for the last few months, I still haven't reached this "until it isn't" point. Review the code that comes out. It goes a long way.
- risyachka 1y ago
  >> Review the code that comes out. It goes a long way. Sure, but if I do 5 reviews for a task - in 99% of cases it is net negative as it is faster to DIY it at that point. Harder for sure, but faster.
  - rane 1y ago
    Maybe our brains are wired different but reading and reviewing code is way faster for me than writing it.
    - wredcoll 1y ago
      There's very few objective ways to measure review 'performance'. Coding is easy, it works or doesn't.
      - pixl97 1y ago
        Or it works till it doesn't. There is a lot of code that will work until some condition is met.
      - nosianu 1y ago
        This ignores a bunch of higher level and long-term concepts like maintenance, complexity and extensibility. With only "it works" you end up like this (iconic HN comment on Oracle codebase): https://news.ycombinator.com/item?id=18442637 https://news.ycombinator.com/item?id=18442637
        wredcoll 1y ago
        Yes, my point is that you don't even have "it compiles" as a way to measure a code review. Maybe you did a great job, maybe you did a terrible job, how do you tell?
Aurornis 1y ago
The people successfully using Claude Code for big projects aren’t letting it get to the point where they don’t understand what it wrote. The best results come from working iteratively with it. I reject about 1/3 of edits to request some changes or a change of direction. If you just try to have it jam on code until the end result appears to work then you will be disappointed. But that’s operator error.
- danielbln 1y ago
  So far I'm bullish on subagents to help with that. Validate completion status, bullshit detection, catching over engineering etc. I can load them with extra context like conventions ahd specific prompts to clamp down on the Claude-isms during development.
- AtlasBarfed 1y ago
  Remind me in two years... I understand completely what you're saying. But with the delusions that management is under right now, you're just going to seem like someone that's resisting the flow of code and becoming a bottleneck.
epolanski 1y ago
You're misusing the tool starting from not giving clear instructions.

lukaslalinsky 1y ago

How can you end up with code you don't understand, if you review anything it writes? I wouldn't let it deviate from the architecture I want to have for the project. I had problems with junior devs in the past, too eager to change a project, and I couldn't really tell them to stop (need to work on my communication skills). No such problem with Claude Code.

tronikel 1y ago
So youre telling me that reading is the same as writing? In terms of the brain actually consuming and processing the info you gave it and storing it
- muspimerol 1y ago
  > a mishmash of vibe coded stuff you don’t understand. No, there is a difference between "I wrote this code" and "I understand this code". You don't need to write all the code in a project to understand it. Otherwise writing software in a team would not be a viable undertaking.
ruszki 1y ago
I don’t remember what architecture was used by PRs I reviewed a month ago. I remember what architecture I designed 15 years ago for projects I was part of.
everforward 1y ago
I've only used the agentic tools a bit, but I've found that they're able to generate code at a velocity that I struggle to keep in my head. The development loop also doesn't require me to interact with the code as much, so I have worse retention of things like which functions are in which file, what helper functions already exist, etc. It's less that I can't understand, and more that my context on the code is very weak.
- ako 1y ago
  Ask it to document the code with design documents and mermaid diagrams. Much faster to review.
  - everforward 1y ago
    I might have to try this. Without having tried it, it feels like the context I think I lack is more nitty gritty than would be exposed like this. It's not like I'm unsure of how a request ends up in a database transaction, but more "do we need or already have an abstraction over paging in database queries?". It doesn't feel like mermaid diagrams or design documents would include that, but I'm open to being wrong there.
    - ako 1y ago
      If you have a question like that, just ask.

jshen 1y ago

The trick is to ask it to do more narrow tasks and design the structure of the code base yourself.

hkt 1y ago
This. It helps to tell it to plan and to then interrogate it about that plan, change it to specification etc. Think of it as a refinement session before a pairing session. The results are considerably better if you do it this way. I've written kubernetes operators, flask applications, Kivy applications, and a transparent ssh proxy with Claude in the last two months, all outside of work. It also helps to tell it to write tests first: I lean towards integration tests for most things but it is decent at writing good unit tests etc too. Obviously, review is paramount if TDD is going to work.
- tiahura 1y ago
  As a hobbyist coder, the more time I spend brainstorming with all the platforms about specs and tests and architecture, the better the ultimate results.

skippyboxedhero 1y ago

Yes, the default when it does anything is to try and create. It will read my CLAUDE.md file, it will read the code that is already there, and then it will try to write it again. I have had this happen many times (today, I had to prompt 5/6 times to read the file as a feature had already been implemented). ...and if something is genuinely complex, it will (imo) generally do a bad job. It will produce something that looks like it works superficially, but as you examine it will either not work in a non-obvious way or be poorly designed. Still very useful but to really improve your productivity you have to understand when not to use it.

bboygravity 1y ago
How do you write complex code as a human? You create abstraction layers, right? Why wouldn't that work with an llm? It takes effort, sure, but it certainly also takes effort if you have to do it "by hand"?
- deleted 1y ago
  [deleted]
- sidjxjxbnxkxkkx 1y ago
  English is much less expressive compared to code. Typing the keys was never the slow part for senior developers. It does work with an LLM, but you’re reinventing the wheel with these crazy markup files. We created a family of language to express how to move bits around and replacing that with English is silly. Vibe coding is fast because you’re ok with not thinking about the code. Anytime you have to do that, an LLM is not going to be much faster.
- skippyboxedhero 1y ago
  Because it creates the wrong layers. In theory, there is no reason why this is the case. For the same reason, there is no reason why juniors can't create perfect code first time...it is just the tickets are never detailed enough? But in reality, it doesn't work like that. The code is just bad.
  - 1y ago

cmrdporcupine 1y ago

You're not setting good enough boundaries or reviewing what it's doing closely enough. Police it, and give it explicit instructions. Then after it's done its work prompt it with something like "You're the staff engineer or team lead on this project, and I want you to go over your own git diff like it's a contribution from a junior team member. Think critically and apply judgement based on the architecture of the project describes @HERE.md and @THERE.md."

GiorgioG 1y ago
Ah yes…the old “you’re holding it wrong”. The problem is these goddamn things don’t learn, so you put in the effort to police it…and you have to keep doing that until the end of time. Better off training someone off the street to be a software engineer.
- hkt 1y ago
  Not so. Adding to context files helps enormously. Having touchstone files (ARCHITECTURE.md) you can reference helps enormously. The trick is to steer, and create the guardrails. Honestly, it feels like DevOps had a kid with Product.
  - GiorgioG 1y ago
    > Honestly, it feels like DevOps had a kid with Product. You've just described a match made in hell. DevOps - let's overcomplicate things (I'm looking at you K8s) and Product - they create pretty screenshots and flows but not actually think about the product as a system (or set of systems.)
- cmrdporcupine 1y ago
  It's just a tool, not an intelligence or a person. You use it to make your job easier. If it doesn't make your job easier, you don't use it. Anybody trying to sell you on a bill of goods that this is somehow "automating away engineers" and "replacing expensive software developers" is either stupid or lying (or both). I find it incredibly useful, but it's garbage-in, garbage-out just like anything else with computers. If your code base is well commented and documented and laid out in a consistent pattern, it will tend to follow that pattern, especially if it follows standards. And it does better in languages (like Rust) that have strict type systems and coding standards. Even better if you have rigorous tests for it to check its own work against.

rane 1y ago

Having used Claude Code extensively for the last few months, I still haven't reached this "until it isn't" point. Review the code that comes out. It goes a long way.

risyachka 1y ago
>> Review the code that comes out. It goes a long way. Sure, but if I do 5 reviews for a task - in 99% of cases it is net negative as it is faster to DIY it at that point. Harder for sure, but faster.
- rane 1y ago
  Maybe our brains are wired different but reading and reviewing code is way faster for me than writing it.
  - wredcoll 1y ago
    There's very few objective ways to measure review 'performance'. Coding is easy, it works or doesn't.
    - pixl97 1y ago
      Or it works till it doesn't. There is a lot of code that will work until some condition is met.
    - nosianu 1y ago
      This ignores a bunch of higher level and long-term concepts like maintenance, complexity and extensibility. With only "it works" you end up like this (iconic HN comment on Oracle codebase): https://news.ycombinator.com/item?id=18442637 https://news.ycombinator.com/item?id=18442637
      - wredcoll 1y ago
        Yes, my point is that you don't even have "it compiles" as a way to measure a code review. Maybe you did a great job, maybe you did a terrible job, how do you tell?

Aurornis 1y ago

The people successfully using Claude Code for big projects aren’t letting it get to the point where they don’t understand what it wrote. The best results come from working iteratively with it. I reject about 1/3 of edits to request some changes or a change of direction. If you just try to have it jam on code until the end result appears to work then you will be disappointed. But that’s operator error.

danielbln 1y ago
So far I'm bullish on subagents to help with that. Validate completion status, bullshit detection, catching over engineering etc. I can load them with extra context like conventions ahd specific prompts to clamp down on the Claude-isms during development.
AtlasBarfed 1y ago
Remind me in two years... I understand completely what you're saying. But with the delusions that management is under right now, you're just going to seem like someone that's resisting the flow of code and becoming a bottleneck.

epolanski 1y ago

You're misusing the tool starting from not giving clear instructions.