Software quality is often discussed as though the goal is always to maximize it. More tests. Cleaner abstractions. Better architecture. Greater maintainability. More rigor. For most production systems, those are worthwhile goals. But I think there is a better way to think about quality: quality is an architectural characteristic.

Like reliability, usability, performance, scalability, or feature richness, quality should be prioritized in context. It is something we make trade-offs around, not something that exists outside of trade-offs. That distinction matters because not all software deserves the same level of investment.

Consider disposable software. If I build a small tool for myself, solve one narrow problem with it, and have no real expectation of maintaining or evolving it over time, then the economics are very different. Do I need extensive automated tests? Do I need carefully designed abstractions? Do I need an architecture built for years of future change? Probably not.

I recently built a small tool using AI-assisted software engineering to manage and visualize MermaidJS diagrams. I use it regularly and have shared it with a couple of coworkers, but I still think of it as disposable software. I am not treating it as a long-lived product. If it becomes difficult to maintain or stops doing what I need, replacing it may be cheaper than carefully evolving it.

That changes the right architectural trade-offs. The appropriate level of quality for that tool is different from the appropriate level of quality for a production system that dozens of engineers may maintain for years. The point is not that quality stops mattering. The point is that the right amount of quality depends on the context.

Every architectural characteristic has a cost. We already accept this when we talk about performance, scalability, reliability, development speed, or infrastructure cost. Improving one dimension usually means spending time, money, complexity, or attention somewhere else. Quality is no different. Teams can spend significant effort refining abstractions, increasing test coverage, eliminating duplication, and preparing for future requirements. Sometimes that is exactly the right investment. Sometimes it is not.

The question should not always be:

"Are we following every software engineering best practice?"

A more useful question is:

"What level of quality does this software actually require?"

That answer should be influenced by things like expected lifespan, number of users, frequency of change, business criticality, operational risk, team size, and the cost of failure.

There is also an important distinction here: software built using AI-assisted software engineering is not automatically disposable software. Those are separate ideas. AI-assisted software engineering is increasingly becoming part of ordinary software engineering. Production systems are being designed, implemented, tested, and evolved with help from coding agents, copilots, and large language models. That does not change what the software itself requires.

If a system is expected to live for years, support customers, evolve with the business, and be maintained by a team, then its architecture still matters. Its tests still matter. Its maintainability still matters. Its non-functional requirements still matter. Using AI-assisted software engineering does not make software disposable. If anything, the speed that AI introduces can make architectural discipline even more important.

One of the most useful mental models for me is this: AI is an accelerant. It does not inherently remove complexity. It increases the speed at which we can produce software. If the underlying engineering approach is strong, AI can help us create maintainable systems and deliver value faster. If the underlying approach is weak, AI can accelerate technical debt just as easily.

You can produce tightly coupled code faster. You can spread bad patterns faster. You can create abstractions you do not understand faster. You can accumulate complexity faster. The ability to generate more code does not reduce the need to reason about architecture. If anything, it makes it more important to understand what kind of system we are trying to build before we accelerate its creation.

AI is not reducing complexity. It is changing how quickly we operate within that complexity.

Good architecture has never been about maximizing every desirable characteristic. It is about understanding which characteristics matter most for a particular system and making deliberate trade-offs. Quality should be treated the same way. For disposable software, the appropriate investment may be very low. For a long-lived production platform, maintainability, testing, design quality, and architectural coherence may be essential.

Neither approach is inherently correct in every situation. The mistake is applying either one without considering the context. Quality matters enormously. But like every architectural characteristic, it matters in proportion to the problem we are actually trying to solve.

And as AI-assisted software engineering lets us build software faster than ever before, making that distinction becomes increasingly important.