upvote
Makes me think of how my Claude.md files specifies to use the built in framework code-generators (rails). Those generators are deterministically right every time.

I wonder how often the Agent actually follows the guidance. I do see them follow it when I look. But it doesn't seem so every time.

reply
This is tricky since it can and will ignore your md directions. When possible I try to lean on tool call hooks or skills that invoke deterministic scripts. As much as you can remove the "choice" the better though still there's a lot of randomness in how reliably it invokes skills ime.
reply
Hooks are incredibly underused by most people and are the easiest way to establish a first line of defense against bad behavior. Things like blocking tool calls that will read .env file or execute "create or replace table".
reply
A lot of the time if you're copying code from one place to another what you actually want to do is abstract it so you can reuse it in both places.

The LLM can easily do this type of stuff, just tell it and it'll happily do it. This is exactly what I mean when I tell people they need to work closer with the AI, tell it how to do things. Don't just tell it what to do and get frustrated when it does it differently than you would.

A good way to achieve this without writing huge prompts is tell it to plan the change first. Just give it some vague low-effort directions. It'll usually get most things right, you tell it what you want different and once you're happy you tell it to go ahead.

reply
There are a lot of instances where you don't want to create an abstraction that will tie two disparate areas of the code together even if they happen to be using a similar pattern you want to copy. For example, when you expect their implementations to diverge in the future.

I have experienced enterprise codebases that have been DRY'd to the point they become ossified.

reply
That's why I said "a lot of the time". Not always. And it's not really a problem to de-DRY things, literally just copy/paste and make the change you want. The bigger problem in my eyes is when the requirements start to diverge people just add an if branch and soon you have a function/component that does 7 different things depending on how it's used and it's a big buggy mess.

It's also possible in many of these cases to identify sub-patterns you could abstract, to create a set of tools you can compose in different ways in order to satisfy the different use cases. Instead of one function/component you make multiple, and use them together.

All this stuff is just basic programming but I've mostly given up trying to preach about it. Most people don't care, and even if they did care they just don't have the talent to write really good code. It's rare to find a dev who does really solid work. In my experience you either do it because that's who you are, or nothing I say will make any difference.

reply
Nah the codebase is legacy fucked and I cant be bothered to try and optimize business flows without the fear of other stuff breaking.

Claude 100% of the time even thinks we use laravel despite the project being some old lumen codebase, so most of laravels features are not available. It also gets the PHP version we are using wrong 100% of the time.

reply
Have you tried adding this information to claude.md so it knows?

I also think your excuse is bad. "The code is legacy fucked so I'll just legacy fuck it some more because I can't be bothered to make an effort"

reply
Are you some kind of entitled corporate dev that barely has any influence on the codebase? If I fuck up a whole business goes down as I am the only dev there currently. We cant afford that happening. Also why would I mess with anything claude.md related? I just use the CLI tool. LLM enthusiasts always claim how smart these things are so they should figure it out on their own, you know?
reply
I have full control of my codebase. I'm not afraid to make changes to it because I know what I'm doing.

You would edit Claude.md to say things like what tech the project is using, because that's the entire point of claude.md. It's literally the solution to the exact problem you're complaining about. Any information you want it to know, you put in there and then it knows it. And you can tell Claude to make or update the file for you.

I'm not one of the people telling you how smart LLMs are. I'm telling you how to use it efficiently, by not expecting it to know everything but rather provide the information that it needs in order to be a more useful tool.

reply
This is a spicy take, unless the business is willing to face some down time, and I am hired to do exactly what you said, I’d never touch any line of code unless I absolutely have to. Different environments don’t help as much.

We tend to obsess over software quality when it’s the least important thing for a business. It’s just a means to an end.

reply
This is what its about, we have multiple ecom shops running 24/7 and cant simply afford downtime or a change of business flow that maybe doesnt affect shop A and B but definitely affects shop C and D...
reply
> Least important thing for a business

- Takes weeks or months to get simple features out the door, and when they're out they're buggy as hell and the bugs never get fixed. Sound familiar?

> I’d never touch any line of code unless I absolutely have to

And this is how legacy code is made. Years of everyone "never touching anything they don't have to" leads to a giant steaming pile of shit.

> unless the business is willing to face some down time

How does a simple refactor cause downtime? I do this kind of stuff all the time and pretty much never cause any downtime. In the very rare cases that prod downtime does occur it's generally not because of some simple code refactor, and we have it back up in no time by just rolling it back. Unless it's not related to the code at all, in which case it also wasn't a refactor that caused it.

reply