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

Victor Kononenko — Thu, 22 Oct 2026 17:53:11 +0000

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:

Intake: restate the problem, the ideal result and the resources you already have.
Contradiction: "improving X worsens Y", mapped to two of the 39 parameters.
Directions: look up the matrix cell and the 40 principles.
Actions: turn the principles into steps that use your resources.
Validation: two Socratic questions before committing.
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

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.

Forge can now hand your audit straight to a coding agent — and share the report with a link

Victor Kononenko — Tue, 20 Oct 2026 12:05:40 +0000

Forge is a security-audit tool I built for people who ship code with AI agents and don't have a security team. Two releases this week closed the loop between finding a problem and fixing it. Here's what changed.

0.30 — Copy an audit's findings as a prompt.

The core audit UI now has a "Copy as prompt" button. It takes every failed check, pairs each finding with its fix, and turns the whole thing into a single ready-made prompt. Paste it into Claude Code, Codex, or any agent that works on your codebase, and it can start fixing the issues directly.

Two things matter here. Checks that already passed are left out, so the prompt is only the work that's actually left. And the prompt is generated in English regardless of what language you read the site in — because that's the language coding agents follow most reliably.

0.31 — Share an audit report with a link.

You can now open an audit and press "Copy link" to get a URL anyone can open without signing in. They see that one report and nothing else of yours. The link lives for 24 hours — and copying it again within that window extends the same link another 24 hours.

The bigger win: "Copy as prompt" now includes that link too. So when you hand the prompt to an agent, the agent can also read the full report behind it, not just the compressed list of fixes.

Why this matters for VibeCoders.

The old flow for a solo dev or VibeCoder was: find a scanner, get raw output you can't read, figure out what's real, fix it by hand. Forge now collapses that into: run an audit, copy the prompt, let your agent fix it, and share the report link with someone who needs to see it. No codebase access required — Forge works as a black box and simulates a real attacker, so you never hand the tool your source.

Both features are live now and free while Forge is in beta. Would love feedback from anyone shipping fast without a security team.

Magery Forge — security audits for shipped code (built for VibeCoders)

Victor Kononenko — Mon, 21 Sep 2026 12:23:15 +0000

I ship fast with AI agents and I don't have a security team — so every time I deployed, I had no idea if I'd just pushed a hole to real users.

Raw scanner output ("Missing Strict-Transport-Security header") means nothing to me. So I built Forge to turn that noise into plain-English risks with a fix for each, delivered as a weekly report to my inbox.

Key things:

• Add a domain, run a check, read results in plain English — no security background needed.
• Every finding ships with a concrete fix, not just a red flag.
• Passive checks (DNS, SSL/TLS, headers, SEO) run instantly; active checks (crawling, forms, secret leaks) unlock after domain verification.
• Exposed over MCP, so my agent (Cursor, Copilot, Claude, OpenClaw) runs the audit and reads the report — I barely open the UI.

Free while in beta. Built in public — honest feedback welcome: what's the first thing you'd want a tool like this to catch?

DEV Community: Victor Kononenko