Clever Spark — Blog

Will AI Make Our Code Quality Worse?

tomasz-feliksik — Tue, 29 Sep 2026 00:00:00 GMT

Clients ask us one question more often than almost any other: if we let AI write our code, will our code quality get worse?

It is a fair question. The people who ask it expect to maintain that code for years.

The short answer: with AI, quality does not come for free. But you can manage it, and the same automation that writes the code can check it.

The Worry Is Rational

The popular version is "AI generates spaghetti code". The serious version has three parts:

Speed: a model writes plausible code faster than anyone can read it.
Review: review was already the bottleneck, and now there is far more to review.
Erosion: quality does not drop on a specific day; it degrades one reasonable-looking change at a time.

All three are true. What I disagree with is the usual conclusion: that erosion is the cost of speed, and the only defence is to keep AI out.

It Is Still Engineering

I have written before, in AI won't fix your architecture, that building software with AI is still engineering, just as building it without AI is. This question is a good test of that.

Look closely at the fear of bad code and it is usually a fear of one way of working: no structure, prompt and hope, vibe coding. Code gets accepted because it looks right, and nothing checks whether it is. That fear is justified. Code written that way does degrade.

Approach it the way an experienced team approaches any system, and the question has a practical answer.

So the useful question is not whether AI writes good code. It is what you build around the agent.

Four Questions a Good Harness Answers

Claude Code and Codex come with a harness off the shelf. The part that decides your code quality has to fit your code, so you build it on top: the workflow, rules and checks an AI coding agent works inside. It has to answer four questions:

Is the code written correctly?
Does the code do what it should?
Can the code and its architecture evolve over time?
Does the path from idea to use protect quality?

None of these is new. Keeping quality in a system built with AI is not fundamentally different from keeping it when people write every line: the same questions, answered with the same kinds of tools.

What AI changes is the cost of acting on the answers. Refactoring is no longer a project you have to schedule. You can write some code, use it to understand the domain better, and improve it soon after. The quality of such a system depends on its feedback loops, and AI lets you automate them.

So I think the claim that AI-generated code is inherently worse is backwards. Set up this way, keeping quality high is easier than with hand-written code, not harder.

1. Is the Code Written Correctly?

This is the job of the compiler and the tools around it: static analysis, linters, formatters. None of them depends on anyone remembering to run them. Run them automatically while the agent works and send the results straight back to it: that is the shortest feedback loop you can have. It does not answer the bigger questions, but it removes many small problems: constructs that lead to undefined behaviour and patterns known to be bad practice. Passing static analysis doesn't make code good; failing it means you are asking for trouble.

This loop is fast and takes almost nobody's time. If static analysis flags a piece of code, the agent can usually fix it straight away, without supervision.

2. Does the Code Do What It Should?

The simplest way to check is to test it. Tests are code, so AI can write them too, and much of that work can be automated. But choosing good test cases, and writing code that can be tested in the first place, takes engineering judgement. The system has to be designed so that it makes the agent's job easier, not harder.

So this area needs more human involvement than the first, at least at the start. A person goes through the test cases with the agent: which behaviours matter, where more tests are needed and where fewer, and which level each part belongs at, from unit to end-to-end.

3. Can the Code and Its Architecture Evolve Over Time?

Here again you need someone who can design the architecture, and good architecture comes from understanding the domain well. Agents can help with the preparation: when a feature is defined, a technical analysis compares what the feature should do with what is in the code today and lists the options, A, B, C, sometimes D. But a person has to review that analysis carefully and choose. No agent knows which domain we are trying to model in code.

This is where most of the design work happens. Someone decides how the system should work and gives it a structure that works today, stays readable for the people and agents who open the code later, and is easy to extend, because most code eventually gets extended.

That needs someone who understands what is being built: the product and the business domain. These are also the decisions that are most expensive to reverse, which is why this is the last place to take the person out. Leave it all to an agent and it will almost certainly fail.

That does not leave the models out. Current ones such as Opus 5.5 and GPT-6 Sol are very good at the review side of architecture. Given the whole codebase, they can compare what the code does with what the architecture says it should do, point out where the two have drifted apart, and keep the architecture documentation up to date: the module map, the decision records, the boundaries between parts of the system. That changes where the architect spends their time. Instead of piecing the structure together from files, they work from an accurate description of it and make decisions at that level. The decisions are still theirs.

No harness will decide what your product should be. If someone promises you one that does, they are giving you an answer without thinking.

Automating the first two areas frees time for the third. The person building the software gets much more time for the part where an agent can help but cannot do the work.

4. Does the Path From Idea to Use Protect Quality?

This question is not about the code but about the path it takes: from noticing that something needs doing, through defining it, planning the implementation and building it with its tests, to checking that it works as intended, deploying it and, finally, someone using it.

How that path is set up, which steps are automated and, above all, where you put deliberate human checkpoints, has a big effect on the quality of the result. In a well-structured workflow with clear rules and a lot of automation, the natural checkpoints to start with are:

defining what we want to do;
deciding how to implement it in the code;
turning that into a concrete plan;
defining how we will test it;
going through or reviewing the test cases;
validating the result.

At each of these, a person applies engineering judgement and checks the agent's work. Everything in between can be automated, so the person can give each checkpoint more attention than they could if they were writing everything themselves.

