blog

Guest post by Sandro Mancuso, Co-founder and Group CEO, Codurance
First published here.

If you feel you have relevant content for our blog, get in touch.

AI coding tools are completely changing the software development landscape. Developers now rely on tools like GitHub Copilot, Amazon CodeWhisperer, and ChatGPT to generate code, fix bugs, scaffold tests, and accelerate routine tasks. Code that once took hours can now be produced in minutes; sometimes seconds. Prompting is quickly becoming a core developer skill.

AI is here to stay. The promise is undeniable: higher output, faster delivery, and fewer repetitive tasks. But with this leap in speed, a deeper question emerges:

Are we building well – or just fast?

This article explores that question through the lens of Software Craftsmanship, offering a pragmatic perspective on how to embrace AI without sacrificing the principles that make great software possible.

What This Article Covers

• The speed vs. quality paradox

• The true bottleneck of engineering

• The degradation of precise code

• The acceleration of knowledge loss

• The crisis of massive pull requests

• The loss of semantic boundaries

• Rethinking AI testing and TDD

• Software Craftsmanship as the compass

1. Productivity is More Than Fast Code Generation

True productivity in software isn't about how many lines of code are produced, or how quickly they're typed. It's about how effectively developers solve meaningful problems, ensure their solutions are correct, and leave the codebase in a better state than they found it.

Productivity is the ability to consistently deliver valuable, maintainable software with minimal friction, rework, or risk. That requires far more than rapid output. It demands clarity, correctness, and changeability.

AI gives us a powerful new engine. But productivity still requires a steering wheel. When speed is mistaken for progress, teams end up shipping more low-quality code, creating more rework, and compounding long-term risks.

In fact, many teams are now experiencing a paradox:

Features are delivered faster… but bugs, regressions, and entropy increase.

This isn't because AI is bad at coding. It's because code quality, modularity, testability, and team knowledge are systemic factors that AI doesn't automatically account for.

And that's the real point:

Software productivity is a property of the system, not of the speed of an individual developer.

Generating code faster doesn't necessarily reduce delivery time, maintenance effort, or rework. If the generated code is misaligned with business intent or poorly designed, it can increase downstream costs. Speed is productive only when it supports clarity, correctness, and adaptability.

When paired with strong engineering principles, AI can amplify not just speed but also effectiveness, helping teams deliver better software, faster.

2. Where is Time Really Spent?

When people talk about productivity in software development, they often think of it in terms of how fast developers can write code. But research and real-world experience suggest a very different picture.

According to a 2019 study by Microsoft Research ("Today was a Good Day: The Daily Life of Software Developers"), it is safe to estimate that less than 25% of a developer's time is spent editing source code. The majority is spent on activities such as reading code, navigating through the codebase, understanding system behaviour, meetings, and refining requirements.

This tells a clear story: the bottleneck in software development isn't how fast code can be typed, but it's how quickly a developer can understand what needs to change and where.

Even with AI accelerating code generation, developers still need to navigate and reason about the existing system. But when that system is messy — with poor modular boundaries, inconsistent naming, duplicated logic, or missing tests — the cost of understanding rises significantly.

The problem isn't how fast we can write new code, it's how fast we can safely change and understand the code we already have.

What makes this understanding difficult?

• Poor modularisation: When code is scattered across poorly defined or overlapping domains, developers have to trace logic across multiple files or services to understand behaviour.

• Inconsistent or vague naming: Bad names at any level increase the mental load required to decipher what code does.

• High complexity: Deeply nested logic, long methods, or tangled conditionals increase both cyclomatic and cognitive complexity.

• Lack of test coverage: Without meaningful, up-to-date tests, it's difficult to understand the intended behaviour or to know whether a change will break something.

• Verbose or poor-quality tests: Ironically, bad tests can be worse than no tests — they introduce noise and false confidence rather than clarity and safety.

• Duplication: Copy-pasted logic spread across the codebase requires multiple changes to fix a single issue, increasing the risk of regression.

