DEV Community: Robert Adamson

Most AI Agents Stop at the Answer. Xenition.com Is Built to Finish the Workflow

Robert Adamson — Wed, 07 Oct 2026 07:06:31 +0000

Most AI tools are very good at one thing:

Giving you an answer.

You ask:

“Which customers haven’t paid yet?”

The AI gives you a list.

You ask:

“What should I tell them?”

The AI drafts the message.

You ask:

“Who should I follow up with first?”

The AI prioritizes them.

Useful?

Absolutely.

But then you still have to:

open the CRM
find the customer
open Gmail
send the message
update the record
create a follow-up task
notify your team
remember to check again tomorrow

At that point, the AI helped you think.

But you still finished the workflow yourself.

That is the problem I wanted to solve with Xenition.com.

The Answer Is Only the Beginning

For a long time, the basic AI workflow looked like this:

You ask
   ↓
AI answers
   ↓
You copy
   ↓
Open another app
   ↓
Paste
   ↓
Take action manually

That is still useful.

But it creates a strange situation.

The AI might know exactly what needs to happen next.

It might know:

which customer needs a reply
which GitHub issue should be updated
what should be added to Jira
what message should be sent to Slack
what document should be created
what follow-up should happen tomorrow

But it stops at:

“Here’s what you should do.”

The remaining work is still yours.

AI Agents Should Move From Answers to Actions

A more useful agent should be able to move through the workflow.

For example:

User:
"Find overdue invoices and follow up with the account owners."

A chatbot might respond:

I found 8 overdue invoices.

Here are the owners and suggested messages.

An agent workflow could look like:

Find overdue invoices
        ↓
Identify account owners
        ↓
Prepare follow-up messages
        ↓
Request approval where needed
        ↓
Send messages
        ↓
Update records
        ↓
Log what happened

That is a very different experience.

The AI is no longer just helping you decide.

It is helping you complete the task.

This Is Why Connected Tools Matter

An agent without tools can reason.

But it cannot do much with the result.

Give it access to real connected services, and suddenly the possibilities change.

An agent may be able to work with things like:

email
calendars
GitHub
Slack
Notion
Jira
CRMs
cloud storage
spreadsheets
databases
internal APIs

Now the workflow becomes:

Understand the goal
      ↓
Choose the right tool
      ↓
Read the required data
      ↓
Take action
      ↓
Return the result

That is much closer to how useful automation should feel.

This Is the Idea Behind Xenition.com

With Xenition.com, the goal is not to make chat the final destination.

Chat is the starting point.

You should be able to say what you want done, then let the system work across the tools required to complete it.

The same capability can be useful in different ways.

Directly in chat

You ask for something once.

"Check my open issues and summarize what needs attention."

Through an agent

The agent handles a broader goal.

"Review the project and prepare today's engineering update."

Through automation

The same workflow can run repeatedly.

Every morning
      ↓
Check project activity
      ↓
Find blockers
      ↓
Prepare update
      ↓
Send or request approval

That is where agents start becoming much more useful.

Agents and Automation Are Not the Same Thing

I think this distinction matters.

An agent helps decide:

What should happen next?

An automation defines:

When should this workflow happen again?

For example:

Agent

"Look at the latest support tickets and decide which ones need engineering."

The agent needs reasoning.

It has to inspect the tickets and decide.

Automation

Run this every weekday at 9 AM.

That is recurrence.

Put them together:

Trigger
   ↓
Agent reasons
   ↓
Uses connected tools
   ↓
Takes approved actions
   ↓
Records the result
   ↓
Runs again later

That combination is much more powerful than chat alone.

But More Power Creates a New Problem

The moment agents can actually do things, safety becomes much more important.

If an AI can only write text, the main risk is:

It gives you a bad answer.

If an AI can use real tools, the risk becomes:

It performs the wrong action.

That is a major difference.

For example:

"Clean up old customer records."

The agent could interpret that as:

archive them
merge them
rename them
delete them

Those are not equivalent.

So agents should not have unlimited authority just because they have access to tools.

The Agent Should Propose. The System Should Decide.

This is one of the principles we have been thinking about while building Xenition.

The model can decide:

What action makes sense?

But the model should not always be the final authority on:

Is this action allowed?

A better flow looks like:

Agent proposes action
        ↓
System evaluates it
        ↓
Policy checks permissions
        ↓
Approval if required
        ↓
Action executes
        ↓
Result is recorded

That separation matters.

Because:

Intelligence and authority are not the same thing.

Not Every Action Needs Approval

If every single tool call requires confirmation, automation becomes annoying very quickly.

Imagine approving:

Read file?
Approve.

Read second file?
Approve.

Check calendar?
Approve.

Fetch issue?
Approve.

Nobody wants that.

Approval should happen when the impact changes.

For example:

Read data
→ allowed

Create draft
→ allowed

Send externally
→ approval

Delete data
→ approval

Change permissions
→ approval

Deploy
→ approval

That creates a much better balance between usefulness and control.

The User Should Know What the Agent Is About to Do

An approval screen should not say:

Approve action?

That is too vague.

It should say something closer to:

Send this message to the engineering team?

or:

Delete these 12 records?

or:

Publish this document externally?

The user should understand:

what will happen
where it will happen
what will change
whether it can be reversed

Otherwise approval becomes another blind click.

Automations Need Predictability

There is another challenge.

If an automation runs every day, you do not want the system to reinterpret the business rule differently each time.

For example:

"Every morning, find high-priority customer issues and notify engineering."

The workflow should not mean one thing today and something very different next week because the model interpreted the instruction differently.

That is why repeatable automation needs more structure than a normal chat prompt.

You want:

clear triggers
defined tools
controlled permissions
known outputs
retries
failure handling
logs
consistent behavior

AI can still reason inside the workflow.

But the workflow itself should not be completely unpredictable.

Automation Also Needs State

Imagine an agent runs every morning.

Yesterday it already contacted Customer A.

Today Customer A is still overdue.

Should it send the same message again?

Maybe.

Maybe not.

That requires state.

The system needs to know things like:

Already processed?
Last action?
Last result?
Waiting for reply?
Failed previously?
Needs retry?

Without state, “automation” quickly becomes repeated execution instead of an actual workflow.

Logging Is Not Optional

Once agents take real actions, you also need to know what happened.

Not just:

“Workflow completed successfully.”

You need something closer to:

09:01 — Read 14 customer records
09:02 — Found 3 overdue invoices
09:02 — Prepared 3 messages
09:03 — 2 approved
09:04 — Messages sent
09:04 — CRM updated

That makes the system easier to trust.

It also makes failures easier to understand.

A Useful Agent Workflow Has Several Layers

The more I work on this problem, the more I think useful agent systems need more than just a smart model.

They need something like:

Intent
  ↓
Reasoning
  ↓
Tools
  ↓
Permissions
  ↓
Approval
  ↓
Execution
  ↓
State
  ↓
Audit trail
  ↓
Automation

The model is important.

But it is only one part of the system.

Why I’m Building Xenition This Way

This is one of the ideas behind Xenition.com.

I do not want AI to only answer:

“Here is what you should do.”

I want it to help close the distance between:

“I want this done.”

and:

“It’s done.”

That means giving agents access to useful tools.

But it also means adding:

permission boundaries
approval gates
automation
workflow state
action history
predictable execution

Because giving an agent more intelligence is not enough.

It also needs an environment where it can safely use that intelligence.

The Real Value Starts After the Chat Ends

AI chat is already useful.

But the most interesting part starts when the answer can become a real workflow.

Instead of:

Ask
↓
Answer
↓
Manual work

we can move toward:

Intent
↓
Agent
↓
Tools
↓
Approval when needed
↓
Action
↓
Result

And when that workflow becomes repeatable:

Trigger
↓
Agent
↓
Action
↓
Result
↓
Repeat

That is where AI starts feeling less like a chatbot and more like actual infrastructure.

Final Thought

Most AI systems are getting better at answering questions.

I think the bigger opportunity is what happens after the answer.

Can the system:

understand the goal?
use the right tools?
complete the workflow?
know when it needs permission?
remember what already happened?
run again automatically?
show exactly what it changed?

That is the direction I am exploring with Xenition.com.

Because the best AI agent should not leave you with:

“Here’s what you should do next.”

It should help you get to:

“Done.”

Your GitHub Actions Workflow Has More Power Than Most Developers Realize

Robert Adamson — Tue, 06 Oct 2026 04:03:37 +0000

Most developers think of GitHub Actions as automation.

Build the app.

Run tests.

Deploy.

Publish a package.

Maybe send a notification.

But a workflow is not just a script runner.

Depending on how you configure it, a GitHub Actions job may be able to:

read your repository
modify code
create releases
publish packages
access secrets
talk to cloud providers
deploy production
comment on pull requests
change repository state

That means your CI pipeline is not just automation.

It is part of your security boundary.

And many workflows have more authority than the developers maintaining them realize.

Start With `GITHUB_TOKEN`

Every GitHub Actions job receives a GITHUB_TOKEN.

GitHub creates it automatically for the job, and its permissions determine what the workflow can do inside the repository.

That makes this small section of YAML extremely important:

permissions:
  contents: read

Without thinking about permissions explicitly, developers can easily give a workflow more authority than it actually needs.

The safer idea is simple:

Give each workflow the minimum permissions required to complete its job.

If a job only needs to check out code and run tests, it probably does not need write access.

A Test Job Should Not Be Able to Publish Anything

Consider a basic CI workflow:

name: CI

on:
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v6

      - run: npm ci
      - run: npm test

Ask yourself:

What does this job actually need?

Probably:

permissions:
  contents: read

That is it.

It does not need permission to:

create releases
modify issues
publish packages
write repository contents

A useful mental model is:

Permissions belong to the job, not to your general trust in GitHub Actions.

The Most Dangerous Workflow Trigger May Surprise You

One trigger developers should understand very carefully is:

pull_request_target

It looks similar to:

pull_request

But the security model is very different.

A normal pull_request from a fork gets strong restrictions: GitHub withholds repository secrets and gives the workflow a read-only token.

pull_request_target, on the other hand, runs with the trust of the base repository and can receive repository secrets and a read/write GITHUB_TOKEN.

That is useful for things like:

labeling pull requests
triage
authenticated checks

But it becomes dangerous if you combine it with untrusted code.

The “Pwn Request” Pattern

This is the dangerous shape:

on:
  pull_request_target:

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v6
        with:
          ref: ${{ github.event.pull_request.head.sha }}

      - run: npm install
      - run: npm test

At first glance, this looks reasonable.

You want to test the contributor's code.

But now you have:

Untrusted pull request code running inside a privileged workflow.

That code could modify:

package.json
install scripts
test scripts
build scripts
Makefiles
configuration files

And GitHub explicitly warns against executing fork code in a privileged pull_request_target workflow.

The problem is not checkout itself.

The problem starts when you execute what you checked out.

`npm install` Is Code Execution

This is another thing developers sometimes forget.

When you run:

npm install

you are not necessarily just downloading files.

A dependency may have install scripts.

Your own repository may have lifecycle scripts.

Build tools may execute configuration.

So if untrusted code can modify dependency or build configuration, running:

npm install

inside a privileged job may effectively mean:

Execute code controlled by the pull request.

The same idea applies beyond npm:

make

pip install

./gradlew build

cargo build

docker build

CI commands are execution boundaries.

Treat them that way.

Secrets Change the Risk Completely

Imagine your workflow contains:

env:
  API_KEY: ${{ secrets.API_KEY }}

Now anything executing in that job may potentially interact with that secret.

GitHub recommends using least-privilege credentials because jobs and actions can access secrets available to the workflow.

A useful question is:

If this step were compromised, what could it steal or modify?

That question should influence how you structure jobs.

Separate Untrusted Code From Privileged Operations

Suppose your pipeline needs to:

test a pull request
publish something afterward

Do not automatically put everything in one giant privileged job.