This is a starting point, not a permanent setup. The checkpoints do two jobs early on: they make the team comfortable with what the agent is doing, and they show where it goes wrong. That second job is what lets you remove checkpoints later. Once you know which kinds of work the agent handles reliably, you can decide by risk. A change that could do serious damage, or would be hard to reverse, keeps a person in the loop. A low-risk change that is easy to undo can go through on its own. Some teams already sort their work this way. Keeping a person on every change is not the goal; it is how you learn which changes need one.

So, Will It?

It can. AI can make your code quality worse. It can also take it to a level of consistency that a team writing every line by hand rarely reaches. Which of the two you get does not depend on the model. The four questions say what good quality means. Whether you get it depends on three decisions about the system you build around the agent:

Where the automated feedback loops go. A feedback loop here means a check whose result goes straight back to the agent: the static-analysis report, the failing test, the compiler error. The agent reads it and fixes the problem itself, so the system corrects most mistakes before it takes up anyone's time.
Where the person goes. At which points someone sees the work early enough to step in when it is going wrong.
How precisely the path is defined. A single step called "check quality" gets done differently every time. Spell it out as fixed steps, such as write the tests, make them pass, review the result, and each one happens on every change. How the agent gets through a step is still up to it.

This is how we work today. The harness we implement for clients is one we built ourselves, so its steps are shaped to each client's system. An agent cannot close a task until every step the process defines is done, and control stays with a person at the points the process names. Inside each step, the agent still works with its full capability.

Get those three decisions right, and track how the four areas above change from where they stand today. Then you know which way your code is going instead of guessing.

When someone last told you your code quality was fine, which of the four were they actually looking at?

The Signs That Your AI Implementation Is Going Wrong

tomasz-feliksik — Sun, 20 Sep 2026 00:00:00 GMT

This is the complement to the piece on the unobvious signs that an AI implementation is working: a collection of the signs that one is going wrong, observable from the CEO's or CTO's chair and easy to misread as "early days". I hope it helps you notice the drift before a metric does.

We have watched these arrive in the organisations we work with — usually several at a time, because they share a root, which the last section names. One simplification: I assume you pay for tokens rather than seats, as larger organisations with real data-handling constraints tend to. The arithmetic differs on a subscription; the signs do not.

1. Nobody Is Using It

You bought the tool, cleared it through security and procurement, announced it — and the usage line stays flat.

The instinct is to treat this as a training problem. Sometimes it is. Just as often it is a human one: people come to work to do the job they agreed to do, and for some the prospect of a machine writing code — and, God forbid, writing it better than they did — is genuinely frightening. That is a reasonable thing to feel, and nobody has addressed it.

The question to ask first is not why aren't they using it but who wanted this rolled out, and what was the goal? Bottom-up and top-down both work; what fails is one side assuming the other will simply follow. Sometimes the answer really is training. Sometimes it is something deeper — not being able, or not wanting to — and worth finding out. The simplest way to tell them apart is to start with that question.

2. Costs Climb, and Nothing Changes

The opposite sign, and the more common one. People are using it; the bill says so, and the bill grows fast. Yet nothing at the level of the organisation has moved: the product changes at the pace it always did, the reviews look the way they always looked, and if you asked what the tokens bought, nobody could point at it.

That is an evident sign something is wrong — and the one most likely to be read as success, because a rising usage line is the one thing a rollout produces on schedule. I wrote earlier that a usage dashboard measures attendance, not proof; here the same line has gone one step further, from proof of adoption to proof of cost, without ever passing through proof of effect.

3. A Proof of Concept for Everything

Demos multiply. Every idea gets a prototype, every prototype gets a presentation, and the organisation is visibly busy with AI. Then a month passes, then two, and nothing beyond the prototypes has appeared.

Making something that works on the happy path is trivial with today's tools. The work is the part after: making the thing that demos well coherent with the architecture you actually run and the way the business actually makes money. That is where the difficulty is, and where prototypes go to stay prototypes.

Some proofs of concept belong at the start. If after a couple of months they are still all you can see, the organisation is playing with the tools rather than solving problems with them.

4. Pull Requests Nobody Can Explain

Code volume goes up and understanding does not go with it. We have been on the receiving end: several pull requests dropped on a team with the instruction "integrate this somehow", and nobody on that team able to see how they connected to the code it was running. Merge, or not? There was no good answer, because the work had been done without understanding the system it was meant to join.

Generating code is cheap now. Understanding the code you generated is still work, and if it is not done, what you are accumulating is code that cannot be maintained. Signs 2, 3 and 4 share one mechanism: the tool was handed out, and the how was not.

5. The Conversation Is About Cost, Never About Effect

This one arrives later. Cost is on the agenda of every leadership meeting; effect is on none. The question being asked is how much has it grown, when the question that matters is does it pay back — and the first question always has an alarming answer, because burning tokens is what usage looks like.

There are three ways to be here: the effects exist and nobody counts them; the effects do not exist; or someone is reading the whole thing purely financially rather than as a balance of gains and costs. From the chair that sets budgets, all three look identical.

The simplest effect needs no instrument. Is there a meaningful increment every week or two? Do the teams say at the daily what they finished? Do completed, genuinely useful pieces of the product show up at the review? If that improved, the cost line reads differently. Either way the question about delivery comes before the question about spend — and in a failing rollout it is never asked.

6. Everyone Gets the Same Cut

