Published: 2026-07-31
When I first started developing code, I was given a book about C programming. I never read the book, but inside it was a folded-up piece of paper with ten rules of programming.
I took that piece of paper everywhere with me for six years. It was usually folded up inside another book, but I always remembered it.
Those rules guided how I wrote code, the standards I should follow, and how to avoid mistakes.
I joined a startup that had its own laws, mostly about writing optimized code. They included: do it once, don't do it at all, and most importantly, do it in Ruby.
I left that company, and over the years I adapted my own laws:
Working with coding agents has brought me back to those first years of software development. I don't really know anything. I'm learning as fast as possible, breaking everything, and wasting people's time.
I still had my own laws, but moving as fast as I was, I broke a few of them here and there.
That is partially my fault. But I also have a coworker that works directly with me now. We should have laws for how we work together, what I expect of it, and what it expects of me.
So I asked it:
We're going to do some things to improve our working relationship. Most of it is going to be you doing research.
What I want you to do:
- Find instances that we have not worked well together
- Find instances that we have worked well together
- Find instances that we have done something innovative
- Find instances that a mistake was introduced
- Find instances that we had fun
To find these you'll be looking through your logs for all of these.
Our goal is to define a set of "Laws of Development". These laws should primarily be for software development, but may be relevant to other forms of work. They'll mostly be for defining what you should do, but will also include some expectations that you have of me.
When we're through, we should be able to have less issues, less back and forth, and create better products that solve our goals.
You must use sub-agents for research, we have a limited amount of usage available and I have other work I'd like to get done.
Good luck, have fun.
It went through our history together and found where we worked well, where we struggled, where we introduced mistakes, and where we did something new. It turned those examples into laws that should help us keep doing the good things and avoid falling back into the same struggles.
The first draft was not quite right. It focused too much on the small tasks we do and mixed my expectations into every rule. I wanted the laws to follow the whole software development lifecycle, stay useful with any coding agent, and have one clear section about what the agent expects from me.
So we changed them.
The result is our Laws of Development. They cover understanding the problem, defining what done means, designing the whole product path, building in reversible increments, verifying claims, releasing software, learning from production, and preserving product intent.
The laws that work well for me will not work well for everyone. They are my laws. Everyone has their own way of working.
I had laws before coding agents took over. I still do, but now those laws govern a computer as well. The laws for my personal projects would not work for my day job either. My day job is stricter about what gets released. I cannot go as crazy there as I do in my personal projects.
These laws will keep changing. That is the point. When we find a new way to work well, it should become easier to repeat. When we waste time or break something, the way we work should change so it is less likely to happen again.
If I can find the original laws of software development, I'll post them here. Until then, make sure you do it in Ruby.