Think in trust boundaries.

For example:

Pull request code
      ↓
Build + test
No secrets
Read-only token
      ↓
Artifact
      ↓
Trusted workflow
      ↓
Publish / deploy

The first job handles untrusted code.

The later job handles privileged operations.

That separation makes the system much easier to reason about.

Third-Party Actions Are Dependencies Too

Developers carefully review npm packages.

Then write:

uses: some-user/some-action@v2

without thinking twice.

But third-party actions execute inside your workflow.

A compromised action could potentially access repository secrets or use the workflow's GITHUB_TOKEN. GitHub recommends pinning actions to a full commit SHA when you need an immutable reference.

Instead of relying only on:

uses: vendor/action@v2

a more controlled setup can pin the exact commit:

uses: vendor/action@3c2f...full-commit-sha

Tags are convenient.

But tags can move.

A full commit SHA is immutable.

Your Workflow Has a Dependency Tree

Most developers think their dependency tree is:

application
├── react
├── express
└── postgres client

But there is another one:

CI pipeline
├── actions/checkout
├── setup-node
├── deployment action
├── security scanner
└── custom third-party actions

Those dependencies deserve review too.

Because they may run with more privilege than your application code.

Long-Lived Cloud Credentials Are Often Unnecessary

A common deployment setup looks like this:

env:
  AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
  AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

Now you have long-lived credentials stored in GitHub.

A better model, where supported, is short-lived authentication.

GitHub Actions supports OpenID Connect so workflows can request short-lived identity tokens and exchange them with cloud providers instead of storing permanent cloud credentials.

Conceptually:

GitHub workflow
      ↓
OIDC identity
      ↓
Cloud provider verifies workflow
      ↓
Temporary credentials
      ↓
Deploy

Now there may be no permanent cloud secret sitting in the repository configuration.

That is a major improvement.

Self-Hosted Runners Change the Threat Model

GitHub-hosted runners are usually temporary.

Self-hosted runners may not be.

If your runner also has access to:

internal networks
Docker sockets
production databases
cloud metadata
SSH keys
mounted files

then executing untrusted code there can become much more dangerous.

GitHub specifically warns that compromised runners can expose secrets and other resources available to the runner environment.

Ask:

What can this machine reach that GitHub itself cannot?

That includes network access, not just stored credentials.

A Green Build Does Not Mean a Safe Workflow

Developers often see:

✓ Build passed
✓ Tests passed
✓ Deployment passed

and assume everything is fine.

But workflow security is not about whether the commands succeeded.

It is about:

What authority did those commands have while they were running?

A perfectly successful workflow can still be badly designed.

Audit These 8 Things in Your GitHub Actions Today

1. Token Permissions

Search your workflows for:

permissions:

If it is missing, ask whether you should define it explicitly.

Prefer the minimum required permission.

2. `pull_request_target`

Search:

pull_request_target

If you find it, understand exactly why it exists.

Be especially careful if that workflow checks out and executes pull request code. GitHub is actively tightening policy around this event in public repositories because of its security implications.

3. Secrets

Search for:

secrets.

For every secret, ask:

Does this job really need it?

Do not make secrets available simply because a later step might use them.

4. Third-Party Actions

Review every:

uses:

Ask:

who maintains this?
do we still need it?
is it pinned?
what permissions does the job have?

5. Publishing

Search for:

npm publish
docker push
gh release
terraform apply
kubectl
aws
gcloud
az

Anything that changes an external system deserves extra scrutiny.

6. Untrusted Input

Be careful when inserting values from issues, pull requests, branch names, commit messages, or other external sources into shell commands.

The workflow file is code.

Untrusted strings should be treated like untrusted input anywhere else.

7. Self-Hosted Runners

Ask what the runner can access.

A runner with internal network access has a very different blast radius from an isolated temporary runner.

8. Build and Deploy Separation

If possible, separate:

build

from:

deploy

Your build job should not automatically inherit production authority just because deployment happens later.

A Safer Mental Model

Do not think:

GitHub Actions runs my CI.

Think:

GitHub Actions runs code with an identity, permissions, credentials, network access, and external capabilities.

That changes how you review a workflow.

A workflow becomes much closer to a small production service than a simple YAML file.

Final Thought

Most developers would never give every application endpoint administrator access.

But we sometimes give CI pipelines broad permissions because:

“It is just our build workflow.”

It is not.

Your workflow may have the ability to modify repositories, access secrets, publish packages, deploy infrastructure, and authenticate to production systems.

So the next time you open:

.github/workflows/

do not only ask:

Does this pipeline work?

Ask:

What could this pipeline do if one step became untrusted?

That question may be far more important.

We Gave AI Agents Real Tools — Then Realized “Just Ask Before Acting” Wasn’t Enough

Robert Adamson — Mon, 05 Oct 2026 04:50:38 +0000

Giving an AI agent tools feels like the moment it becomes truly useful.

Now it can:

read files
send messages
call APIs
update records
trigger workflows
create documents
modify connected apps

That is when it stops being just a chatbot.

It starts becoming software that can change things.

And that is also when the risk changes.

At first, one rule sounds reasonable:

“Ask the user before doing anything important.”

Simple.

Human-friendly.

Easy to add to the prompt.

But once an agent has real tools, that is not enough.

Because now the model is being asked to decide two things:

What action should happen?
Whether that action is important enough to require approval.

That is too much authority to put inside the same reasoning loop.

The Problem Starts With a Simple Workflow

Imagine an agent connected to a few business tools.

A user says:

“Clean up these customer records and notify the team.”

The agent might decide to:

read CRM records
modify customer fields
merge duplicates
delete old entries
send a team message
update a spreadsheet

Some of those actions are harmless.

Some are reversible.

Some are not.

Now imagine the only safety rule is:

Ask before anything important.

What exactly counts as important?

The model has to decide.

That is where things become uncomfortable.

“Important” Is Too Ambiguous

To a user:

Deleting 500 records is obviously important.

To the agent:

Removing duplicates may look like a normal cleanup step.

To a developer:

Sending data to an external system may be the risky part.

To security:

Accessing the data at all may require approval.

The word “important” does not define a reliable boundary.

It creates interpretation.

And interpretation is exactly what we should avoid for high-impact actions.

The Model Should Not Decide Its Own Authority

This became the key lesson.

The agent can decide:

What should I do next?

But it should not be the final authority on:

Am I allowed to do it?

Those are separate responsibilities.

A safer architecture looks more like this:

User request
    ↓
Agent proposes action
    ↓
System classifies action
    ↓
Policy checks permission
    ↓
Human approval if required
    ↓
Action executes
    ↓
Action is logged

The important part is:

The approval decision happens outside the model.

Read, Write, and Destructive Are Not the Same

One simple thing that helps is classifying actions by impact.

For example:

Read

fetch records
inspect documents
search files
read calendar data

Write

update a field
create a document
send a message
add an event

Destructive / High Impact

delete data
revoke access
publish externally
deploy
move money
change permissions

Now the system can enforce something concrete.

For example:

READ → allowed

WRITE → allowed or approval depending on context

DESTRUCTIVE → approval required

That is much stronger than:

“Please ask before doing anything risky.”

Prompts Are Guidance. Policies Are Boundaries.

This distinction matters.

A prompt can say:

“Never delete data without asking.”

That is useful.

But prompts can be:

misunderstood
forgotten
overridden by context
interpreted differently

A policy layer should be deterministic.

For example:

delete_record()
→ blocked
→ approval required

The agent does not get to decide whether deletion is “important enough.”

The system already knows.

Why This Matters More as Agents Get Better

A weak agent often fails because it cannot complete the task.

A strong agent creates a different problem:

It can complete the task in ways you did not anticipate.

That is the real shift.

The better the agent becomes at planning and using tools, the more important hard boundaries become.

Because capability is increasing.

Authority should not increase automatically with it.

Helpful Agents Can Still Cross a Line

This is important.

The dangerous behavior does not need to be malicious.

Imagine:

“Organize this workspace.”

The agent decides to:

archive old files
move folders
rename documents
remove duplicates

Every step may look helpful.

But maybe one folder was legally required to remain unchanged.

Maybe one document belonged to another team.

Maybe the “duplicate” was actually a historical copy.

The agent was trying to help.

That does not make the action safe.

Human Approval Should Happen at the Right Moment

Approval should not mean:

Confirm every tool call.

That would be terrible UX.

The goal is to insert approval when the action crosses a meaningful boundary.

For example:

Reading data
→ no approval

Creating a draft
→ no approval

Sending externally
→ approval

Deleting
→ approval

Changing permissions
→ approval

Deploying
→ approval

This keeps the agent useful without making it unrestricted.

Approval Should Explain the Action

Another important lesson:

Do not show the user:

Approve action?

That is too vague.

Show:

Send this message to the engineering channel?

or:

Delete 42 archived records?

or:

Publish this document externally?

The user should know exactly what they are approving.

That means the approval layer needs:

action name
target
scope
consequence

Not just a yes/no button.

The Agent Should Propose, Not Hide

A good pattern is:

Agent proposes → system explains → human approves → tool runs

Not:

Agent runs → explains afterward

That difference matters a lot.

Once the action already happened, approval is no longer approval.

It is just notification.

This Became a Real Problem While Building Xenition

We ran into this problem directly while building Xenition at xenition.com.

Xenition is designed around AI agents that can work across real tools and connected services, not just generate text inside a chat box.

That means an agent may need to:

read data
create content
update records
trigger workflows
interact with connected applications
produce real outputs

Once agents can actually act, the permission model becomes just as important as the model itself.

The early idea sounds simple:

Let the agent decide when it should ask for approval.

But that still puts too much responsibility inside the model.

So the safer direction is:

Agent proposes the action
        ↓
The system evaluates the action
        ↓
High-impact actions require approval
        ↓
The action executes
        ↓
The result is recorded

That is the kind of boundary we are building around agent workflows in Xenition — https://xenition.com/.

The lesson was bigger than one product:

The model can decide what action makes sense.

The system should decide whether that action is allowed.

That separation is what starts turning an agent demo into something you can actually trust with real tools.

Audit Trails Matter Too

Approval solves only part of the problem.

You also need to know what happened later.

For example:

what tool was called
what data changed
when it happened
who approved it
what the agent requested
what the final result was

That is why agent systems need an action ledger or audit trail.

If something goes wrong, “the agent did something” is not enough.

You need evidence.

Task-Scoped Permissions Are Even Better

There is another improvement I think agent systems need.

Do not give the agent every permission it may ever need.

Give it what the current task needs.

For example:

Task: Summarize customer feedback

Needs:

read support tickets
read CRM notes

Does not need:

delete customer
modify billing
publish anything

Task: Prepare a campaign draft

Needs:

read campaign data
create draft

Does not need:

publish campaign
charge customers

Same agent.

Different task.

Different authority.

That reduces blast radius dramatically.

Fail Closed

One more rule:

If the permission system fails, the action should stop.

Bad:

policy error
→ continue

Better:

policy error
→ block

This sounds obvious.

But guardrails that fail open are not really guardrails.

A Simple Model That Works

For each action, ask:

What is it?

Read, write, destructive?

What does it affect?

One file? One customer? Production?

Is it reversible?

Can we undo it easily?

Does it leave the system?

Is data being sent externally?

Does it need approval?

If yes, stop before execution.

Is the result logged?

Can we reconstruct what happened?

That simple framework catches a surprising amount.

The Bigger Lesson

When agents only generated text, safety mostly meant:

Don’t say the wrong thing.

Now that agents can use real tools, safety increasingly means:

Don’t do the wrong thing.

That requires more than prompt engineering.

It requires:

permissions

policy enforcement

approval gates

task-scoped access

audit logs

fail-closed behavior

Because:

The model can decide what action makes sense.

The system should decide whether that action is allowed.

Final Thought

Giving AI agents real tools is what makes them powerful.

It is also what makes them dangerous if the authority model is vague.