In this context, Software Craftsmanship practices like modular design, naming discipline, and clean code principles are not luxuries but time-saving mechanisms. They reduce the cognitive friction developers experience every day.

AI can dramatically reduce effort — but only when it helps clarify and simplify, not obscure. Craftsmanship ensures that acceleration doesn't come at the cost of comprehension.

3. From Imprecise Language to Precise Code

Programming is one of the most precise forms of communication humans engage in. Unlike natural language, where ambiguity and nuance are expected, source code must be explicit, unambiguous, and logically consistent. Every character matters.

Large Language Models such as Copilot and ChatGPT are designed to predict and generate plausible text sequences, including code. However, the inputs they receive — our prompts — are written in the same imprecise natural language we use in conversation. So we now have a situation where:

• Developers write vague prompts based on an incomplete understanding of the code or system.

• AI-generated code can be influenced by poor-quality patterns in the surrounding codebase or public training data.

• The generated code is accepted and merged, sometimes without a clear understanding of what it does or whether it introduces inconsistencies, technical debt, or subtle bugs.

Without solid foundations in software design and modularisation, AI tools tend to amplify existing flaws in the codebase. For example:

• A bloated class gets even bigger.

• A poorly named method is copied and modified elsewhere.

• A missing abstraction remains missing, repeatedly duplicated across different files.

In this scenario, Software Craftsmanship becomes even more important, not less. Well-modularised, well-named, and well-tested code doesn't just help humans navigate the system — it gives AI tools better patterns to work with.

LLMs operate in a grey zone between fuzzy language and deterministic code. If the base code is poor and the prompts are vague, even the most powerful models will generate subpar solutions. Bad code tends to propagate more bad code.

Craftsmanship brings the precision AI needs. If AI is the power tool, then Software Craftsmanship is the blueprint. Without the latter, we're just generating code faster, not better.

4. Speeding up Knowledge Loss

One often-overlooked consequence of generative AI in software development is the acceleration of knowledge loss.

Traditionally, when a developer wrote a piece of code, they spent time thinking through the logic, making design choices, naming things, and understanding how it fit within the system. This process, though sometimes slow, helped developers internalise the business rules, technical constraints, and trade-offs behind the code they were writing.

But when AI generates that code in seconds, the developer becomes a passive editor, not an active author. The mental model and the deep understanding that comes from wrestling with a problem is often missing.

We are seeing a growing pattern:

• Developers can no longer explain their own code.

• Codebases grow faster than teams can understand them.

• Knowledge is not transferred — it's outsourced to the tool.

Even worse, this isn't just happening at the individual level. In modern organisations, systems are often large and distributed, built by multiple developers working in parallel. Their prompts vary. Their context differs. The result? A mess of overlapping logic, duplicated effort, diverging implementations, and semantic drift across services.

Software Craftsmanship offers a counterbalance. It values shared understanding, semantic clarity, and intentional design. Without these principles, we're building systems we don't fully understand, at a speed we can't keep up with.

5. Size of Changes and Review Discipline

"Over-dependence on AI assistance could erode core engineering competencies"

Code review has always been one of the most important quality gates and knowledge-sharing activities in a professional software development process. But for reviews to be effective, the changes under review must be understandable, contextual, and critically, small enough to reason about.

AI-generated code is disrupting this balance. Developers can now make sweeping changes across dozens of files in minutes. The speed is intoxicating — but it comes with serious downsides:

• The size of pull requests is growing dramatically.

• The complexity of changes is increasing, often with inconsistent design decisions across the modified files.

• Reviewers are overwhelmed and unable to meaningfully assess what changed and why.

The natural response to a massive pull request? Skimming, or worse, rubber-stamping. When reviews become superficial, quality declines, bugs slip through, and the opportunity for shared learning disappears.

Software Craftsmanship calls for a different approach:

• Frequent, small, well-scoped commits.

• Intentional design choices, not just functional outputs.

• Meaningful reviews, where both the author and the reviewer learn and improve together.

