DEV Community: Dechive

AI Agents Need More Than Fact-Checking

Dechive — Sun, 24 May 2026 05:07:08 +0000

When AI starts taking actions, developers need to verify direction, scope, reversibility, and responsibility.

For a long time, verifying AI meant checking the answer.

If an AI generated an explanation, we could read it.
If it summarized a document, we could compare it with the original.
If it gave a wrong fact, we could correct it.
If the answer was incomplete, we could ask again.

That kind of verification is familiar to developers.

It is close to reviewing text.

But AI tools are changing.

They are not only answering questions anymore.

They are starting to act.

They can send emails.
They can book meetings.
They can edit files.
They can run commands.
They can open pull requests.
They can trigger workflows.
They can move from one step to the next without waiting for every instruction.

That changes the problem.

Because an answer can be reviewed.

An action leaves a trace.

Wrong answers and wrong actions are different

A wrong answer is usually annoying.

It may confuse someone.
It may waste time.
It may require correction.

But in many cases, the damage can stop at the text.

A wrong action is different.

An email that has already been sent is in someone else’s inbox.

A meeting that has already been booked has taken space on someone’s calendar.

A file that has already been changed may affect other work.

A command that has already been run may change the environment.

Code that has already been deployed is now running somewhere.

That is why AI agents require a different kind of verification.

Fact-checking is not enough.

When AI starts acting, we need action-checking.

What does it mean for AI to “act”?

When people hear “AI agent,” they often imagine something dramatic.

But the real shift is much more practical.

An email assistant does not only draft a reply.
It may send the reply.

A calendar assistant does not only suggest a time.
It may book the meeting.

A coding assistant does not only suggest code.
It may edit files, run tests, open a PR, or deploy changes.

A research assistant does not only return search results.
It may collect sources, compare options, summarize findings, and move the task forward.

That is the practical meaning of an agent.

It takes a goal, breaks it into steps, uses tools, reads intermediate results, and decides what to do next.

This is useful.

But it also means that the thing we verify is no longer only the final answer.

We need to verify the action path.

The old verification questions are not enough

When we verify AI-generated text, we usually ask:

Is this true?
Is this accurate?
Are the sources real?
Is the explanation complete?
Is the information up to date?

These questions still matter.

But they are not enough when AI takes action.

For actions, developers need a different checklist.

1. Direction: is the action serving the right goal?

An AI-generated email can be grammatically perfect and still be the wrong email to send.

The wording may be polished.
The tone may be professional.
The facts may be correct.

But maybe the timing is wrong.
Maybe the relationship needs a softer response.
Maybe the user did not want to commit yet.
Maybe the message moves the conversation in the wrong direction.

Fact-checking cannot catch that.

The question is not only:

Is this correct?

The question is:

Is this action moving toward the goal I actually want?

For developers, this matters in code too.

An AI agent may “fix” a bug by changing a larger part of the system than expected. The patch may pass tests, but it may not align with the intended design.

So the first action-verification question is:

Is the direction right?

2. Scope: did the agent stay inside the boundary?

Agents interpret instructions.

That is useful, but it also creates risk.

Consider these instructions:

Clean up this folder.

Fix this bug.

Improve this component.

Organize this document.

Each one sounds simple.

But each one has hidden scope.

“Clean up this folder” might mean renaming files.
It might also mean deleting files.

“Fix this bug” might mean changing one function.
It might also mean refactoring surrounding code.

“Improve this component” might mean adjusting UI spacing.
It might also mean rewriting its state logic.

The problem is not always that the AI is broken.

Sometimes it is doing what it thinks the instruction implies.

That means we need to verify scope.

Before letting an agent act, ask:

What is it allowed to touch?
What is it not allowed to touch?
Which files, tools, APIs, or users are out of bounds?
Does the agent need approval before crossing a boundary?

The second action-verification question is:

Did it do only what it should do?

3. Reversibility: how hard is this to undo?

Not all actions have the same weight.

Saving a draft is not the same as sending an email.

Running code locally is not the same as deploying it.

Changing a private note is not the same as changing a shared document.

Deleting a test file is not the same as deleting production data.

When an AI-generated answer is wrong, we can usually edit it.

When an AI action is wrong, we may need to undo a real-world change.

That makes reversibility one of the most important checks.

Before approving an AI action, ask:

Can this be undone?
Is there a backup?
Is there a preview step?
Is this a draft or a final action?
What happens if the agent is wrong?