The move that follows from sign 5, and it is an averaging. The organisation looks at how much it is able to spend, divides it equally, and does not look deeper or try to understand where the spend came from. Fair, defensible upward, and the one control that does not look like picking favourites — I have held versions of the position myself. The trap is on the other side of the average: the teams that may have been using the tools effectively now have a budget that lasts a week instead of a month.

The trouble is what the flat rule does not look at. Spend is not spread evenly, and it is uneven for reasons: some teams never picked the tool up, some use it without judgement, and some have built a working workflow in which increments arrive quickly and the tools are used heavily because they are used well. A cap that treats those three the same barely touches the first, trims the second, and sends the third back to writing code by hand — or to rationing tokens across a feature to make sure it can be finished.

That is the organisation shooting itself in the foot. The teams that had made the investment work are exactly where its potential was, and they are the ones a flat cut hits hardest — precisely because they were trying. A team on the receiving end will ask the question the cut skipped: why did nobody ask who delivers how much? Before any cut, find the teams using it well, look at what they do, and optimise with them. Cut per delivery, not per head.

7. Token Usage Becomes Something to Brag About

The trap at the end of this road. An organisation with no way of seeing the work has one number it can see, and the temptation is to show it: usage, per team, per month. Once that is accepted as the way work is presented, the final form of the problem arrives — people start taking pride in how many tokens they used rather than in what they did, and a good team comes to mean a heavy user.

A team showing its usage next to what it delivered is fine. In the first two weeks, when the only question is whether anyone uses the tool at all, even usage alone is fine. Past that, a beauty contest on consumption is a very red light: high token usage says nothing about whether it was worth it, and an organisation that rewards it has stopped asking.

They Share a Root

Every sign here is the same fault from a different angle: the organisation is watching the input — tokens, licences, prototypes, pull requests — because it never wrote down what the output would be. Each is measurable the day the contract is signed; none is an effect.

I have watched this habit for years: organisations using story points as a proxy for something they simply could not see in the data. This is the same situation with a new number on it. Every metric you watch should come with one more question attached — what decisions will we make on the basis of it? If you have an answer, the metric is probably a good one. But for a metric to work, you usually have to look at the thing from several perspectives, and an organisation that wants to simplify a complex problem down to a single number that is easy to track on a slide is giving up visibility it ought to have.

An organisation that can count its tokens and cannot name its effect is not measuring the rollout. It is measuring the bill.

The room the sibling piece describes is the effect. When the room has nothing to show, the numbers start talking instead, and the seven signs above are what that conversation sounds like.

What This Asks of You

Before the next cost conversation, write down what the effect was supposed to be, and put it next to the spend, team by team, in whatever form you can already see: increments shown, not tokens burned. Then decide the cut, if there is one, per delivery rather than per head.

That costs two real things. The uniform rule, which looked fair and was easy to defend. And the admission that the rollout was bought without anyone saying what it would have to change.

Which of these could you see from your chair this month — and which number were you looking at instead?

7 Signs Your AI Adoption Is Working That No Usage Dashboard Shows

tomasz-feliksik — Tue, 15 Sep 2026 00:00:00 GMT

This is a collection of signs we see in software teams whose AI adoption has worked. They are observable and they are not obvious — none is the thing a leader is usually told to watch. I hope it helps you tell whether your own AI rollout is working.

I noticed each of them once, then watched to see whether it kept happening. It did, in more than one team, usually several at a time. I am writing them down because they are easy to miss: most look like a pleasant side effect, or like nothing happening at all, and an AI usage dashboard shows none of them. Here they are, named directly.

1. Reviews Run Long, and the Stakeholders Start Talking

The old review: someone walks the board, and the next item is "done on the backend, so there's not really anything to show." Everyone nods — I said versions of it myself — and the meeting ends early.

When the rollout has worked, the review has the opposite problem. It has to be extended, because demonstrating what was built takes real time. Stakeholders who used to sit politely start speaking, because watching a product work is engaging: could we do this slightly differently? Could we also add that? Discussion replaces demonstration.

Underneath: a larger piece of functionality costs far less, and a well-designed AI harness can build a change end to end. Five partial tasks become one complete change a user would notice.

2. Quarterly Planning Starts to Look Naive

Product development accelerates enough that a detailed three-month plan loses its value: the gap between deciding a direction and acting on it shrinks to days, and the plan is out of date weeks before the quarter ends.

The same goes for how the work is seen. If your stakeholders experience the team's work once a quarter, through a slot at one large meeting where everyone presents PowerPoints, that is far from what is possible today. The path to better is shorter than it looks: the product already changes every week or two; the meeting only has to catch up. The right interval is for each organisation to work out — the sign is that the question gets asked at all.

3. The Team Asks for Meetings With the Business

Easy to misread, so the mechanism matters. An overloaded developer used to have good reason to avoid another meeting with the business: it carried personal risk. New requirements, new expectations, more work — or rewriting what they were halfway through.

With a good harness the effect disappears, then reverses. The work gets far enough that a lack of information from the business becomes the real obstacle — the thing stopping developers from working effectively and feeling confident in what they are building. That is when the appetite appears, unprompted: let's work more closely together. The risk of doing something that has to be undone is largely gone, and when something is reversed, it does not hurt. And hearing from the business that the work is good does more for confidence than any internal review.

