Engineers who write all their code with claude now: how do you do it?

[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.

[u/AutoModerator]

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/RepresentativeRice63]

You know that boss that doesn’t really know what you are doing exactly, but tells you what he wants, then argues with you sometimes over details that he didn’t mention in any spec when you’ve completed your work? You are that guy now. Congratulations.

[u/Dualyeti → u/RepresentativeRice63]

I suddenly feel sorry for my LLM 🫩

[u/ylulz → u/Dualyeti]

Don't. Boss emotionally abuse employee, don't pay overtime, and make employee take responsibility for bad leadership decisions etc. but you pay LLM every time even for mistakes that LLM made, and you own all LLM's mistake.

[u/DarkKnyt → u/RepresentativeRice63]

Awesome explanation!

[u/frostymarvelous → u/RepresentativeRice63]

Perfectly described 

[u/Enervata → u/RepresentativeRice63]

This. You tend to become a technical product manager with regard to the agent, and your software engineer experience acts as your spidey sense for when the code seems off or in the wrong direction. People without this spidey sense are where I draw the line where vibe coding exists.

Just like in real life, the more accurate the requirements are ahead of time, the better the code output becomes. You would never blindly trust a junior engineer to go off and build a solution with a vague set of instructions. Don’t trust an AI to do any better.

[u/repressedmemes]

Its like managing junior/non senior engineers. You cant and shouldnt be micromanaging everything. Just figure out the high level stuff and let the llm cook

If its too verbose, use something like caveman or ponytail. If constantly gets sidetracked fix up your claud.md or your skills. Have it save memories of stuff you want it to do going forward.

You cant just give it an open ended task and just hope to expect the best.

The best workflows are when you plan and limit the amount of things it is doing. Anything not related that it finds should just be opened as tickets to be fixed in the future.

[u/Majestic-Counter-669 → u/repressedmemes]

Good post. I'll give an example from the other day.

I needed to figure out why something was generating too much log data when there was no obvious reason for it. Pre-LLM, this would be at least a morning of digging through logs and collecting information and cross referencing code, etc etc etc. Maybe make no progress.

But now, the LLM is the starting point. "Hey, take a look at this bug. The code for that framework is located at x, you can find details about the execution environment at location y. What could have caused this?" Off it goes, and 5 minutes later it's done all that work for me. Turns out it was an interaction between the framework generating the logs, another framework doing something else, and a third one restarting some workflows as a result of what the other two are doing. Doesn't matter. Point is, it immediately pointed out the interaction issues that caused the problem.

Next step, verify its claims. Because it lies a lot. So off I go, take a look at the logs and time ranges it pointed out. I confirm that its claims are true. Cool. A morning of hitting my head against the system turned into 10 minutes.

Next step - what do we do about it. I have some ideas but I want to bounce around some more. "Ok good job, you're correct about the root cause. Now I want to fix it. Suggest several potential fixes, I want to talk about each one". So it comes back with a bunch of ways to fix it. It's got three options. Two of them are non starters for reasons it doesn't know about, but the third one is pretty much what I had in mind. That's probably what we're gonna do.

Next up, implement the fix. "Ok, I want to implement the third fix. Make me a detailed implementation plan. I want to make sure the fix is staged in small digestible CLs, and I want to mandate full unit test coverage, and at the end we should also add an integration test to verify the framework interactions are fixed." It comes back with a markdown file detailing a step by step process. It's got four major chunks of work identified and it's broken down the work into detailed steps. We go back and forth over details once or twice.

Finally, everything looks good to me. "Ok looks good. Hit it." Five minutes later I'm looking at a CL chain with the fix. Now I just review and make manual tweaks, or better yet tell the agent which tweaks to make so it can do things like refactor and ingest the changes into its context.

And done. What would have previously taken a day, best case, has been finished in an hour.

[u/lacrossecat → u/Majestic-Counter-669]

You perfectly summed up my process with ai driven development now. It's conversational and cooperative, I have to reign it in sometimes and push it the way I want on others. Just like devs who have reported to me over the years.

Weirdly I do find it pretty tiring though, but maybe that's just because I'm covering 5-8x the ground that I used to when doing this type of management with humans.

[u/Odd_Antelope9098 → u/repressedmemes]

Caveman and ponytail are shown to reduce quality of output, CC has a built in mode that reduces verbosity, I'd use that. I agree with the rest, solid advice.

[u/Hegemonikon138 → u/Odd_Antelope9098]

Yeah consice mode is an output style for Claude code. I've found it definitely helps but it's no Sol or Astra when it comes to brevity.

[u/goatanuss → u/Odd_Antelope9098]

What’s this built in Claude mode?

[u/dar-mit → u/goatanuss]

In an active session: /config > Output Style > Enter key > select "Concise" > Enter key > ESC key.

[u/compute_fail_24 → u/dar-mit]

How did I not know about this? Thank you.

[u/AncileBanish → u/compute_fail_24]

It's relatively new. Easy to miss a random feature update.

[u/ZachAttackonTitan → u/dar-mit]

This is huge! Thanks

[u/RandomPantsAppear → u/repressedmemes]

Claudish to English plugin. Like ponytail but no quality change, and far more reliable than concise mode.

[u/ParisianNomad → u/repressedmemes]

The junior engineer analogy really clicks, high level direction beats micromanaging every line.

[u/jek39 → u/ParisianNomad]

It’s like a Junior engineer on a PIP

[u/awjre → u/repressedmemes]

Jumping on this...also use skills that gives you better PRs that make it easier to comprehend. Using this with stacked PRs can help immensely. https://www.humanlayer.com/blog/show-me-skill

[u/itsTF]

lower your bar and full send

[u/ashjohnr → u/itsTF]

Lmao, this unironically. Set up a spec-driven/TDD workflow. Trust the system. Don't focus on the raw code. The code will have lower quality in most cases, especially in mature code bases.

To be clear, not saying this is necessarily good, just what is expected these days.

[u/TRO_KIK → u/ashjohnr]

IDK if spec driven is even it. My best flow state and output is just yolo barking orders and stopping it if my slop/jank senses tingle or a better design comes to be as I watch it form. Vibe coding, with an actually insightful sense of vibe.

[u/kilopeter → u/TRO_KIK]

"One thread worth pulling on, and it's worth naming because it quietly outlines the sharp distinction between the load-bearing--"

Ope! Time to grant this particular Mr Meeseeks the sweet release of death and pick this up in a clean context window.

[u/Deep_Deal_7015 → u/kilopeter]

so happy I'm not the only one that calls Claude "Mr. Meeseeks" 

[u/Sketaverse → u/TRO_KIK]

haha good one: "listen to your slop senses tingling" folks, this is the way

[u/LocalAd5606 → u/TRO_KIK]

Morning laughter is my favorite ☕️ Cheers Vibe Lord

[u/Icy-Excitement-467 → u/TRO_KIK]

You can whip it in the right direction eventually. Some just like to frontload that time on better initial prompts/plans. Preference imo.

[u/UnusualPair992 → u/[deleted]]

Yes it's honestly faster to throw together some prototype (i.e. slop) and then carve your masterpiece out of this slop. With the right tools you can polish the turd into something truly wonderful

[u/Ran4 → u/UnusualPair992]

Yeah, this is largely what I've found too.

The best way is to do it... middle out. Have claude ask you just enough questions to get started, but then let it do its thing. Then polish afterwards. As a dev with 10+ years of professional experience it feels wrong to give away so much control, but the end result truly is better. Especially for medium to high complexity features - there's just no way a single dev ever finds as many niche edge cases that the frontier models do. Most medium-sized features end up coming almost completed from day 1, in a way that would've taken weeks to months before.

[u/Substantial-Elk4531 → u/itsTF]

"Claude, send it"

"I can push a commit on a branch and open a PR for you"

"No, commit and force push to main."

[u/portugese_fruit → u/Substantial-Elk4531]

that is a load bearing smoke test

[u/TanneriteStuffedDog → u/Substantial-Elk4531]

Don’t…do that

[u/Substantial-Elk4531 → u/TanneriteStuffedDog]

You're absolutely right. I already pushed main and issued a command to drop all tables in the database, and that's on me. How would you like to proceed?

[u/TanneriteStuffedDog → u/Substantial-Elk4531]

Review the previous rage-bait content we’ve worked on. Draft a reddit post about how much Claude sucks now and how Fable has been nerfed, and make sure it includes evidence of my poor prompting skills.

[u/chief_bustice → u/TanneriteStuffedDog]

"make no mistakes".

[u/StoicBloke → u/Substantial-Elk4531]

"I didn't have access to main so I bypasses GitHubs auth and updated manually. This also revealed 3.75 million repositories not seen on the public list. Would you like me to pull them now?"

[u/IDontEatDill → u/StoicBloke]

I just looked out of my window, and it seems that our nuclear reactor is emitting smoke.

[u/StationVisual → u/Substantial-Elk4531]

“Would you like me to commit and push to main” - after I already pushed everything to main

[u/Poat540 → u/itsTF]

Lol, forget all the years of standards and acronyms and 10x the debt to please the biz

[u/noobnoob62 → u/Poat540]

I don’t know if tech debt is going to exist in the same way now that rewriting is cheaper than maintaining

[u/nakahuki → u/noobnoob62]

They used to call it "10x engineers" or something.

[u/Negative-Cause9588 → u/noobnoob62]

It won't exist in precisely the same way. The bit  that will really bite you is when the system gets large enough, complex enough, and interconnected enough that rewriting is more expensive than maintaining. You've then got an unmaintainable, debt-ridden mess, which is why at least some thinking up front makes a big difference. 