The third action-verification question is:

Can this action be reversed if needed?

4. Responsibility: who owns the outcome?

AI does not remove responsibility.

If an AI sends an email, someone allowed it to send the email.

If an AI deploys code, someone approved the deployment.

If an AI deletes the wrong file, books the wrong meeting, or changes the wrong setting, the result still belongs somewhere.

This is uncomfortable, but important.

Automation changes how work happens.

It does not make responsibility disappear.

So before giving an agent more autonomy, ask:

Who approves this action?
Who is notified when it happens?
Who reviews the result?
Who is responsible if it goes wrong?
Where is the audit trail?

The fourth action-verification question is:

Who owns the outcome?

A simple action-verification checklist

Before letting an AI agent take action, I want to check four things:

Direction:
Does this action move in the right direction?

Scope:
Does it do only what it should do?

Reversibility:
Can it be undone if needed?

Responsibility:
Who owns the outcome?

This is not a complicated framework.

But it changes how we think about AI tools.

We stop asking only:

Is the answer correct?

And start asking:

Should this action happen?

Example: an AI coding agent

Imagine an AI coding agent receives this instruction:

Fix the issue in the dashboard.

A weak verification process might only check:

Did the app build?
Did the tests pass?
Does the UI look okay?

Those checks are useful, but incomplete.

Action verification asks more:

Direction

Did the agent fix the actual dashboard issue, or did it solve a nearby problem?

Scope

Did it only change dashboard-related files, or did it modify unrelated shared logic?

Reversibility

Can the change be reviewed and reverted easily? Is it in a branch or already deployed?

Responsibility

Who reviews the PR? Who approves the deployment? Who owns the result if something breaks?

This is the difference between checking code output and checking agent behavior.

Convenience moves judgment upstream

It is tempting to think that as AI tools become more convenient, human judgment becomes less important.

I think the opposite happens.

Convenience moves judgment upstream.

When AI handles more steps, humans may not need to make every small decision manually.

But the remaining decisions become more important:

What goal should be given?
How much autonomy is allowed?
Which tools can the agent use?
Where should it stop?
Which actions require approval?
What should never be delegated?

The more an AI system can do, the more carefully we need to define the boundary.

Automation reduces manual effort.

It does not remove judgment.

What should developers delegate?

This is not an argument against AI agents.

Many tasks should be delegated.

Agents are useful when:

the workflow is clear
the task is repetitive
the result is easy to verify
the scope is limited
mistakes are easy to undo
the system has logs or review steps

But we should be careful when:

the action affects other people
the result is difficult to reverse
the instruction is ambiguous
the agent can touch sensitive data
the task depends on personal or business context
the outcome creates responsibility outside the tool

You can delegate work to AI.

But you cannot delegate judgment completely.

Final thought

The first phase of AI verification was mostly about answers.

Can we trust this explanation?
Is this fact correct?
Are these sources real?
Is this summary faithful?

That still matters.

But AI agents push the question further.

Now we also need to ask:

Is the direction right?
Is the scope appropriate?
Is the action reversible?
Is the responsibility clear?

When AI makes answers, we verify facts.

When AI takes actions, we verify consequences.

Because answers can be read.

Actions leave traces.

Originally published on Dechive — an archive for verifying AI-generated answers before we trust them.

https://dechive.dev/en/archive/when-ai-acts-beyond-answers

You Don’t Need to Try Every AI Tool to Keep Up

Dechive — Sat, 23 May 2026 03:50:18 +0000

A practical note on AI tool anxiety, productivity pressure, and choosing better standards.

Every developer feed has started to feel like a speedrun.

Someone built an app with AI over the weekend.
Someone launched a small SaaS.
Someone connected a new model to an agent workflow.
Someone tested the latest coding assistant and already has a thread about it.

Then the quiet question appears:

Am I falling behind?

It does not always feel like failure.

Sometimes it feels like absence.

I am not necessarily doing something wrong.
I am just not doing enough.

Not building enough.
Not testing enough.
Not automating enough.
Not using the newest tools quickly enough.

In the age of AI, that feeling can become exhausting.

But before we accept it as truth, we should ask a better question:

What standard am I using to decide that I am behind?

Two types of AI anxiety

I think AI anxiety often shows up in two forms.

1. Productivity anxiety

This is the feeling that everyone else is producing more with AI.

They are writing faster, coding faster, launching faster, publishing faster, and turning small ideas into visible projects faster than before.