The strongest version of this signal is the team saying: "We want to discuss this with the customer. We have two or three ideas, and we want someone to help us decide which is better for users." Recently a team asked for exactly that — an extra half-hour with a stakeholder — and came out with a simpler solution. The tell is not that the meeting happened. It is that the team asked for it.

4. Nobody Asks About Story Points Any More

Organisations fall back on simple metrics when they have no good way to see what they actually want to see: the product is not changing visibly, so at least make sure the team completed a lot of story points. A well-implemented AI system makes the process observable through its outcomes — what changed in the product this week is there to click through. At that point nobody needs story points, or team performance metrics, to see that things are going right.

Comments like "finally we are talking about the product instead of someone evaluating me on story points" and "great, we are focusing on the work" start to emerge. Your ticketing tool did not change; it is just that a board reflecting what is actually happening organises the work instead of policing it.

Good process management is still needed: freed capacity can also be filled with more tasks in progress, and then nothing changes. Properly managed work-in-progress remains the discipline — but…

5. The Process Becomes Invisible

Not because there is less of it — because more of it is automated. An agent sits in the requirements meeting and drafts the story from the conversation, so the team's attention goes to what the story is and whether it was grasped correctly, not how to record it in Jira.

With automatically calculated flow metrics in place, the only discipline left is keeping the board's status accurate; forecasting and release planning follow from it. That is what effective automation produces: less time on the process, more on the product. Technology becomes something that helps, instead of being a control mechanism.

6. Hard Problems Get Solved

Exploring a new library, learning a new framework, evaluating several options and picking one — this used to sound like a lot of work, and it was. The kind an overloaded developer postpones, while the problem sits there occupying thought.

Good choices still matter. The unexpected part is motivation. Developers have a natural tendency to learn, and when learning gets faster and gives more frequent feedback — when the loop is shorter — the motivation to do it rises sharply. Work that would once have been avoided gets picked up out of curiosity, so the problem stops occupying anyone's thought. The mechanism is cognitive load, not courage. This is the easiest sign of all to miss, because it looks like nothing happening.

The leadership consequence: decisions get less risky — and with lower product risk goes the personal burden of being the one who had to make the right call.

7. A Change of Direction Is Not a Crisis Anymore

This is the sign that tests whether the others were real.

An engagement started as a simple scheduler, firing automations on time. Once the client began using it, we discovered together that the real need was larger: an internal automation product its own users could extend. This was a change in the client's requirements — not in the initial brief, but a genuine, well-founded need that surfaced while doing the work. These things happen.

In the past, this would have been a major problem. Now it took one week to reorganise: test the hypothesis, decide whether this was really what was needed, compare the options, choose a workflow engine.

Nobody perceived the change as a crisis.

The direction changed substantially, on evidence, toward a more coherent product. What made it cheap had been assembled weeks earlier by signs 1 to 6: the product was already visible weekly, the business was already in the room, the mechanical work was already covered.

They Arrive Together

These are not seven independent tells to check off. When the process fits what the technology can now do, most of them occur together, each reinforcing the others. See one, look for the rest. If none of them is happening, the rollout has not landed, whatever your usage numbers say.

What This Asks of You

First, look — some of this may already be happening in your room, unnamed.

Then say it out loud. What you do not notice, you cannot reinforce. Naming it — a hard problem came up, you took it on as a team, and it was resolved in days — tells people this is the direction the organisation wants. It costs one sentence.

Which of these have you seen in your own team — and did anyone name it?

Your AI Rollout Worked. The Money Is One Step Further Up

tomasz-feliksik — Fri, 21 Aug 2026 00:00:00 GMT

Three weeks into a client's AI rollout, we were watching the numbers move. The developers had the tools, the harness, and enough practice for it to show: code was arriving noticeably faster.

But the product was not speeding up with it. Delivery improved — some — but nowhere near as far as the code had.

The flow measurements we had put in on day one showed the details, weeks before it would have surfaced as a missed date. No incident, nobody escalating; the queue had simply relocated to testing.

This Has a Name

Dr. Eliyahu Goldratt worked this out forty years ago and named it the Theory of Constraints: a system has one binding limit at a time, and improving anything else changes nothing. There is a part of the theory the one software development sometimes skips — once something else has become the limit, go back to the beginning. Organisations can spend years working hard on problems that are no longer where the problem is.

The Obvious Fix

The obvious move is the one that surfaces in every organisation under pressure: add people where it is going badly. Put another tester on it.

But hiring is not a purchase, it is a subscription. You are not paying once to clear a queue that is long this month; you are committing to pay every month afterwards, against capacity you hope you will keep needing. In a company of fifteen or twenty people, a single hire also visibly changes the shape of the team. Sometimes it is exactly the right call, but it is also the longest commitment of any option on the table — a good reason to exhaust the faster, cheaper and more reversible ones first.

The Proper Fix

We didn't add testers. The queue was not a capacity problem — the work arriving had changed shape, and started to comes in larger batches than the old arrangement was built for. So we reorganised: automated part of the checking, and moved a share of the testing back into development, where the context already sat. That move was cheap precisely because the developers were already working through the harness, so writing those tests cost them a fraction of what it would have cost a year earlier.

That worked. Within weeks the queue reappeared one step upstream, at requirements. Development and testing were now consuming work faster than anyone was deciding what the work should be: items were reaching the team not yet defined and commonly understood well enough to start.

The Same Move, One Level Up

