The old adage “software is never done” means something very different now than it used to.
In software development of yore, we frequently used the phrase “software is never done” to mean that once a launch happens, you can’t set it and forget it – you needed to maintain the software, chip away at post-MVP features, and gradually refactor aging code over time. “Never done” was manageable. You shipped something, then you tended it.
That’s not what “never done” means anymore.
The Ground Moves While You Build
In this new era of software development, the technology you designed around at the beginning no longer represents the state of the art when you ship. Not because you were slow, but because the underlying capabilities shifted meaningfully during your development cycle.
This isn’t like the past experience of upgrading frameworks, where the new thing was a better way to do what you were already doing. This is more categorical. AI capabilities aren’t just improving, they’re changing what’s possible to build at all. Each advancement doesn’t let you do the same thing faster, it lets you do a fundamentally different thing. The product you could build in January is not the product you could build in March.
A React app built in 2019 launched into roughly the same React ecosystem it was designed for. A cloud-native system conceived in early 2023 around GPT-3.5 launched into a world with GPT-4, then GPT-4o, then a dozen competitors. Products that spent 12 months in development have found themselves obsolete-adjacent on release day — not because of the market, but because of the substrate. This is a structural feature of building during a period of exponential growth.
What This Breaks
Traditional product lifecycle thinking has always assumed a relatively stable foundation. Even agile — with its sprints and continuous delivery — assumes that the thing you’re iterating on stays roughly the same kind of thing. You’re adjusting the sail, not replacing the ocean.
AI breaks that assumption in a few specific ways.
You build to the model’s limitations, then the limitations disappear. This is the one that stings the most. You may have experienced this burn already, for example spending time architecting a complex multi-step pipeline to work around a model’s context window. You build chunking logic, retrieval systems, stitching layers — real engineering work solving a real constraint. Then the next model ships with a context window ten times larger and a competitor does in a single prompt what took you real time to build.
Or you build an entire application because models can’t reliably do X. You design the workflow, the guardrails, the human-in-the-loop checkpoints, all structured around what the models of today can and can’t do. Then, sometimes literally the next week, a new release handles X natively. Your effort wasn’t wrong — it was rational given what you knew. But it’s now surplus.
This is a new kind of technical debt. Not cruft that accumulates from your decisions, but effort that gets undermined by someone else’s breakthrough.
User expectations move with the technology. From a UX perspective, what users are comfortable with is evolving rapidly. In legal specifically, we are seeing first hand the evolution of lawyers using AI from playing around, to specific tasks, to thought partner. The UX of your solution needs to keep pace with the user’s ever-changing expectations around how they engage with AI.
This Isn’t Scope Creep
Unfortunately, none of this fits neatly into how most teams plan and budget for software.
Traditional project management assumes the target is fixed and you’re iterating toward it. When the substrate shifts, the target moves. Rebuilding the same product with a fundamentally different architecture isn’t indecision, it’s responsiveness to a platform that handed you new primitives. But the politicking is challenging for some stakeholders.
Clients, stakeholders, and budgets are calibrated to a world where you define the thing, build the thing, and ship the thing. “The thing keeps changing because the AI can do more now” is a hard sell in a planning meeting, so you need to set expectations at thewhe start that stakeholders should assume no finite ending to a project.
This is especially acute in legal. Law firms and their vendors operate with structured procurement cycles, phased rollouts, and annual budget processes. Those processes were designed for a world where the major variable was execution risk — can we build what we said we’d build, on time? The new variable is capability obsolescence — will what we’re building still be the right thing to build by the time we ship it? That’s a different kind of risk, and most planning frameworks aren’t built to hold it.
Model Drift Is Real, and That’s Why Evals Matter
There’s a subtler version of the same problem that gets less attention: model drift.
When a foundation model is updated — even a minor version bump — its behavior can change in ways that aren’t announced and aren’t always obvious. A prompt that produced consistent, structured output last month may now be slightly off. A classification that was reliable may now have different failure modes. The model didn’t break, it changed. Now your application, which was tuned to how the model used to behave, is running on different underlying logic.
You’re faced with two choices here: lock your app to a specific model to avoid model drift or keep updating with new model versions. With the former, you avoid model drift but don’t get all the features of the subsequent versions. With the latter, you can run into trouble not knowing how it’s going to impact your outputs.
The answer — to the extent there is one — is evals. Evaluation frameworks are how you know when your product has drifted from what you built and tested. They’re the difference between discovering a model change through a customer complaint and catching it in a systematic check before anything ships.
Evals used to be the domain of ML teams at big companies. They’re rapidly becoming table stakes for anyone building seriously on top of AI. If you’re not building evals alongside your application, you’re effectively flying blind through a landscape that keeps rearranging itself.
Think of it this way: you wouldn’t deploy a new version of your software without testing it. But every time the underlying model updates, you’ve effectively deployed a new version — whether you intended to or not. Evals are how you stay honest about that.
The Throw-It-Away Question
Every software team eventually faces the rewrite question. The classic debate: do you maintain and extend the existing system, or do you burn it down and start fresh? There’s a whole graveyard of projects where teams chose wrong in both directions.
The calculus used to be about technical debt — how much cruft has accumulated, how hard is it to add new features, what’s the cost of maintenance versus the cost of rebuilding. ROI over a multi-year horizon.
That calculus now has a new variable: foundational obsolescence. And it doesn’t wait for your depreciation schedule. Now we need to ask if we’re building on a foundation that will still make sense in 6 months.
Rethinking Maintenance and Lifecycle
If the foundation shifts faster than the product cycle, the mental model has to change. A few principles that are emerging:
Think in generations, not versions. Versioning assumes continuity — v1.2 builds on v1.1. Generational thinking acknowledges discontinuity. A product built around one generation of AI capability is a different product than one built around the next. Budget and plan accordingly. Expect to rebuild, not just maintain.
Build the flexible thing first, then harden the desire paths. Pre-computing what users will want is increasingly a losing bet. A better approach: connect capable tools to real users, watch where the value actually lands, and harden the paths people actually walk. This only works if the flexible thing is good enough to use — a text box connected to a mediocre model produces frustration, not signal. But a capable model with good tools produces a live map of what your product should become.
Optimize for the ability to change, not for features. Features are the thing that keeps changing. What matters is whether your team can adopt a new AI capability in days rather than months. Whether you can throw away a subsystem without grieving it. Whether your organization has the flexibility to say “that thing we shipped last quarter is now the wrong approach” without it being a crisis. The teams that build the best AI-powered products over time aren’t the ones with the best v1. They’re the ones that can get to v5 without burning out or going broke.
Decouple aggressively. The more cleanly you can separate your application logic from your AI layer, the less painful it is when the AI layer changes. Teams that treat the model as a commodity to be swapped are far better positioned than teams that treat it as an infrastructure constant.
Shorten the meaningful horizon. Five-year software roadmaps are mostly fiction right now. Not because the business won’t exist, but because the technology assumptions embedded in those roadmaps will have expired. Six months of real visibility[MB5] is better than five years of false confidence.
Make the exit ramp part of the design. For enterprise buyers especially: if a vendor can’t articulate what a transition away from their system looks like, that’s a risk factor, not just a negotiating point. Data portability, integration flexibility, and contract structures that account for foundational change are table stakes, not nice-to-haves.
One Problem That May Actually Be Going Away
In the spirit of not ending on pure doom: there is one long-standing software headache that AI may have solved.
For most of software history, one of the high-stakes decisions in any project was framework choice. Pick the right one and you were riding a wave of community support, tooling, and talent. Pick the wrong one and you were maintaining a stranded codebase that nobody wanted to touch.
We built a project on Google Polymer once – I'm guessing you’ve never even heard of it. It made sense at the time — Google was behind it, web components felt like the future, and the technology was genuinely interesting. Then React took off, Polymer died, and that project became something we never touched again because the ecosystem around it died and the cost of re-engagement wasn’t worth it. On the other hand, we took a solid bet on React early, and that bet compounded for years.
Getting the framework call right — or wrong — had long-term consequences. A significant part of software strategy was just picking ponies and hoping yours could run.
AI coding tools have changed the rewrite calculus in a meaningful way. What used to be a six-month project requiring specialized expertise is increasingly something you can delegate over a few weeks. The framework becomes less of a permanent bet and more of an implementation detail. Stranded codebases are becoming unstuck. Post-launch concerns about the long-term sustainability of your framework choice are becoming more manageable.
So in that one dimension, the risk has genuinely decreased.
I don’t have an elegant way to sum this up and put a bow on it. Developers, designers, and product managers need to be super light on their feet now. Perhaps more importantly, stakeholders need to be attuned to these fundamental changes and how they impact project timelines, execution, and budgeting. The whole team needs to get used to operating with a lot more ambiguity.
If your team is thinking through what this means for legal AI strategy, product design, or delivery, get in touch.