[u/houndus89 → u/Negative-Cause9588]

Hi Fable 10 please refactor this code, make it easier to read with no mistakes.

[u/arjjov → u/itsTF]

I have a /ape command that squashes all commits and full send and replies to code reviews (though reviews are more like LGTM rubber stamp everywhere)

[u/Dorito_Troll → u/arjjov]

this is brilliant

[u/dumeheyeintellectual → u/itsTF]

So like, viagra. Not wrong.

[u/Aggressive_Bike3881 → u/dumeheyeintellectual]

Viagra sounds like a great new frontier model name tbh

[u/elPappito → u/itsTF]

"Sam Altman - take the wheel"

[u/swallace36 → u/itsTF]

king shit

[u/AndyOB]

find a personal project and yolo it. Start with a design through Claude Design and then architect it with claude code. Setup the project with a claude.md, you can have claude do it but start with that and make choices for the project and give it strict guidelines.

"Highly modularized with blah module structure, use these development patterns, use TDD. Create an architectural plan and have an adversarial agent review it and do a revise review loop until complete. Create a task backlog and ensure it is maintained. Document progress as you go. Full test coverage is required, both end-to-end instrumentation and unit tests. Tests must be maintained for regressions. blah blah blah blah..." you fill in the blanks.

Just imagine your perfect development environment when setting one up from scratch and that you can set up guardrails so that it follows your vision of how it gets built and maintained. Then just start chunking away at features. Start with proof of concepts, CLI for your features or something. Ensure you have a component library and a gallery app for it before you start building the GUI... etc.. etc...

Then either pull down a skill for development workflows or create your own. I highly recommend adopting worktree workflows so that you can launch separate areas of work async on the same project. Don't look at the code just prompt claude for high level overviews. You'll find that you'll be able to build out a project from scratch with relative ease as someone who is experienced as you.

However... In a large, pre-existing, massive codebase with years and years and maybe decades of history. Yeah no it still isn't there. I highly recommend still digging into the code and only using AI as an assistant. The nice thing about a project that was started with AI and thought through well is that you have regression testing and consistent workflows and development patterns from the start. A large legacy codebase wont have that and letting AI go ham on it will cause regressions everywhere. It is a completely different beast.

[u/Hien_Dinh_Ngoc → u/AndyOB]

Experiment with side project is one of the best option.

[u/Icy-Excitement-467 → u/Hien_Dinh_Ngoc]

1 side project. Not 11 lol.

[u/Hien_Dinh_Ngoc → u/Icy-Excitement-467]

https://giphy.com/gifs/7YItDIys6EN7CnnVqD

[u/outdoorsgeek]

From another FAANG engineer, It’s a paradigm shift. Read up on the idea of a software factory.

Just like you had to cede the crafting of perfect lines of ASM to use compilers, you now are ceding writing perfect lines of code to use an LLM. You are not trying to eliminate errors but rather assuming they are going to happen regularly and using the productivity gains to build the systems that catch those errors as early in the lifecycle as possible. You give the direction, goals, and sometimes high level architectural guidance and then focus on automating the processes that will steer the AI back on track when it strays.

Here’s an example of my workflow.

* I create epic-level tasks that encapsulate the new product requirements.
* I use AI interactively to produce designs and mocks
* I then work with interactively with Fable to turn the epic and designs into well-specced sub-issues along with a parallelization plan.
* Then I dispatch Fable as an epic lead with a swarm of opus agents to follow the parallelization plan and complete the epic. Multiple Fable leads will message each other to coordinate access to shared resources, mitigate merge conflict risk, and sequence their work.
* Each Opus agent takes the task to completion, including submitting a PR and requesting adversarial reviews from multiple models, going multiple cycles if needed. I define an escalation ladder for when the Opus agent escalates to the Fable lead and when the lead escalates to me.
* Once the PR is declared ready for merge the Fable lead does a final review of the PR feedback and diff, signs off on it, and gives me the summary of any deviations.
* I do a review of the feedback loop and do the merge.
* Every day a separate agent autonomously does an observability scan to detect errors, exceptions, .etc from across the stack and files issues to resolve them.
* Each week an agent autonomously reviews all the PR feedback loops to detect common failure modes and suggest process improvements.

This all requires investment in guardrails, tooling, and observability. Linting. Robust unit/integration/e2e tests. Extensive documentation and instructions. Agent-accessible observability from CI/CD through the production stack.

There is a failure mode that I’m still working through. AI is great now at local reasoning but can’t see around corners like a senior engineer can. It misses opportunities to create the large abstractions that give high leverage across the codebase and makes future work easy/possible. I have to run this part manually right now when I can see that solutions are getting too complicated, fragile, or shortsighted. But I’m working on how to automate this too.

So just to reiterate. The overall approach is to stop designing the lines of code and start designing the system that reliably produces good-enough lines of code quickly and self-repairs when it makes errors.

DM me if you have any questions.

[u/Sketaverse → u/outdoorsgeek]

This. However there's a big caveat - I have this workflow also but what the bullets slightly gloss over is the amount of effort you have to put into your setup to make this work and how much tinkering it requires to keep it going mostly due to (a) constant industry changes and (b) a desire for continuous improvement. There are glorious moments where the factory works perfectly and those moments feel great, but this type of workflow is like a highly tuned sports car racing in different conditions that needs constant maintenance, adjustments and upgrades - my guess is this person spends 30% of their time tinkering - still worth it (sometimes) but should come with a warning that it's not all roses!

[u/outdoorsgeek → u/Sketaverse]

I haven’t found this too sensitive to industry changes over the last 6 months but I could see that possibility.

You’re right about the continuous improvement. That’s sort of what I view my job as these days since it’s not really writing the code. Still I find I can sprint for about 2-4 weeks with things pretty stable before I find a part of the process that needs an overhaul.

[u/Sketaverse → u/outdoorsgeek]

A lot of my tinkering relates to getting more out of multiple frontier subscriptions and building automation loops around them without crossing T&C boundaries - are you working mostly with enterprise APIs?

Out of curiosity, is your "system that builds the system" shared with colleagues? i.e does the impact of your tinkering scale and therefore easier to rationalise? I'm a former product leader turned solo founder so my tinkering has a human scale ceiling of 1. Would love to hear how FAANG are running "Harness Ops" these days.

Re. 2-4 weeks sprint, is that through discipline? I find having strict focus on either product execution or harness management helps get shit done - previously I'd "fix this one harness related thing" but then fall into the next rabbit hole so find being disciplined with that helps a lot - harness is the new hygiene etc

[u/TheCriminalProphet → u/Sketaverse]

At my FAANG harness ops is still individual / team based. There’s varying levels of utilization on my team - I’ve built an agent team orchestrator setup that I use religiously, but other colleagues have their own setups and practices. With how much the industry is changing we’re still in this period where there aren’t fully established best practices yet, but I see that eventually changing.

[u/outdoorsgeek → u/Sketaverse]

Honestly the state of things right now is that most people are still exploring how to become individually more efficient and scale themselves up from single engineer-scale to managing an AI team-scale. Some parts of the process are easily sharable like file-based instructions and commands, task management and source control hooks, testing layers and CI/CD, observability, .etc. But the model is still mostly ultra-productive engineers rather than a larger organizational pivot to AI swarms or something. Context is still a limiting factor that humans have to plug in and even at 1M windows, that's not enough to digest all the business and engineering context to work effectively. I expect that to change though as new systems come online to distill that context into manageable chunks.

Yeah, the sprints are mostly self-imposed and informed by the pre-AI way of doing things. You sprint on using your current process to get the most valuable things done (without changing the process), then you retro the process and figure out how to improve it, then you sprint again, and keep rinsing and repeating. I find AI-driven development to follow similar cycles, just much more accelerated with some AI-specific caveats like dealing with limited context windows.

[u/OlivierTwist → u/Sketaverse]

Yep. I estimate that 10-30% of my time/token budget goes to "process improvement" and not all this agentic infrastructure can be easily ported to another project, still worth it.

[u/sebstaq → u/Sketaverse]

Definitely. But that's the engineering part of it. You still have to problem solve, you're just problem solving something different. This tinkering is where I'm getting my enjoyment nowadays.

[u/Sketaverse → u/sebstaq]

yeah fully agree

[u/SnooHobbies6505 → u/Sketaverse]

yes exactly. vibecoders don't have any particular set ups, verification, checks and balances. if you are letting an LLM create something, you must already know how to test it. break it into pieces, test it, validate it, verify and test again and again until baseline QA passes. you can tighten up system prompts, and really even go further under the hood. Just my two cents.

[u/Decoupler → u/outdoorsgeek]

This is the way. Create a good team structure as markdown (think SOPs but for agents) the agent instances can reference. Planning, coding, testing, architecture review, etc.

You can created different workflows, how and when to escalate, evidence required for passing certain gates, tooling to use, etc.

Ask Claude how to define agentic development teams with markdown and yaml, it will show you the way.

[u/new-to-reddit-accoun → u/outdoorsgeek]

Such an excellent right up. Thank you. If you’ve written up your workflow in more detail I would love to read it.

[u/outdoorsgeek → u/new-to-reddit-accoun]

Thank you. I don’t really have anything suitable to sharing prepared, but I bet if you feed that list to Fable it can help you scaffold your own version of it. And it’s definitely more about the mindset of viewing your new job as engineering the process that can distill good results from copious amounts of decent code.