So we made the same move again — not the same fix, but the same aim: at the step where the queue now sat. We put an AI agent into the requirements conversations themselves. What it changed matters more than what we built (how it works is a different article):

The cognitive load in the room dropped. Attention went to what the client needed, not to who was writing it down and whether they had caught it.
The meetings got shorter, because servicing the meeting stopped being part of the meeting.
People came out of them more satisfied — every sentence now served a real problem rather than the record.
The time that used to go into formulating requirements went into weighing two or three ways to get there.

Point that same agent at the developers instead and almost nothing would have happened, because nobody was queuing in front of them. Speeding up a step that is already keeping up does not raise throughput anywhere. It can lower it, by pushing more work into the queue that is actually the limit.

That is the part that does not transfer between companies. Neither fix was the clever bit. The diagnosis was — working out which stage was asking for help, and only then choosing what to put there.

The Constraint Does Not Stop Moving

Each time we removed a limit, the system did not become limitless. It handed the limit to whatever was next in line — and each time, the next place was somewhere nobody had been looking, because everybody had been looking at the last one.

A system will always have a binding constraint somewhere, and that is not a failure state — slack everywhere else is what protects the constraint from starving. The costly idleness is at the constraint, where an hour lost is an hour the whole system never gets back.

So the skill is not eliminating constraints; it is knowing which one is currently yours — and in an AI rollout, that ability matters more than the tools being rolled out. The work is putting a good tool at the one place in the process that is actually asking for it, and where the queue currently sits is what tells you which place that is.

It Was Supposed to Be Five Times Faster

If you have run a rollout of your own, the shape may be familiar. The first weeks were dramatic. Then the curve flattened. You were expecting something like five times and you are looking at one and a half, and the obvious conclusion is that the tooling was oversold.

The sloppy version of that conclusion says you sped up the part that was never the problem. Nothing in the sequence above was a mistake. Code production was the problem — for thirty years the longest step, the one that consumed the budget and shaped every methodology. Making it fast was right. So was moving the testing, and so was putting an agent where the requirements were being decided. Each removed a real limit and each one paid.

Your rollout did not underdeliver; it delivered its whole increment, and then the limit moved while you were still measuring the old one. Money going into a step that is now keeping up buys nothing at all — while the real limit sits one move away, unmeasured and untouched. The team works hard, the numbers do not shift, and nobody can say why.

What nobody mentions is how much is left standing. An organisation that does the first step and stops there — buys the tools, speeds up development, calls it done — collects a fraction of what was available. Not nothing. A fraction. The rest was never inside development at all. It is in how requirements arrive, how decisions get made, how work moves between the people doing it. That is what those meetings were: the same class of tool, aimed one step up, made nobody type faster — it changed what the room spent its attention on. And none of it is visible from inside a codebase.

The next improvement is also cheap by comparison. Ours took a reorganisation, then an afternoon's decision.

Buying your team an AI subscription buys a small improvement. What you are actually buying is the entry point to a much larger one.

What This Asks of You

Not a tool. Not a hire. Not a framework with a capital letter.

Using AI well opens a path through your organisation that was not there before, and the path is where the return is. But look at what the steps along it are actually made of. The first one was an investment — licences, training, streamlining and measuring your development process. The ones after it usually are not. They are changes to how work moves: some testing shifted to where the context already sits, a meeting run differently, responsibility routed to someone closer to the problem.

Those are cheap. Most of them need a decision rather than a budget.

Which is also what makes them hard. When we moved part of the testing into development, nobody's budget changed — but somebody's remit did. Every change of that kind redraws a line that was drawn for a reason that sounded good at the time, and the person holding the line pays for the redrawing. That is the real price of the second improvement, and it is not payable in money.

So if you have been waiting to start, the first step is smaller than it looks. And if you have already started — if the team is faster and the delivery is not — you are standing at the point where stopping is the expensive choice.

Which change in your organisation is waiting on a decision rather than a budget?

Choosing AI Is a Small Decision. Adopting It Is the Real Work.

tomasz-feliksik — Fri, 14 Aug 2026 00:00:00 GMT

The announcement is easy to picture, because most of us have now seen a version of it. We are going to be an AI-first company. Licences arrive on Monday. A short message goes round about how everyone is expected to use the new tools.

By Friday, two or three people are visibly flying. Everyone else has opened it twice.

The part worth noticing is who those two or three are. In most of the teams I have watched, they were already doing it — at home, in the evenings, on their own subscriptions, months before anyone bought anything. The rollout did not create them. It found them, and then quietly took credit for them. Everyone else, which is most of the team, is still waiting for someone to make this make sense for them.

Meanwhile the usage line goes up, because those two or three use it constantly. And the question closes. Tools distributed, usage rising, problem solved.

The problem is not solved. Very little about it has been touched.

Why This Is Not a Small Problem

I wrote earlier about what happens to a codebase when you accelerate it without steering it — AI won't fix your architecture. The short version: a model that is fast and usually right is still making a great many choices that nobody decided. Each one is plausible. Each one is roughly in the right direction. Aggregate enough of them and the system arrives somewhere — just not anywhere in particular.

Left alone, a fast and mostly-right machine doesn't hold a direction. It only gets somewhere sooner.

That is the consequence of an unsteered rollout, and it is not cosmetic. It shows up as a codebase harder to change than it was a year ago, decisions nobody can reconstruct, and conventions that exist in four incompatible versions because four people each asked a model and each got a reasonable answer.