The feed keeps showing a version of:

I built this with AI.

So if I am not building something too, it can feel like I am wasting time.

2. Tool anxiety

This is the feeling that every new model, framework, agent, editor, or workflow needs to be tested immediately.

A new model comes out.
A new AI coding tool gets attention.
A new automation pattern spreads.
A new “best workflow” appears.

Someone has already tried it.
Someone has already compared it.
Someone has already connected it to five other tools.

So the question becomes:

If I am not using all of this, am I falling behind?

Both anxieties feel real.

But both depend on comparison.

Trying a tool is not the same as keeping up

Here is the mistake I keep noticing:

We confuse trying a tool with moving forward.

But these are different things.

Trying a tool quickly is not the same as understanding it.

Understanding a tool is not the same as using it well.

Using a tool well is not the same as building something meaningful with it.

The first person to test a new model is not automatically the person who understands it best.

The person who connects many tools together is not automatically solving a better problem.

The person who launches faster is not always moving in a better direction.

In the AI era, activity can easily disguise itself as progress.

That does not mean we should ignore new tools.

Experimentation matters.
Curiosity matters.
Trying new models can reveal what is changing.

But a tool is not a direction.

A model is not a goal.

A workflow is not a standard.

The feed is not a good standard

The feed is good at showing motion.

It is not always good at showing meaning.

It shows:

Who launched something
Who tried the newest model
Who built a workflow
Who automated a task
Who shipped faster
Who got attention

But it does not always show:

Whether the tool actually solved a real problem
Whether the workflow is maintainable
Whether the output was useful
Whether the project will survive next week
Whether the person building it even needed it

That is why using the feed as a standard is dangerous.

The feed can always move the finish line.

After you try one tool, another one appears.
After you launch one project, someone launches three.
After you automate one workflow, someone shows a better one.

If the standard stays outside of you, no tool will be enough.

A better checklist before trying a new AI tool

Before trying a new AI tool, I want to ask better questions.

Not because tools are bad.

But because attention is limited.

Here is the checklist I want to use.

1. Why do I want to use this?

Is it curiosity?

Is it connected to a real problem?

Or am I only reacting because everyone else seems to be using it?

2. What problem does it solve?

A tool should be connected to a problem.

If I cannot name the problem, I am probably just collecting tools.

3. What would count as a useful result?

Before using the tool, I should know what “better” means.

Does it save time?
Does it improve quality?
Does it reduce friction?
Does it help me understand something?
Does it help me build something I actually care about?

4. What will I stop doing if this works?

This question is important.

If a tool does not change anything about how I work, maybe it is not actually useful yet.

A useful tool should replace, improve, or clarify something.

5. Am I curious, or am I anxious?

Curiosity and anxiety can look similar.

Both can make us test tools.
Both can make us write notes.
Both can make us post screenshots.

But they feel different internally.

Curiosity builds judgment.

Anxiety borrows direction.

A practical example

Instead of saying:

I need to try this new AI coding tool because everyone is talking about it.

I want to say:

I want to test this tool because I spend too much time refactoring repeated UI patterns, and I want to see if it can reduce that friction without lowering code quality.

That second sentence has a standard.

It has a problem.
It has a reason.
It has something to verify.

The goal is not just to use the tool.

The goal is to find out whether the tool helps with a real task.

That difference matters.

Keeping up does not mean using everything

Keeping up with AI does not mean using every new model, framework, agent, or workflow.

It means building the judgment to decide what is worth using.

It means knowing why we are trying something before we mistake the act of trying for progress.

It means knowing what we are building before we confuse output with direction.

AI can make us faster.

But speed only helps when we know what it is serving.

Without an internal standard, every new tool becomes a demand.

Every launch becomes a comparison.

Every post becomes evidence that we are late.

With a standard, a tool can become just a tool again.

Something to test.
Something to use.
Something to ignore.
Something to return to later.

Maybe falling behind in the age of AI is not always about using fewer tools.

Maybe it is often about borrowing too many standards from the feed.

Originally published on Dechive — an archive for verifying AI-generated answers before we trust them.

https://dechive.dev/en/archive/am-i-falling-behind-in-ai-era

Why WHERE phone = NULL Returns Nothing in SQL

Dechive — Sun, 10 May 2026 15:33:56 +0000

If you are new to SQL, this query can look perfectly reasonable at first:

SELECT name
FROM users
WHERE phone = NULL;