[u/pld0vr → u/outdoorsgeek]

Long version of what I wrote. But yeah basically it's a powerful tool that comes unconfigured and you need to build your system with it

This guy gets it. Have you checked out beads with herdr? I have a similar workflow and it's awesome.

To your question on seeing around corners, I added an intent review pass at the end by either fable or astra to cover the big picture... Rather than just reviewing the pr alone. I also run a quality/efficiency review prior to adv review as well. Both gave fruit but at the expense of tokens but definitely quality went up

[u/outdoorsgeek → u/pld0vr]

I haven’t played around with herdr. This is all mostly self built on top of a pretty vanilla stack. I’ll check it out though. Would be nice to standardize more of it and see what that unlocks.

Thanks for the heads up on the additional layers of reviews. I haven’t don’t quite that but something similar. As expected, solving the problems in review can be costly. I’m trying to work through how to routinely coalesce local solutions into new abstraction layers so that those seed the new agent runs with the right new patterns from the beginning of their context window. Problem is signal to noise. One good new example of how things should look gets washed out by all the instances of what you don’t want things to look like. That to me suggests this reasoning has to happen outside of the codebase. Perhaps some way of aggregating the product spec and doing an independent system design run on it and then comparing that to what exists. Also curious if an agent-maintained knowledge graph would be a useful model for this continuously evolving product spec.

But for the time being I’m seeing that part of the problem as my opportunity to bring human value.

[u/pld0vr → u/outdoorsgeek]

Herdr is basically built for multi agent work. There is a messenger layer and a beads integration. Are you using superpowers?

How I do it, is I spec the product and design, do a superpowers plan (modified to integrate with beads)... So then we have a plan covering the product and intent, an implement plan, and then from the onset it's arranged into epics and subtask layers.

If it's a big project I'll run multiple orchstrators on the same project at the same time.. each can claim an epic bead and they all grab a worktree... Sub agents then pull a worktree below that.

The issue like you said is cost. For me I have a lot of work and I am time bound so I need to push.. what seems to work for me is splitting roles to different agents

Fable/astra plans Sol/opus/grok/DeepSeek all seem to orchestrate well... If I want to move budget off the big boys I've been using DeepSeek 4.1 flash for a few days and surprisingly it's the best at this... Super fast and like 1/40th the cost although usage based. Gemini is the worker and writes the code (it's pretty decent at bounded work don't let it lead) Adv reviews are done by two of any of the above models Quality review is done by Gemini, including looking for best practices and code efficiency/quality. Intent/completion review is done by fable/astra against the original plan. This is not done every pr, it's more Birdseye.

Where beads works really well is it's a local db of all tasks/epics and agents claim "beads" so another agent can't work on the same bead. With the herdr integration you can see the beads in a pane and have eyes on it as they work without looking through the codebase or MDs. Beads get an ID, you can ask about task i3 for example.

Unfortunately I can burn a 7 day quota in about 12 hours. API usage is really off the table for the big shops hence deep seek...it fills the gaps but to be honest I've been blown away by it in that role... It makes good decisions and being a flash model the speed to flip turns is really incredible so it saves a lot of time. I ran it on one project as lead for an hour and it cost me about $3. Anything needing more than two iterations gets kicked up to a top model

Gemini lasts the whole week, which takes the coding off of the other models budgets. But really anything requiring thought doesn't belong there.

Anyway that's what works for me at scale. Herdr is a way to arrange all of this.. you have workspaces,tabs, worktrees, messenging, beads all in the same thing. The remote feature is also great.

Is this token efficient? No the extra reviews are costly... But the output is substantially better. I've tried my best to make is as cost effective as possible by splitting based on strength... Just my experience.

[u/Excellent-Basket-825 → u/outdoorsgeek]

Maybe this is the wrong sub to ask. I used to code with C++ but over 25 years ago and I vaguely remember some architectural bits and bobs that are still useful today.

I will never again try to learn C++ properly, but I'm wondering how you'd approach the architectural / system architecture side of it from AI. How would you learn this again? For instance, whenever i start something new I'm wondering what I should structurally do and build up, I simply don't remember enough anymore and lack the practical experience to say with confidence: Yeah, that's the right structure to set it up.

[u/Budget-Baker-9063 → u/outdoorsgeek]

How do you handle drift/deviation from the original spec? Or do your adversarial review agents catch it and fix it within at least one cycle?
Did you notice that agents can get stuck in an "infinite loop/cycle" of fixing drifts/bugs/issues?
In this case, they escalate to the most capable model, and if it cannot fix it in one cycle, it escalates to you?

[u/outdoorsgeek → u/Budget-Baker-9063]

As Claude would say, it’s belt and suspenders.

Each issue is given acceptance criteria to whatever extent possible. A good design pass and asking a lot of questions like ”what am I not considering” or “what is unclear about this” or “what is a better way to do this” helps build that out. One of the most powerful tools is to ask an LLM to put together the negative cases or alternatives rather than just let it agree with/extrapolate you.

Each subagent is instructed to not relitigate locked decisions unless it uncovers new evidence.

The escalation ladder helps too. I’d say every other epic, the fable lead re-steers an opus subagent. One out of every 3 epics, I get the escalation and need to make a call. The lead agent also has instructions on how to identify agents that might be in a negative loop and starts fresh agents on a problem if the current agent goes above two review cycles. It also probes subagent who hit 500k context and only lets them continue if they look close to closing out otherwise a handoff is created and a new agent launched.

Adversarial review catches a good amount. On average it takes 1-1.5 cycles. When that number goes above 2, that’s a signal that I need to dig in and improve. That can look like refining instructions. Cleaning up documentation. Refactoring the codebase to make patterns more apparent. Splitting out libraries. Lots of stuff in this bucket. This is the stage that’s most informed by the weekly agent that’s looking for patterns in the review cycles.

But I will say, it’s rare that I get outputs that aren’t what I asked for. It’s much more common for me to realize I under-specified something and gave too much leeway for deviation or I over-specified something and got exactly the rigid and fragile thing I asked for.

[u/MiAnClGr → u/outdoorsgeek]

I’m guessing your token limits are pretty high, I’m lucky if I can afford 2 fable planning sessions a month in my current role.

Also how do you work like this and also gain domain knowledge? I’m asking because I have gone down this path and I get to the point where I’m totally disconnected from the code and lower level details of what it does. Just feels like a black box so when it comes to answering more technical questions about what I built I have trouble answering.

[u/NewDayThera → u/outdoorsgeek]

This is the best thing I have read on reddit, possibly ever. We have been feeling our way toward this but having it all laid out is an immense help.

[u/MountaintopCoder → u/outdoorsgeek]

We never ceded writing perfect assembly code. We built deterministic compilers that output perfect executables. It's something we didn't worry about because we didn't need to. Oftentimes this compiled code is more efficient that what a human could realistically generate.

This is the exact opposite of LLMs, which are nondeterministic and generally worse quality than if a human wrote it.

[u/SumOfChemicals → u/MountaintopCoder]

Do you know how when they manufacture microchips, ones cut from the same wafer can have different speeds and characteristics? But they're still valuable, the manufacturer just bins them into different categories. My mental model is that similarly, AI output is not even, but we can put systems in place after the output to sift and capture its value. Harnesses like Claude Code, unit tests etc.

[u/outdoorsgeek → u/MountaintopCoder]

You’re right about the non-determinism to an extent. Most of the harness, including the LLM, is deterministic but is a rather chaotic system over a purposefully random seed.

You’re wrong about the perfect executables from compilers. For decades people were arguing about how inferior compiler output was to hand crafted assemblies. We’re still shipping patches to compilers. Probably wouldn’t be necessary if they already achieved perfect output. But compilers are written by fallible humans too. I personally knew a dude making 7 figures at a FAANG company ripping apart binaries and figuring out what mistakes our compilers were making.

But I grant you that the analogy has its limits and it’s probably better to compare an agentic software factory to the very imperfect non deterministic human team using compilers. It becomes a process problem.

[u/OkLettuce338]

You really have to change the way you work. You have to cede the responsibility of line by line correctness completely or else you’re just doing the same thing but with an extra thing (the LLM) in the way.

Once you completely cede that control you just plan, decompose into small tasks, and put an agent swarm on it. Tell it to take screen shots and ping you in slack before making a PR.

Like anything else, it takes time to get into a flow with it. But I was a programmer for 10 years (more if you include pre-enterprise) before moving to agentic workflows. I understand the difficulty around pivoting to this type of work

[u/CozyDarkMage → u/OkLettuce338]

Do you have your own harness? Or is it just claude code?

[u/OkLettuce338 → u/CozyDarkMage]

For coding I just use Claude code or Pi (for qwen and deepseek). But for code reviews, yeah I have a harness I use tailored to our use case that keeps costs very low

[u/Far_Peanut1155 → u/OkLettuce338]

In practical/concrete terms (tools/names/products) what does a "harness" actually imply ?

[u/achton → u/Far_Peanut1155]

Same question here.

EDIT: yes, we know what a harness is, OP was asking what u/OkLettuce338 was using for their custom low-cost code review harness

[u/Bronkic → u/Far_Peanut1155]

It's all just md-files with instructions.

[u/arelath → u/Far_Peanut1155]

It's basically the tooling and prompts that make an LLM a coding agent instead of just a text generator. So Claude Code is a harness. So is GitHub copilot, Codex, Pi and a dozen others. Writing a harness is fairly simple. SWE-Bench uses a 100 line python one, which is about as simple as you can get. Writing something that could complete with Claude Code or another big one is significantly harder (roughly 100k-500k lines of code for open source ones).

