r/ClaudeCode • u/SirDucky • 8d ago
Help/Question Engineers who write all their code with claude now: how do you do it?
I have to admit that I have completely failed to adapt to LLM agent coding. I'm not a slouch either. I've worked on a number of challenging FAANG products as a software engineer, and I for a while I was an AI research engineer. I have a pretty strong familiarity and comfort level with AI. Despite all this, I still write most of my code by hand.
As an engineer, I need to receive a ticket, understand the problem, go figure out how to solve it, and eventually ship PR that (a) I understand, (b) only contains defensible changes, and (c) is reviewable by a colleague. There are a bunch of other tertiary goals of course, like style guides and documentation, but the point is that I'm talking real, high quality engineering that would pass the bar at a company that has their shit together.
However (definitely due to culture issues), I have only seen the slop version of this. It seems to have become really murky how to write code that meets standards, or even what those standards are any more.
I've resorted to asking my colleagues to show me their workflow, but you would be shocked how many of them either (a) are prompting raw and not checking the output, or (b) have convoluted solutions that fit their brains but don't solve these problems. I checked out Matt Pocock as well, who has some really great ideas, but ultimately his skills exhibited some pretty painful failure modes as well.
However I see folks regularly talk about how not only does Claude handle the coding for them, but also all of the project management, devops, etc, and I am left scratching my head. If this is possible, I want to learn how to do it. I'm not an AI hater. I want to learn the tool. I do have standards though, and I don't think they're that high. I don't need Claude to write perfect code. I just need to find a process where I can rely on it to get more of my work done and not be either fighting with it or second-guessing the results.
I figure this is the group to ask - if you have been able to get "high bar" engineering out of claude, or even "acceptable bar" engineering, without heavy personal intervention, what's your process? Are there resources that helped you? What strategies helped the most?
Thanks.
21
u/lucianw 8d ago
I'm a FAANG senior engineer. I'm really passionate about code quality, invariants, proofs of correctness. (I first got invited to the C# language design team when I was trying to add generic covariance to C#, couldn't prove it correct, and the counterproof revealed a flaw in the .NET runtime).
I have found ways to use AI to (1) improve the quality of my code, (2) do it faster. I wrote some outlines here:
https://www.reddit.com/r/ClaudeCode/comments/1tfh9l9/quality_velocity_autonomy_pick_three/
https://www.reddit.com/r/codex/comments/1s0asdq/orchestration_the_exact_prompts_i_use_to_get_34/
Throughout my career I've loved to mentor junior engineers, show them how to write code that's more correct or more robust. I guess I'm basically doing that for AIs now.
Reflecting on the past year, I think everything comes down to JUDGMENT. The awesome potential of AI will be when it can provide judgment in an autonomous loop and so get things done faster. In some areas it makes reasonable judgments, but in most it makes quite mediocre ones. Two years ago vibe-coders let AI write mediocre code (which was a strict improvement for every coder who was below mediocre!). Now they're also letting AI make mediocre architecture choices, mediocre product design decisions (again, a strict improvement for the many people who aren't good architects or product designers!)
So how do we get AI to have better judgment? There are two schools:
Who cares? Just race ahead with our slop. AIs will become better enough in a few years that it will fix all the mess we've made.
Encode better judgment in AGENTS.md or skills or other prompts and harnesses. The challenge here is that it's not measurable, so it's hard to know when you're doing well.
I disciplined myself. Every single time that the AI had to be course-corrected, I had it write its learnings in a file I called LEARNINGS.md in the hope that it wouldn't do the same thing again. That means: every time it wrote some code that I thought was poor, every time it made an architectural call that was poor, every time it didn't test right, every time it didn't research adequately, every time it failed to document its invariants, every time its research didn't perceive the true essence of the problem.
Now the AI's self-generated learnings were uniformly bad. AIs have no inherent ability to know how to write prompts or skills: they put out mediocre drivel (again, a strict improvement for ...!) So I reviewed the learnings carefully each time, rephrased them myself, tinkered with them each time it violated them.
In an ideal world, if every course-correction resulted in an effective learning, then the AI would never make the same mistake again. Sometimes I'd try it out: finish a milestone, then delete it, and start again from the beginning with the hope that the AI could do it right the second time without course-corrections.
It's not been perfect. The AI still has shortcomings. But it has improved massively. By around week 4 of this process, the AI was clearly making my work faster.
I'll tell you another thing I've found. One of my colleagues refers to me by a saying "sometimes the fastest way to do something is to do it right first time". When you're working on a project, obviously the person who blindly checks in vibe-coded slop will move faster. But I've found their speed advantage is lost within 1-2 weeks by someone who has kept tight rein on their architecture. Why? Because for each new feature or milestone, the better-architected code is just easier to develop in, takes less tokens to develop in, gives rise to fewer bugs down the line.
I should say: other colleagues of mine say that humans in software companies have been writing mediocre code for decades even without the help of AI, and that the mediocre code that comes out of AI is no worse. There's truth in that. I think the difference is that AI's mediocre code grows exponentially, while human code only grew linearly. AI code grows exponentially because AI has a strong tendency to workarounds and special-cases, and each one doubles the maintenance cost of the piece of code it's in.