The Opportunity Is Real

None of that is an argument against the tools. The transformation underneath the noise is genuine: building software has become cheap enough to change what is worth building — not typing faster, but which ideas now clear the bar.

This is worth doing. Which is precisely why it is worth not squandering.

Why Usage Becomes the Answer

I do not think companies land on the usage metric out of laziness. They land on it because the better question is genuinely hard, and something has to go in the report.

The better question is what should I be looking at? — and while that goes unanswered, you look at what is already being counted. Seats. Active users. Tokens. The line goes up.

That number is measuring something real. It tells you the tool is being used, which is a floor worth clearing. It just isn't evidence about the thing you wanted to know. It's attendance.

And it gets worse if you lean on it. Goodhart's law — a measure that becomes a target stops being a good measure — is old and well attested. Ask for usage every month and usage is what will improve, including where reaching for the tool was the wrong call.

What a Real Rollout Starts From

The obvious alternative is to give good people good tools and get out of the way. I have made that argument myself — but look again at who took to it fastest. They taught themselves, before there was a policy, because they wanted to. The approach works beautifully on the people who needed no approach, and says little about everyone else.

What has worked for us starts from the other end: consistency first, adaptation second.

Before anyone is handed an agent, there is a set of practices fitted to this codebase and this organisation — not a generic best-practice document. Much of it is unglamorous and old: SOLID, continuous integration, a deployment pipeline that actually works. Those make good opening rules precisely because they are well understood and easy to state. Someone who understands them turns them into a harness: the conventions, the constraints, and the checks the model works inside.

The reason this comes first is specific and boring. If four developers each work inside their own private setup, the code that comes back disagrees with itself: exceptions raised here, error values returned there, two defensible conventions for the same decision. Every individual change passes review. The codebase quietly stops being one thing. A shared harness makes that a decision instead of an accident.

Then it adapts, because projects are not alike. One needs its debt paid down before anything else is worth attempting. Another has clean foundations and wants throughput on new features. Same starting point, different next move.

Two Ways to Get This Wrong

The interesting failures are not carelessness. They are managerial decisions, made sensibly, at a slight distance from the work.

The harness nobody is allowed to fix. I have seen a setup imposed from above and kept in a repository of its own. Contributing to it was permitted in principle — through architectural approval and a round of discussion. In practice the process to change a rule ran three times longer than the change itself, so people stopped proposing changes and started working around it. Within months there was no standard left, only a document describing one.

That is the trap on the other side of this argument. A harness so closed that the person inside it is confirming the machine's suggestions and nothing else — next, next, next — is not a good harness. It is a highly standardised one, and those are not the same thing. And it fails by the same mechanism as having no harness at all: when the rules stop matching the work, moving fast means letting the model decide, and you are back to a system that goes somewhere in particular only by accident.

The cheaper model. A team was told to stay on the older one, because the newer cost about a dollar more. The newer one also had a much larger context window — so on the old one, long pieces of work kept hitting the limit and having to be compacted and restarted, while on the new one the same task went through in one pass. Faster, and in the end cheaper. Nobody was being foolish; the price difference was real and sat in a column somebody owned. What was missing was a person close enough to the work to know that a dollar in that column can buy back several elsewhere.

Both mistakes are the same shape. Somebody made a reasonable call about a system they were not close enough to see.

The Third Thing You Build

For years we built two things at once: the code, and the tests that hold it honest. There are now three. The harness is built alongside the system, in the same commits, by the same people.

That sounds like more work, and at first it is. Designed well, it is considerably less — because the third thing is what makes the other two cheap. A team that isn't building it isn't adopting AI; it is running AI commands.

This is also the shift in what a developer's job is. Producing code is no longer where the value sits; the model does that well. What remains is looking after the system that produces it — because a well-maintained system produces code of the quality that person would have written by hand, and produces rather a lot of it.

For the company, that turns something soft into something structural. Practices used to be agreements: we said we would handle errors this way, and mostly we remembered. Encoded into the harness, they stop depending on everyone's discipline on a bad Thursday.

And it lifts a real weight off the people doing the work. When the conventions live in the system rather than in everyone's head, the cognitive load drops, and the attention that gets freed goes somewhere useful: how this should actually behave, which version is worth building, when, what the customer will do with it. The programmer finally has time to think about the customer.

How to Start Without Poisoning It

The instinct at this point is to get the harness right first and hand over something finished. I do not think that is the best move either, because there is no version of this you download and run. It always has to be adapted to the codebase you actually have.

So start with people rather than with completeness. Go in and find the ones who already want this — most organisations have two or three — and let them do the adapting, including the hard part: finding where standardisation should stop. They will accept a rough first version, because they already understand that the first version is always rough.

And leave everyone else alone for now. Not indefinitely, and not because they are the problem — but a half-built system handed to someone who did not ask for it produces exactly one outcome, which is a person who has now personally verified that this does not work. They will be right, at the moment they say it, and you will spend a year arguing with a true statement.

Not everyone comes to work to learn a new craft on top of the one they were hired for. That is a legitimate position, and it does not need converting. Bring those people in when the thing works well enough to be obviously worth their time, and let them judge it then.

The Real Work of a Leader

