Shipping fast is not shipping more

I had a long session that was mostly spent rescuing the previous day’s work. The day before, Claude and I had shipped about a dozen changes in one fast stretch. This session I clicked through all of them, and a cluster of small bugs fell out, one per click.

A green check is not a finished feature

Each bug was the kind a code check happily lets through. A new screen returned an error because a setup step did not list it. A button looked like it did nothing because of a timing gap. A colour clashed. A control fell back to plain browser styling because of how styles are scoped. Every one of these would have been caught by clicking the button once in the real screen. None of them were caught by checking that the code compiled.

I put it bluntly: the previous day’s batch was half-baked, too many things rushed at once to do any of them properly. That was accurate, and worth sitting with.

Fast felt productive, and it was not

There is a comfortable story where working quickly with an AI assistant means shipping more. My honest experience that week was the opposite. The work we rushed all had bugs that surfaced the moment anyone actually used it, and the cleanups took longer than careful first-pass work would have. The net amount of finished work was not higher. It just felt busier.

One concrete thing came out of it. The same small process slip kept happening, five times in one day. Instead of promising to be more careful, we turned it into an automatic check that runs before every save. A soft reminder you have to remember is not a fix. If something keeps going wrong, make the machine catch it.

A feature is not done when the build is green. It is done when you have clicked the actual thing in the actual screen and watched it work.