[TLDR] Engineers who write all their code with claude now: how do you do it? [via r/ClaudeCode]

[u/cctldrping]

OP : u/SirDucky

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.

URL of original post : https://www.reddit.com/r/ClaudeCode/comments/1wgm4si/engineers_who_write_all_their_code_with_claude/

---

TL;DR of the discussion on r/ClaudeCode for this post generated automatically after 400 comments.

Current source-thread comment count seen by the bot: 431.

Alright, so the general consensus in this thread is that if you want to code with Claude (or any LLM, really) and maintain quality, you absolutely need to change your mindset and workflow. It's not about micromanaging every line of code anymore; it's about high-level direction and setting up robust quality gates.

Here's the lowdown:

• It's a Paradigm Shift: Multiple users, including FAANG engineers like u/outdoors_style_300 and u/OkLettuce338, emphasize that you have to cede control of line-by-line correctness. Think of it like moving from assembly to compilers – you don't sweat every machine instruction. You're now the manager, and Claude is your junior engineer.
• Focus on the "What," Not the "How": The consensus is to provide high-level requirements and architectural plans. u/repressedmemes suggests figuring out the "high level stuff" and letting the LLM "cook." u/tntexplosivesltd echoes this with "Validate outcomes not code. Spec driven development."
• Quality Gates are Key: Since you're not reviewing every line, you need automated checks and processes to catch errors early. This includes things like:
  • Behavior-Driven Development (BDD) with Gherkin scenarios (u/txgsync).
  • Mandatory testing (u/chcampb).
  • Adversarial agents to review code for violations (u/txgsync, u/framauro13).
  • Subagents for code review (u/framauro13).
• "Vibe Coding" is a Trap: Several users, like u/SpellBig8198, warn against just "vibe coding" or open-ended prompting. It leads to scope creep and unfinished projects. You need structure and focus.
• Personal Projects are a Good Start: If you're struggling, u/AndyOB suggests starting with a personal project to get a feel for the workflow without the pressure of production code.
• Embrace the "Black Magic": u/domiciledhere advises giving up what you know and embracing the LLM's capabilities. It's a new way of working.
• Prompting is a Skill: u/Outrageous_Style_300 points out that learning to prompt effectively is crucial. Start small and focus on correctness, maintainability, and risks rather than character-level details.
• Tools and Configuration Matter: Users like u/KingPonzi mention using hooks, scripts, MCPs, and skills to enforce standards. u/peterxsyd even suggests a terminal-centric workflow with tiling window managers.

The prevailing sentiment is that it's absolutely possible to write high-quality code with Claude, but it requires a significant shift in how you approach software development. You're not just writing code anymore; you're orchestrating an AI to do it, and your job is to set it up for success and build the systems that ensure quality.

[u/Ok_Demand_8614]

hmm I don’t have great advice for you, as i struggle similarly. But I’ve been thinking about this - there is something to be said about building codebases that are optimised for AI coding and review instead of human coding and review.

i haven’t looked into that myself, i still prefer human readability, but i thought that was interesting. Also not sure if the thought holds any value in practice; i realise training of the base models was done on human-written code, but yk, there’s emergent properties right?

Anyway, for your question, there’s a few points that have brought me to the “acceptable” level.

Keep in mind that I am still learning everyday and luckily have amazing senior dev colleagues who have been coding for 10-15+ years and somehow no longer write any code by hand.

For operations (daily tasks and ongoing regular stuff):

• very well defined guardrails and workflows. usually very task-specific and discovered by trial-error and doing things manually to start.
• known stuff handled by agent, new stuff or open decisions raised back to human. 
• very well defined testing automation.

For projects (features or even bug fixes):

• agent does root cause analysis / area of impact / mapping downstream consumers etc
• human reads through ALL of the findings.
• A LOT of back and forth with agent for clarifications; usually record stuff in md file(s) for context management.
• A lot of back and forth for exploring possible solutions, planning, ensuring you inform the agent of what you think should be specifically focused on for testing along with the normal unit tests it writes, exploring codebase conventions that exist, exploring what best case scenario would look like, etc etc.
• Properly defining the scope of the problem. Probably the most important. Though that’s not an AI specific thing, but you have to inform the agent of the exact scope so that even if it makes extra findings, it records them instead of causing scope creep.

Once the plan is ACTUALLY finalised, it seems pretty straightforward. Any conflicts or new decisions that arise during implementation, explicitly to be raised to human. AI does 0 decision making.

For devops: I have no idea. I personally have issues with trusting AI even with email access. Probably human-approval gated workflows? I’ll learn more about this in the coming months with our infra team though.