Here is the part that I think gets missed, and it is the more forgiving half of this argument: you do not have to understand how any of it works. You do not have to write the harness, or read it, or have an opinion about how errors are handled.

What you have to do is make sure it exists, that someone owns it, and that the team is expected to extend it rather than route around it. And then hold the boundary — standardise what is worth standardising, leave open what people need in order to keep developing it, and move that line as the project changes. That judgement is not delegable, because it is not a technical question. It is a question about your organisation.

That is what this asks for. Not a transformation programme, and not a bigger budget. Attentiveness, a working understanding of what the technology actually does, and the willingness to build the conditions rather than buy the tools and hope.

Where to point that attention first is the subject of the next piece: the constraint has moved, and it is not sitting where most of us are still looking.

What would you have to stop doing to give this the attention it needs?

Will AI Fix Your Architecture? Or Just Accelerate Its Decay?

tomasz-feliksik — Thu, 23 Jul 2026 00:00:00 GMT

Let me tell you a story about probability.

You have a fair coin and plan to toss it 100 times. Expecting around 50 heads is reasonable — mathematically proven, even.

Now you toss it 40 times and get 15 heads, 25 tails — a deficit of 10 heads, from nothing but randomness.

Here's what people quietly assume: the coin will compensate. The next tosses will lean toward heads to restore the balance.

That instinct — that the coin is "due" — is the gambler's fallacy, and gamblers have lost money to it for a century.

The next toss is still 50/50. So is the one after. The coin has no memory of your deficit. The average never pulls you back to the line — it is not a correcting force, it's an accounting convention.

You cannot rely on probability to guide you back to stability inside a process that has already deteriorated.

Now Replace "Coin" With "Codebase"

That, roughly, is what happens when you vibe-code with AI and skip the good old, not-so-shiny engineering underneath.

The tools are genuinely remarkable. Ask for a working demo and you'll get one. That part is real.

Then you complicate it.

You add a feature. You modify a behaviour. You try to sustain the thing over months rather than an afternoon. And you discover that maintainability has almost nothing to do with how fast the code was produced. It depends on whether the architecture was coherent, the decisions consistent with one another, and the business domain actually modelled rather than approximated.

Every small choice can deviate a little from the reality the code is meant to describe — each one insignificant and fully defensible in isolation. And like the coin's, these deviations do not cancel. They accumulate.

The Price of Every Subsequent Change

Once the incoherence exists, you pay interest on it with every change. Call it technical debt — but with AI it shows up in the process and the product far more visibly than when code was written by hand.

It is created by perfectly normal work:

Someone shipped a fix that quietly ignored the assumptions the rest of the system relies on.
Someone approximated the domain instead of modelling it.
Someone missed the idea behind an interface and broke its encapsulation.

And so each of these changes might be a matchstick. Each one works. Each one ships.

Eventually many systems end up held together by matchsticks.

Anyone who has worked in software long enough has been inside one. What's easy to forget is why it didn't collapse sooner.

The Limit That Just Disappeared

For decades, what saved these systems was friction.

Matchsticks went in slowly. A human had to understand enough of the surrounding code to place one, and that understanding cost time — not a good brake, an accidental one, but a brake nonetheless. Incoherence accumulated at human speed.

That limit is now gone.

AI taken off the shelf does not remove the existing matchsticks. It removes the cost of inserting them.

Which leads to the sentence I'd like you to sit with:

If your system is built on matchsticks, adding AI to it will not make it coherent next year. It will make it a larger pile of matchsticks, much faster.

What the Tools Actually Give You

The argument is not that these tools are weak. It's the opposite.

Ask a good model for a first version and you can trust what comes back, the way you trust a fair coin to land near 50/50. The baseline is predictable, and today it is high.

But a model is a coin in a second sense: it averages toward the patterns you put in front of it, with a little randomness each time. Point it at your codebase and it reproduces what's already there — faithfully, tirelessly, fast. Left alone, it makes the existing code more like itself. And its nudges don't average out: an unmanaged model walks a system downhill one defensible step at a time, faster than any human hand.

So coherence isn't what the model lacks. It will hold a system perfectly consistent — including consistently bad. A pile of matchsticks is a pattern too, and the model extends it without hesitation.

What it can't supply is the direction of that coherence — which shape to converge on. That doesn't live in the code; it lives in your head, until you build the thing that carries it to the AI model.

That thing is the harness around the tool, and it is two jobs:

Systematise the process — so the model follows a deliberately defined harness path, instead of improvising one.
Point the direction — so even a weak codebase gets pulled, change by change, toward the shape you want, instead of just more faithfully weak.

Do both and even a shaky system improves under the tool. Do neither and the pile grows faster. That isn't a setting you switch on. It's engineering work that has to be deliberately done.

Here is what that looks like when we run it. Every change an agent produces goes out as an ordinary pull request, and team members review it like anyone else's work. But the comments do double duty. When a reviewer writes "we don't reach across this module boundary," that sentence doesn't just fix one change — it becomes a rule in the harness, checked against every change that follows. A retrospective after every change, not every two weeks.

Those rules always existed. They lived in people's heads and travelled by review comment, one head to another, written down nowhere. Now they accumulate — and when a new rule contradicts one already recorded, that collision is an architectural decision surfacing: to be made once, in the open, instead of twice, differently, in two corners of the codebase.