• Pair programming, where knowledge-sharing and better design decisions are a direct byproduct, minimising the need for formal code reviews.

AI can assist in this process — generating boilerplate, suggesting improvements, and accelerating menial tasks — but only if we maintain control over the pace and scale of change.

6. The Loss of Semantics

In software development, structure is *meaning*. We rely on semantic modularisation — clear architectural boundaries, meaningful naming, and well-defined responsibilities — to make systems understandable and maintainable.

Unfortunately, most codebases are already far from ideal. Semantic boundaries are blurry or non-existent. Business logic is scattered across layers and services. And now, AI tools are learning and building on top of this mess.

Without a solid semantic foundation, even the most powerful AI assistant struggles to generate high-quality solutions. Semantic deterioration accelerates over time:

• AI-generated changes are based on the available context — often a poorly structured codebase.

• Different developers provide different prompts, based on their own mental models.

• AI-generated code across services introduces naming collisions, duplicated logic, and divergent implementations — a form of semantic drift that makes large systems harder to evolve.

What emerges is a system that technically works, but is conceptually incoherent — a patchwork of ideas, styles, and assumptions.

Craftsmanship places semantics at the core: code should express intent; modules should reflect business capabilities and change boundaries; names should reveal purpose, not just implementation.

Combining AI's speed with the design awareness of Software Craftsmanship can help teams preserve meaning and structure at scale.

7. Rethinking Testing with AI: From Verification to Design Partner

One of the most powerful practices in Software Craftsmanship is Test-Driven Development (TDD) — not only for ensuring correctness but also for guiding design. Starting with a test helps developers clarify expectations, break down complex behaviours, and produce cleaner, more modular code.

Many developers now generate production code first and then ask AI to create tests afterwards. While convenient, this reverses the flow of intent. Instead of tests defining behaviour, they become a rubber stamp for whatever the code currently does — even if it's wrong, inefficient, or misaligned with business goals.

We're increasingly seeing test suites filled with:

• Weak or redundant assertions

• Loads of duplicated test setup for small behaviour variations

• Tests that don't clarify intent or edge cases

• Verbose code that's difficult to read or maintain

That said, AI can be a powerful ally in testing when properly guided. Developers can use a TDD mindset to prompt AI in a more structured way:

1. Provide the AI with overall system context and design guidelines.

2. Work in small steps, explicitly defining the behaviour, class names, method parameters, and return types expected.

3. Outline specific test scenarios (sunny-day to edge cases) and ask the AI to write the test or check for vulnerabilities before generating implementation code.

In the end, testing isn't just about validating correctness — it's about protecting quality. The more we embrace AI as a tool that augments human judgement, the more we can preserve the essence of Craftsmanship, even as we build faster and at greater scale.

8. How Software Craftsmanship Helps

AI is revolutionising how we write code, but without guidance, it may erode the very qualities that make software valuable. That's where Software Craftsmanship comes in.

Craftsmanship is not about resisting change or romanticising the past. It's about upholding timeless principles that ensure software remains an asset, not a liability, no matter how it's built.

At its core, Craftsmanship is a commitment to:

• Well-crafted software — code that is clear, testable, maintainable, and aligned with business needs.

• Professionalism — practices that ensure long-term sustainability, team growth, and business agility.

• Productive partnerships — between developers and stakeholders, grounded in trust and shared understanding.

Large language models don't understand your business. They don't care about your architecture. They don't recognise the trade-offs you're making. Without thoughtful prompts and high-quality context, they will generate plausible code, fast, that could just as easily create long-term friction as short-term progress.

Software Craftsmanship helps by:

• Framing the role of AI: not as an autonomous coder, but as a powerful assistant that must be guided.

• Emphasising intent: ensuring that every change reinforces modularity, clarity, and business meaning.

• Safeguarding correctness: by embedding tests, design thinking, and review into the workflow.

• Slowing entropy: through consistent practices, naming conventions, and architectural discipline.

Most importantly, Craftsmanship embraces AI while upholding standards. It recognises that typing has never been the bottleneck — comprehension, decision-making, and quality have.