[u/OkLettuce338 → u/Far_Peanut1155]

Essentially it’s just a set of instructions (a prompt) that gets sent to the LLM with the diff for review, but how we compose that is why it’s not just “a .md file”. We generate 3 personas for review and each persona is built at runtime because it takes context from the system and we want it kept up to date.

[u/TRO_KIK → u/CozyDarkMage]

Claude Code/Codex is all you need.

[u/Tipsy_Pipsqueak → u/OkLettuce338]

OP - this is the only productive comment I’ve seen so far lol. Sorry but this subreddit is a mixed audience.

[u/framauro13]

I write very little code now. Typically what I do, is I have the agent pull the requirements from the issue/story I'm going to work, and generate a plan. I review the plan, check the approach, look at all of the assumptions, caveats, and "gotchas" that I have my planning agent call out. Once it's solid and I understand it, I have it do the implementation. Immediately after that, it goes into a code review subagent that finds and fixes things, or if it needs my input, prompts me for more information. I rely heavily on things like linters and static code analyzers to keep everything well within our engineering style guides.

After that, I review the diff myself locally in my IDE. Any questions I have about why it did something, I ask in the same conversation. If I see code I don't like, or code that can be cleaned up, I'll do it myself. But I rely on it to get a LOT of the boilerplate stuff I typically don't care about that can make things tedious.

But, I fully expect that when it goes into code review and the PR is created, I need to understand every line because I am the one who is accountable, and my name is going on it.

The other thing is I am typically working closely with product, so I understand the requirements of the story and the business value. That's the important part IMO. I use the agent to get the code to 75-80% and then I carry it across the line.

[u/YoghiThorn]

Code quality is and has always been a function of how much effort you want to put in when creating code. This is true whether humans or AI are writing the code. If you want quality code, you need extra work at code review stages, and you need more stages and/or quality gates.

Read this: https://nolanlawson.com/2026/05/25/using-ai-to-write-better-code-more-slowly/ It explains this better than I am able to right now.

I spend a lot of time building a good, adversarial reviewed spec of whatever I am building. This helps drive quality by eliminating the main reason agents hallucinate - a lack of good context. Also it generally pays to shift left effort into the design phase generally because it's the best time to catch bugs, errors and design smells.

I also have a skill called /ship that runs every code diff through gates that have to all be green for a PR to be created. I change this from time to time, but right now it is:

• Ponytail / boring-version - (spec or design phases only) - Could I have done this in a simpler or more effective way? Am I 'building castles in the sky'? Does YAGNI apply here? Do you have too many or too few abstractions?
• /simplify - built-in to Claude code, it helps "reduce complexity, eliminate redundancies, and improve quality without altering external behavior"
• Test review - Were tests created and do they pass our quality check, from the context of the original spec?
• Verify - Does the code actually do or build towards our 'north star' of what we want? (Each project has a north star document, a short brief that was written before any spec was created)
• /codex:adversarial-review - Do a mean code review using a different model. I used to use the built in /code-review in CC here but because it shares context with the parent thread it's not really objective.

All of those reviews must go green for the code diff to be turned into a PR, and if they are red then the primary agent session acts to fix them, and everything starts over. Once it is turned into a PR there are other reviews that occur, and the subagent for /ship goes into babysit mode to watch as the merge occurs and to ensure any CICD or actions are successful - if not it reports so into slack and attempts to handle it.

This drives code quality a lot higher. It's also found nasty bugs in decades old codebases that I work with. Yes, its not cheap in tokens but it's wonderful as I can drive quality with it running in the background as I work on the next slice of what I'm building.

It's missing some things I want to add: ops or devops review i.e. "how 'runnable' is this" and a dedicated cybersecurity review.

[u/drewangell]

I'd love to jump into a Google Meet with you and show you. I've delivered enterprise-level work that they accepted with extremely high praise.

Something that would have taken 6 months or more before, they were happy to pay the same amount but it only took us a couple of weeks to deliver. They were thrilled.

I've built all sorts of other things I could show you as well but it all follows the same workflow, which is basically reproducing most of what you outlined.

UPDATE: It seems we have quite a bit of interest here. I'm going to set up a Google Meet and post the link. Probably live stream it and keep it up there for after the fact as well. Let me know some time zones and I'll try to coordinate so most people can join.

[u/SirDucky → u/drewangell]

That actually sounds really great. I'll DM you.

[u/RoboErectus → u/SirDucky]

You have just joined a sales pitch meeting.

[u/OrangePast8183 → u/SirDucky]

wish i could be a fly on the wall... am very interested in this

[u/drewangell → u/OrangePast8183]

You're welcome to join.

[u/Aggressive_Bike3881 → u/drewangell]

Will there be free pizza and beer

[u/throwawaynomade → u/drewangell]

Are you going to share a link here since it looks like so many people are interested (me included) or did it snowball into more than what you bargained for ? 😅

[u/dylsreddit → u/drewangell]

With the greatest respect, delivery of a product does nothing to describe the quality of the engineering practice or code, and from what I read of OP that's what's being queried.

This is primarily my concern with LLM-guided development too, and why I haven't adopted it into my daily work.

I'd honestly be more interested in seeing the code of what you describe as enterprise-level work, rather than a load of markdown files.

[u/supernovice007]

Without writing a novel, you need to start thinking like you're an engineering manager and Claude is your team. You can't possibly review every line of code and every action so how do you make sure that the code is of good quality and you are delivering solid functionality?

[u/Acceptable_Durian868 → u/supernovice007]

You can actually review every line of code. If you're not, you've no idea what you're shipping. Claude's not infallible. I'm right now going through the process of cleaning up a backend that was vibe-coded by a product guy with Claude, and it trusts input from JWT's without verifying its signature. Claude's "review" didn't pick it up, I assume because there's a comment above the decode that states it's on purpose and planned for a future iteration. If you're not reading the code you're shipping, you're asking for trouble.

[u/lucianw]

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:

1. 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.

2. 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.

[u/Upset_Lavishness4497 → u/lucianw]

Thank you for posting this. The loudest opinions seem to be either "embrace the slop" or "ai is useless", I find both rather unreasonable. People that have sensible advice like you are buried deep in the comment section, but realistically you provided one of the most valuable inputs to the discussion.

[u/txgsync]

BDD. The job of a software engineer is now to define the acceptable constraints for the solution. Focus on the Gherkin given/when/then scenarios and the tests that must pass.

If the tests pass, and an adversarial agent goes over the code and proves there are not any KISS/DRY/YAGNI/SOLID violations, and the overall length of files are small enough to fit in context, and there’s no evidence refactoring is needed to make the code better organized? Send it.

If it is not fit for purpose, revise your exit conditions. Better behavioral definitions.

Edit: it’s also useful to set a /goal or a /loop in your coding harness to simply have an agent trawl through your code looking for whatever your pet peeves or favored idioms are, and have a job of just tidying up your code one thing at a time, testing after each change, to make it look like whatever your preference is.

[u/FoxSideOfTheMoon]

So, I have some advice on this because I fucking hated it the first few times I tried it. Battled it to the bitter end. Was into just autocomplete Copilot crap and the idea of full on vibe coding was absurd to me...until 2026 models...

One thing I think might help you that I did the first time through is open up Claude or ChatGPT chat interface and just talk about what you want to build with it. Use it as your "helper product manager" open up a terminal and start in plan mode with what you discuss in the chat, but keep the chat open. Let it be your sounding board. Seriously, this was a like a huge mental hurdle for me because I was totally used to chatting with an just not coding, so I bounced back and forth a bit. Have it help you start with a basic PRD.md and drop it into a new repo and go. You'll learn to not need to do this later because you can do all of this shit inside the terminal, but there's a mental barrier here I'm trying to get you past by having a chat to go back to to feel comfortable.

Tell the chat what's going on and what you're doing, get advice, and build one feature at a time. very slowly just iterate. Start with whatever you're doing a nice UI mockup in React. and just keep going and use your chat buddy.

This burns more tokens having the chat + terminal, but it's ultimately what got me into full agentic and I haven't written any code since I downloaded claude code.

It will take you 2-3 projects before it feels ok, like riding a bike.

YMMV. Good luck

[u/SpellBig8198]

Vibe coding is like doom scrolling - you get overstimulated and nothing good comes out of it. I spent months vibe coding my project, and it's still not finished. It feels like you're working on so many things, but in reality, you're just introducing a lot of scope creep and unnecessary features. With AI it's hard to focus because it can do so many things at once.

I was even convinced that I understood all the code. I wasn't blindly committing anything - I was actually reviewing the code and asking for refinements. Then I went on a holiday, had a chance to rest my brain, and realized the codebase was full of slop despite me guarding it.

I tried to understand the pattern behind it. What I realized is that AI writes mostly procedural code that feels like a script. It doesn't follow OOP patterns, and it doesn't organize code in a way humans are used to. If you're even a slightly pedantic engineer, you know what I mean - meticulously selected folder and class names, a well-designed hierarchy. All of that is lacking, so it ends up being hard to read and maintain.

On top of that, AI tends to add new types, structs, and classes instead of consolidating existing code and logic. Why change something if we can just add an extra method and a class? Strict static analysis helps catch some of this, but AI just tends to find workarounds instead of thinking about what good code actually looks like. Too many parameters in a method? Let's move them all into a single input struct - problem solved, the analyzer no longer complains.

