There’s a thought that has been with me for months, maybe since AI stopped being a distant promise and became a tool we use every day. It’s an uncomfortable thought, because it puts in question some convictions that guided me for years, and that maybe were more fragile than I wanted to admit.
It came back to me today when Prof. Zanero reposted this skeet:
An Uncomfortable Thought
The thought is this: absolute quality, the kind sought as a value in itself, may be a luxury we can no longer afford. Not always, not everywhere, not as a universal principle.
I write that and already hear the objections, the same ones I made to myself for a long time. “But quality always pays”, “Technical debt accumulates”, “Anyone who cuts corners fails in the long run”. All true, in a sense. And all things that deserve to be re-examined in light of a world that has changed faster than we were ready to accept.
I’ve spent years building teams, defining standards, fighting to have time to do things “properly”. I argued with sales people who wanted everything yesterday, with clients who didn’t understand why more time was needed, with developers who wanted to ship something imperfect. And in most cases I think I was right. But the right of then isn’t necessarily the right of now, and part of my work is to distinguish immutable principles from habits dressed up as principles.
The point was never speed versus quality, as if they were two opposite poles to choose between. The point was always: which quality, for whom, when, and how much does it cost me to maintain over time? Only today this question has different answers from the ones I was giving five years ago, because AI has changed the rules of the game in ways we’re still trying to understand.
When a generative model can write working code in a few seconds—code that once would have taken hours—the perception of value changes. I’m not talking about real value, I’m talking about perception. And in business perception counts, sometimes more than reality. A client who watches a competitor shipping features at a fast pace starts wondering why we’re so slow. And it isn’t enough to explain that our code is cleaner, more tested, more maintainable. Those are things they’ll only understand when they have a problem, and at that point it might be too late for everyone.
When Craftsmanship Works
The pure artisan model, the “we do everything by hand, calmly, with care” model, still works. But it works only in specific conditions that don’t always hold. You need a truly critical problem, where an error costs dearly. You need few credible competitors, because if there are many, the client has alternatives. And you need a client willing to pay a lot to sleep at night, which means a client who understands the risk and has the resources to mitigate it.
When those three conditions align, craft wins. When even one is missing, the promise “we do everything by hand, very well” risks being perceived as slowness and cost rather than value. And it isn’t the client’s fault if they don’t understand—it’s our responsibility to find a way to communicate that value or, if we can’t, to adapt to the market that actually exists.
Quality as Progressive Investment
Maybe the trick is to stop thinking of quality as an absolute and start treating it as a progressive investment, tied to the product’s stage and the actual needs of the moment. It’s a perspective that took me time to accept, because it goes against the instinct of someone who grew up professionally believing things should be done well or not done at all.
At the start of a product, when you’re still trying to figure out if there’s a market, you need something reliable enough on a very small perimeter. You don’t need perfection. You need something that works, doesn’t crash on first use, and is designed cleanly enough to grow without imploding. It’s the idea some people call “simple, lovable, complete”: little, but well done on what really counts. Not everything polished to perfection, but the right things done with care.
As the product finds market, as customers start paying, as revenue grows, you raise the level of robustness, security, and finish on the pieces that generate more value or more risk. You don’t polish everywhere uniformly, because you don’t have infinite resources and not everything deserves the same investment. You concentrate the craft where it matters, where a bug translates into direct damage, where quality makes the difference between a customer who stays and one who leaves.
And speed? Real speed isn’t obtained by writing mediocre code. I know because I’ve watched enough projects drown in their own technical debt to understand that cut corners always come back to bite you. Speed is obtained by cutting scope, deciding what not to do, automating tests, moving quality controls as close as possible to the moment the code is written. Especially when AI is in the picture, which can produce mountains of code in little time but doesn’t have the judgement to know which of that code deserves to exist.
This way you aren’t choosing between perfection and fast shipping. You’re choosing among various combinations on a front of possibilities that you can shift based on context. It’s a more honest way to think about the craft, I believe. Less romantic, perhaps, but more useful.
Real Quality and Perceived Quality
There’s also an uncomfortable thing that gets discussed too little, and it’s the gap between real quality and perceived quality. For the client, quality is mostly experience, not internal implementation. A clear interface, good response times, present and honest support cover plenty of technical defects that don’t break the flow. And paradoxically you can have technically very refined software perceived as mediocre because it’s slow to evolve, poorly aligned with the need, or badly communicated.
I’ve watched it happen. Projects we worked on for months to reach very high standards, that the client found frustrating because they didn’t answer their actual needs. And less technically polished projects that clients loved because they solved a specific problem in a simple way and got updated often without drama.
This doesn’t mean technical quality doesn’t count. It means it counts in relation to everything else, not as an absolute value disconnected from context. And it means part of our work is understanding what the client perceives as quality, not only what we know to be quality.
Where to Spend Craft Time
The question I ask myself most often lately is: where do I put my craft time in a world where AI can do a large part of the standard work? Not 60%, maybe not even 80% as some claim, but still a meaningful share of what once required hours of human labour.
At equal cost, the client willingly pays for the part where your judgement reduces a big risk or significantly increases the result. They don’t pay for the part where you handwrite something a generative model can churn out in seconds. And if you insist on billing time as if AI didn’t exist, sooner or later you’ll find someone offering the same result at half price, because they figured out how to use it.
I’ve started to think in different terms. I do by hand, to very high standards, everything close to money, to legal or reputational risk, to security. The pieces where a bug translates into direct damage, where judgement is needed and not just execution. And I let AI do, under careful supervision, everything that’s commodity, repetitive, easily testable, substitutable. Not because I trust it blindly, but because I know where to check and what to verify.
Pricing, then, should reflect the risk you take and the value you enable, more than the number of hours you spent on it. It’s a change that takes time to be accepted, both by us and by clients. But it’s the direction we’re going, whether we like it or not.
Who Really Risks Failing
And who really risks failing in this new world? I’ve asked myself that question many times, trying to understand where the real dangers lie.
I don’t think the people who love quality are at risk. I think the people who confuse perfectionism with professionalism are at risk—those who always slow down, who can’t say “this isn’t needed today”. Those who polish endlessly while the market overtakes them, convinced the world will eventually recognise their value. Sometimes it happens. Often it doesn’t.
And those at the other extreme also risk: those who chase only speed, saturate the system with ungoverned changes, accumulate technical debt without even noticing. Sooner or later the problems surface, customers lose trust, and all the time saved at the start gets paid back with interest.
Whoever has a better chance, in my view, is whoever can do three things together. Use AI to move fast, because not doing so means falling behind. Use the head to decide where to stop and polish, because not everything deserves the same care. And use honesty to tell the client what kind of quality they’re buying and why.
That last part is maybe the hardest. It requires admitting that not everything we do is perfect, that there are compromises, that some choices are made for time or budget reasons and not technical reasons. It requires trusting that the client can understand, or at least trying. And it requires accepting that sometimes they won’t, and we’ll have to find a way to keep going anyway.
These are reflections in progress, not definitive conclusions. The craft is shifting under our feet, and anyone who claims to have all the answers probably hasn’t fully understood the questions. What I do know is that the balance between quality and speed isn’t what it used to be, that AI has redrawn the boundaries of the possible, and that our task is finding a new way to create value in this different context.
It doesn’t mean abandoning principles. It means understanding which principles are really principles and which were just habits that made sense in a world that no longer exists. It’s a discernment work that requires humility, intellectual honesty, and the willingness to put one’s certainties in question.
And maybe, in the end, this is what separates a good professional from one who’s just repeating formulas they learned: the capacity to adapt without losing yourself, to change without betraying, to evolve while staying faithful to what truly matters. Which isn’t quality in itself, but the value that quality creates for the people who need it.
Key takeaways
The ghost of the perfect craftsman generates guilt in those who use AI and a sense of superiority in those who refuse it: both useless, because the value isn’t in the lines written by hand but in the system that holds up.
Real speed isn’t mediocre code: it’s scope cut, automated tests, quality controls close to the writing—otherwise AI produces technical debt that explodes at six months.
Pricing should reflect the risk you take and the value you enable, not hours on the clock—anyone billing as if AI didn’t exist will be overtaken by people who figured out how to use it.
Questions & answers
Why does AI put the relationship between quality and speed in software back into question?
Because for twenty years quality was the trade-off of speed: doing it fast meant doing it worse, doing it well took time. AI breaks that correlation across a certain band of work: you can get decent-quality output at speeds that previously required sacrifices. But the band where this holds doesn’t coincide with the one we imagine—and that’s where the ghost of the perfect craftsman comes from.
What is the "ghost of the perfect craftsman"?
It’s the idealised image of the developer who ponders, designs, writes every line with maniacal care. It existed in a few privileged situations, but became universal myth. AI makes it untenable not because it isn’t valid—because it isn’t scalable. The ghost generates guilt in those who use agents and superiority in those who don’t. Both useless.
Can you have quality and speed together with AI?
Yes, but not automatically. You need a control infrastructure: serious code review, comprehensive tests, observability, explicit acceptance criteria. With that infrastructure, AI multiplies productivity without compromising quality. Without it, it accelerates by producing accumulated technical debt that explodes six months later. The difference isn’t the tool, it’s the process around it.
What should someone do today who feels squeezed between the two demands?
Stop chasing the ghost. Accept that a good professional uses the tools available (AI included) with critical judgement—not with nostalgia. Value doesn’t sit in having handwritten every line, it sits in having produced a system that holds up, is documented, can be modified. Anyone measuring their work in hours spent writing code is measuring the wrong thing.
The author
