ask an agent to make an app scale and it will happily add caching, queues, autoscaling, the lot. most of it u did not need. the word scale is too vague for it to make a good call. made a short splitting it in two. the swing is load going up and down, busy saturdays, quiet tuesdays. thats handled with headroom and servers that join and leave. growth is more users every day, year over year. that needs a back end that can actually spread across more servers. what worked for me is writing both numbers into CLAUDE.md before any infra work. peak vs normal load, and expected users in a year. with those two lines the agent stops guessing and picks the smallest setup that fits. what do u give ur agent before it touches infra, or do u let it decide.

Claude Code will get ur test suite to green. that is what u asked for. it is not the same as the feature doing the right thing, and the gap between those two is where most of my rework came from. made a short on the idea behind it. in systems there are two separate numbers. availability is can u reach it. reliability is does it do the right thing when u do. a service can be up 99.999% and still write bad rows all day, and no health check will say a word. same shape in a codebase. the suite passes, the types check, and the behaviour is wrong. what worked for me is writing the correctness check into the CLAUDE.md as a plain sentence before any code. something like every saved order must have a matching payment row. then the agent has a definition of right to build against, instead of a definition of green. whats ur equivalent, do u write the acceptance rule down anywhere the agent can read it.

made a short on a rule i now write into the CLAUDE.md before any automation build. if u just ask Claude Code to build an automation, it will often reach for a model call at every step, bc it can. reading an email, checking a total, saving a row, sending a receipt, all thru the LLM. the split from the video. judgement goes to the agent, rules go to code. in an invoice flow only one step needs judgement, reading the messy email and pulling out the amount. checking the total, saving it, sending the receipt never change, so those are plain functions. what worked for me is listing the steps in the CLAUDE.md with a tag on each, agent or code, before it writes anything. then Claude builds the code steps as normal deterministic functions and only calls the model where i said so. the build gets cheaper and way easier to test. do u put rules like this in ur CLAUDE.md or decide it as u go.

when u ask Claude Code to deploy something it will happily put the whole thing on one server, bc thats the simplest thing that works. nothing wrong with that, but its a choice and its worth making on purpose. made a short on what that choice actually is. one server means if it dies, ur app dies with it. run it on several nodes and the others take the traffic when one fails. thats availability, measured in nines. 90% uptime is 36 days offline a year, 99% is three and a half days, 99.99% is under an hour. each nine costs more, so more isnt automatically better. what worked for me is writing the target into the CLAUDE.md before any infra work, something like target 99.9, managed database with a standby. then the agent builds toward that number instead of guessing. how many nines are ur own projects actually running at, if u had to guess.

Am I the only one having a hard time pricing stuff??? When I ask Claude it seems super dupper high. I aint sure people pay so much. Need help understanding the pricing aspects of the business.