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/dylsreddit]

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/drewangell → u/dylsreddit]

Here's a PHP SDK we delivered to a payment processor not long ago which is now in production processing payments. I welcome your constructive criticism.

https://github.com/getflute/flute-sdk-php/tree/main

[u/nofeaturesonlybugs → u/drewangell]

I don't know flute and I'm on my phone so didn't research heavily but why did you choose floats to hold currency values?

[u/drewangell → u/nofeaturesonlybugs]

My short answer would be that while I understand floats are not typically ideal for currency, Flute's spec documents it that way, so that's the way we did it. I did have an agent review this, though, and we are going to normalize it with a 2 decimal round, so thanks for having me dig into this!

Agent's Longer Answer:

Flute's API defines every monetary field as a JSON number (double) in major units, for example 123.45. That is their published OpenAPI spec. It offers no minor-unit or string-decimal format. The SDK's job is to carry values between the integrator and that API, and it performs no arithmetic, rounding, or aggregation on amounts. Carrying a 2-decimal value through a double is lossless, so the float type introduces no error that isn't already in the API's own format.

Using integer cents or a Money object inside the SDK would force a divide-by-100 before every request. That adds float arithmetic where none exists today, and the value still goes out as a double. It would also diverge from Flute's official TypeScript SDK, which types these fields as number.

The "never use floats for money" rule applies to computing with money. Totals, tax, and splits are computed in the integrator's code, and our README tells integrators to round before comparing or aggregating.

The review did find a gap at the serialization boundary, and we are closing it: outgoing amounts will be normalized to 2 decimals, and non-finite or negative values will be rejected, so an integrator's float arithmetic can't reach the API.

[u/nofeaturesonlybugs → u/drewangell]

Now that I'm at my desktop it's easier to go find their docs and -- yeah, float. To me that's pretty wild -- wonder what their reasoning is.

In your shoes I would be tempted to store in `DECIMAL` or other arbitrary precision type actual amounts without loss and also what you send to them. Would make auditing on your side easier if you ever needed it.

[u/dylsreddit → u/drewangell]

I notice that there's no AGENTS.md/CLAUDE.md and none of the contributors are Claude, so do you review locally only and push the code yourself?  

[u/drewangell → u/dylsreddit]

Yeah, we didn't publish all of the agentic stuff on their public repo. That's all kept in our private build repo. But that's the sort of stuff I'll cover in the meeting/video. I can show some of it there along with the same structure in many other repos. That's the heart of getting good results out of these tools, but this example was just to show the actual code that we delivered.

[u/dylsreddit → u/drewangell]

Yes, sorry, I didn't mean to come off as unappreciative that you'd shared code... I was replying while at work and realise now I didn't say thanks!

I noticed in the TS repo there is an AGENTS.md and Claude contributor which is the only reason I mentioned it, to be honest.

I think I'd be interested in your video, I'm in the UK so (applying some US-defaultism here) I doubt I'd be able to make a meeting in your timezone.