Look again at the chart at the top. The drift happens because every deviation silently becomes the new baseline, and nothing pulls the process back toward the line. This loop is the correcting force the coin never had. Each deviation gets pointed back at the same target, and each correction improves not only the code but the process that produces the next change — compound interest, finally working in your favour.

It also widens what "your system" means: not just the code and how its components talk to each other, but the process that governs them.

What This Actually Asks of Us

Not "don't use AI." That would be silly, and wrong.

It asks for something less comfortable than a tool purchase.

Restoring architectural coherence is a conscious decision — about what the system is supposed to model, which assumptions are load-bearing, which matchsticks come out before anything new goes in, and who is accountable for the shape of the whole rather than the correctness of the parts.

The tools will not make that decision for you. They will execute whichever decision you have already made — faithfully, tirelessly, fast — including the one you made by not deciding.

If you want to know which decision you've made so far, three checks will answer it on Monday morning:

Where does the architecture live? If it's in a wiki that was written once, updated never, and sits where your tools can't reach it, then as far as the AI is concerned it doesn't exist. Documentation that lives with the code — and changes in the same pull request — is the version the model actually reads.
How does a new engineer land? If someone can build, run, and usefully change the system from what is written down, an agent can too. If they first have to ask fifteen people how it works, the model will fill that gap with inference from what was in context at the moment.
Ask the model what your assumptions are. Have it read the codebase and list the assumptions it considers load-bearing. Then take that list to your team and count the ones nobody knew were in there. Every one of those is a rule the AI is already following. Nobody chose it.

What the harness consists of in practice — the conventions, the constraints, the checks — is the next piece. None of it ships with the subscription. All of it starts as a decision.

The coin does not correct itself.

Neither will the codebase.

What's the most expensive matchstick you've ever had to remove?

The Grammar of Responsibility

tomasz-feliksik — Wed, 15 Jul 2026 00:00:00 GMT

"Claude Did It" Isn't a Description. It's a Handoff

At the end of a call, minutes before the next meeting, a colleague gave a name to something that had been on my mind for a while: the personification of Claude.

"When we say Claude did this instead of I did this with Claude, we're personifying it — this sounds like handing it the responsibility for the code we produce."

We spent the last minutes of that call searching for patterns we could learn from this insight. Here is what I've learned from this conversation.

The Handoff Has No Receiver

Grammar is quietly generous. Make something the subject of a sentence and you grant it agency — and agency drags accountability behind it. "Claude did this" has exactly the shape of "John did this": an actor, an act, and someone to answer questions about it later.

Except a terminal tool doesn't attend the incident review.

Put to good use, it can help with design decisions that have been taken, but it doesn't have a preference for this abstraction over that one, and the exact context that was used today won't be here next quarter explaining the migration path. It can help, but cannot be accountable — not because the models aren't good enough yet, but because accountability isn't a capability. It's a relationship between people.

So the handoff in "Claude did it" never completes. Responsibility leaves the speaker and arrives nowhere.

The sentence doesn't transfer responsibility to the tool. It evaporates it.

The Sentence Predicts the Review

Let me be fair to the phrasing first, because nobody says "Claude did it" in order to dodge anything. It's shorthand, and in the narrow mechanical sense it's even accurate — the model did produce those lines. That's precisely why it spreads: it is true about the typing and false about the owning.

And substitute Copilot, Cursor, or whatever name your team's tool answers to — the grammar works the same.

But the framing has a cost, and the cost lands in a specific place: code review.

Say "Claude did it" often enough and you start standing next to your own diff instead of behind it. You feel a little less obliged to understand what was produced — and that is the classic "looks good to me" review: approved by someone who was never quite its author, merely nearby when it happened.

"I did this using Claude" reverses the stance before the review even starts. The diff is mine. The model was leverage, the way the compiler and the framework are leverage. If it's wrong, the failure sentence starts with "I".

None of this says people stop being responsible for their work the moment they phrase it badly. It's a risk, not a verdict. But it's the kind of risk that compounds quietly, one unexamined pull request at a time.

Leaders Set This Standard Further Than They Intend

Here's where this stops being a style preference.

Habits of speech don't spread evenly through a team — they spread from the people others calibrate against. When a team lead says "Claude built this service," in praise or in complaint, the team hears something more durable than the sentence: this is how we talk about ownership here. The standard travels further than the intention. Nobody decides to set it. It gets set anyway.

Which means the cheapest AI-governance instrument available to anyone running a team is the grammar of their own standup sentences.

We don't hand AI responsibility for the code we produce.

My colleague said that in passing, as something obvious. I've read policy documents ten pages long that speaks about the same and still commit to less.

What I Take From This Conversation

Not a rule about language — correcting other people's sentences only turns a useful observation into an office joke.

What I took was an agreement with myself: this is how I talk about my work now. The price is the free excuse — "Claude did something weird" — and what it buys back is every line I merge being mine again.

The surprise, after sitting with it for a while: the effect is upstream of the sentences. Knowing the work gets reported as "I did this using Claude," I make the many tiny decisions — merge this diff or read — in a way I won't hesitate to take full responsibility for. A different agency model, not a different phrasing. The price is paid in installments too small to notice.

And that's the part that counts: the standard my team absorbs won't come from anything I announce about AI. It will come from the subject of my sentences — and the actions that follow.

Listen for it in your next standup: which sentence does your team reach for when the demo works — and which one do you reach for when production breaks?