With modern AI tools it's very tempting to get sucked into a scope creep black hole. The cost and time of adding new features to your product are at an all-time low, and results come so quickly that it can be addictive to add just one more feature.
When I'm working on my projects, the first thing I keep in mind is what I value on that project. Is it shipping early and often, or is it getting things perfect? With that in mind, I run through a few questions to decide whether a feature gets added now or goes into the backlog:
- Does this touch something foundational, like security, the data model, or the architecture?
- Does this serve the goal of what I'm working on right now?
- Will it cost more to add this feature later instead of doing it now?
- If it costs more later, is it still worth doing now?
All of these questions are really there to answer the ultimate question: Is this feature required now, or is it nice to have?
If you're afraid of forgetting it, write it down
For all of my projects I have a full dev plan that lives inside the project and repo. Often I'll get the urge to add a feature because I just thought of it while touching another part of the application, and I'm afraid I'm going to lose that thought. If you're acting out of the fear of forgetting a task, that's a perfect tell that you really just need to document the idea so you can pick it up later.
Sometimes I'll write out the idea in detail and have it added to my dev plan. Other times, I'll mention it to my agent in passing, such as, "I just noticed bug [x] while looking at this. Note this as something to come back to later." Before agents I would have logged a bug ticket instead, but when I'm working with an agent on a project it's much easier to just mention it and have it added to either the dev plan or a bug list within the repo.
Why not just do it now?
You may also say, who cares? The agent can implement the feature or fix the bug in the middle of whatever task I'm doing, or I can spin up another agent to handle it while I keep the main agent at work. Those are all valid and good solutions, but I prefer to be intentional and work through my dev list methodically so I can give the task at hand my full focus. After every bug is squashed or feature is added, I like to manually test things, review the code, and make sure nothing went off the rails. I find that cleaning up a mess the agent created because it didn't properly understand the requirements is more costly than being patient and handling things at the right time and place.
Is the pendulum swinging?
Scope creep has existed since the beginning of software development, but Opus 5.5 just came out, and it has me rethinking some of this. Models are getting more powerful, and the cost of using them keeps coming down. According to Anthropic, Opus 5.5 performs at the level of Fable 5.1 on most work for 40% less, and it's even 20% cheaper than Opus 5.
If you haven't tried it yet, here's how it compares:
Anthropic's published benchmarks for Opus 5.5.
Opus 5.5 pricing compared to Opus 5.
So far my own results line up with that. Fixing a bug or adding a feature on the fly is getting cheaper in both tokens and time, and the messes I described above are happening less often. The more I trust a model to give me great results with less babysitting, the easier it is to say sure, let's just add one more feature. I have tokens to spare, and the time to implement and test won't set things back much.
I don't think my checklist goes out the window, though. I think it changes. The question used to be "Can I afford to build this right now?" and more and more the answer is yes. The questions that are left are the ones a better model can't answer for me. Do I actually want this feature in my product? Do I have the focus to review it properly? Will I still want to maintain it six months from now? A model can write the code faster than ever, but I'm still the one who has to own it.
So is scope creep becoming a thing of the past? I don't think so. It's just getting cheaper to give in to. Welcome to the era of just one more round. Just make sure you're the one deciding when the round is over.
Top comments (1)
That last distinction—cheaper to give in versus actually wanting the change—is the useful one. For client work I make “done” an explicit event: a checklist, a short review window, and a clear home for new asks. When another round arrives, I batch it, separate bugs from preferences, and ask for a fresh decision before touching the approved work. Faster implementation makes that pause more important, not less.