AI made me faster at building, but I had to change what “progress” meant
AI has made some parts of building dramatically faster for me.
A feature that used to take a long session can sometimes become a much shorter implementation task.
At first, I treated that as straightforward productivity.
More shipped = more progress.
Then I noticed something.
The faster I could generate changes, the more time I needed to spend deciding:
Is this actually the right change?
Did the agent touch anything unrelated?
Does this fit the existing workflow?
What assumptions did it make?
What needs to be tested?
Is this worth keeping?
So I started separating creation time from decision time.
Before:
Build → Build → Build → Review later
Now I try to work more like:
Decide → Build → Check → Learn → Decide again
It feels slightly slower in the moment.
But I think it gives me a better definition of progress.
A line of code being generated isn't progress by itself.
A feature being shipped isn't necessarily progress either.
Reducing uncertainty, solving a real problem, or learning something important is progress.
AI makes creation cheaper.
That makes choosing what deserves your attention even more important.
For people building with AI:
Have you changed how you measure progress since AI made building faster?
Replies
I found that faster implementation can create more unfinished decisions. My approach is to keep a small decision log so each build has a clear reason behind it.
@alheri_murya One thing I’ve started watching is how much rework a feature creates. If faster implementation leads to more fixing later, the initial speed doesn’t really feel like progress to me
@alheri_murya @bradely_charlesbois Exactly. I’m starting to think rework is a better signal than raw implementation speed.
If AI helps me make a change in 10 minutes but creates an hour of cleanup later, I didn’t really gain much. The interesting metric becomes how much of the work actually survives.
@alheri_murya The decision log is a great addition. I think it solves a problem I’ve been noticing too: once implementation becomes cheap, it’s easy to forget why a change was made in the first place.
Having the reason written down makes the later review much more useful.
There’s definitely a trap here: faster building can create a false sense of momentum . You can end the day with 20 changes and still have no clearer idea whether the product is better.
@victor_coleman That distinction is becoming more important for me.
I can finish a day with a long list of changes and still have less confidence about the product than I had in the morning. More activity doesn’t necessarily mean more progress.
I like the definition of progress here . S hipping is an activity. Learning ,reducing uncertainty, and solving the right problem are outcomes. AI makes it easier to confuse the two.
@owen_carter3 Yes — that distinction between activity and outcome is the part I’m trying to pay more attention to.
AI makes activity incredibly visible because you can produce so much more, but the outcomes are still things like learning, reduced uncertainty, and solving the right problem.
Thank you for this post @evolvix_ai I’ve started treating rework as a better progress signal than output. If AI helps me ship five things but two get reverted and another creates more cleanup, the speed was mostly noise.
Have you started tracking how much AI-generated work survives unchanged after a week?
@alpertayfurr I haven’t been formally tracking that yet, but I think that’s a much more interesting metric than raw output.
“Survival rate” could tell you a lot more about whether AI-assisted work was actually useful — especially if you separate work that survives unchanged from work that needed significant rework or got reverted.
That’s something I’d like to start tracking while building.