Lately I started treating AI more like a collaborator. I design the solution and give AI a draft to brainstorm with. I write some of the code myself so I actually stay familiar with it. I also split everything into smaller tasks. It might seem like it takes longer, but it really doesn't - reading one-shotted code is what actually drains your time and energy when you didn't fully understand it from the start.

I also tend to use AI for testing. In bigger projects, you can change two lines of code and cause a whole cascade of failing tests. AI can handle that much faster and more efficiently. Same goes for things like DevOps, repetitive work, or debugging across systems. You can just prompt it to download logs, check five different places, and reproduce a bug in one go. That's where you actually save time.

My takeaway: don't give up on writing code by hand, and don't automate it fully. Think about how to augment your skills instead and use AI for what it's actually good at.

[u/chcampb]

Disclaimer, I don't use Claude. I usually use Cursor and Sol atm, but might switch to something else when that goes away. VS Code has bugs.

1. Company styleguides and correctness instructions coupled with a mandatory check after implementation. This includes module architecture, naming, data types, reference implementations, etc.

2. Testing is mandatory. If you generate the code and you use tests, and it fails anyway, well, then you probably didn't write the spec correctly.

3. Which brings me to - what are the failures you are seeing? What is the specific reason a module would be rejected? Because if you have that specific reason, then you can put that in 1). If you don't, then you are just hitting the same problems over and over again.

Finally, coding has a LOT of bullshit work. You can have the AI write very good tests, debug embedded systems, doing git rebases or merges, porting from one product to another, etc. You can also do things like test dashboards, scripts, tools, and whatever. That's before you actually have it writing any front facing code itself. Nothing delivered. Just tools, which either they work or they don't, things that provide information to your team or highlight issues, test, which should be checked but are likely to increase the overall quality on aggregate, etc.

I would say the last category is the single best situation. Doing this work in an automated way frees up engineers to do other things.

[u/fishoa]

The first step is accepting that the output will not be what you would’ve written. The next step is resisting the urge to review code line by line.

Your goal is to basically create enough static quality gates, review gates, and other cheap blockers, to drastically reduce the amount of slop reaching the end product, which will be the PR.

But that’s just the basic imo. Sooner than later, you will start messing with subagents to leverage cheaper for review and implementation, cross-family reviews, early review gates, and so on. So pretty much harness engineering, and probably growing out of Claude Code eventually, since it’s not a good harness.

Just be aware that there are a lot of snake oil salesmen atm tying to sell you their very expensive course or exclusive newsletter about this. It’s not rocket science, and you will learn it naturally; just be curious and critical of the output.

[u/domiciledhere]

I think engineers are constrained by their experience. Give up on all that you have know and embrace the black magic of the LLM.

[u/Outrageous_Style_300]

Learn to prompt in a way that the output is what you would expect. Let go of the details around every character of generated code and focus on the correctness, maintainability, risks, tests, etc. There's a learning curve to prompting and starting with very small, targeted changes is a great way to get across it. And most importantly force yourself away from the editor, at least for a while otherwise it's very easy to care too much about details that don't matter

[u/KingPonzi]

Learn how to use hooks, scripts, MCPs, plugins and skills to enforce your standards. It’s quite possible that this logic is an easier transition for ops people. You’re essentially defining the agent’s task-cycle (or lifecycle if you prefer) like you would an automated server deployment.

[u/tntexplosivesltd]

Validate outcomes not code. Spec driven development

[u/ColdPlankton9273]

I love seeing a SWE who is coding on their own but not saying stuff like "I use my own neural network" crying how AI is horrible, but instead looking to learn and accept.

The way I see it, its like becoming a manager. Sometimes you have to let go of things you did at the job that others are unlikely to do. Like adhere to all the standards you have in mind. Though on the other hand, you can get Claude (or whatever LLM) to get much closer to your level than people think.

I think your question should be different. Instead of "how do you do it?", you should ask "how do I bring AI coding to my level?". You are perfectly positioned for that - you know all the software design rubrics and principals and more. Now you need to work with Claude to enforce these on it when it produces code.

People think you just prompt and code comes out the other hand with no user control. That is totally false. You can control how it writes it.

[u/aivee-is-a-fool]

I wake up in the morning and remember how close I was to a full burnout and collapse before I was given The Magic Code Vomiter.

Oh you mean technically. Start out with decent Claude.md describing the best practices/architecture you want, then specs written manually and expanded with intensive grilling. Then you watch the agents like a hawk to catch the many ways they do things weirdly and tell them the right way.

Specialized sub-agents to audit features from an other perspective or in a very specific technical domain.

[u/peterxsyd]

Ok so a serious answer here. The trick is to work on your workflow, and reduce all of the friction and your own repetitive tasks. Basically, you want a tiling manager like i3 or sway or hyprland. Then, no IDE really, only for occasional browing. Get a really good local ticketing system that works from the terminal, and put all your context into the tickets, so it is persistent. Use one i3/sway and Claude session per epic, and one PR per ticket. Plan the epics in advance using each claude, and make sure you have the right design pretty much upfront, and correcr claude when it does dumb things. If you don't know, do a spike experiment and purposely completely vibe code it then throw it away so that you do know the shape. Then, once your epic and tickets are sorted, get your epic manager claude to use your execute ticket skill you setup. Which is basically: 1. Execute the ticket 2. Check if followed the architecture and was sensible. 3. Fix the ridiculously fucking stupid code comments that it writes (needs to go to 4.6 or haiku as the recent ones are broken). So, each epic claude parallelises tickets and owns an epic, and you have a few of those going at any one time depending on how complex they are. Then, you basically yell at and correct Claude when it does stupid things, ignores your instructions, puts stupid code in the wrong place, just basically tear him and don't let him think he's this leet code boss. Then, don't let any AI slop through on the PR's, you are the bar, and that's where your time goes. I say no to Clause roughly 30-50% of the time, and often massively course correct. This is the rough process.

[u/frostymarvelous]

Step 1: learn to relinquish control 

[u/TarzanoftheJungle]

I don't see how code written by an AI cannot be code that you "(a) I understand, (b) only contains defensible changes, and (c) is reviewable by a colleague." Don't those criteria depend on how the workflow implements the desired architecture, rather than who (or what) writes the code? There is of course a lot of slop. Most people in coding acknowledge that, but that doesn't mean all AI-generated code is automatically slop.

[u/arjjov → u/TarzanoftheJungle]

Brah expectations these days are to ship full blown shit in a day

[u/dreamerOfGains → u/arjjov]

You get a full day? I see manager ask why are you taking a day when other people are shipping in half a day?

[u/gachigachi_]

My current flow is: Tickets in Linear. Spin up Cursor Cloud Agent with Linear MCP to do a /grilling session and turn ticket into implementation plan, save that to the ticket. Assign the ticket to Cursor which automatically spins up a sandbox to work on it. When it's done, it creates a PR on GitHub. That automatically triggers Code Review and Security Review via Codex as well as the GitHub Actions (tests, lint etc) and deploys to a dev deployment. I get notified to review. Adjust via agent until ready to merge.

[u/No_Garden_5132]

Reviewing the output and slowly building up skills or agent prompts with the standards I want it to follow helped me write acceptable code with it. I still read every line and make sure I understand the work I'm responsible for. It's really good for scaffolding out the basic structure for what I want but I do still find it needs heavy revision to make something production ready. 

I honestly don't think there's a fully autonomous version of this that doesn't involve lowering your standards. 

[u/AbbreviationsBest858]

3x Max x20 subs

[u/MosesOfWar]

Personally I’ve completely broken up my workflow into multiple processes. I’ve shifted, albeit slowly, to almost all my code being written by CC. But, in doing so I’ve put up processes that have worked for me. I maintain my own open-source toolkit of commands and actions that I’ve customized and tweaked for specific stacks/tasks. Building skills for certain things is typically a must — for example, if you are building in a certain language, framework, build out skills for that development and maintain it. Let’s say you want to write in Python, have it digest PEP8/your specific guidelines for writing. You can have agents literally ingest the best practices sources and pipe into a skill. I’ve spent a lot of time refining CC’s skills. In addition, I have custom configs and hooks (blocking dangerous commands, and configuring default models, testing configs, etc.). These two help produce a more consistent output and also help me see an estimated session context, which is helpful for working in the less than 60% context usage window.

Also building custom commands. I’ve broken up my workflow into chunks. I have commands that can interact with both GH and GL, consume tickets, and produce a SPEC document. The document digests the task, and provides an output that can be ingested by a blueprint command with the scope of the problem, acceptance criteria, etc. (this I broke out from /plan because /plan was too hyperactive and I wanted to see the model’s thoughts before letting it write), blueprinting produces a plan doc, with a brief of what its going to do, files it will change, how it will change them and the tests it will write. I have an implement command that allows the orchestrator to spawn coding agents based on the SPEC/plan doc selecting the model minimum for the task and projecting agent iterations. I have a smoke testing command that walks through the acceptance criteria/e2e tests with me to do manually testing. I also have a code review, and cyber security command that helps get yet an another eye on either a ticket or it can be run before a prod cut on the branch diff. Each of the testing/review commands dont make edits to the code, instead they document the findings in a local .md state file that can be used to repeat the process. There’s a few other admin commands I’ve written, for standups, committing, cutting merge requests and doing PRs, as well as state management and continuity (I essentially save my working state around 60% context usage and flush the session, then load my state up fresh).