You have a users table.

Some users did not enter their phone number.

The phone column looks empty.

So you try to find those rows with phone = NULL.

But the result comes back empty.

The table is not necessarily wrong.
The column name may be correct.
The query may even look logical.

The problem is that NULL is not a normal value.

To understand why this query returns nothing, we need to understand what NULL really means.

NULL is not an empty value

At first, NULL looks like an empty cell.

It feels similar to 0 or an empty string.

But in SQL, these are different things:

0      -> a number
''     -> an empty string
NULL   -> an unknown or unrecorded state

0 is a value.

It means the number zero.

'' is also a value.

It means a string with no characters.

But NULL is different.

NULL does not mean “empty” in the same way.
It means the value is unknown, missing, or not recorded.

That difference looks small, but it affects comparisons, calculations, and aggregate functions.

Why `= NULL` does not work

Look again at the original query:

SELECT name
FROM users
WHERE phone = NULL;

This condition asks:

Is phone equal to NULL?

But NULL means unknown.

SQL cannot say that one unknown value is equal to another unknown value.

Even this expression is not true:

NULL = NULL

The result is not true.

It is unknown.

And WHERE only keeps rows where the condition is true.

So when you write:

WHERE phone = NULL

SQL does not find the rows where phone is NULL.
The comparison itself does not become true.

That is why the correct query is:

SELECT name
FROM users
WHERE phone IS NULL;

And if you want rows where phone has a value:

SELECT name
FROM users
WHERE phone IS NOT NULL;

IS NULL is not just another style of writing = NULL.

It asks a different question:

Is this value in an unknown or unrecorded state?

NULL spreads through calculations

NULL also affects calculations.

If an unknown value is part of a calculation, the result is usually unknown too.

SELECT 100 + NULL;  -- NULL
SELECT NULL * 5;    -- NULL

This makes sense if you think about what NULL means.

If you do not know one part of the calculation, you cannot know the final result.

For example:

SELECT item_id,
       price * quantity AS total
FROM items;

Imagine this table:

item_id	price	quantity	total
1	100	2	200
2	NULL	3	NULL
3	200	NULL	NULL
4	NULL	NULL	NULL

If price is unknown, the total is unknown.

If quantity is unknown, the total is also unknown.

The calculation is not broken.
SQL is preserving the fact that something is unknown.

Sometimes you may want to replace NULL with another value.

For that, SQL provides COALESCE.

SELECT item_id,
       COALESCE(price, 0) * COALESCE(quantity, 0) AS total
FROM items;

COALESCE(price, 0) means:

Use price if it is not NULL.
If price is NULL, use 0 instead.

But this should be done carefully.

Replacing NULL with 0 is not just a technical fix.
It changes the meaning of the data.

There is a difference between:

The value is zero.

and:

We do not know the value.

SQL keeps that difference visible.

Aggregate functions treat NULL differently

There is another place where NULL often surprises beginners.

Aggregate functions usually skip NULL values.

For example, imagine a score column with these values:

80, NULL, 90, NULL, 70

Now look at this query:

SELECT SUM(score),
       AVG(score),
       MAX(score),
       MIN(score)
FROM scores;

SUM(score) returns:

It does not treat NULL as 0.

It skips the unknown values.

AVG(score) returns:

Because it calculates:

(80 + 90 + 70) / 3

It does not divide by all five rows.

That is important.

NULL is not zero.
It is ignored by many aggregate functions.

`COUNT(*)` and `COUNT(column)` are different

The most common mistake is with COUNT.

Look at this query:

SELECT COUNT(*),
       COUNT(score)
FROM scores;

These two expressions do not ask the same question.

COUNT(*) asks:

How many rows are there?

COUNT(score) asks:

How many rows have a known value in the score column?

So if the table has five rows, but only three rows have a score:

COUNT(*)     -> 5
COUNT(score) -> 3

Both answers are correct.

They are just answering different questions.

This matters in real data.

The number of users is not always the same as the number of users with phone numbers.

The number of orders is not always the same as the number of orders with payment dates.

The number of rows is not always the number of known values.

NULL is a record of uncertainty

NULL is not just an empty space.

It is a mark left by uncertainty.

A user did not enter a phone number.
A measurement was not recorded.
A delivery address was not decided yet.
A value was not known when the row was stored.

That is why this does not work:

WHERE phone = NULL

That is why this becomes NULL:

NULL + 1

