Why I Stopped Creating AI Agents by Default

서나루 — Thu, 20 Aug 2026 03:57:35 +0000

Why I Stopped Creating AI Agents by Default

AI coding tools are getting incredibly capable.

But while using Codex and Claude Code on longer projects, I started running into a strange problem:

the AI development environment itself was becoming another project to maintain.

I would start with a simple repository.

Then gradually add:

AGENTS.md
CLAUDE.md
custom skills
specialized agents
memory files
workflow rules
validation instructions
session checkpoints
more tools to manage all of the above

Every addition made sense individually.

But eventually I was spending too much time managing the system that was supposed to save me time.

That led me to a different question:

What if the default wasn't “add another agent”?

What if the default was:

Do nothing until the project proves something is missing?

That idea became NULNUL.

GitHub:
https://github.com/SeoNaRu/nulnul-harness

Start with the repository, not the agent architecture

A lot of agentic coding setups begin by defining the system first.

You decide:

which agents exist
which skills they need
what roles they have
how they communicate
what memory they keep
which tools they can use

And then the actual project gets inserted into that structure.

I wanted to reverse that relationship.

NULNUL starts with the repository.

read the repository
        ↓
reuse what already works
        ↓
find what's actually missing
        ↓
add the smallest necessary mechanism
        ↓
do the requested work
        ↓
run the real repository checks

If the repository already contains sufficient instructions, tools and tests, NULNUL should reuse them.

It should not create another abstraction simply because it can.

Sometimes the correct result is:

0 new agents
0 new skills
0 new infrastructure

That became one of the most important design principles of the project.

“The agent said it's done” is not a completion condition

Another problem I repeatedly encountered was completion.

A coding agent can confidently say:

Done. Everything is working.

But confidence isn't evidence.

For me, completion needed to mean something executable.

For example:

python3 -m unittest discover -s tests -p 'test_*.py' -v

or:

npm test

or whatever the actual repository defines as its completion check.

So NULNUL treats the repository's executable checks as the source of truth.

The answer isn't complete because the agent believes it is complete.

It's complete when the expected behavior can actually be verified.

Long sessions create another problem: context

Long-running coding projects often span multiple sessions.

The naive solution is to preserve more context.

More transcripts.

More memory.

More summaries.

But eventually that becomes another growing source of complexity.

NULNUL instead tries to leave a small verified checkpoint in the repository.

The next session can resume from that verified state rather than reconstructing the project from the entire conversation history.

And if the underlying files changed after that checkpoint was created, the old verification should no longer be trusted.

That sounds obvious, but it changes how I think about agent memory.

The repository should remember the important state, not the conversation.

What about self-improving agents?

This became the most interesting part of the project.

Suppose the same failure happens repeatedly.

It may indicate that the current harness itself is missing something.

The tempting approach is:

failure
↓
agent modifies its own workflow
↓
new workflow becomes the default

But there's an obvious problem.

The system proposing an improvement is also judging whether its own improvement is good.

So NULNUL separates those responsibilities.

reproduced failure
        ↓
improvement candidate
        ↓
current approach vs candidate
        ↓
independent verification
      ↙              ↘
   reject           accept
                       ↓
                 observe usage
                  ↙        ↘
               keep       rollback

A proposed improvement does not automatically become an improvement.

And sometimes:

NO_PROMOTION

is the correct result.

Nothing changed because nothing proved it was better.

I think that's an important property for systems that can modify their own development environment.

Growth shouldn't be append-only

Another design decision followed naturally.

If the project changes, the harness may need to grow.

But growth shouldn't always mean adding things.

A responsibility may disappear.

Two roles may become redundant.

A workflow may no longer need its own agent.

So the harness should be able to:

add
merge
reuse
remove

rather than continuously accumulating configuration.

The goal isn't to build the most sophisticated agent system.

The goal is to keep the smallest system that reliably supports the project.

Codex and Claude Code

NULNUL currently works as a repository-local, skills-oriented harness for both Codex and Claude Code.

For Codex:

codex plugin marketplace add SeoNaRu/nulnul-harness --ref main
codex plugin add nulnul-harness@nulnul-harness

For Claude Code:

claude plugin marketplace add SeoNaRu/nulnul-harness
claude plugin install nulnul-harness@nulnul-harness

Then the initial request can be as simple as:

Set up the harness for this repository.
Reuse what already works and add only what is missing.

But explicit setup isn't even necessary.

You can simply ask for the actual work:

Fix the booking API and verify that the existing behavior still passes.

The harness exists to support the work.

The work shouldn't exist to justify the harness.

The idea I'm experimenting with

NULNUL is still evolving, but the core idea has become pretty simple:

Let the project determine the agent architecture instead of letting the agent architecture determine the project.

Inspect first.

Reuse first.

Add only when necessary.

Verify everything that matters.

And don't assume that more agents, more memory or more automation automatically means a better development environment.

Sometimes the best infrastructure is the infrastructure you never needed to create.

NULNUL is open source and MIT licensed:

https://github.com/SeoNaRu/nulnul-harness

I'd be especially interested in hearing how other developers handle this problem.

Do your AI coding setups tend to get simpler over time — or do they just keep growing?

DEV Community: 서나루

Why I Stopped Creating AI Agents by Default

Why I Stopped Creating AI Agents by Default

Start with the repository, not the agent architecture

“The agent said it's done” is not a completion condition

Long sessions create another problem: context

What about self-improving agents?

Growth shouldn't be append-only

Codex and Claude Code

The idea I'm experimenting with