DEV Community: Eric Vincent Bermudez

The Model Didn’t Get Dumber. My Agent Skills Got Stale.

Eric Vincent Bermudez — Sun, 16 Aug 2026 15:16:30 +0000

When Claude Opus 5 and GPT-5.6 arrived, I expected my coding agents to become noticeably better.

Instead, some of my workflows felt worse.

The agents seemed more eager, less predictable, and occasionally “dumber” than before. Naturally, I blamed the new models.

Very scientific of me.

Maybe it was a skill issue

Then I watched Andrej Karpathy’s interview on the No Priors podcast. One idea stuck with me: when an agent fails, the capability may already exist. The problem could be how we instruct it, what memory we provide, or how we arrange the workflow.

That made me question something I had mostly ignored:

Were my custom skills still compatible with the newer models?

I gave my agent this prompt:

Can you audit our custom skills against the current models? Flag stale prompts, conflicting instructions, outdated assumptions, and anything that should be simplified or removed. Then test each skill on a representative task and propose the smallest updates needed.

The audit found instructions written around the behavior of older models. Some were redundant. Some were no longer necessary. Others pushed the newer models too hard and caused them to overdo tasks.

After cleaning those up and testing the skills again, the results felt noticeably better.

The official guidance supports this

This was not proof that every disappointing result is caused by an outdated prompt. Models can still regress, behave inconsistently, or introduce genuine breaking changes.

But both Anthropic and OpenAI recommend recalibrating instructions during model migrations.

Anthropic’s Claude Opus 5 documentation says the model now verifies its work without being told. It specifically recommends removing verification instructions carried over from earlier models because they can cause over-verification.

OpenAI’s GPT-5.6 guidance recommends removing repeated instructions, simplifying tool descriptions, and running the same evaluations after each change. In OpenAI’s internal coding-agent evaluations, leaner system prompts improved scores by roughly 10–15% while reducing token usage. OpenAI describes those numbers as directional and recommends validating them against your own workload.

Research also shows that prompt performance does not transfer perfectly between models. An ICLR 2024 study found that performance across prompt formats correlated only weakly between the models it evaluated.

In other words, a prompt that helped yesterday’s model may confuse tomorrow’s.

Model updates need skill maintenance

My new model-update checklist is simple:

Run existing skills against representative tasks.
Look for instructions created to work around old model behavior.
Remove duplicated or conflicting rules.
Delete instructions the new model follows naturally.
Change one group of instructions at a time.
Run the same tests again.
Keep only changes that produce a measurable improvement.

This is basically dependency maintenance, except the dependency is natural-language behavior.

The lesson

Custom skills are not permanent documentation.

They are part of the agent system, and that system changes whenever the underlying model changes.

Before concluding that a new model has become worse, audit the instructions surrounding it. You may have upgraded the engine while keeping the old owner’s manual.

Or, in developer terms:

The model might be fine. Your prompts may just have technical debt.

Sources

Disclosure: I used OpenAI Codex to help organize and edit this article. The experience, observations, conclusions, and final review are mine.

How Git Worktrees Improve AI Coding Workflows

Eric Vincent Bermudez — Sat, 08 Aug 2026 12:48:51 +0000

AI coding tools become much more useful when they are given clear boundaries.

One practical way to create those boundaries is with Git worktrees.

A Git branch gives you separate history. A worktree gives you a separate working directory connected to that branch.

Instead of making several AI agents share one workspace, you can give each agent its own isolated environment.

What is a Git worktree?

A worktree lets you check out multiple branches from the same repository at the same time.

For example:

git worktree add ../feature-a -b experiment/feature-a
git worktree add ../feature-b -b experiment/feature-b

You now have two separate directories. Claude Code, OpenAI Codex, or another coding agent can work inside each one without constantly switching branches in your main project.

1. Create different versions of a feature

Sometimes there is no obvious best implementation.

Instead of asking one agent to repeatedly rewrite the same code, create separate worktrees:

Worktree A: simplest implementation
Worktree B: performance-focused implementation
Worktree C: implementation that follows a different UI or architecture

You can then compare the actual code, tests, and tradeoffs before choosing a solution.

The unsuccessful versions can be removed without affecting the selected implementation.

2. Give every subagent its own workspace

Multiple agents editing the same directory can easily overwrite files or mix unrelated changes.

A safer setup is:

project/
project-agent-api/
project-agent-ui/
project-agent-tests/

Each agent receives:

Its own worktree
Its own branch
A clearly defined task
A list of files it is allowed to change
Its own verification requirements

This makes every agent’s output easier to understand and review.

3. Work on independent tickets in parallel

Worktrees are useful when several tasks do not depend on each other.

For example:

One agent fixes an API bug
Another updates a frontend component
Another adds tests or documentation

These tasks can progress at the same time without repeatedly stashing changes or switching branches.

However, parallel work should still be planned carefully. If two tasks modify the same important files, they may need to be handled in sequence.

4. Separate implementation from review

One worktree can be used for implementation while another agent reviews the resulting diff.

The reviewing agent can look for:

Missing requirements
Edge cases
Unnecessary changes
Security or performance concerns
Missing tests

The developer still makes the final decision, but the separate review provides another quality gate before integration.

5. Handle interruptions safely

Imagine an agent is working on a large feature when an urgent bug appears.

Without worktrees, you may need to stash incomplete changes, switch branches, fix the bug, and restore the previous state.

With worktrees, the feature can remain untouched while the urgent fix happens in another directory.

A simple agentic workflow

My general workflow looks like this:

Break the work into independent tasks.
Identify dependencies and possible file collisions.
Create one worktree for each independent task.
Give every agent explicit requirements and boundaries.
Review and test each result.
Integrate only the changes that pass.

Worktrees do not automatically make multiple agents effective. Clear instructions, task boundaries, testing, and human review are still required.

What worktrees provide is isolation.

That isolation creates clearer ownership, fewer accidental collisions, and changes that are easier to compare, accept, reject, or roll back.

Git worktrees can turn AI coding from one long conversation into a more structured engineering workflow.