9. Closing: Crafting Code in the Age of AI

AI is transforming the software development landscape, helping us code faster, automate the mundane, and explore solutions we might not have considered on our own.

But speed is not the same as productivity. And volume is not the same as value.

If we embrace AI blindly, we risk flooding our systems with hard-to-maintain, disconnected code — generated rapidly, poorly understood, and halfheartedly reviewed.

What we need now is intentionality. A mindset that values clarity, structure, and continuous improvement. A commitment to practices that preserve business agility, not just accelerate short-term delivery.

That's the role of Software Craftsmanship in the AI era. Not to resist change — but to guide it. To ask better questions. To set better constraints. To ensure the software we build remains robust, understandable, and adaptable, even as the tools we use evolve.

Craftsmanship turns AI into a powerful ally. Not by handing over control, but by raising the standard of what "good" looks like — and ensuring that every line of code, AI-written or human-written, contributes to long-term success.

The future of software won't be written by AI alone — but by those who know how to wield it with craft. AI is the engine. Craftsmanship is the compass.

Frequently Asked Questions

If AI can write code in seconds, why should I care if my codebase is messy?

LLMs do not inherently understand your specific business context — they rely heavily on the context provided in your prompt and your existing code. If your codebase has poor modular boundaries, inconsistent naming, and high complexity, the AI will use those exact flawed patterns as its baseline, generating bloated classes, duplicating missing abstractions, and amplifying your existing technical debt at a much faster rate. Clean code is no longer just for human readability — it is the vital blueprint AI needs to give you accurate results.

The article says developers spend less than 25% of their time editing source code. What are they doing with the rest of their time, and can AI help?

According to Microsoft Research, the vast majority of a developer's day is spent reading code, navigating complex systems, discovering system behaviour, refining requirements, and aligning with team objectives. While AI can assist with some of these tasks (like summarising files or explaining unfamiliar legacy code), it cannot replace the deep mental model an engineer needs to make safe architectural changes.

How exactly does AI cause "knowledge loss" if the developer is still the one prompting it?

Traditionally, the slow process of wrestling with a problem forced developers to internalise business rules and technical trade-offs. When developers rely on AI to instantly generate massive blocks of code, they shift from being active authors to passive editors. They might skim the code, see that it "works," and paste it in. As a result, developers lose the ability to explain their own changes, codebases become black boxes, and team-wide domain knowledge erodes.

I use AI to write my unit tests after I write the code. Why is this bad practice?

Writing tests after the code flips the intent of testing on its head. Instead of the tests acting as a design tool that enforces business requirements, the AI-generated tests simply conform to whatever the production code currently does — even if that code is wrong, inefficient, or missing edge cases. This results in a "rubber-stamp" test suite with a high coverage percentage but weak, bloated, difficult-to-maintain tests.

How can I use AI for TDD if the AI just wants to write code immediately?

You have to change how you prompt. Treat the AI as a design partner by:

1. Providing the AI with your overall system context and design guidelines.

2. Directing the AI in small, incremental steps, explicitly defining the behaviour, class names, method parameters, and return types you expect.

3. Outlining specific test variations (from sunny-day to edge cases) and asking the AI to write the test or check for vulnerabilities before generating the actual implementation code.

If AI delivers features faster, isn't that a net win for business productivity?

Only if those features don't require massive rework later. True software productivity isn't just about output volume — it's about the consistent delivery of maintainable software with minimal friction and risk. If AI-generated code is conceptually incoherent or misaligned with business intent, it dramatically increases downstream maintenance costs. Speed without direction is just creating a bigger mess faster.

Citations

1. Microsoft Research (2019). "Today was a Good Day: The Daily Life of Software Developers."

microsoft.com/en-us/research/wp-content/uploads/2019/04/devtime-preprint-TSE19.pdf

2. Yegor Denisov-Blanch, Researcher, Stanford (2025). "Can you prove AI ROI in Software Engineering?"

youtube.com/watch?v=JvosMkuNxF8