4/1/2026 at 1:15:51 PM
Here's one way to approach this: Imagine you work for a giant company where humans would push 10k lines of code per week. In a codebase like that there's no expectation that you'd understand everything. However, there is an expectation that teams contributing code will "own" it.So if the client is contributing you should ask them if they are okay for long term maintenance and fixes of new code they are adding. If not, then maybe you should discuss pricing changes because now you are effectively maintaining code written by them which requires different set of skills and arguably higher cognitive overhead.
by jatins
4/1/2026 at 5:20:02 PM
Agree. "Owning" in this context should mean: understanding the domain, working on new capabilities and handling fallout if anything goes wrong. Whether AI or human ownership transfer this ends with the new owner just handling new work, while the other two remain with previous owner (who might emotionally provide support for it due to attachment of "I've built it")by eithed
4/1/2026 at 2:26:14 PM
Correct. And also hiving off areas that they own, vs you own. Who has decision right and controls the burn down of the kanban board? Basically treat yourself like an API that they consume. You build the good stuff that you know is right. They are responsible for making their crap works right. (Understandably there is some obvious tension around the interfaces.)by meetingthrower