DEV Community

Cover image for I taught my AI agent a 1970s invention method, then graded it blind
Victor Kononenko
Victor Kononenko

Posted on

I taught my AI agent a 1970s invention method, then graded it blind

Ask an AI agent to fix a trade-off and watch what happens.

"Our inference bill is $42k a month. Finance wants it halved. We tried a
smaller model and wrong answers went from 3% to 9%."

A typical answer: use a mid-size model, add caching, tune your prompts,
consider fine-tuning, monitor quality. All reasonable. None of it is a plan.
It's a compromise and a list, and the agent never says what the actual
conflict is.

I wanted my agents to do better on exactly this kind of problem, so I gave
them TRIZ.

What TRIZ is, in two paragraphs

From the 1940s on, Genrich Altshuller, a Soviet patent examiner, studied
thousands of inventions and noticed that the hard ones share a shape:
improving one thing makes another worse. Lighter but weaker. Faster but
sloppier. He called that a contradiction, and found that inventors kept
solving the same contradictions with the same few tricks, across unrelated
fields.

He boiled it down to 39 engineering parameters, 40 inventive principles
(segmentation, preliminary action, parameter changes...), and a 39x39
contradiction matrix: pick the parameter you want to improve and the one
that gets worse, and the cell lists the principles that resolved that
conflict most often.

Packaging it as an agent skill

An Agent Skill is a folder with a SKILL.md and
whatever data it needs. Claude Code, Claude.ai and other agents load it
when a task matches. The TRIZ skill makes the agent go through six stages:

  1. Intake: restate the problem, the ideal result and the resources you already have.
  2. Contradiction: "improving X worsens Y", mapped to two of the 39 parameters.
  3. Directions: look up the matrix cell and the 40 principles.
  4. Actions: turn the principles into steps that use your resources.
  5. Validation: two Socratic questions before committing.
  6. Plan: a short plan in chat and a full one saved to triz-plans/.

Every plan has three required fields: Resources (what it uses, and
anything new with its cost), Watch for (the top risk, a measurable
signal and what to do) and Done when (a metric, a target and a date).

The matrix and principles are JSON and CSV files with a small Python lookup
script (standard library only). Agents that can't run scripts read the files
directly.

The inference bill, with the skill

Same problem. The agent asks one question ("What can't change?": wrong
answers stay at or below 3%, no new vendor), then names the conflict:

Improving serving cost (23, Loss of substance) worsens answer reliability
(27, Reliability). Physically: the model must be small, to be cheap, and
large, to be right.

The matrix gives #35 Parameter changes and #11 Beforehand cushioning.
"Small and large at the same time" also points to separation on
condition
: large only for the chats that need it. The labelled eval set the
team already had showed that 70% of chats (order status, returns, password
resets) score the same on the small model. So:

  • Route those ticket types to the small model (#35: the model's size changes per request). Bill falls to about $15k.
  • If a small-model answer cites no help-center article, or the customer says it's wrong, re-run it on the large model (#11: a fallback prepared in advance). Adds about 5%.

And the plan ends like this:

Watch for: wrong-answer rate on the small-model route above 4% for a
week, then move that ticket tag back to the large model.
Done when: monthly bill at or below $21k with wrong answers at or
below 3% for 4 weeks in a row, within 8 weeks.

That's the difference I was after: a named conflict, a fix that removes it
instead of splitting it, and a finish line you can check.
(Full example)

Does it actually help? Blind evals

I didn't want to trust my own impression, so I built evals:

  • 13 cases across software, business, engineering and personal problems, three of them in autonomous mode (no human in the loop).
  • 3 runs per case per arm, with and without the skill: 78 conversations. For each run, a fresh agent played both the assistant and a persona user from the case file; the persona only answered what it was asked. The baseline couldn't see the repository.
  • Blind grading: a separate agent saw each pair as A and B in random order, checked them against case-specific items, and said which plan it would act on.
With the skill Without
Grader would act on this plan 38 of 39 1 of 39
Names the root conflict 39 of 39 25 of 39
Dated, measurable target 39 of 39 4 of 39
Risk signal with a threshold 39 of 39 6 of 39
Median user replies 6 1

What surprised me: without the skill, the core idea was often just as
good.
Both arms usually found the same main fix. What the baseline lacked
was everything around it: a target with a date, a signal that tells you it's
failing, owners for the next steps.

And the cost is real: about five more replies from you, because the skill
asks before it commits.

What I got wrong first

The first eval round, one run per arm, lost both engineering cases in
autonomous mode. The skill passed every check, but the grader preferred the
baseline's deeper engineering detail: where the CI minutes actually go,
which tests are slowest. A 400-word cap on autonomous output was cutting
exactly that. I removed it and added a metric breakdown, levers ordered
cheapest first and a verify-before-switch step. In the 3-run eval the skill
won all 9 autonomous comparisons.

The honest caveats

  • The users were simulated, and the same model family played the assistant, the user and the grader. Blind A/B order helps; it doesn't remove that.
  • Some graded items (dated target, risk threshold) are things the skill's template always asks for, so they favour its format. The grader's overall preference is the fairest number.
  • Public copies of the contradiction matrix disagree. I cross-checked three: 1,492 of 1,521 cells agree, the other 29 are flagged as disputed, and the agent shows both values. They haven't been checked against the 1997 book yet.

Try it

Claude Code:

/plugin marketplace add magery-ai/triz-skill
/plugin install triz@triz-skill
Enter fullscreen mode Exit fullscreen mode

Claude.ai: download the zip from the
latest release
and upload it under Settings > Capabilities > Skills. Other agents:
npx skills add magery-ai/triz-skill --skill triz, or copy AGENTS.md
into your project for Cursor, Copilot and others.

Then give it a problem where improving one thing makes another worse.

The repo is MIT licensed:
github.com/magery-ai/triz-skill.
If you try it on a real problem, I'd love to see the plan, good or bad, in
Discussions.

Top comments (0)