New AGQ article on AI, patching, and design drift

1

I just published a new guide and a related field note on Ask Good Questions that connect pretty directly to something many of us are running into with AI-assisted development.

Guide:
https://askgoodquestions.dev/guides/dont-let-ai-help-you-lose-the-big-picture/

Field note:
https://askgoodquestions.dev/field-notes/audit-not-another-patch/

The theme is losing the big picture while making a series of perfectly reasonable local fixes.

That can happen especially easily when you’re working with older code, preserving native behavior, or layering modern behavior on top of existing controls and event flows. AI can help move things forward quickly, but it can also make it easier to keep patching without stopping to ask whether the current problem is really the original problem anymore.

The guide covers that broader pattern.

The field note is a concrete example of reaching the point where the next step was not another fix, but an audit of the sequence, responsibilities, and collisions.

I thought some of the folks here might relate to it. I just published a new guide and a related field note on Ask Good Questions that connect pretty directly to something many of us are running into with AI-assisted development.

Guide:

https://askgoodquestions.dev/guides/dont-let-ai-help-you-lose-the-big-picture/

Field note:

https://askgoodquestions.dev/field-notes/audit-not-another-patch/

The theme is losing the big picture while making a series of perfectly reasonable local fixes.

That can happen especially easily when you’re working with older code, preserving native behavior, or layering modern behavior on top of existing controls and event flows. AI can help move things forward quickly, but it can also make it easier to keep patching without stopping to ask whether the current problem is really the original problem anymore.

The guide covers that broader pattern.

The field note is a concrete example of reaching the point where the next step was not another fix, but an audit of the sequence, responsibilities, and collisions.

I thought some of the folks here might relate to it.

2

How do you tackle the code review signing off problem?

It affects all even some big names like Amazon.
https://www.ft.com/content/7cab4ec7-4712-4137-b602-119a44f771de
https://archive.ph/wXvF3

3

I think the Amazon example points to one of the classic traps of agentic programming.

An agent is usually working against the tests, constraints, and rules that apply to the particular piece of the problem in front of it at that moment. That can make it very effective locally while still allowing it to drift globally.

So if there is not a higher-order guardrail that keeps forcing the question, “does this still fit the overall design, pattern, and goal of the project?”, you can end up approving changes that satisfy the local rules while quietly moving the whole system off target.

And I do not think that is solved just by putting a human over the top of it.

That person is still going to be inundated with a steady stream of “tested,” “passed,” “working,” and “completed” reports. After enough of those, review can become mechanical. Their eyes glaze over, and the question that really matters, “does this still fit the grand design?”, starts getting asked less and less.

The bigger and more complex the project, the worse that gets.

So to me, that is how you tackle the sign-off problem: you cannot treat sign-off as just “the patch passed” or “the agent says it worked.” You have to make architectural fit a separate, explicit check, and it has to outrank the local task rules.

In other words, it is not enough to state the project goal once at the beginning and hope everything stays aligned. Those higher-level rules have to be deliberately brought back into the process over and over again, for the agents and for the humans reviewing them.

Otherwise you get exactly the kind of drift we are talking about: a series of changes that all look defensible in isolation, but collectively take the software somewhere nobody actually meant to go.

4

I dont know the exact problems Amazon were having, but if I were a manager and had to sign off on code produced by an Ai or person, I would need to know about as much of the “system” as possible before I could sign off on it.

Afterall I could be signing off on code that is very efficienct but cpu intensive which results in killing off or slows up other processes. I think its safe to say we’ve all had it where a loop on a thread makes the app unresponsive.

It makes me wonder if Amazon have manager’s who dont have the experience. An argument for recruiting from within and also an argument for promoting coders, instead of sideways shuffling manager’s about.

For example, if I was Bezo’s or whoever is CEO now, would I’d favour technical system & code knowledge in management over management skills.who can politically, tactfully and coercively manipulate a team? Probably.

I do laugh at the corporate buzz words, it reminds me of the The Asch Line Experiment and highlights people who dont know what they are talking about!

There is also this.

https://archive.is/VCLqb

Musk cutting more jobs due to poor performance.

Question is, did he anticipate this and is now using this poor performance hurdle to consolidate. It looks like that to me.

5

Yes, I think that is exactly part of the problem.

The real issue is that sign-off requires system knowledge, not just managerial authority. Whether code is written by AI or by a developer, the person approving it needs enough technical understanding of the wider application to judge performance, side effects, sequence, and interaction with the rest of the system.

Otherwise you end up approving something that is locally correct but globally harmful.

That is why I think this gets more dangerous as projects get larger. The more moving parts there are, the easier it is for review to become superficial unless the reviewer really understands the system they are signing off on.

So yes, I would put a lot more weight on technical depth in that role than on generic management language or process skills. If the reviewer cannot see beyond the patch in front of them, then AI just magnifies the risk.