DEV Community

서나루
서나루

Posted on

Why I Stopped Creating AI Agents by Default

#ai #programming #productivity #opensource

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

or:

npm test
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

A proposed improvement does not automatically become an improvement.

And sometimes:

NO_PROMOTION
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

For Claude Code:

claude plugin marketplace add SeoNaRu/nulnul-harness
claude plugin install nulnul-harness@nulnul-harness
Enter fullscreen mode Exit fullscreen mode

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.
Enter fullscreen mode Exit fullscreen mode

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.
Enter fullscreen mode Exit fullscreen mode

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?

Top comments (0)