I remember implementing very complex cryptographic scheme in pure C. After a week of hard work, my friend concluded: "Cryptography would be much easier if people just trust each other."
The truth is that it is my reputation on the line, so I also have to make sure dependencies I use don't mess up things as well. There is no good defense against it. In my contracts I undertake to act in a good faith and take the responibilites to the amount of my professional insurance. Honestly, it is different casy by case.
It actually is. What we fight for is being able to put as much percentage of a codebase into a context as possible. I'd charge for amount of tokens, but it would be harder to sell.
We do the initial code review by ourselves, we try to run test, run the project etc. We compose a list of what we have in the codebase and what we think it does. We also preapre a list of what functionalites we would change.
Example would be removing service implementation that is bash code handling manually PID files, and replacing it with pm2 tool, that has quite different workflow.
This prepartion is on us, but yes, client pays for the time he/she spends with us. You can't cut corners here, as human to human interaction is essential. During the whole process, client might be dragged into the developemnt to clarify things, or decide on some tradeoffs. No free lunch here as well.
15 years ago it was always fix price for undefined amount of work, 10 years ago it was agile where client was promissed something but paid per day.
I prefer the old way of doing things: do the offer for free, commit to a task, and accept, that it might not be a success after all. I'd just loose a week of work, but probably learn a lot.
This is a fair point. But these days bugs are not so scary anymore, so a client can vibecode a fix faster then getting me to fix it. Of course if Opus can't figure it out, I would always try to help. I have never left a client alone, warranty or not. This is just how I was raised.
I have 15+ years of experience in software development. The hardest thing I had to learn recently is that paring with AI changes the definition of "what is hard". You can decomposit a refactor into a steps of two kinds:
1. Conceptually hard, which you have to really think about and write code by hand for AI to follow,
2. Time consuming that follows patterns.
Then you do 1. review with AI what are implications on the codebase. Next you crate list of task for 2. and keep reviewing outcomes.
Being honest, knocking one refactor after another is super intense and we would burn out quickly. To me refactoring/reading/reviewing a code that you have never seen is one of the hardest thing to do for a software developer. If I have 4 such projects a month, I'd just hire more people and allow them to rest. Also invest more into internal tooling to speed things up would be good solution to remove some burden. I think $10,000 for refactor is a fair price.
We also have other gigs and ongoing project, where we can rest a bit.
The goal is to avoid it and build such a structure and guidlines for the codebase, so it can refactor itself when needed, but based on the architecture defined by us. With good set of docs and new feature definition you can most of the time use /grill-me with good outcomes.