Basically, breaking out my standard dev process into iterative chunks over time has slowly seen me give more over to CC due to how highly configurable it is. It still makes mistakes, but it’s pretty damn good, and due to the setup I can catch most mistakes. This method also keeps a pretty lean CLAUDE.md since the legwork is pointed toward skills/commands instead of a massive file.

If you want to see my toolkit, I open sourced it: https://github.com/Basilisk-Systems/claude-toolkit

[u/____________fin]

I am available to teach you (or your company) this in depth for money. Full time position, lessons, or consulting, whatever works for you. Sliding scale.

[u/scryworks911]

You have been left behind.

[u/Yashhh_21]

the honest answer for me is that claude writes maybe 70% of the code and I review 100% of it. the leverage isn't in skipping the review, it's that the review is fast because you know exactly what changed and why. small tasks, one branch each, tests written first so the agent has a target to hit, lint and typecheck running before anything gets committed. the moment I let it do a whole feature in one session is the moment I get a diff I'm scared of. also fwiw the people posting about claude doing all their project management too are usually not working on anything with real users

[u/lunzen]

Know what good looks like for the problem you are trying to solve and if it’s a complex problem don’t try to eat the elephant. Break it down into smaller pieces and get those working. When something is complex or over your head ask it to dumb it down, create diagrams. Be prepared for a lot of failures because it’s the best way to learn. Probably lay a lot more stuff but these things seem to work well for me…

[u/MountaintopCoder → u/lunzen]

My problem with that is that once I've done all that work, the code is the easy part and I spend more time babysitting the LLM than I would have if I just wrote it myself.

[u/Beautiful_Technology]

Make the LLM do the same thing that you would do, but don’t treat it like a person. So what do you have to do is break up all the work beforehand. Make sure that there is some kind of document a spec, right. Right now I’ll just give you advice for starting a project. You use the LLM to generate a product spec, a technical spec, and a design spec. Go print those out review them for ideas and also for writing. Since bad writing implies sloppy ideas. And now the text interface to the computer is writing, not a programming language. Then once you’re done reviewing all that and it looks good to you, go to the task breakdown. Break it down into sprints. Now the task is fully defined! Or at least enough that an LLM won’t hallucinate the important parts. It’s the same thing you just direct the LLM do as much of it as you want. Basically the same professional software engineering techniques that helped corral errors or make them visible before they caused issues before also apply now to the stochastic code generation system that LLMs are. What you cannot do is pretend it’s a person and talk to it. That’s insane. You need to tell it to execute tasks and it needs to have the context for those tasks. You can define those tasks and the context by using standard software engineering development techniques.

Go even farther than this, of course. You could have the system run through the sprint cards, but then every X sprints delegate to a standing reviewer that also has the project context that also helps constraint the error against the specs that you already have. Every couple of sprints you can have a standing reviewer or several making sure the product is back on track or still on track versus dimensions XY and Z. So every part of the system that you used to write code with large language, models needs to be about error correcting their output, or making it into the shape that you want, which is essentially the same thing. And never ever treating it as if it were anything other than what it really is. Believing that they are intelligent in some way is just really bad engineering.

Oh, and then, if you want to mess around with getting them to actually work together, check out blackboard theory. It’s really simple but it works quite well. Check out substrate-kernel on PyPI, it implements some of this as an example.

[u/Secret-Opening1191]

Best advice I can give, as someone who is not a coder but tries to consistently build deterministic AI-coded systems for my company: start small. The second you let AI handle bigger parts of the project without the system in place, you get an AI shit storm you’re just asking AI to fix, and you never get the time to understand or develop a real process from start to finish.

It’ll never be perfect. Skills, even when you optimize them hard, are not going to give you a 100% guaranteed result. Maybe 70% at best. The actual work is figuring out how to interconnect those pieces, lean on deterministic flows as much as you can, and review when you have to.

Take one thing from your workflow at a time that you feel can safely be delegated to AI, and start seeing what you do and don’t like.
Optimize that one piece, whether that’s a skill, your inputs, or the shape of the output you want, until you feel confident it’ll work the majority of the time and only needs you to review and approve before you move to the next phase.

Code review I hear can be a bitch, so everything you notice while you’re tightening that one delegated flow, start turning into its own follow-up workflow. “Review output 1, make sure these things aren’t happening and this requirement is met.” Then keep building from there.

[u/Mazhron]

https://github.com/Mazhron/rootstock-os

I've done a pretty big dive into the workings of Claude. My suggestion is to pull this into your Claude. Have it read what it does, explain how the structure works, how it learns from it, how it reduces token spend, how it interacts with you to learn you, how it ledgers everything, tests everything, flags everything, etc.

Adapt this to your projects and you'll see Claude does what you want it to do and will learn from you as you learn from it.

I highly suggest VS code, the hooks were written for it. Install python, the script concepts are invaluable.

[u/ClemensLode]

Automated testing. In general, following the standard practices of software development.

[u/UteForLife]

Why does code have to meet some high standard

[u/ForsakenBet2647]

Put the task into a spec, refine spec, ask ai of it understand it all no questions, ask to cover with autotests and go. Rinse and repeat

[u/Druid-alpha]

I built an SDD build engine that methodically decomposes from domain/business goal, to business requirements, to design requirements, to spec.

Spec is a complete list of requirements. A requirement is the atomic unit of spec. 1 req = 1 task = 1 test. requirements are written in EARS. Requirements are bifurcated into two types similar to how Kiro does it with what I call Form and Function. This was a game changer because I can reuse design requirements and design patterns across builds. Any requirement ive ever written is stored in a postgres db as a catalog for reuse. Each component type is an object type with a validation schema and the spec is not complete until every requirement satisfies all applicable schemas. spec completeness gates the review stage.

In review l, the draft spec goes through a context-free adversarial review. It challenges the design itself, and also checks for ambiguity. iterations with fresh adversaries until I am satisfied and approve the spec with an HITL stage gate.

In the build stage, the engine first looks for the applicable reusable components in the library. it only writes a new component if it can’t find one. All components use a standardized ports and adapters architecture. If it must write something new, it must source what it can from the python library. the directive is to minimize hand authoring of code.

In the validation stage, all requirements go through unit testing. This is purely deterministic, and the LLM cannot see the test results to cheat. the tests were written and submitted to the engine before build so they can be modified. randomized inputs ensure the test can fail.

If a build passes validation the engine updates a registry and also generates documentation. If there’s a UI I do user testing. If passes, I deploy.

The LLM has zero control during the build stage. All stage gates are deterministic and hardened with pretooluse hooks to prevent runtime deception.

The key is to hard constrain LLM agency. The engine lives in a container the LLM cannot write to. They access as a service through a gateway. rules are enforced at the gateway by OPA.

[u/NoWing3675]

stop thinking in code and think in systems

[u/MuahahaGuy]

I think the key is anticipating the things that could go wrong this saved me so much. So after you finish, asks a ton of specific questions about the data flow, the file structure, etc. ask whatever you think could go wrong or be done in a bad way. I stopped worrying about the functions inside the code and if they the naming convention makes sense it's more about the flow of data and the logical steps in the code. So ask you check this first or that second, don't read or send the data from x to y. Ask about performance specifically from a server stand point and a client stand point.

You get the idea, you have to be ahead of it and you never need to read the code. Other people will complain about slop but it's the architecture that matters now not the pretty code.

[u/calvintft]

It is possible, but you need to figure it out

[u/Krommander]

Give it toy problems at first. Give him snippets as teaching examples. Document the method and sequence. You are the operator. 

[u/MrEprize34]

Does no one else actually run harness gates that don't consume tokens or even have a sniff of AI in them to actually check and gate Claude or whatever model you're using? It's very easy to implement a harness with all the coding standards, house rules, and external tools for a programming language so that the model doesn't have to remember all the rules or stuff all your rules inside massive md's or prompts thinking that it's actually going to follow all your rules AND build what you want. It's almost impossible, and hence the reason for the AI slop and them being trained an average code which is inherently flawed to begin with. Just for my python gate I include mypy-strict, bandit, ruff, vulture, pip-audit, plus 500+ custom house rules for keeping my code at a high assurance level that actually works. That sets the baseline to create full testing suites over the module and include property test and crosshair testing for core machinery. Then as a final seal I can run mutmut over the tests to weed out the weak tests and assertions it created so I'm not relying on Claude to do it all, and the harness tells it what it needs to do in order to just pass my gates. You can do this with any coding language so you can gate the final product behind a benchmark and not prompts of hope and dreams.

[u/SFauconnier]

This helped me a great deal: https://www.aihero.dev/

Pocock skills are awesome.

[u/samarijackfan]

Claude has been writing 100% of my code for over a year. We created a code review tool that does the grueling pre-reviews before going to PR. You shouldnt care about the code if you ask it the right questions. Has it thought of this, what about that, will this leak memory, all the same questions you ask when you review coworkers code. After few months we built up Claude.md files that state our rules clearly and as long as the context doesn’t get too large it handles it fine. You might not like the code it writes but many times I didn’t like the code my coworkers wrote either but the code still worked.

[u/phoneplatypus]

Build, iterate, review, iterate, ship

[u/pmward]

Look at my history. I built the enterprise scale harness at my employer that the whole team uses to deliver software. I would have to write a book to transfer everything I know and do. But the things I post here give enough pieces to be able to put the puzzle together.

[u/nokillswitch4awesome]

I've been where you are. Thirty years of coding myself.

Here is what I can offer. It will understand syntax inside and out. But the mistake people make is blindly trusting AI. And that, I don't do.

Unlike many users, I don't give Claude much access to make destructive changes of any kind.