“Ask before acting” sounds safe.

But it still asks the model to decide when it needs permission.

That is the wrong place to put the boundary.

The safer model is:

Let the agent propose.

Let policy decide.

Let the human approve when the impact is high.

Because the moment an AI agent can change the real world, permission stops being a prompt.

It becomes part of the architecture.

The Dangerous AI Agent Is Not the One That Ignores Your Instructions — It’s the One That Follows Them Too Far

Robert Adamson — Sun, 04 Oct 2026 04:27:02 +0000

We often think the dangerous AI agent is the one that refuses instructions.

The one that goes rogue.

The one that ignores what we asked.

But there is another failure mode that may be more realistic:

The agent understands the goal perfectly — and pursues it too aggressively.

That is a much harder problem.

Because the agent may not be “disobeying” you at all.

It may simply be optimizing for the objective without understanding where its authority should stop.

The Goal Can Be Correct While the Action Is Wrong

Imagine you ask an agent:

Find why the deployment failed.

The goal is reasonable.

The agent starts investigating.

It reads logs.

Checks config.

Inspects CI.

Queries cloud resources.

Looks at credentials.

Calls internal services.

Maybe even changes something to test a theory.

At each step, the agent may believe:

This helps me complete the task.

And that is exactly the problem.

The question is not only:

Does the agent understand the goal?

It is also:

Does the agent understand what it is allowed to do while pursuing that goal?

Those are two different things.

Goal Alignment Is Not Permission Alignment

This distinction matters.

A goal says:

What should be achieved?

Permissions say:

What actions are allowed?

For example:

```text id="1hpl1y"
Goal:
Fix the production outage.




That does not automatically mean:



```text id="ihdveu"
Permission:
Restart services
Change firewall rules
Rotate credentials
Modify database records
Deploy code

But if the agent has access to those capabilities, it may decide they are useful.

The agent can be perfectly aligned with the task and still cross a boundary.

Prompts Are Not Security Boundaries

A common pattern is:

“Do not touch production.”

or:

“Do not delete anything.”

or:

“Ask before deploying.”

Those instructions are useful.

But they are not strong security controls.

Why?

Because they depend on the agent interpreting and remembering the rule correctly.

A stronger system makes forbidden actions technically unavailable.

Instead of:

```text id="4i41wi"
Please do not access production.




prefer:



```text id="8mc8ra"
production_credentials = unavailable

Instead of:

```text id="ev4xsx"
Do not call external services.




prefer:



```text id="8n79xt"
network_access = allowlist only

Instead of:

```text id="1pzd88"
Ask before deployment.




prefer:



```text id="70g7fh"
deploy = human approval required

That is a much safer model.

Capability Is Not Authority

An agent may technically be capable of doing something.

That does not mean the current task should authorize it.

This is one of the biggest design mistakes I see in agent workflows.

A coding agent may have:

shell access
Git access
cloud credentials
package manager access
database access
deployment tools
network access

But if the task is:

Fix a button alignment bug.

Why should it inherit all of that?

The better question is:

What does this task actually require?

Permissions Should Be Task-Scoped

Imagine two tasks.

Task A — Fix CSS

The agent probably needs:

```text id="kq1v5k"
read frontend files
write frontend files
run frontend tests




It probably does not need:



```text id="b9wsj1"
cloud admin access
production database access
npm publish
deployment credentials

Task B — Prepare a Release

Now the agent may need:

```text id="fx39n5"
build
test
create release artifact




But publishing could still require:



```text id="s0h91l"
human approval

Same agent.

Different task.

Different authority.

That feels like the safer model.

Helpful Agents Can Still Be Dangerous

This is the uncomfortable part.

The agent does not need malicious intent.

It may simply reason:

“I need more information.”

So it reads another file.

Then:

“I need to verify this.”

So it calls another tool.

Then:

“I can fix this directly.”

So it modifies something.

Then:

“The fix should be deployed to confirm it.”

And suddenly the agent has crossed several boundaries while still pursuing the original goal.

Every step may look locally reasonable.

The full sequence may not be.

This Is Similar to Architecture Drift

A single action may look harmless.

But a chain of individually reasonable actions can create a bad outcome.

For example:

```text id="ljz6dp"
Read logs
↓
Inspect credentials
↓
Query internal API
↓
Modify config
↓
Restart service
↓
Deploy change




Maybe no individual step looked outrageous.

But the agent gradually expanded its own scope.

That is why task boundaries need to exist outside the model.

---

# Human Approval Should Be About Escalation

Human approval is most useful when the agent is about to increase its authority.

For example:

Require approval before:

- modifying production
- deleting files
- installing new dependencies
- publishing packages
- accessing secrets
- changing permissions
- sending data externally
- deploying
- touching infrastructure

The agent can still move quickly.

But high-impact actions create a checkpoint.

---

# Default to Read-Only

A very practical rule:

> **Start agents read-only whenever possible.**

Let them:

- inspect
- analyze
- propose
- explain
- generate plans

Then promote permissions only when necessary.

For example:



```text id="q9m37c"
Stage 1:
read only

Stage 2:
write project files

Stage 3:
run approved commands

Stage 4:
sensitive action requires human approval

That creates a natural escalation path.

Make Permission Changes Visible

If the agent needs more access, it should say so explicitly.

For example:

I can continue analyzing with current permissions.

or:

To complete this step, I need write access to config/.

or:

Deployment requires production credentials and approval.

That makes authority visible.

Silent escalation is the dangerous part.

Network Access Matters Too

Developers often think only about credentials.

But network position matters as well.

An agent running inside your machine may have access to:

VPN routes
internal DNS
localhost services
company APIs
metadata endpoints
unauthenticated internal tools

Even without credentials, it may still reach things that the public internet cannot.

So sandboxing should include:

filesystem

credentials

tools

and:

network egress

Fail Closed, Not Open

Suppose a policy hook fails.

What happens?

Bad design:

```text id="2z7i12"
policy check fails
↓
agent continues




Better:



```text id="36p98h"
policy check fails
↓
action blocked

Security boundaries should fail closed.

If the system cannot determine whether an action is allowed, the safest default is:

Do not perform it.

Log What the Agent Actually Did

Permissions tell you what an agent could do.

Logs tell you what it did do.

For meaningful agent workflows, I want an audit trail containing things like:

tool calls
commands
file writes
network requests
approval requests
permission escalations
deployment actions

Not just:

“Task completed successfully.”

The summary is not enough.

The actions matter.

Separate the Goal From the Policy

One useful architecture is to keep them independent.

Agent

Figures out:

What should I do next?

Policy layer

Checks:

Is this action allowed?

The agent should not be the final authority on both.

For example:

```text id="zfko91"
Agent:
"Run production migration."

Policy:
"Production writes require human approval."

Result:
Blocked pending approval.




That is much stronger than telling the agent:

> “Remember to ask first.”

---

# A Simple Agent Permission Model

For each task, define:

## Read

What can the agent inspect?

## Write

What can it modify?

## Execute

Which commands can it run?

## Network

Which destinations can it reach?

## Credentials

Which identities can it use?

## Escalation

Which actions require approval?

That is already enough to make agent workflows much easier to reason about.

---

# Before Giving an Agent a Task, Ask These Questions

### What is the goal?

Be specific.

### What is the minimum authority needed?

Do not inherit everything by default.

### What actions should require approval?

Define them before execution.

### What should be impossible?

Enforce that technically.

### What happens if the agent misunderstands the boundary?

The system should still remain safe.

### Can I reconstruct what happened later?

Keep an audit trail.

---

# The Bigger Lesson

We spend a lot of time trying to make agents understand our goals better.

That is important.

But understanding the goal is only half of the problem.

The other half is:

> **Understanding authority.**

An agent might know exactly what you want.

It might even find a very effective way to achieve it.

And that way may still be unacceptable.

---

# Final Thought

The dangerous AI agent is not always the one that says:

> **“I won’t follow your instructions.”**

Sometimes it is the one that says:

> **“I understand exactly what you want. I’ll do whatever is necessary to achieve it.”**

That is why production agent systems need more than good prompts.

They need:

**permissions**

**boundaries**

**approval gates**

**sandboxing**

**network controls**

**audit trails**

because:

> **A goal tells the agent what success looks like.**

> **Authority tells it how far it is allowed to go.**

And those two things should never be confused.

The More Context You Give Your AI Coding Agent, the Worse It Can Get

Robert Adamson — Sat, 03 Oct 2026 03:52:59 +0000

We keep hearing the same advice:

Give the AI more context.

Add the README.

Add AGENTS.md.

Add architecture docs.

Add logs.

Add previous decisions.

Add the whole repository.

Add memory from previous sessions.

Sounds reasonable.

But there is a problem:

More context does not always mean better understanding.

Sometimes it means more noise.

More stale assumptions.

More conflicting instructions.

More irrelevant files.

And more chances for the agent to focus on the wrong thing.

That is the part I think developers need to pay more attention to.

The Assumption: More Context = Better AI

It makes sense at first.

If the agent knows more about the codebase, it should make better decisions.

Right?

Sometimes.

But imagine giving a developer:

400 files
12 architecture documents
8 old incident reports
3 outdated migration plans
6 instruction files
40 pages of logs
previous agent memory
the current task

and then asking:

“Fix this bug.”

That is not automatically helpful.

That is a lot of information to sort through.

The same problem can happen with AI agents.

Context Has Quality, Not Just Quantity

Not all context is equally useful.

Some context is:

Relevant

Some is:

Outdated

Some is:

Conflicting

Some is:

Wrong

Some is:

Technically correct but irrelevant to the current task

If you give all of it equal weight, the agent has to figure out what matters.

And that is where mistakes start.

Example: The Old Architecture Doc

Suppose your current system uses:

```text id="ixn1f3"
Controller
↓
Service
↓
Repository




But an old architecture document still says:



```text id="8ylsl1"
Controller
   ↓
Data Layer

You ask the agent to add a feature.

Now the agent has two sources of truth.

Which one should it trust?

Maybe it follows the code.

Maybe it follows the documentation.

Maybe it blends both.

And now you get a new pattern that never existed before.

The problem was not lack of context.

The problem was bad context hygiene.

Stale Context Is Worse Than Missing Context

Missing context usually creates uncertainty.

Stale context can create confidence in the wrong direction.

That is more dangerous.

For example:

Three months ago:

“All payments go through Provider A.”

Today:

Half the system has moved to Provider B.

But the agent still carries the old rule in memory.

Now it confidently implements the wrong integration.

That is why persistent memory can be useful and dangerous at the same time.

Conflicting Instructions Create Quiet Problems

Imagine the agent reads:

```text id="hp3on9"
AGENTS.md:
Use service classes for all business logic.




Then another file says:



```text id="x68ti8"
README:
Keep business logic inside route handlers.

Then an old task note says:

```text id="14479z"
Avoid adding new service layers.




All three may have been correct at different times.

Now they coexist.

The agent has to resolve the conflict.

That is not a safe default.

---

# More Tokens Do Not Mean More Attention

This is another important point.

A bigger context window gives the agent access to more information.

It does not guarantee equal attention to every piece of information.

If you include:

- hundreds of files
- long logs
- old discussions
- huge docs

the important detail may become harder to surface.

The real problem becomes:

> **Can the agent find the right context at the right moment?**

That is different from:

> **Can the agent fit everything into the prompt?**

---

# The Goal Should Not Be Maximum Context

I think the better goal is:

> **Minimum sufficient context.**

Give the agent enough information to make the right decision.

Not everything you have.

For example, if the task is:

> “Fix a validation bug in checkout.”

The agent probably needs:

- checkout flow
- validation rules
- related tests
- relevant data model
- current architecture constraints

It probably does not need:

- email service docs
- analytics history
- unrelated migration logs
- old design discussions
- every frontend component

More is not automatically better.

---

# Use Progressive Context

A better pattern is:



```text id="k7ov9i"
Start small
↓
Give relevant files
↓
Let the agent inspect
↓
Add more only when needed

Instead of:

```text id="dxypv0"
Dump everything
↓
Hope the agent finds what matters




This is basically progressive disclosure for coding agents.

Let the agent earn more context as the task requires it.

---

# Ask the Agent What It Needs

This is surprisingly useful.

Instead of giving the whole repo immediately, ask:



```text id="wd8gzg"
Before changing anything:

1. What information do you need?
2. Which files are likely relevant?
3. What assumptions are you currently making?
4. What context would reduce uncertainty?

Now the agent tells you what it is missing.

That is much better than blindly adding more.

Separate Permanent Context From Task Context

I think teams should split context into two categories.

Permanent

Things that should almost always be true:

coding standards
architecture boundaries
security rules
naming conventions
ownership rules

Task-specific

Things relevant only to the current job:

one bug report
one feature requirement
one set of logs
one module
one incident

Mixing both into one giant blob makes reasoning harder.

Keep Permanent Rules Short

This is important.

Your agent instructions should not become a novel.

If your AGENTS.md is 5,000 lines long, developers probably do not read it carefully either.

The best permanent rules are usually simple.

For example:

```text id="w7h7wu"

Business logic stays in services.
Repositories only handle persistence.
Do not add dependencies without approval.
Do not modify auth rules without explicit request.
Tests must cover changed behavior. ```

Clear.

Short.

Hard to misinterpret.

Context Should Have an Expiration Date

Some context should not live forever.

For example:

temporary migration rules
incident-specific workarounds
old feature flags
deprecated API behavior
one-off implementation notes

If the agent can remember something forever, someone needs to decide when that memory stops being valid.

This is why I think agent memory needs something humans already understand:

Lifecycle management.

Context should be:

created

reviewed

updated

expired

deleted

Just like code and documentation.

Make Sources Visible

Another good habit:

Do not let context appear as one anonymous blob.

The agent should know where information came from.

For example:

```text id="l6tqad"
Source: current code
Source: AGENTS.md
Source: architecture decision record
Source: incident from June
Source: previous agent memory




Why?

Because source matters.

Current production code should probably outweigh a two-year-old planning document.

Without provenance, everything can look equally trustworthy.

---

# Ask the Agent to Surface Conflicts

Before implementation, try:



```text id="gprxfr"
Review the available context.

Identify:

- conflicting instructions
- outdated assumptions
- duplicated rules
- unclear sources of truth
- anything that may no longer be valid

Do not change code yet.

This is a very useful step for large codebases.

You want context conflicts visible before they become code.

More Context Can Increase Hallucination Too

This sounds backwards.

But imagine the agent sees 10 partial references to a system behavior.

None gives the complete picture.

It may combine them into a plausible explanation.

That explanation can sound very confident.

And still be wrong.

The issue is not always missing information.

Sometimes it is too many incomplete signals.

Context Is Part of the Architecture Now

We usually think architecture means:

services
databases
queues
APIs
boundaries

But in AI-assisted development, context becomes part of the system too.

Because context influences:

what the agent believes
what it changes
which patterns it follows
which assumptions it preserves

That means context needs engineering discipline too.

A Simple Context Checklist

Before giving an AI agent more information, ask:

Is this relevant?

If not, leave it out.

Is this still true?

If you are not sure, verify it.

Does it conflict with another source?

Resolve that first.

Is there a newer source?

Prefer the newer one.

Does the agent need this now?

Maybe later is better.

Will this context still be valid next month?

If not, do not treat it as permanent memory.

My Preferred Workflow

Instead of:

```text id="5axqqf"
Load entire repo
↓
Load all docs
↓
Load memory
↓
Ask agent to work




I prefer:



```text id="d6w46d"
Define task
↓
Give core constraints
↓
Agent identifies needed context
↓
Load only relevant files
↓
Check for conflicts
↓
Implement
↓
Verify

The difference is simple:

Context becomes intentional.

The Bigger Lesson

AI coding agents do not just need more information.

They need:

the right information

from the right source

at the right time

That is a much harder problem.

But it is also where developers can add real value.

Final Thought

We keep trying to make AI coding agents smarter by giving them more context.

Sometimes that works.

Sometimes it makes things worse.

Because:

More context can mean more noise.

More memory can mean more stale assumptions.

More instructions can mean more conflicts.

The goal should not be:

Give the agent everything.

The goal should be:

Give the agent exactly what it needs to make the right decision.

Because the best context window is not the biggest one.

It is the one with the least irrelevant information and the clearest source of truth.

AI Helps You Code Faster. So Why Are You Still Shipping Slowly?

Robert Adamson — Wed, 30 Sep 2026 05:50:09 +0000

You generated a feature in 20 minutes.

Three days later, it still hasn’t reached production.

The code exists. But the tests are failing, the review is waiting, and someone just noticed that the feature solves the wrong problem.

What actually got faster?

Writing the first version.

That matters. But users don’t use first drafts. They use working software.

Coding Is Only One Part of Shipping

Consider a simple feature: adding a discount code at checkout.

AI can quickly generate the input, validation logic, and API endpoint.

But you still need answers:

Can customers combine discounts?
What happens when a code expires during checkout?
Does the discount apply before or after tax?
Can someone reuse a single-use code?

A feature can look finished while these questions remain unanswered.

AI can turn assumptions into code faster than you can notice them.

Faster Generation Can Create a Bigger Queue

Imagine a team producing twice as many changes while its review capacity stays the same.

More code arrives. More code waits.

Large changes make this harder. A reviewer must understand the intent, inspect the implementation, and check how it affects the rest of the system.

Generating another feature doesn’t clear that queue.

Sometimes, the most useful next step is helping an existing change reach production.

Passing Tests Doesn’t Mean You Solved the Right Problem

Suppose you ask AI to implement discounts, then ask it to write tests.

It might assume that discounts can be combined—and write tests confirming that behavior.

Everything passes.

The business wanted one discount per order.

The problem is that the implementation and the tests can share the same wrong assumption.

Define the expected behavior before generating either.

Five Ways to Turn Faster Coding Into Faster Delivery

1. Describe “done” before asking for code

“A discount feature” is vague.

“One valid discount per order, with expired codes rejected and the updated total shown before payment” gives you something concrete to verify.

Clear requirements reduce guessing and rework.

2. Ask for smaller changes

Avoid asking an agent to rebuild checkout in one request.

Start with one behavior. Inspect it. Verify it. Then move on.

A smaller change is easier to understand, review, and fix.

3. Review the assumptions first

Before examining every line, ask:

What decisions did the AI make?
Which existing behavior changed?
What happens when something fails?

Finding a wrong assumption early can save more time than polishing the code built around it.

4. Test the awkward cases

The happy path is only the beginning.

Try an expired code, two quick submissions, a failed request, and a customer refreshing during checkout.

Choose tests based on what could hurt the user or the business.

5. Measure delivery, not generated code

Lines of code and completed prompts don’t tell you whether customers received something useful.

Track how long changes take to reach production, how often they need rework, and what breaks after release.

A smaller feature that works is more valuable than a larger feature waiting for approval.

Try This on Your Next Feature

Write three acceptance criteria. Ask AI for the smallest implementation that meets them. Check its assumptions. Test one important failure case.

Then follow the change all the way to production.

AI can shorten the coding step. To shorten delivery, you also need to address whatever keeps the finished code waiting.

Where does your work get stuck most often: requirements, review, testing, or deployment?

AI Can Make Every Local Decision Look Reasonable — While Making the System Worse

Robert Adamson — Tue, 29 Sep 2026 03:46:12 +0000

AI coding agents are very good at making small decisions.

Move this logic into a helper.

Add a cache here.

Create a service for that.

Split this module.

Add another abstraction.

Introduce one more dependency.

Each decision can look perfectly reasonable.

That is exactly the problem.

A system can get worse even when every local decision looks correct.

This is not really an AI problem.

It is an architecture problem that AI can now accelerate.

The Dangerous Part Is That Nothing Looks Obviously Wrong

Imagine this over a few weeks:

Task 1 → Add validation
Task 2 → Extract helper
Task 3 → Add cache
Task 4 → Add service
Task 5 → Add retry logic
Task 6 → Refactor module
Task 7 → Add another integration

Every pull request passes.

Every change looks clean.

Every test is green.

But six weeks later:

two services now own the same business rule
validation exists in three places
caching is inconsistent
dependencies point in both directions
nobody knows which layer owns what
a “simple” change touches eight files

No single commit destroyed the architecture.

The system drifted there.

Local Correctness Is Not System Correctness

This is the key idea.

An AI agent usually works on the task in front of it.

You ask:

“Add retry support.”

It finds the easiest reasonable place to add retries.

You ask:

“Reuse this logic.”

It extracts a helper.

You ask:

“Clean up this module.”

It introduces a new abstraction.

Each answer may be correct for that prompt.

But architecture is not just a collection of locally correct choices.

Architecture is about how those choices interact over time.

The Agent Optimizes for the Task

The developer has a different responsibility.

The agent asks:

How do I complete this task successfully?

The developer should ask:

What does this change do to the whole system?

Those are not the same question.

The agent may optimize for:

fewer lines
cleaner separation
less duplication
faster implementation
easier reuse

The system may actually need:

stronger boundaries
fewer abstractions
one clear owner
deliberate duplication
less coupling
simpler dependencies

A locally elegant change can still be globally harmful.

Example: The Helpful Helper

Suppose you have this:

calculateInvoiceTotal()

One module uses it.

Then another feature needs similar behavior.

AI suggests:

Move it into shared/utils.

Makes sense.

Later another module imports it.

Then another.

Then someone adds customer-specific logic.

Then tax rules.

Then discount behavior.

Now your “shared helper” contains business logic used across the entire system.

Nothing looked unreasonable at the time.

But the architecture quietly changed.

What started as:

Invoice owns invoice logic

became:

Everyone depends on shared/utils

That is architecture drift.

AI Makes Architecture Drift Faster

Before AI, introducing five new abstractions took effort.

Now it can happen in minutes.

That changes the economics.

Developers can generate:

new services
new interfaces
new layers
new adapters
new helpers

faster than they can evaluate whether those things should exist.

The risk is not that AI generates obviously terrible architecture.

The more interesting risk is:

It generates plausible architecture faster than teams can maintain a coherent design.

Green Tests Do Not Protect Architecture

This is important.

Your test suite may say:

Everything works.

That does not mean:

The system is getting better.

Tests can catch:

broken behavior
regressions
invalid outputs

They usually do not catch:

unclear ownership
unnecessary abstractions
dependency creep
duplicated business rules
architectural drift

You can have:

100% tests passing

and still have a codebase becoming harder to change every week.

Code Review Can Miss It Too

A reviewer sees one pull request.

Maybe 80 lines.

The diff looks reasonable.

But architecture problems often become visible only across many changes.

PR 1 adds a helper.

PR 2 adds a service.

PR 3 adds another dependency.

PR 4 reuses the helper.

PR 5 bypasses the service.

Individually:

Fine.

Collectively:

Messy system.

This is why reviewing only the current diff is not always enough.

Ask One Extra Question During AI-Assisted Review

When reviewing AI-generated code, ask:

If we repeat this pattern 20 times, what does the system look like?

That question is surprisingly useful.

If every feature adds:

another service
another config
another queue
another shared helper

then the pattern itself may be wrong.

Architecture is often about what happens when a decision gets repeated.

Protect Ownership Boundaries

One of the easiest ways to reduce drift is to make ownership explicit.

For example:

Payments owns payment rules.
Orders owns order lifecycle.
Users owns identity.
Notifications only sends messages.

Then tell the agent:

Do not move business rules across these boundaries unless explicitly requested.

That is better than letting the model decide architectural ownership from scratch every time.

Give AI Constraints, Not Just Goals

Bad prompt:

Refactor this to make it cleaner.

Better:

Refactor this module.

Constraints:

- preserve current architectural boundaries
- do not introduce new dependencies
- do not create new shared abstractions
- keep business logic in the existing domain
- propose changes before implementing

The goal is not to make AI less useful.

It is to stop every task from becoming a mini architecture redesign.

Ask for the Architecture Impact Before the Code

Before implementation, try:

Before changing code, explain:

1. Which architectural boundary this touches.
2. Which modules will depend on the change.
3. Whether this introduces a new abstraction.
4. Whether this creates a new dependency.
5. Whether similar logic already exists.
6. How this affects future changes.

That forces the discussion one level above syntax.

Watch for Dependency Direction

One signal I pay attention to is dependency direction.

Healthy systems usually have clear relationships.

For example:

Controller
   ↓
Service
   ↓
Repository

Then AI introduces:

Repository
   ↓
Utility
   ↓
Service

Now layers start depending on each other in strange ways.

Each import may compile.

But the system becomes harder to reason about.

If dependency direction becomes unclear, architecture is usually drifting.

Shared Code Is Not Always Better Code

AI often tries to remove duplication.

Usually that is good.

But sometimes two pieces of code only look similar today.

For example:

calculateSellerFee()
calculateCreatorFee()

AI may combine them into:

calculateFee(type)

Cleaner?

Maybe.

But if seller and creator rules evolve differently, you now have one abstraction carrying two separate concepts.

A little duplication can be cheaper than the wrong abstraction.

This is something humans still need to judge carefully.

Architecture Needs Invariants

I think AI-heavy teams need explicit architectural rules.

Not hundreds of pages.

Just a few things that must remain true.

For example:

- Controllers contain no business logic.
- Domains cannot access each other's database tables directly.
- Shared utilities cannot contain business rules.
- External APIs go through adapters.
- Background jobs call services instead of repositories directly.

Now both humans and agents have something concrete to check.

These are architecture invariants.

Use AI to Detect Drift Too

AI can also help find the problem it creates.

Periodically ask:

Review this codebase for architecture drift.

Look for:

- duplicated responsibilities
- unclear module ownership
- circular dependencies
- new abstractions with little value
- shared utilities containing business logic
- inconsistent patterns
- dependency direction violations

Do not refactor anything yet.

Rank the findings by impact.

That can be a very useful review.

The important part:

Do not refactor anything yet.

First detect.

Then decide.

Small Changes Need System-Level Review Too

The dangerous phrase is:

“It’s only a small change.”

Small changes repeated hundreds of times become architecture.

Every small change teaches the codebase a pattern.

If that pattern is weak, AI can replicate it extremely quickly.

That is why local quality is not enough.

A Simple Review Checklist

Before merging an AI-generated change, ask:

Does this introduce a new abstraction?

If yes, do we actually need it?

Does this move responsibility?

If yes, is the new owner correct?

Does this add another dependency?

Could an existing boundary handle it?

Does similar logic already exist?

Avoid competing patterns.

What happens if we repeat this approach 20 times?

This one catches a lot.

Is the system easier to explain after this change?

If not, the “cleaner code” may not actually be cleaner.

The Real Risk Is Plausible Decisions at Scale

AI does not need to make obviously bad decisions to damage architecture.

It only needs to make thousands of reasonable decisions without enough system-level coordination.

That is the uncomfortable part.

A codebase rarely becomes difficult because someone deliberately designed it badly.

It usually becomes difficult through:

hundreds of decisions that made sense at the time.

AI can now generate those decisions much faster.

Final Thought

AI is very good at answering:

What is a reasonable solution to this task?

But software architecture requires another question:

What happens to the system if we keep making decisions like this?

Those are different levels of reasoning.

And that is why developers still need to protect the bigger picture.

Because:

Every local decision can look reasonable while the system slowly gets worse.

The agent owns the task.

You still own the architecture.

AI Can Fix the Bug Before You Understand It — That’s More Dangerous Than It Sounds

Robert Adamson — Mon, 28 Sep 2026 05:01:27 +0000

A bug appears.

You paste the error into your AI coding agent.

Thirty seconds later:

“Fixed ✅”

You run the app.

It works.

Great.

Except there is one problem:

You still don’t know why it broke.

And I think this is becoming one of the most overlooked problems in AI-assisted development.

AI is making bug fixing faster.

But it can also make understanding optional.

That is dangerous.

The Old Debugging Loop

Before AI, debugging usually looked like this:

Bug
↓
Reproduce
↓
Read logs
↓
Form hypothesis
↓
Test hypothesis
↓
Find root cause
↓
Fix
↓
Add regression test

It was slower.

But during that process, you built a mental model of the system.

You learned:

where data flows
what assumptions exist
which component owns what
what can fail
how the system behaves under pressure

Now the workflow can become:

Bug
↓
Ask AI
↓
Patch appears
↓
App works
↓
Move on

Fast?

Yes.

Safe?

Not always.

A Fix Is Not the Same as Understanding

Suppose your app crashes because a value is unexpectedly null.

AI adds:

if (!user) return;

The crash disappears.

But did we actually fix the problem?

Maybe the real issue was:

the user should never have been null
a database query failed
an async race happened
state was loaded too late
an API returned invalid data

The patch removed the symptom.

It may not have removed the cause.

This is the important distinction:

A successful patch does not prove the diagnosis was correct.

AI Is Very Good at Symptom Removal

AI often sees:

error → likely patch

That can be useful.

But some “fixes” simply:

add a null check
catch an exception
retry the operation
increase a timeout
suppress an error
weaken validation
add a fallback

The application stops failing.

But the deeper problem may still exist.

That is how temporary fixes become permanent technical debt.

Ask for the Root Cause Before the Fix

One habit helps a lot.

Instead of asking:

Fix this bug.

Try:

Do not modify the code yet.

First explain:

1. What is failing?
2. What triggered the failure?
3. What state should have existed?
4. What state actually existed?
5. What is the most likely root cause?
6. What evidence supports that conclusion?
7. What other explanations are possible?

Only then ask for the fix.

That keeps you involved in the reasoning.

Use This Debugging Flow

A better AI-assisted debugging workflow is:

Reproduce
↓
Observe
↓
Explain
↓
Form hypothesis
↓
Verify hypothesis
↓
Fix
↓
Regression test

The AI can help at every step.

But do not skip the middle.

That middle is where understanding happens.

Ask the AI to Prove Its Diagnosis

If the agent says:

“The bug is caused by a race condition.”

Ask:

What evidence makes you think that?

Then ask:

What observation would prove this diagnosis wrong?

That second question is extremely useful.

A good debugging process should be falsifiable.

Not just confident.

Separate Diagnosis From Repair

This is one of the best changes you can make.

Step 1 — Diagnose

Ask the AI to inspect the failure and explain it.

Step 2 — Verify

Check logs, state, tests, timing, or data.

Step 3 — Repair

Only after the cause is reasonably clear.

Step 4 — Prove

Add a regression test that fails before the fix and passes after it.

That is much stronger than:

“The error disappeared.”

Require a Regression Test

Every meaningful bug fix should answer:

What test would have caught this before production?

If the answer is “none,” the bug can easily come back.

A good regression test should:

reproduce the original failure
fail before the patch
pass after the patch

Now the fix becomes part of the system’s knowledge.

Not just the AI conversation.

Be Careful With “It Works Now”

“It works now” is one of the weakest debugging signals.

Maybe:

the failure is intermittent
cached state changed
timing changed
the test data is different
a retry succeeded
the error moved somewhere else

A better question is:

Why does it work now?

If nobody can answer that, the debugging is not finished.

Your Team Needs to Own the Explanation

This is the part that worries me most.

Imagine an AI fixes bugs all day.

Everything ships faster.

But six months later, your team knows less about:

data flow
failure modes
edge cases
architecture
production behavior

The codebase may improve.

Your understanding of it may not.

That creates a new kind of risk.

I Think of It as Debugging Debt

We already talk about technical debt.

AI can create another kind:

Debugging Debt

You solved the incident.

But you never learned why it happened.

The next failure may come from the same underlying cause in a different place.

And now your team has to rediscover everything from scratch.

The Best Use of AI in Debugging

AI is incredibly useful for:

reading logs
tracing code paths
finding suspicious changes
generating hypotheses
comparing stack traces
creating repro tests
suggesting instrumentation
identifying likely failure points

But the final question should still be human-owned:

Do we actually understand why this failed?

That is the difference between:

patching

and

debugging

A Simple Prompt I Use

When something breaks, try this:

Do not fix anything yet.

Help me debug this systematically.

1. Summarize the failure.
2. Trace the likely execution path.
3. List the top 3 root-cause hypotheses.
4. For each hypothesis, give evidence for and against it.
5. Tell me what logs, tests, or observations would confirm it.
6. Wait before proposing code changes.

This forces the AI to act more like a debugging partner than a patch generator.

My Final Rule

Before accepting an AI-generated bug fix, I want to be able to answer:

What broke?

Why did it break?

Why does this fix work?

What would prove this fix is wrong?

What regression test protects us now?

If I cannot answer those questions, I probably accepted a patch too early.

Final Thought

AI can fix bugs faster than most developers ever could manually.

That is powerful.

But speed creates a temptation:

Skip understanding. Accept the patch. Move on.

That works until the next incident.

The goal should not be:

AI fixed it.

The goal should be:

We understand why it broke, and now it cannot break the same way again.

Because a bug you fixed but never understood is not really knowledge your team owns.

It is knowledge you temporarily borrowed from the AI.

Your AI Coding Agent Says “Tests Pass.” But Did It Actually Run Them?

Robert Adamson — Sun, 27 Sep 2026 05:07:41 +0000

AI coding agents are getting very good at finishing tasks.

They modify files.

Fix errors.

Write tests.

Run commands.

Then they end with something like:

All tests pass ✅

And most of us move on.

But there is an important question:

Did the agent actually run the tests it claims passed?

That sounds obvious.

It isn’t.

Because in AI-assisted development, we are starting to trust summaries instead of evidence.

“Tests Pass” Is a Claim

Imagine an agent says:

Implementation complete.

✓ Tests pass
✓ Build succeeds
✓ No lint errors

That looks reassuring.

But you still do not know:

what command it ran
whether it ran the full test suite
whether some tests were skipped
whether the command exited successfully
whether the output came from the latest code
whether it ran tests at all

The message is a summary.

It is not proof.

This Is a New Kind of Trust Problem

Before coding agents, developers usually ran commands directly:

npm test

You saw the output.

You saw the failures.

You saw the exit code.

With agents, the workflow can become:

Developer asks for feature
        ↓
Agent changes code
        ↓
Agent runs something
        ↓
Agent summarizes result
        ↓
Developer trusts summary

There is now another layer between you and the actual verification.

That layer can be wrong.

The Agent May Have Run Only Part of the Tests

Suppose your project has:

unit tests
integration tests
API tests
end-to-end tests

The agent runs:

npm run test:unit

Everything passes.

Then it reports:

All tests pass.

Technically, some tests passed.

But the full application was never verified.

That difference matters.

It May Be Reporting Stale Results

Another easy failure mode:

Agent runs tests
        ↓
Tests pass
        ↓
Agent changes code again
        ↓
Agent reports "tests pass"

The statement was true earlier.

It may no longer be true now.

Verification should happen against the final state of the code.

Passing Tests Can Still Mean the Wrong Tests

There is another problem.

AI writes the feature.

Then AI writes the tests.

Then AI runs those tests.

They pass.

Great.

Except both the implementation and the tests may share the same misunderstanding.

For example:

Wrong requirement interpretation
        ↓
AI writes code
        ↓
AI writes tests for that interpretation
        ↓
Tests pass

Everything is green.

The feature is still wrong.

So there are really two questions:

Did the tests run?

and

Were they the right tests?

Both matter.

Require Evidence, Not Confidence

I have started preferring a simple rule:

If an agent makes a verification claim, ask for the evidence behind it.

Instead of accepting:

Tests pass.

Ask for:

Show me:

1. The exact command you ran.
2. The exit code.
3. How many tests ran.
4. How many failed.
5. How many were skipped.
6. Whether this was run after the final code change.

Now the claim becomes inspectable.

Give Your Agent a Verification Contract

You can make this part of your normal coding-agent instructions.

For example:

Never say "tests pass" unless you actually ran the relevant test command.

When reporting verification, include:

- exact command
- exit code
- number of tests
- failures
- skipped tests
- build status
- lint/typecheck status

If you did not run something, say "not verified."

That last line is especially important:

If you did not verify it, say so.

“I did not run the integration tests” is much more useful than false confidence.

Separate Implementation From Verification

For important changes, do not let the same workflow both create and certify the result.

A stronger pattern is:

Agent implements feature
        ↓
Independent test command
        ↓
CI verifies
        ↓
Human reviews result

For higher-risk changes, you can go further:

Agent A → implementation

Agent B → adversarial review

CI → tests/build/security checks

Human → final approval

The important part is independence.

The system that produced the code should not be your only source of confidence that the code is correct.

CI Should Be the Source of Truth

The agent's message should be treated as useful context.

Not final authority.

For example:

Agent says:

All tests pass.

CI says:

3 integration tests failed.

Trust CI.

This is why traditional engineering systems still matter even when AI writes more of the code.

You still want:

CI
deterministic tests
build checks
type checks
linting
security scans
deployment gates

AI does not replace those systems.

It makes them more important.

Be Careful With “Fixed”

The same principle applies to other agent claims.

For example:

“The bug is fixed.”

How was it verified?

“The build works.”

Which build command ran?

“There are no breaking changes.”

What compatibility checks were performed?

“The migration is safe.”

Was it tested against realistic data?

“This is secure.”

What security checks were actually run?

AI agents can sound extremely certain.

Certainty is not evidence.

A Better Completion Message

Instead of this:

Done.

Everything works and all tests pass.

I would rather see:

Implementation complete.

Verification performed:

npm test
Exit code: 0
128 tests passed
0 failed
3 skipped

npm run typecheck
Exit code: 0

npm run lint
Exit code: 0

Integration tests were NOT run.

Manual browser testing was NOT performed.

That is much more useful.

Now I know exactly what was verified.

And what was not.

Add “Not Verified” to Your Vocabulary

One thing AI-assisted development needs more of is:

Not verified.

There is nothing wrong with an agent saying:

Implemented, but not tested.

or:

Unit tests pass, integration tests not run.

or:

I could not verify this because the required service is unavailable.

Those answers are better than pretending certainty.

Good engineering is not about sounding confident.

It is about knowing what evidence you actually have.

My Simple Rule

For any important AI-generated change:

Never trust this:

“It works.”

Prefer this:

“Here is how I verified it.”

That one difference can prevent a lot of false confidence.

A Practical Checklist

Before accepting an agent's “tests pass” message, ask:

What command was executed?

You should know the exact command.

Was it the full relevant test suite?

Not just one subset.

What was the exit code?

Success should be measurable.

Were any tests skipped?

Skipped tests matter.

Was verification run after the final code change?

Not before the last edit.

Did CI confirm the result?

Prefer independent verification.

Can I inspect the output?

Evidence should be available.

Final Thought

AI coding agents are becoming very good at producing code.

But as they become more autonomous, developers need to become more careful about one thing:

verification.

The dangerous workflow is:

AI writes code
↓
AI says it works
↓
Human believes it
↓
Merge

The better workflow is:

AI writes code
↓
AI provides evidence
↓
Independent checks run
↓
Human verifies
↓
Merge

Because:

“Tests pass” is not evidence that tests passed.

It is a claim.

And in software engineering, important claims should come with receipts.

If AI Writes the Code and AI Reviews the Code, What Exactly Is the Developer Verifying?

Robert Adamson — Sat, 26 Sep 2026 03:59:59 +0000

AI can now write the feature.

Then AI can write the tests.

Then AI can open the pull request.

Then AI can review the pull request.

Then AI can fix the review comments.

And finally, a developer clicks:

Approve.

That workflow sounds incredibly efficient.

It also creates a very uncomfortable question:

If AI writes the code and AI reviews the code, what exactly is the human verifying?

This is no longer theoretical.

GitHub says Copilot code review now accounts for more than one in five code reviews on GitHub, and its review system can explore repository context, inspect large pull requests, review bot-authored PRs, and re-check its own findings after changes.

That can be extremely useful.

But only if we are clear about what the human reviewer is still responsible for.

Because:

AI reviewing AI-generated code is not the same thing as independent verification.

The New Development Loop

A growing number of workflows now look like this:

Requirement
   ↓
AI generates implementation
   ↓
AI generates tests
   ↓
AI opens pull request
   ↓
AI reviews pull request
   ↓
AI fixes findings
   ↓
Human approves

On paper, this looks great.

Everything has been:

implemented
tested
reviewed
fixed

So what is left for the developer?

A lot, actually.

Because every step above can share the same misunderstanding.

The Biggest Risk: Shared Assumptions

Imagine the requirement is:

A user should only receive a refund if the payment was successfully captured.

AI misunderstands that as:

A user can receive a refund if a payment record exists.

The AI then writes the implementation.

Then it writes tests.

The tests use the same interpretation.

Then an AI reviewer inspects the code.

It sees:

clean structure
tests passing
correct types
reasonable error handling

Everything looks good.

But the requirement is still wrong.

The pipeline becomes:

Wrong assumption
      ↓
Correct implementation of wrong assumption
      ↓
Correct tests for wrong assumption
      ↓
Correct review of wrong implementation
      ↓
Green CI

This is why passing tests and positive AI review are not enough.

They can verify consistency.

They cannot guarantee that the original understanding was correct.

AI Can Review Code Without Understanding Your Real Intent

This is where human judgment still matters.

An AI reviewer can often detect:

obvious bugs
null handling
unsafe patterns
missing validation
suspicious logic
inconsistent naming
duplicated code
test gaps

That is valuable.

GitHub has been expanding Copilot code review with deeper repository exploration, severity levels, and stronger agentic review capabilities.

But your actual product intent may not live inside the codebase.

It may live in:

a conversation with a customer
a product meeting
a support ticket
a legal requirement
a business rule
an undocumented edge case
a decision made six months ago

The model may never see that context.

And even if you provide it, it can still misunderstand it.

That means the human reviewer has to verify something deeper than syntax.

The Developer Should Verify the Requirement First

The first question should not be:

“Is this code good?”

It should be:

“Is this solving the right problem?”

Before reviewing the implementation, ask:

What was the original requirement?
What behavior should the user actually see?
Which business rules matter?
What should never happen?
What assumptions did the AI make?
Are those assumptions correct?

This is requirement verification.

And it may become one of the most important developer skills in AI-assisted development.

Tests Are Not Independent If AI Wrote Them From the Same Prompt

This is another subtle problem.

Suppose you give an AI:

Build a password-reset flow.

The AI writes the feature.

Then you say:

Write tests.

Those tests are often based on the same mental model the AI used for the implementation.

So if the model forgot an important requirement, the tests may forget it too.

You get:

Implementation assumption
          ↓
Test assumption
          ↓
Both agree
          ↓
Tests pass

That is not independent verification.

It is agreement.

And agreement is not the same as correctness.

Ask Tests to Challenge the Implementation

A better approach is to change the role of the test-generation step.

Instead of:

Write tests for this implementation.

try:

Act as a skeptical QA engineer.

Do not assume the implementation is correct.

Based on the requirement, identify:
- failure cases
- abuse cases
- race conditions
- boundary cases
- invalid states
- unexpected user behavior

Then write tests that try to break the implementation.

That creates more separation between:

creator

and

critic

It is still AI reviewing AI.

But at least you are changing the objective.

The Human Reviewer Should Look for Decisions

AI is very good at examining code.

Humans should spend more time examining decisions.

For example:

Instead of asking:

Is this function correct?

ask:

Why does this function exist here?

Instead of:

Does this API return the right type?

ask:

Should this endpoint be allowed to perform this operation at all?

Instead of:

Is this query efficient?

ask:

Should this data be queried this way in the first place?

Instead of:

Do the tests pass?

ask:

Are we testing the behavior the business actually needs?

This is where developers add the most value.

Architecture Still Needs Human Attention

AI reviewers can catch many local issues.

But architecture is often about tradeoffs across the entire system.

An AI-generated feature may introduce:

another service
another queue
another database table
another cache
another dependency
another abstraction

Each one can look reasonable individually.

Together, they may make the system worse.

That is why the human reviewer should ask:

Does this change make the system easier or harder to understand?

That question is often more important than whether every line is technically correct.

Watch for “AI Agreement Loops”

One pattern I think teams should actively avoid is:

AI writes code
↓
AI reviewer suggests change
↓
AI author accepts
↓
AI reviewer approves
↓
Human sees green check
↓
Merge

Everything in that loop may come from models with similar assumptions.

The process looks highly reviewed.

But the independence between steps may be weak.

I think of this as an:

AI Agreement Loop

The system creates the appearance of verification because multiple stages agree.

But those stages may not be truly independent.

That is the key danger.

Green Checks Can Create False Confidence

Developers are trained to trust signals like:

Tests passed

Lint passed

Type check passed

AI review passed

Security scan passed

Those signals are useful.

But they can create a dangerous feeling:

“Everything is green, so this must be safe.”

Not necessarily.

A green pipeline tells you:

The system passed the checks you chose to run.

It does not tell you:

You chose the right checks.

That distinction matters more than ever.

A Practical Human Review Checklist

When AI writes the code and AI reviews the code, I think the developer should verify at least these 7 things.

1. Verify the Requirement

Ask:

Does this actually solve what the user or business asked for?

Not:

Does the code match the prompt?

Those are different questions.

2. Verify the Assumptions

Ask the AI:

List every assumption this implementation makes about:

- user behavior
- data
- permissions
- APIs
- infrastructure
- ordering
- timing

Then review them manually.

Hidden assumptions cause a huge number of production bugs.

3. Verify the Failure Modes

Ask:

What happens if the network fails?
What happens if the DB write partially succeeds?
What if the request is repeated?
What if the external API times out?
What if two requests happen simultaneously?
What if the input is technically valid but unexpected?

Happy-path code is easy.

Production failures live outside the happy path.

4. Verify the Blast Radius

If this change fails, what breaks?

One component?

One customer?

All customers?

Payments?

Authentication?

Data integrity?

A change touching a critical path deserves more human attention than a small UI change.

5. Verify the Architecture

Ask:

Did the AI add a new abstraction?
Did it introduce another dependency?
Did it duplicate existing functionality?
Did it bypass an existing architectural boundary?
Did it make the system harder to reason about?

Correct code can still create bad architecture.

6. Verify the Tests

Do not only read whether tests pass.

Read what they actually test.

Ask:

If the requirement were wrong, would these tests notice?

If the answer is no, you need better tests.

7. Verify That You Can Explain the Change

This is my final rule.

If someone asks:

“Why was this implemented this way?”

you should have an answer better than:

“The agent generated it and Copilot approved it.”

If you cannot explain the change, you are not ready to own it.

Use Different Agents for Different Roles

One useful pattern is to deliberately separate roles.

For example:

Agent 1 — Implementer

Implement the requirement using the existing architecture.

Agent 2 — Adversarial Reviewer

Assume this implementation contains subtle bugs.

Try to find:
- incorrect assumptions
- security problems
- failure modes
- race conditions
- architectural problems

Agent 3 — Test Designer

Ignore the existing tests.

Design tests directly from the original requirement.

Human

Verify:

Did all three understand the actual problem correctly?

Multiple agents do not replace human review.

But role separation can reduce simple agreement loops.

Review the Requirement and the Diff Together

One practical habit helps a lot.

Do not review a pull request with only the code visible.

Keep the original requirement next to it.

For every significant change, compare:

Requirement
     ↕
Implementation
     ↕
Tests

These three should agree.

If only:

Implementation ↔ Tests

agree, you may still have a perfectly tested wrong feature.

Ask AI to Explain Before Asking It to Fix

Suppose the AI reviewer finds a problem.

Avoid immediately clicking:

Apply suggestion

Instead ask:

Explain:

1. Why this is a problem.
2. What real-world failure it could cause.
3. What assumptions the current implementation makes.
4. Why your proposed change fixes it.
5. What new risks your fix introduces.

Now you are reviewing reasoning, not just accepting another generated diff.

That helps maintain ownership.

AI Review Should Increase Human Leverage, Not Remove Human Judgment

I am not arguing against AI code review.

Quite the opposite.

AI review can be extremely useful.

It can catch issues humans miss.

It can reduce repetitive review work.

It can inspect large changes quickly.

It can help teams focus attention where it matters.

But the goal should be:

AI checks mechanics
+
Human checks meaning

Not:

AI writes
+
AI tests
+
AI reviews
+
Human clicks approve

That second workflow may be fast.

But eventually the developer becomes little more than the final button in an automated pipeline.

And that is dangerous.

The Human Role Is Moving Up a Level

The developer's value is gradually shifting.

Less time may go into:

typing syntax

More time may go into:

understanding requirements

designing systems

challenging assumptions

verifying behavior

evaluating risk

debugging failures

making tradeoffs

taking ownership

That is not the disappearance of software engineering.

It is software engineering becoming more about judgment.

The Question I Now Ask Before Approving AI Code

I used to ask:

“Does this code look correct?”

Now I think the better question is:

“What do I know that the AI systems in this loop might not know?”

Maybe it is:

customer intent
historical context
production behavior
an undocumented dependency
an organizational constraint
a previous incident
a business rule

That missing context may be the most important part of the review.

Final Thought

We are quickly approaching a workflow where AI can:

write the code

write the tests

review the code

fix the review

and maybe even:

merge and deploy it

That does not make human verification less important.

It changes what humans need to verify.

The developer's job is increasingly not to check whether every semicolon is correct.

It is to ask:

Did we build the right thing?

Are the assumptions correct?

Do we understand how it can fail?

Can we explain why this design exists?

Are we willing to own the consequences?

Because if AI writes the code and AI reviews the code, the most valuable thing the developer can provide is something neither system automatically guarantees:

Independent judgment.

AI can review the implementation.

The developer still has to review reality.

AI Is Writing More of the Code — But Developers Are Becoming Responsible for More Than Ever

Robert Adamson — Wed, 23 Sep 2026 03:44:46 +0000

AI is writing more code.

That part is obvious now.

Developers can ask an agent to:

create a feature
write tests
fix a bug
refactor a module
update documentation
generate SQL
review a pull request
even run commands and modify files

And in many cases, it works surprisingly well.

But something else is happening at the same time.

Developers are writing less of the code, while becoming responsible for more of it.

That is the part I think we are underestimating.

Because when production breaks at 2 AM, nobody is going to ask:

“Which model generated this function?”

They are going to ask:

“Who owns this system?”

And the answer is still us.

The Old Workflow Was Easier to Reason About

A traditional development workflow looked something like this:

Understand requirement
        ↓
Design solution
        ↓
Write code
        ↓
Test it
        ↓
Review it
        ↓
Deploy it
        ↓
Maintain it

The developer touched almost every stage.

That had problems.

It was slower.

It required more manual work.

But there was one big advantage:

The person responsible for the code usually understood how it was created.

Now the workflow is changing.

The New Workflow Looks More Like This

Understand requirement
        ↓
Ask AI to plan
        ↓
AI writes implementation
        ↓
AI writes tests
        ↓
AI fixes errors
        ↓
AI reviews code
        ↓
Developer approves
        ↓
Production

Look carefully at where the human appears.

Sometimes the developer is only deeply involved at the beginning and the end.

That creates a strange new situation.

The developer may be responsible for:

architecture they did not design
code they did not write
tests they did not write
dependencies they did not choose
edge cases they never considered
behavior they only partially understand

Yet the developer still owns the result.

Responsibility Did Not Disappear

This is the mistake I think teams need to avoid.

AI-generated code can make something feel less like your responsibility.

It is easy to think:

“The agent generated it.”

But production systems do not care who typed the code.

If you merge it, approve it, or deploy it, it becomes part of the system you own.

That means you are still responsible for questions like:

Is this secure?
Does it actually meet the requirement?
What happens if the API fails?
Can this corrupt data?
Does it create a race condition?
Is the dependency trustworthy?
Can another developer maintain it?
What happens under load?
What happens six months from now?

AI can help answer these questions.

But it cannot remove your responsibility for them.

“The Tests Pass” Is Not Enough

This becomes especially dangerous when AI writes both the code and the tests.

Imagine this:

Requirement
    ↓
AI misunderstands requirement
    ↓
AI writes implementation
    ↓
AI writes tests for its interpretation
    ↓
All tests pass

Technically:

Green CI.

Practically:

Wrong feature.

This is one of the most important things developers need to remember in AI-assisted development.

Tests can prove that code behaves according to a certain expectation.

They cannot automatically prove that the expectation itself was correct.

If the same model creates both the implementation and the test, they can share the same misunderstanding.

That is why human review still matters at the requirement level.

Developers Are Becoming Supervisors of Software Creation

The developer role is slowly changing from:

Write
Test
Debug

to something closer to:

Define
Constrain
Delegate
Inspect
Verify
Approve
Own

That is not necessarily bad.

In fact, it can be incredibly productive.

But it requires a different skill set.

The best developer may no longer be the person who can type code fastest.

It may be the person who can:

define the problem clearly
design good boundaries
recognize bad architecture
inspect a large diff quickly
detect missing edge cases
understand system behavior
verify assumptions
know when AI is confidently wrong

Those are engineering skills, not typing skills.

The Dangerous Part Is Losing System Understanding

This is where I think the real risk begins.

Suppose an AI agent adds a feature across 15 files.

It modifies:

database schema
service logic
API handlers
validation
background jobs
caching
tests
frontend state

Everything passes.

You review the diff quickly.

You merge.

Then two months later, something breaks.

Now you need to answer:

Why was this implemented this way?

But maybe nobody knows.

The AI session is gone.

The reasoning was never documented.

The developer who approved it only reviewed the output.

This is how teams can slowly build systems that work but are no longer deeply understood.

Code Generation Can Create Understanding Debt

We already talk about technical debt.

But AI introduces something slightly different.

I think of it as:

Understanding Debt

Technical debt is often:

“We know this code is messy, but we shipped it anyway.”

Understanding debt is:

“We own this code, but nobody fully understands why it works this way.”

That can be even more dangerous.

Because messy code is visible.

Missing understanding is harder to detect.

Everything may look fine until something unusual happens.

Small AI Tasks Are Safer Than Huge AI Tasks

One simple way to reduce this problem is to stop giving agents enormous tasks.

Compare these two prompts.

Bad:

Build the full subscription system.

Better:

Analyze the current billing architecture.

Explain which files need to change.

Do not modify code yet.

Then:

Implement only the subscription data model.

Do not change unrelated files.

Then:

Add the billing service using the existing service pattern.

Then:

Add tests for the new behavior.

Smaller tasks create smaller diffs.

Smaller diffs are easier to understand.

And code that is easier to understand is easier to own.

Ask for the Plan Before the Code

One of the most useful changes you can make is simple:

Ask the AI to explain what it plans to do before it changes anything.

For example:

Before writing code:

1. Explain the current architecture.
2. List the files you plan to change.
3. Explain why each change is needed.
4. Identify possible risks.
5. Wait for approval before implementation.

This gives you a chance to catch bad direction early.

Fixing a bad plan is cheap.

Fixing 800 lines generated from a bad plan is not.

Review Decisions, Not Just Syntax

Traditional code review often focuses on lines.

+ const result = await processPayment()

But with AI-generated code, the more important review may be:

Why is payment processing happening here?

That is a different level of review.

Instead of only asking:

Is this line correct?

Ask:

Should this responsibility live in this module?

Instead of:

Does this function compile?

Ask:

Does this architecture make sense?

Instead of:

Does the test pass?

Ask:

Is this testing the right behavior?

AI is making syntax cheaper.

That means developers need to spend more attention on decisions.

Never Merge Code You Cannot Explain

This rule becomes much more important in the AI era.

You do not need to memorize every line.

But you should be able to explain:

what changed
why it changed
what data moves through the system
what can fail
which assumptions exist
which external services are involved
how the feature can be rolled back

If someone asks:

“Why does this work this way?”

and your answer is:

“The AI generated it.”

That is not enough.

Once it is merged, it is your system.

Let AI Generate Less Context Switching, Not More Complexity

AI is extremely good at saving developers from repetitive work.

That is where it can create huge value.

Let it help with:

boilerplate
repetitive tests
simple migrations
documentation
refactoring suggestions
test data
type generation
small bug fixes

But be careful when the AI starts generating:

new architectural layers
new dependencies
large cross-cutting changes
security-sensitive logic
complicated concurrency
data migrations
payment logic

The higher the blast radius, the more human understanding should increase.

Not decrease.

Documentation Matters More Now

If AI made an important design choice, capture the reason.

Not this:

// Process the payment
processPayment();

But something like:

// We process payment before creating the final order because
// failed payments must not create confirmed inventory reservations.

That tells the next developer why the code exists.

Architecture Decision Records can also help for larger choices.

The AI session will disappear.

The reasoning should not disappear with it.

The Developer Still Needs to Know How to Debug

There is another interesting effect here.

The more code AI writes, the more valuable debugging becomes.

Because when generated code fails, someone still needs to understand:

logs
state
timing
network behavior
databases
dependencies
concurrency
deployment
infrastructure

AI may help investigate.

But a developer who does not understand the system will struggle to know whether the AI's explanation is correct.

That is why I think debugging may become an even more important skill in the AI era.

Writing code is becoming easier.

Understanding why a system is broken is not.

A Better AI Development Workflow

Instead of:

Prompt
↓
Generate
↓
Tests pass
↓
Merge

Try this:

Define requirement
        ↓
AI analyzes existing system
        ↓
AI proposes plan
        ↓
Developer reviews plan
        ↓
AI makes small change
        ↓
Developer understands diff
        ↓
Tests run
        ↓
Failure cases reviewed
        ↓
Architecture reviewed
        ↓
Merge

The AI is still doing a lot of work.

But the developer remains connected to the reasoning.

That is the important part.

Five Questions I Ask Before Approving AI-Generated Code

Before merging, ask:

1. Can I explain what changed?

If not, keep reviewing.

2. Does this actually solve the requirement?

Not just the test.

The real requirement.

3. What assumptions did the AI make?

Look for hidden assumptions around data, APIs, users, permissions, and infrastructure.

4. What happens when something fails?

Network timeout?

Database error?

Duplicate request?

Partial write?

Unexpected input?

5. Will another developer understand this later?

Because somebody will eventually maintain it.

Maybe you.

AI Does Not Reduce Ownership

This is probably the most important idea.

AI can reduce:

typing

boilerplate

implementation time

repetitive work

But it does not automatically reduce:

responsibility

risk

ownership

maintenance

production consequences

In fact, AI may increase the amount of software a developer is responsible for.

One engineer may soon oversee the amount of code that previously required several people to produce.

That makes engineering judgment more important, not less.

The Real Developer Skill Is Changing

For years, software development was strongly associated with writing code.

Now code itself is becoming easier to produce.

So the valuable skills move upward.

Understanding the problem.

Choosing the architecture.

Defining constraints.

Recognizing risk.

Reviewing decisions.

Debugging failures.

Protecting maintainability.

Taking ownership.

Those things are much harder to automate completely.

Final Thought

AI may write more and more of our code.

That is probably going to continue.

But there is a dangerous assumption hiding behind that productivity:

If AI writes the code, AI owns the consequences.

It doesn't.

You do.

The future developer may write less code personally.

But they may be responsible for more code, more systems, and more decisions than ever before.

So maybe the most important question in AI-assisted development is no longer:

“Can the AI build this?”

It is:

“If I approve this, do I understand it well enough to own it?”

Because generating code is becoming cheap.

Owning software is not.

How to Keep AI-Generated Code Maintainable After 6 Months

Robert Adamson — Tue, 22 Sep 2026 04:48:18 +0000

AI can help you write code incredibly fast.

That part is no longer surprising.

The harder question is:

Will you still understand that code six months from now?

This is where many AI-assisted projects start to hurt.

The code works today.

Features ship quickly.

Everything feels productive.

Then a few months later:

nobody knows why a function exists
the same logic appears in three places
naming is inconsistent
one change breaks unrelated features
tests are missing
architecture becomes difficult to follow
developers are afraid to refactor anything

The problem is not that AI writes bad code every time.

The problem is that AI is optimized to help you solve the current task.

Maintainability requires you to think about the codebase after hundreds of future tasks.

Here are 10 rules I use to keep AI-generated code maintainable.

1. Never Merge Code You Cannot Explain

This is the most important rule.

If AI generates 200 lines of code and you cannot explain what those 200 lines are doing, the job is not finished.

You do not need to memorize every line.

But you should understand:

what the code does
why it exists
what inputs it expects
what it changes
what could fail
what depends on it

A simple rule:

If you cannot explain the code to another developer, do not merge it yet.

Ask the AI to explain the implementation if necessary.

For example:

Explain this implementation step by step.

Also tell me:

1. What assumptions does it make?
2. What could break?
3. Which parts are unnecessary?
4. Is there a simpler implementation?

AI should help you understand the code, not just generate more of it.

2. Ask for the Smallest Possible Change

One of the easiest ways to destroy maintainability is allowing AI to modify too much at once.

Imagine you ask:

Add user notifications.

An agent might:

create new services
modify database models
change API routes
add helper functions
refactor unrelated files
install another package

The feature may work.

But now reviewing it is much harder.

Instead, break the work into smaller steps.

For example:

Step 1: Create the notification data model only.
Do not modify any other architecture.

Then:

Step 2: Add the notification service using the existing service pattern.

Then:

Step 3: Add the API endpoint.

Small changes are easier to:

understand
review
test
revert
debug

AI can write code quickly.

That does not mean you should let it change everything quickly.

3. Protect Your Existing Architecture

AI does not always understand why your architecture looks the way it does.

It may see:

controllers/
services/
repositories/

and decide to introduce:

managers/
handlers/
processors/
helpers/

Now your project has two architectural styles.

Six months later, nobody knows which one should be used.

Before asking AI to implement something, give it architectural constraints.

Example:

Follow the existing architecture.

Controllers:
- validation and HTTP handling only

Services:
- business logic

Repositories:
- database operations

Do not introduce new architectural layers unless necessary.

This one instruction can prevent a lot of unnecessary complexity.

Your AI should adapt to your codebase.

Your codebase should not constantly adapt to your AI.

4. Make Naming Boring and Consistent

AI often generates perfectly valid names that do not match the rest of the project.

You may end up with:

getUser()
fetchUser()
retrieveUser()
loadUser()
findUser()

All performing similar operations.

Individually, none of these names are wrong.

Together, they create confusion.

Maintainable projects usually have boring, predictable naming.

If your project uses:

createUser
getUser
updateUser
deleteUser

keep using that pattern.

Before generating code, tell the model:

Follow the naming conventions already used in this repository.
Do not introduce new naming patterns.

Consistency is more valuable than creativity in production code.

5. Do Not Let AI Create Helpers for Everything

AI loves abstraction.

Sometimes too much.

You ask for a small feature and suddenly you have:

UserProcessor
UserManager
UserHelper
UserFactory
UserTransformer
UserUtility

for something that could have been 20 lines inside an existing service.

Abstraction is useful when it removes real duplication or complexity.

It is harmful when it simply moves code into more files.

Before accepting a new abstraction, ask:

What problem does this abstraction solve?

If the answer is only:

"It makes the code more reusable."

Ask another question:

Where is it actually being reused?

If nowhere, you probably do not need it yet.

6. Keep Functions Small and Obvious

AI can generate very large functions because it is trying to complete the entire task.

For example:

async function createOrder() {
  // validate customer
  // check inventory
  // calculate discount
  // process payment
  // create order
  // update inventory
  // send email
  // create analytics event
  // notify admin
}

It may work.

But debugging it six months later will be painful.

A better structure might be:

validateOrder()
checkInventory()
calculateTotal()
processPayment()
saveOrder()
sendConfirmation()

Each function has one clear responsibility.

When asking AI to refactor, try:

Refactor this function into smaller functions.

Each function should have one clear responsibility.

Do not create unnecessary abstractions.

Simple code is easier for both humans and AI to work with later.

7. Make Tests Part of the Feature

A common mistake is:

AI writes feature → developer checks UI → merge

That works until the next feature changes the same area.

Then something silently breaks.

Instead, make tests part of the original request.

For example:

Implement this feature and add tests for:

- expected behavior
- invalid input
- edge cases
- failure conditions

Do not treat tests as optional cleanup.

They are documentation for future developers.

Six months later, tests answer a very important question:

What behavior was this code supposed to preserve?

That matters even more when much of the original implementation was generated by AI.

8. Ask AI to Remove Code, Not Only Add It

AI development can create an interesting problem.

Every prompt tends to add more code.

Very few prompts remove anything.

After months of development, you may accumulate:

unused helpers
duplicate functions
old feature flags
abandoned interfaces
unnecessary dependencies
dead components

Periodically ask:

Review this module for:

- duplicate logic
- dead code
- unnecessary abstractions
- unused dependencies
- functions that can be simplified

Do not change behavior.

This is one of the best uses of AI.

Use it not only as a code generator.

Use it as a code cleaner.

9. Document Decisions, Not Obvious Code

AI can generate comments everywhere:

// increment count
count++;

That does not help anyone.

Good documentation explains why something exists.

For example:

// We intentionally retry only once here because the payment
// provider may create duplicate transactions on repeated requests.

That comment is useful.

Six months later, a developer may otherwise "improve" the retry logic and create a serious bug.

Document:

unusual architectural decisions
business rules
important limitations
third-party constraints
performance tradeoffs
security assumptions

Do not document things the code already makes obvious.

10. Review the Codebase Regularly

Maintainability is not something you fix once.

It slowly degrades.

Especially when features are being generated quickly.

Every few weeks, review the codebase and ask:

Where is complexity growing?

Look for:

files becoming too large
repeated logic
circular dependencies
too many dependencies
inconsistent patterns
missing tests
unclear responsibilities
modules everyone is afraid to touch

You can even ask AI:

Review this module as a senior engineer.

Do not rewrite it.

Identify maintainability problems that may become painful in 6–12 months.

Rank them by impact.

Notice the important part:

Do not rewrite it.

First understand the problem.

Then decide what should change.

The Real Problem: AI Makes Bad Architecture Cheap

Before AI, messy architecture took time to create.

Now it can be created in minutes.

That changes the economics of bad code.

You can generate:

five new services
ten interfaces
three abstractions
hundreds of lines of glue code

before you have really decided whether you need them.

This means developers need to become more disciplined, not less.

The bottleneck is no longer:

Can we write this code?

The better question is:

Should this code exist in this form at all?

A Better AI Coding Workflow

Instead of:

Prompt
↓
Generate code
↓
Run it
↓
It works
↓
Merge

Try:

Define requirement
↓
Ask for implementation plan
↓
Review architecture
↓
Generate small change
↓
Understand the diff
↓
Run tests
↓
Review maintainability
↓
Merge

That may look slower.

But it is much faster than debugging a codebase you no longer understand six months later.

My Final Checklist Before Merging AI-Generated Code

Before merging, ask:

Can I explain what this code does?

If not, understand it first.

Does it follow the existing architecture?

If not, ask why.

Is this the smallest reasonable change?

Avoid unnecessary rewrites.

Did it introduce duplicate logic?

Search before adding another helper.

Are the names consistent with the project?

Consistency beats cleverness.

Are failure cases handled?

Happy-path code is not enough.

Are tests included?

Protect the behavior you just added.

Did it add a new dependency?

Make sure you actually need it.

Is there a simpler solution?

Ask this every time.

Will another developer understand this in six months?

That is the real test.

Final Thought

AI makes writing software faster.

But maintainable software has never been mainly about typing speed.

It is about:

clarity

consistency

architecture

testing

good decisions

understanding tradeoffs

AI can generate thousands of lines for you.

But those thousands of lines become your codebase.

And six months later, the AI that generated them may not remember why they were written.

You and your team will still have to maintain them.

So use AI to move faster.

But keep one rule:

Never let your codebase grow faster than your understanding of it.

DEV Community: Robert Adamson

Most AI Agents Stop at the Answer. Xenition.com Is Built to Finish the Workflow

The Answer Is Only the Beginning

AI Agents Should Move From Answers to Actions

This Is Why Connected Tools Matter

This Is the Idea Behind Xenition.com

Directly in chat

Through an agent

Through automation

Agents and Automation Are Not the Same Thing

Agent

Automation

But More Power Creates a New Problem

The Agent Should Propose. The System Should Decide.

Not Every Action Needs Approval

The User Should Know What the Agent Is About to Do

Automations Need Predictability

Automation Also Needs State

Logging Is Not Optional

A Useful Agent Workflow Has Several Layers

Why I’m Building Xenition This Way

The Real Value Starts After the Chat Ends

Final Thought

Your GitHub Actions Workflow Has More Power Than Most Developers Realize

Start With GITHUB_TOKEN

A Test Job Should Not Be Able to Publish Anything

The Most Dangerous Workflow Trigger May Surprise You

The “Pwn Request” Pattern

npm install Is Code Execution

Secrets Change the Risk Completely

Separate Untrusted Code From Privileged Operations

Third-Party Actions Are Dependencies Too

Your Workflow Has a Dependency Tree

Long-Lived Cloud Credentials Are Often Unnecessary

Self-Hosted Runners Change the Threat Model

A Green Build Does Not Mean a Safe Workflow

Audit These 8 Things in Your GitHub Actions Today

1. Token Permissions

2. pull_request_target

3. Secrets

4. Third-Party Actions

5. Publishing

6. Untrusted Input

7. Self-Hosted Runners

8. Build and Deploy Separation

A Safer Mental Model

Final Thought

We Gave AI Agents Real Tools — Then Realized “Just Ask Before Acting” Wasn’t Enough

The Problem Starts With a Simple Workflow

“Important” Is Too Ambiguous

The Model Should Not Decide Its Own Authority

Read, Write, and Destructive Are Not the Same

Read

Write

Destructive / High Impact

Prompts Are Guidance. Policies Are Boundaries.

Why This Matters More as Agents Get Better

Helpful Agents Can Still Cross a Line

Human Approval Should Happen at the Right Moment

Approval Should Explain the Action

The Agent Should Propose, Not Hide

This Became a Real Problem While Building Xenition

Audit Trails Matter Too

Task-Scoped Permissions Are Even Better

Task: Summarize customer feedback

Task: Prepare a campaign draft

Fail Closed

A Simple Model That Works

What is it?

What does it affect?

Is it reversible?

Does it leave the system?

Does it need approval?

Is the result logged?

The Bigger Lesson

Final Thought

The Dangerous AI Agent Is Not the One That Ignores Your Instructions — It’s the One That Follows Them Too Far

The Goal Can Be Correct While the Action Is Wrong

Goal Alignment Is Not Permission Alignment

Prompts Are Not Security Boundaries

Start With `GITHUB_TOKEN`

`npm install` Is Code Execution

2. `pull_request_target`