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.
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.
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.
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.
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.
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.
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?
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."
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.
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.
Yes, sometimes you are actually indeed holding it wrong. Sometimes a product has to be used in a certain way to get good results. You're not going to blame the shampoo when someone uses only a tiny drop of it, and the hair remains dirty.
This is still early days with LLMs and coding assistants. You do have to hold them in the right way sometimes. If you're not willing to do that, or think that provides less value than doing it another way... great, good for you, do it the way you think is best for you.
I've been a coding assistant skeptic for a long time. I just started playing with Claude Code a month or so ago. I was frustrated for a bit until I learned how to hold it the right way. It is a long, long way from being a substitute for a real human programmer, but it's helpful to me. I certainly prefer it to pair programming with a human (I hate pair programming), so this provides value.
If you don't care to figure out for yourself if it can provide you value, that's your choice. But this technology is going to get better, and you might later find yourself wishing you'd looked into it earlier. Just like any new tool that starts out rough but eventually turns out to be very useful.
They don't learn by themselves, but you can add instructions as they make mistakes that are effectively them learning. You have to write code review feedback for juniors, so that s not an appreciable difference.
> Better off training someone off the street to be a software engineer.
And that person is going to quit and you have to start all over again. They also cost at least 100x the price.
I've been telling people, this is Uber in 2014, you're getting a benefit and it's being paid for with venture capital money, it's about as good as it's going to get.
Your claude.md (or equivalent) is the best way to teach them. At the end of any non-trivial coding session, I'll ask for it to propose edits/additions to that file based on both the functional changes and the process we followed to get there.
That's not the end of the story, though. LLMs don't learn, but you can provide them with a "handbook" that they read in every time you start a new conversation with them. While it might take a human months or years to learn what's in that handbook, the LLM digests it in seconds. Yes, you have to keep feeding it the handbook every time you start from a clean slate, and it might have taken you months to get that handbook into the complete state it's in. But maybe that's not so bad.
The good thing about this process its it means such a handbook functions as documentation for humans too, if properly written.
Claude is actually quite good at reading project documentation and code comments and acting on them. So it's also useful for encouraging project authors to write such documentation.
I'm now old enough that I need such breadcrumbs around the code to get context anyways. I won't remember why I did things without them.
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.
> 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.)
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.
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.
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.
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.
> 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.
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.
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.
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.
You are responsible for the layers. You should either do the design on your own, or let the tool ask you questions and guide you. But you should have it write down the plan, and only then you let it code. If it messes up the code, you /clear, load the plan again and tell it to do the code differently.
It's really the same with junior devs. I wouldn't tell a junior dev to implement a CRM app, but I can tell the junior dev to add a second email field to the customer management page.