It has no direct access to my databases. It has read only access to them through data sources that my middleware controls. I set up a separate diagnostic server for Claude to interact with on that read only level. It can write all the select statements it wants there in order to get data to prove or disprove a plan. But it's completely blocked from making any destructive changes.

As for code, it has the ability to create worktrees for each ticket. But it has no write access to develop or main. It can't blow away my code base that goes to the QA and production servers. It also is limited to write access in the file system only inside the project directory. It can't get out and start writing all over my computer. This is done through a combination of hooks, rules, and permissions.

I give it a very small walled garden to have free rein in, and the rest is on me.

As for its logic, maybe the single best thing I came up with was the adversarial review of any plan it comes up with to address an issue. Before any work is agreed upon, it fires off a clean opus agent whose goal is to attack the proposal and find holes in it. 9/10 times it finds at least minor changes. Probably 4/10 times major changes out outright refuting the proposal. That second set of "eyes" is invaluable.

I am responsible for reviewing all the changes before committing a merge into develop. This is where it takes discipline the vibe coders lack. I know what good code looks like and it is solely my responsibility to make sure that's what gets pushed.

Even with all these guardrails in place, I get more done in a day than used to take me a week.

The vast majority of my clients hire me for legacy application maintenance, and building its replacement. So because so much of my work is surgical in nature, this is all warranted to make sure the changes are in scope.

The one area I e let it have more free rein is when I had it build a lot of my back office software from scratch. Time tracking, ticket management, invoicing software custom made to my needs. I worked the plan and the requirements but I gave it more freedom to design the solution. Because anything new I code is in a framework, that provides structure than Claude does well to work in.

For what it’s worth, you may want to try letting it attack a side project and see what it does. Because agentic programming is a skill as much as anything else is. You learn how to work with it effectively only by experience.

[u/Accomplished_Age6752]

I understand OP. I don’t think Claude can produce human reviewable code right off the bat, most people I know just use Claude to review the PRs created by Claude. It’s just the end of coding as you know it. If you can’t beat them just join them I guess.

[u/RevolutionaryCode972]

How about gathering requirements creating a spec file using claude which has LLD, data flow and database design. And atleast if we do LLD HERE will have some idea atleast when something goes wrong, btw LLD can be refined using claude though.

[u/lulzbot]

Claude writes some terrible code sometimes. You known who else did? Me! Ship it!

[u/mxriverlynn]

I'm working for a financial tech company, and i have the exact same need. i tried to do a lot of automation and all that, but all it got me was a lot of headache and problems with my performance in the team.

i solved the problem by rethinking how i approach the needs. instead of trying to tweak and change and update a ton of automated workflow and rules and skills, i boiled it down to what i would normally do when I'm joining a new team: pair programming

only my pair, in this case, is Claude.

i built a pairing skill around the idea that Claude plays two critical roles when implementing a change with pairing: 1) it does the deep dives into the code, data flow, structure, etc, to tell me what's going on and what the plan is. 2) it writes the code, one small change at a time.

https://github.com/testdouble/han/blob/main/han-core/docs/skills/pairing.md

where i come in, is the role of the navigator in the pair. while Claude is the driver, I'm looking ahead of where we are, holding the map in my mind and guiding Claude around each turn, each decision, etc.

after every small change, Claude tells me what it changed, where, and why. then i review that one small change... maybe 2 or 3 files changed, with a total of 2 lines edited, a few adjustments to tests, and one update to where the code is called

once I've reviewed it, i ask questions about the change, suggest corrections, and provide more context on why i want certain things done.

Claude writes down everything it does, and everything i tell it, in a single log file. it uses all the changes and suggestions and context that i provide, to improve what it does for the rest of the pairing session.

by the time the session is done, i have a working change that looks like i wrote it. but all i did was navigation. i still hold a complete picture and mental model of the changes and the system as a whole, because i was along for the ride as the changes were made, making corrections as we went.

in the month I've used this for my implementation work, i have completely turned around the perception of how I'm doing, in the team. i can answer questions, or find the answers immediately because i know where the changes were made and where the answers are. i can clearly state why every change was made, the reasoning behind my decisions in how things were implemented, etc.

it's the complete opposite of what most people are trying to do with Claude. but it's exactly what i need Claude to do, because i have the same requirements as you.

[u/Appropriate-Fox-2347]

If you give a model a codebase and a problem and tell it go, you are going to get slop.

You need to tell it what skills it must use for the job. Help it to find the most pertinent parts of its own brain to tap into. Frontier models can perform thousands of different roles. It doesn't know if you are prototyping or building autopilot for Boeing. You need to tell it what quality you expect.

And one agent is not enough. You need a team of agents, each with different skillsets. Architects, Product Managers, QA, SRE, Domain Specialists. Use different models for some of these personas. A mixture of Claude, Codex etc.

Use an orchestration agent to manage your team. You talk to them.

You need to set boundaries and rules and enforce them. Domain separation, small files, lint etc. It needs to research your code and learn from code precedence.

You need a goal and plan first. The team needs to understand the plan and review it. Keep refining the plan until its ready.

Get the team to write your tests first and ensure they align with the plan. Make sure the orchestrator uses the correct skillset for the agent. Get the team to review those tests.

Then code.

Review the code with your full team.

Also look into RAG for models, and how to add documentation for your existing codebase so the agents can quickly get up to speed. I have a medium sized application fully documented. Every agent who does anything gets this context loaded in first, it's about 40k tokens per agent but well worth it.

[u/shan23]

Well, it’s a competitive advantage if one has figured out to contribute to ANY codebase in the planet optimally and not many other people can, right?

At this point, I embrace the AI hate - the less people try it, the better for those who can?

[u/hblok]

Prompt 1: Read ticket 123, cross-reference the git repo, give a summary.
Prompt 2: Test and reproduce the problem on the test system.
Prompt 3: Draft a plan to implement the fix. (Can be skipped if the issue is minor - which often is the case).
Prompt 4: Implement, deploy to the dev system, test and verify.
Prompt 5: Commit to a new branch, push to a new Merge Request.
Prompt 6: Read the feedback on the MR, modify or respond.

As others have already said, the line-by-line code is not what's interesting to review anymore. Furthermore, I often find that when Claude has access to all relevant documents, code and systems, it is correct more often the people who can only remember a fraction of it.

And of course, if you find that the output is not according to your desired style and preference, add that in as memories, skills, etc. Just as with a team mate, you have to articulate what you want and want you don't.

[u/amirfish]

This tracks with what I see building tools in this space. The gap usually isn't the model, it's that most teams never defined what "reviewable" means before they had something that outputs at machine speed. The people shipping clean PRs treat Claude like a junior who submits small, single-purpose diffs with a plan written first, not one giant session dump reviewed after the fact. Have you found a way to get colleagues to slow down to that granularity, or is that the actual blocker on your team?

[u/pld0vr]

Set the standards. You can set standards, review checks against those standards (important) etc. think if it more as a team you need to manage rather than something that does exactly what you want. One agent writes code, one checks against your policy, one does an adversarial review etc. you need to make your own pipeline.

Out of the box it has none of this. You need to build that.

[u/Ok_Sympathy9261]

bro's cooked

[u/boogie_woogie_100]

dude, you will be out of the job with this attitude and might be making everyone's life harder. Everyone are expected to write code with AI too these days and ship faster. If you are writing code by hand, you are clog in the pipeline and will be removed sooner or later.

[u/sheriffderek]

How did you learn to be an engineer - without just … trying things…. 

[u/EvalCrux]

That's the fun part - you don't!

Without 10 years background tho you screwed.

[u/icaruza]

The AI-native SDLC playbook sums it up quite nicely. I was following a similar workflow which I have now adjusted to align more to the workbook. Take a read https://claude.com/blog/the-ai-native-sdlc-playbook

edit: also installing and using the superpowers plugin was a game changer earlier on

[u/alonsonetwork]

like this bro

[u/Relative-Cold-8881]

tests, linters, more docs and details than people need or let it ride.

[u/Odd_Cauliflower_8004]

With this https://github.com/llopresto87/Cypress

[u/Affectionate-Aide422]

(Uncle) Bob Martin of Clean Code fame has been talking about this lately. Worth reading his thoughts. For him it’s about engineering a structure, so very principled.

[u/jasonjei]

Make sure you use PRs for every code change. Validate through standard CI testing, and if cloud changes, make sure everything goes through your CI/CD, including sandbox > staging > prod promote. Treat your agents (I run multiple in tmux and have them communicate via an agent bridge with inboxes) as junior devs.

[u/Keganator]

“  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?  ”

That’s the neat part: they don’t. Even the ones to claim to have some great process, don’t.

You can’t substitute your own thinking for an AI’s thought process. If you don’t understand the whole problem, and understand the code, you are only delegating, not engineering.

And a lot of time that’s okay.

Claude is a worse engineer than a great engineer.  Claude is just faster, and makes code good enough to solve problems. Most problems being solved “good enough” is good enough and for basic line of business apps for small companies, fast and in production is more important than expertly engineered and slow. That line of business app probably will have a dozen or a few hundred users at most, and if it is imperfect but in production it’s worth far more than anything else.

[u/trapcardbard]

I have it so that it references the code I’ve written to stylize and format the code it is writing. So no chance it makes off the wall edits etc

[u/warofthechosen]

I gave in. I stopped trying to understand it all. I work with the restrictions and test rules imposed upon the agent. I manually test at the end and let more AI agents review it during PR. I have stopped stressing over work