That is why these two counts are different:

COUNT(*)
COUNT(column)

They all come from the same idea:

Unknown values remain unknown until we decide how to handle them.

Sometimes we replace them.

Sometimes we exclude them.

Sometimes we leave them as they are.

The database is honest about what it does not know.

How we read that uncertainty is up to us.

Originally published at Dechive:
https://dechive.dev/en/archive/what-null-leaves-behind

We Do Not Teach Thinking to AI

Dechive — Sat, 09 May 2026 21:39:00 +0000

Most of us learned to prompt AI by guiding its thinking.

"Think step by step."

"Here's an example of how to solve this."

"First check A, then compare B, finally conclude with C."

These techniques made sense — because we were working with models that needed a path. Without structure, they'd rush to a conclusion.

But reasoning models shift this premise.

Thinking Comes Before the Answer

General conversational models excel at producing natural answers quickly. For tasks where the direction is clear — brief summaries, simple explanations — this is sufficient.

Reasoning models work differently. Rather than pushing problems straight toward conclusions, they're designed to compare conditions, trace possible paths, and hold problems longer before forming answers.

Models like Claude's extended thinking or OpenAI's o-series represent this direction — built to spend more computation on internal reasoning.

A reasoning model isn't one that writes longer answers. It's one built to grapple with harder problems for longer.

When Your Old Methods Get in the Way

With general models, "think step by step" can be helpful. It forces intermediate steps rather than jumping to conclusions.

But with reasoning models, the same approach doesn't always work.

When you strongly specify an arbitrary sequence of thinking to a model already designed to break problems down, you narrow the space for it to find a better path.

The same goes for examples. Good examples show the standard for an answer. But overly detailed examples can lock the model into a specific solution method — even when a superior approach exists.

This isn't about Chain of Thought being wrong. It's about using the same habits when your tool has fundamentally changed.

Specify the Goal, Then Step Back

With reasoning models, sometimes saying less is better.

Rather than mapping out the process in detail, give:

A clear goal
The criteria for a good answer
The output format you need

Then leave the middle steps to the model.

The model doesn't need you to design its thinking process. It needs to know what counts as a good answer.

This is an excerpt. The full piece — including a side-by-side prompt comparison and when reasoning models are the wrong tool entirely — is at Dechive.

Dechive is a quiet library for the AI age — a place to read slowly, think deeply, and ask why.

Why Artificial Intelligence Tells Lies

Dechive — Mon, 13 Apr 2026 00:00:00 +0000

Before a Professional Industrial Hygiene Exam, I asked an AI to solve some past questions. It got the answers wrong. That part was fine. The problem was how perfectly it explained its wrong answers. It cited relevant laws, analyzed each option one by one, and laid out the logic of why its answer was correct. Confidently. Flawlessly.

Suspicious, I told it the correct answer directly. The AI didn't back down. It insisted its choice was right and that the answer I'd given was actually wrong. At the end, I uploaded both the test sheet and answer key as files. Still wrong.

This wasn't a bug.

Not a Lie, But Certainty

It's acceptable that AI produces wrong answers. Every system gets things wrong sometimes.

What's hard to accept is something else: the AI doesn't know it was wrong.

A lie means knowing the truth and hiding it. Hallucination is different. A model may not generate enough signals to itself that the answer is incorrect. It lacks any sense of being wrong. Because of this, wrong information doesn't look wrong. There's logic to it, evidence behind it, a stable tone.

This is what sets hallucination apart from other kinds of errors.

Why Does It Speak Without Knowing?

An LLM doesn't work the way humans understand text. It's closer to a machine that predicts the most plausible token coming next in a given context. The measure of "plausibility" isn't factual accuracy—it's what followed similar patterns in the training data.

When asked "What is the workers' compensation standard for noise-induced hearing loss?", the model generates the most natural text that would follow such a question. If older standards appear more frequently in the training data, it confidently outputs the outdated standard instead of the current one. There's no way for it to know it's wrong.

Even when you provide the correct answer, its stubbornness stems from the same source. The model holds two kinds of knowledge: the billions of parameters inscribed during training, and the information the user provides in this conversation. When these collide, context doesn't always win. Information the model learned strongly tends to override what the user says in the moment.

How can we reduce these hallucinations? And what are the limits that prompts simply cannot overcome?

Continue reading the full article at Dechive →

Dechive is a bilingual digital library for deep thinking about AI, prompt engineering, and technology.