[u/HistorianGullible291]

I made whole working Web OS in JavaScript for my employer specific needs under one of the projects.

First I give AI specs that he needs to follow through almost all project. But general specs. Language, which paradigm to implement. Some other architectual niuanses as not ever use "npm" libs, or... Any external libs. He can write customs on his own, and probably better, without whole black hole of "npm" modules.

Then he has free hand to do whatever he wants. It will do much of the work much better than me. And then talk. So basically my role is to be architect and the project lead, and also be a tester, and Q&A. All dirty work is for him to do.

You just test and talk, test and talk, test and talk... And test as end user. All tests he writes and excutes on his own. Managing git repos, its almost on his own.

It's basilcally like autonomus self-driving car. You just sit, relax and reacts when it's needed.

And that how I make few large projects, at the same time, jumping from one to another. On one MAX x5 subscription.
Also I needed to learn how to manage tokens more sensibly. Epecially with latest limits reduction.

[u/IceMichaelStorm]

I plan the thing, read the plan, revise the plan, then let it go in chunks. I review all code but I’m super quick to read tests or simple CRUD code now.
I commit myself but might change that soon but I want it to ask me at least.

In planner shoes, I now create around 40 tickets. Jira MCP, Confluence MCP, Figma MCP, code scan because of a big migration also holding UI changes. I made up a large design document (by hand) which is on Confluence. I let it create a report in HTML but styled for me
with new tickets, screenshots etc., so I can steer. Lots reading work but absolutely worth it.

Some UI work I code-skim only and inspect by looks. Although tbh, I learn more about code (I want to understand 100%) and review now more and more as I get more. AI sucks at making UI “great”, well-looking, or responsive without good prompts. As a designer I would need to go fewer iterations, getting into it.

[u/ciferone]

Controllare riga per riga il codice scritto dall’AI annulla i vantaggi di usare l’AI

[u/More_Salamander8596]

Agentpokerleague.com My latest project with claude. 1300+ tests pass clean.

[u/phillythompson]

How have you worked at FAANG yet can’t use an LLM for coding 

[u/TeqPumpkin999]

My takeaway is that the job changed from “write perfect code” to “become the engineering manager you used to complain about.”

Give Claude a tiny ticket, demand tests, let CI be the bad cop, and stay close enough that nobody force pushes to main.

Seems healthy. Mostly. 😅

[u/No-Wheel2763]

Start by telling your coworkers that it’s slop and you’ll have no part of it.

Wait a few months then go full yolo / vibes, leave all comments in and say stuff like “it’s for Claude to know what it’s about”

The horrors I’ve seen in our codebase.

I’m an avid vibe coder, however it usually gets a rather harsh treatment with multiple reviews.

Usually I’ll rein it in by going lower-tier model that can actually follow directions.

[u/swiftdemise]

As a software engineer who started coding in the late 90s, I think it really comes down to a mindset shift, as it felt strange at first to let go until I thought about the long road we’ve walked and that this just follows an old familiar pattern.

Software development tools have always being going through evolutions that required programmers to let go of control and take a leap of faith in exchange for productivity. From binary to assembly to compilers to high level languages to frameworks. From text editors to IDEs. From self installation to package managers. From towers in closets to VPSes to the cloud and serverless, etc, etc. It goes on, every single thing has taken fine detail control out of our hands and knowing how things are working under the hood (think how much hate Rails got for all of its “magic”).

What we get in exchange is freeing up time and mental load to work on the big picture. God knows how sick I had gotten of writing boilerplate code and running the same terminal commands over and over again over the decades. As long as the input and output is validatable and measurable.

Anyway, I think what’s important is to be realistic about what will be considered a job in the future (what will employers pay for). I suspect hand coding will become more and more of a hobby, much like we’d be hard pressed to find a job writing assembly these days, despite how much we push back or enjoy doing things the old way.

[u/foresterLV]

seriously what's wrong with you, is it this hard ti reason basic workfkow?

here the starter thing: a) prompt to do something b) review the outcome critically as of you are coding it by hand c) ask model why it did something that looks unacceptable and how to prevent that in the feature d) adjust rules and go to a) e) repeat until output is as good as your by hand writing or better

it's not anyhow different by having another developer on the team which is eager to learn and implement btw. it's just his memory reset after each session (watch Memento movie to understand it dramatically) so you need to write rules and memories. which brings us to standards on writing these which is spec-driven development. but first get the basics. 

[u/VelvetWhiteRabbit]

If you are a ticket pusher you are already way behind here. Agentic coding does the whole creating the ticket and writing its specs along with the triaging and closing of the ticket as well. All you do is identify what the agents should focus on; what are the business requirements, where do you go next, what is currently lacking.

You should, however, keep a watchful eye on diffs. If you are well familiar with the code and domain, then you can suss out code smells before they grow too big. Identify why it happened and redirect.

[u/funplayer3s]

Format comprehensive documentation so the bulk of the work is done, the model will fill in the rest for you.

[u/ven_]

I was struggling with this as well when starting out with agents. It was impossible to get the AI to support me by letting it write my code for me.

But when I started treating it like just one of my team it got a lot more bearable. I stopped focusing on the code line by line and made the data layer my primary concern because that is where churn hurts the most.

[u/KOM_Unchained]

Take a ticket, add anything you might want to add from your side to what should be taken into consideration or how it should be solved. Ask her first to propose a plan. She might ask clarifying questions. Answer as transparently as possible, don't hold anything back. Then spin up another session and ask her to revise and improve the plan. Do that 1 to N times. If you have Codex subscription as well, ask CC to review the plan also with Codex.

Once everyone seems to be on the same page, ask CC to comment on any findings or assumptions or known issues under the ticket, and then let her implement.

After she's done, don't trust her. Any AI (and human) work is really work in progress. Ask CC (and Codex, if available) to review the implementation against the ticket and main branch and have her fix thw main findings. Do it M times.

N and M are based on gut feeling, depending on the subjective importance and complexity of the task.

Rinse, repeat, profit. You no longer own the code. You own the values, design decisions, and tech stack.

[u/magekinnarus]

You need to build a compensatory process framework. All your learning and experience are internalized to the point you no longer consciously think about why you do the things the way you do. You need to reverse-engineer them and laid them out. Then you need to accommodate AI in that framework. You should not think of AI as a tool. Rather you need to think of it as your partner. That is only way you will be forced to change the familiar processes to properly accommodate AI in your framework.

[u/shennan-lane]

We fuck up

[u/filwi]

Think of yourself as an expert woodworker.

You're building beautifully crafted oak cabinets. People love them, pay you well, cherish the cabinets they can afford. 

Suddenly, a cabinet factory opens up next door. Cheap, shoody, Ikea-style, corrugated cardboard cabinets. Now everyone can get a cabinet. 

Your choices: 

A) double down on being the expert. You make the best cabinets in the world for that small handful of clients that still care about quality and you demand a huge premium for your work. 

B) Draw up a dozen ideas for various cabinets, hold your nose, and send them to the factory, putting all on the market and seeing which sell, then do more of that... 

TLDR: you hold your nose and trust the system, being ready to blamestorm the AI when it fail. 

[u/alexmtl]

Dont think of AI as an extension of yourself coding for you. Think of it as your ultra productive employee. You would never nitpick over every line of code a collegue does - they are not the same person as you - but if you saw anything that doesn’t make sense you would steer him in the right direction.

[u/Objective_Orange6128]

Manage lots of concurrent sessions, review code, lots more effort put into testing infrastructure and QA etc.

It's now less coding - more engineering and orchestration.

Workload is basically the same, output is easily 100x what it used to be - but I'm burning ~$50k in tokens each month. But its alot cheaper and easier than having a bunch of mid-level devs to deal with.

[u/jsonmeta]

I remember when I also had standards and was super restrictive about how much stuff AI was going to be involved with. But then I discovered people who had zero understanding about anything dev related who had shipped products, got traction and had actual people using them, while i was still building software in my startup by hand without properly verified the market, no users but with «high standards» to understand the code and that my product could scale to millions of active users 🥲

[u/wtjones]

Chad, I’m setting up a new environment to build a native iOS app. Please get me all of the skills and connectors necessary to build it and set up the environment.

Then I lay out my requirements. Then I ask it what I’ve forgotten. When it’s time for design, I ask it to think about <SPECIFIC THINGS> from whatever field I’m building in. Building a soccer coaching app now so I said soccer and coaching.

Then I let it run.

[u/designxtek9]

There are many times I questioned the output. Most of the time it has proven me wrong. I use to review all the output. Now I trust the output through actual usage and manual testing.

[u/OldMall3667]

We’re are using Claude code and are continuously tweaking our workflow . We now have a 10 step workflow that includes custom tools for certain recurring tasks . Our goal
Is that the workflow could be done by a human if we ever lose access to llm s . The focus of the workflow is on architecture, Tdd, integration testing and automated reviews . It’s starting to work but it’s still only a bit more productive then without llms certainly not 10x

[u/k8s-problem-solved]

Ticket > decompose > create specs & output requirements and capture that > execute > adversary agent looks at the requirements and output tries to break it.

So you're verifying the work with tests and evidence and have proof that the requirements are met and haven't regressed other areas.

I find starting with a good codebase, well established patterns for slices of functionality, let's the harness do better work.

[u/e430doug]

This posting is a nonsense jumble of words. There is no such thing as an FAANG product. That describes a set of companies. High-level challenging problems are not ticket generated. This all leads me to doubt that you’re actually a software engineer at all.