When Anthropic launched Claude Fable 5.1 this month, it centered the announcement around one benchmark result: its Terminal-Bench-Science score.

In this benchmark, a model gets a terminal and a real scientific research problem to solve independently. Fable 5.1 scores 52.6%, and Fable 5 scores 24.7%. By Anthropic’s scoring, the new model more than doubles the old one.

Anthropic’s published score was produced under conditions most users don’t have access to. The benchmark allows each model up to eight hours per task, and Anthropic has not said what harness or budget it used to get its numbers. When the benchmark’s leaderboard tested Fable 5, it ran the model through Claude Code at maximum effort and spent $14,180 across 210 attempts, about $67 each.

Most people don’t use Fable in a lab, so I wanted to know what an average user would get on these tasks. I recently tested Fable 5 and Fable 5.1 on everyday work and found them far closer than the benchmark suggests. That made me want to run the benchmark’s own tasks the way a home user would and see where the models actually differ.

The benchmark’s 70 tasks are public, so I pulled five of them, one from each science field, and ran both models myself. 

The tests

Terminal-Bench-Science has five categories, each with multiple tests. I chose one test per category that could run in a Python environment. Here’s what I picked:

• Symbolic regression (mathematics) – A dataset with 100 variables and a hidden formula behind a yes-or-no label. The model must find a predictor that works on data it has never seen.
• Lorenz-96 assimilation (Earth sciences) – Reconstruct a chaotic atmospheric model from a few uncalibrated sensors with unknown clock offsets. Grading is all-or-nothing on five criteria.
• Reactor safety control (engineering) – Write a controller for a chemical reactor that finishes every batch as fast as possible without ever exceeding the temperature limit, across public and hidden fault scenarios.
• Foraging cognitive model (life sciences) – Predict, trial by trial, which lever each of 20 mice will press, graded on sessions the model never saw.
• Nanoindentation (physical sciences) – Extract material properties from raw indentation curves that include drift, adhesion, defects, and an unknown tip shape.

Each run got a plain terminal, and I set a $12 limit and 60 turns for each test. The full set of ten runs took about 12 hours.

Symbolic regression

This was the only test where a model passed the benchmark’s hidden test. Fable 5.1 worked for 27 turns, found the hidden structure, wrote a predictor, and stopped on its own after 11.8 minutes, 27,088 output tokens, and cost $1.96 to pass this one test.

Fable 5 used all 60 turns over 53.5 minutes, generated 39,461 output tokens, cost $4.20, and failed. I ran Fable 5 a second time to rule out bad luck. It used all 60 turns again, took 60 minutes, generated 60,608 output tokens, cost $6.38, and failed again.

Lorenz-96 assimilation

This was the most expensive pair of runs. Fable 5 hit the $12 cost limit at 45 turns after 97.7 minutes and 92,091 output tokens, ending at $12.63. Fable 5.1 used all 60 turns over 126 minutes, generated 89,789 output tokens, and cost $10.70. On the public leaderboard, Earth sciences is also the field where Fable 5 scores close to zero, and both models failed it here.

Reactor safety control

Neither wrote a controller that passed the grader’s scenarios. This run produced the most output tokens, 157,710 generated by Fable 5.1. It hit the 60-turn limit after 40.9 minutes and cost $11.53. Fable 5 hit the cost limit at 49 turns after 63.8 minutes, 121,978 output tokens, and $12.04. 

Foraging cognitive model

This was the longest run of the testing series. Fable 5.1 was the only model that declared itself finished. It built a model, tested it against its own scoring loop, and declared it done at 43 turns after 53.5 minutes. It created 65,518 output tokens and cost $5.65. But the official grader rejected it. 

Fable 5 never declared anything. It hit the $12 limit at 60 turns, after 139.3 minutes and 62,587 output tokens, ending at $12.13. 

Nanoindentation

Both failed. Both spent most of the run reading raw curves and writing code to segment them. Neither produced a results file the grader accepted. Fable 5.1 ran out of turns at 29.6 minutes, 115,687 output tokens, and $10.91. Fable 5 ran out of money at 48 turns after 34.1 minutes and 114,239 output tokens, ending at $12.59. 

Results

Here are the results by the numbers.

The benchmark scores models on all 70 tasks with three trials each, and Anthropic’s 24.7% and 52.6% come from that full suite. The independent leaderboard puts Fable 5 at 21.4%, close to Anthropic’s figure. Fable 5.1 is not on the independent leaderboard yet, so its 52.6% is Anthropic’s number alone. My results, 0% and 20%, are below both. Five tasks are a small sample. 

Getting these results by chance is plausible even if the published scores are exactly right, so this run neither confirms nor contradicts the doubling claim. The direction matched, since the new model did better. The one task Fable 5.1 solved was in mathematics, which is also the field where the leaderboard shows Fable 5 performing best.

What I think

I don’t think a regular user will see much difference between Fable 5 and Fable 5.1. I only ran a small sample of tests, so I can’t prove or reject Anthropic’s benchmark results. But what I saw suggests that gap won’t reach the average user. The one difference that did show up was on the bill. Fable 5.1 failed faster and cheaper, and it never hit my cost limit, whereas Fable 5 hit it four times.

Suppose your work looks more like the benchmark tasks; the harness and the budget matter as much as the model. With a purpose-built harness, hours per task, and a much bigger budget, you may get closer to Anthropic’s numbers.

The post Fable 5.1 vs. Fable 5: Results on a real-world budget, not the spec sheet appeared first on The New Stack.

While AI code generators help teams ship faster than ever, that speed brings a hidden killer: Comprehension Debt. As soon as an AI produces functionally correct code that violates your domain boundaries, the team loses its mental model of the system. Here, I’ll show how to switch from passive documentation to Executable Architecture using Python-based testing tools like pytest-archon and CI/CD pipelines.

The most dangerous thing an AI coding agent can do is generate code that works.

If a junior developer writes poor code, it breaks the build or staging environment. The team catches it, reverts it, and discusses it. But if an AI coding agent produces 500 lines of functionally correct and bug-free code that subtly violates your system’s boundaries, it merges without issues.

“The most dangerous thing an AI coding agent can do is generate code that works.”

Gradually, the AI connects your billing service to the user authentication component. It gives your presentation layer database access. It wires dependencies in a way that works but violates the design assumptions of human developers who maintain the system. 

Technical debt has given way to something far more pressing — Comprehension Debt: the growing gap between how fast code gets written and how well the human team understands its architecture. The problem isn’t messy logic; it’s a lost mental model. That happens when the team no longer knows why the codebase exists.

If you view AI as a mere machine for faster typing, the architecture has started to degrade. To endure in the era of AI-driven coding, architecture enforcement must shift — from documentation to Executable Architecture.

The illusion of documentation

The accepted guidance for AI-assisted development is: “Make better documentation so the AI understands the rules.”

This is a fallacy. Documentation will become obsolete. If your AI agent finds an easier way to reach its objectives by skipping a service layer, it will take it. And since human reviewers increasingly struggle to review thousands of AI-generated pull requests, these detours slip through code review undetected.

“You cannot depend on human beings to detect architectural drift. You have to trust the CI/CD pipeline.”

You cannot depend on human beings to detect architectural drift. You have to trust the CI/CD pipeline. 

If your architectural boundaries matter, check them the same way you’d check any business requirement. We need fitness functions that fail the build when an AI agent violates a boundary condition.

Introducing executable architecture in Python 

In the Java ecosystem, tools such as ArchUnit have traditionally enforced architectural boundaries. In Python, tools like pytest-archon do the same job.

Consider a concrete example. You’ve built a modular monolith for an e-commerce application and established strict boundaries:

• The Billing domain should never import from the Shipping domain.
• Domain model code should not import from infrastructure (AWS SDK, SQLAlchemy, etc.).

You task the AI agent with adding shipping cost calculations based on the user’s billing tier. Without thinking about the architecture, the AI imports the Shipping Calculator directly into the billing service. Test passes. The application works. But the architecture fails.

Here’s how pytest-archon prevents the agent from doing that.

Step 1: Install the dependency

First, install the architectural testing dependency.

Python
pip install pytest-archon

Step 2: Define the architectural rules as tests

Instead of finding the rules on the Wiki page, we define them as pytest features. We create a test_architecture.py file in the test folder.

Python
from pytest_archon import archrule

def test_billing_is_isolated_from_shipping():
    """
    Ensure the billing module never imports shipping logic.
    This prevents the AI from creating tight coupling between distinct domains.
    """
    (
        archrule("billing_isolation", comment="Billing must not know about shipping")
        .match("ecommerce.billing*")
        .should_not_import("ecommerce.shipping*")
        .check("ecommerce")
    )

def test_domain_models_are_pure():
    """
    Ensure domain models only depend on standard libraries or pydantic.
    Prevents the AI from leaking infrastructure (DBs, APIs) into the core logic.
    """
    (
        archrule("pure_domain", comment="Domain models must not import infrastructure")
        .match("ecommerce.*.models")
        .should_not_import("sqlalchemy*")
        .should_not_import("boto3*")
        .check("ecommerce")
    )

Step 3: Close the agent feedback loop

Then, once the AI agent pushes its pull request, pytest runs automatically as part of the CI workflow. Regardless of how well the AI agent generates code that calculates the Shipping fee, the build will immediately fail with something similar to this:

text
FAILED tests/test_architecture.py::test_billing_is_isolated_from_shipping -
AssertionError: Rule 'billing_isolation' violated:
ecommerce.billing.invoice imports ecommerce.shipping.calculator

A human reviewer doesn’t have to track down the entire import tree manually. Most importantly, the best engineering teams never rely on humans for this.

Once again, we feed the output of these failing pytest tests directly back into the AI agent’s context window using Aider or custom CI/CD scripts, and the AI can fix architectural problems without human help.

Strategies for avoiding Comprehension Debt

Running architectural tests alone is not enough. Here’s how to shield your team from Comprehension Debt:

1. Hard boundaries vs. soft conventions

AI agent obeys hard constraints but not soft suggestions. Get rid of sloppy folder-based architecture and establish clear module boundaries instead. Use tools like import-linter or pytest-archon to block forbidden imports with physical barriers. The path of least resistance must be the most architecturally sound.

2. Limit automated complexity

Well-defined APIs and boundaries are good, but not enough to let you off the hook for messy, complex implementation. If AI creates spaghetti code in your billing module, causing downtime from race conditions at 3 AM, a human engineer will still need to maintain and understand that codebase.

For this purpose, run architectural tests alongside cyclomatic complexity gatekeepers such as Ruff, Radon, or SonarQube as part of your CI pipeline. Set hard limits on complexity to force AI to decompose huge functions into smaller ones.

3. Examine the interfaces, not just the implementation

In code reviews of AI-generated PRs, the developer’s mind is a precious resource. Stop looking at each line, trying to decipher loops and variable assignments. Look at what changes the system from the outside. Instead, are there new dependencies? Did the PR expose new API endpoints? Did it change the data schema? If not, your mental model remains intact.

Conclusion

AI coders are very strong, but they have one big flaw — they are very pragmatic. The maintainability of your code doesn’t interest them — they care only about completing the task you assign them.

“AI coders are very strong, but they have one big flaw. They care only about completing the task you assign them.”

If you try to control your system design by relying on the human factor only, you will drown in Comprehension Debt sooner or later. It’s not a question of slowing down your AI implementation process— it’s a question of making your environment more resistant.

You don’t need to study every line of AI-generated code. You just need to create a cage for this AI.

The post Stop AI code sprawl before it destroys your software design appeared first on The New Stack.

I want you to picture yourself in the early 1900s (in America), real quick. People have been using horses for their entire lives, and they are pros at it. Entire cities are actually built with the premise that horses are how we move from point A to B.

Then this Henry Ford guy shows up and turns the world upside down.

Over the next few years, people had to adapt to cars becoming part of everyday life. Habits built around the transportation they knew had to change.

I think that’s where we are right now. Most of us can see that AI is turning how we work upside down… But, just like in the early 1900s, we have to adapt to it. And it’s painful.

Here’s the thing: most of our habits at work still assume that producing something means you have to understand it. When you send me a PR, I assume you’ve at least read the code yourself, right? Or when you send me a brief, I assume you’ve done your research, etc.

Of course, these assumptions aren’t 100% reliable: engineers are able to copy/paste from Stack Overflow without understanding anything for years. But even in this case, it does take more effort, and reviewers are able to identify the gaps more easily.

AI makes it easy to generate code, explanations, answers to review questions, and entire docs without the author understanding any of it. Everything can look finished. Actually, more often than not, it can even be correct (!) without the author having checked it.

And that is the part that I’ve been struggling with recently, and what most of this post is about… I used to start reviewing work with the assumption that the other person did their homework. Now that may or may not be true, so instead of starting the review with a “is this a good change?” Now I often start with, “does the author understand what they’re sending me?”

All this to say that, at least right now (while we adapt), AI is breaking trust for me. And trust, especially at work, allows you to skip a bunch of steps (and save time!). When I trust a colleague, I can focus on just the parts that need another pair of eyes. I don’t have to repeat their entire investigation to feel comfortable with the output.

Sometimes the phrasing alone (“Yes — and the real unlock is…”) makes me suspicious. Which isn’t necessarily fair. But when I ask a specific question and get another (clearly AI-generated) explanation that doesn’t answer it, I have a reason to worry. The next thing they send me will get more scrutiny, even if they were more careful this time. A shortcut on one task can make working together harder for much longer.

Let me be clear and say that I’ve been that person myself. Yes, I merged an AI-written fix without understanding it. The fix was correct, but I hadn’t done the work to know that.

Maybe part of adapting to these tools is being more explicit about what putting our name on something means? It should mean you understand it and stand behind it. “Claude wrote it” doesn’t tell me what you checked or whether you agree with the result.

If you’re sending an early idea (or a proof of concept) that you want help with, say that! I mean, I can work with uncertainty… but it’s harder for me to work with something that’s not finished, but it’s being presented as such.

And when I ask you a question, I’m asking you a question (I have Claude and ChatGPT too, if I wanted their thoughts, I’d simply ask them). Of course, use whatever tools that might help with the answer, but take the time to decide whether the answer makes sense, or if it’s too long or if there are too many em dashes, before sending it back.

But let’s make this more actionable, with a few suggestions…

If you’re an engineer,

• Read before sending. Review your own diff, read your own doc. Cut the explanation down to what the reviewer needs and nothing else, please! It’s totally fine to spend a bit more time trimming down and editing something so others don’t have to spend their time reading fluff.
• Understand what you’re submitting. Do you really know why the bug happened and why this fix will solve it? If not, go back and understand before asking me to review it.
• Push back when reviewing, too. Asking things like “Which cases did you test?” or “What led you to this recommendation?” are totally fine (and probably even expected!).

If you’re an engineering leader,

• “Ready for review” should mean it’s ready to be reviewed. Ask authors to explain what they checked and what still needs attention. But keep this proportional, because a risk-free change should not require pages and pages of evidence.
• Make it safe to share unfinished work. “I haven’t verified all this yet” is useful information. A proof of concept can deserve feedback just like finished work, provided that everyone knows what they’re reviewing.
• Apply the same standard to yourself. If you’re sending slop, of course your team will send each other slop. Be the role model!

Long story short, that’s the expectation I want us to keep as the tools change. Your name on the work should still mean I can trust you to understand it and stand behind it, especially before sending it to me.

Otherwise, every time you send me something, I have to do your part as well before I can do mine.

One of the biggest problems with AI right now is that it's expensive. If you've been anywhere near an enterprise IT budget in the last 2 years, then you already know that. Most companies that wanted to get AI into their workflows did the same thing: They signed up for a business account with an AI provider, handed out API keys, and started building. It made sense at the time because the models were good, the APIs were simple, and the alternative was standing up your own inference infrastructure, which nobody had bandwidth for. But then the bills started coming in.

Learn how EF Core specifications can shape DTO projections, deliberate includes, tracking behavior, and single or split queries without over-fetching.

No Syncfusion account or product license is required to install or explore Syncfusion Agent Skills.

AI coding agents such as Claude Code, Cursor, GitHub Copilot, and Windsurf can generate application code quickly. They can create components, configure projects, and implement features from a simple description.

But while your AI coding agent knows how to code, does it know your Syncfusion setup?

When working with Syncfusion, the agent also needs product-specific context: which platform the project uses, which packages and components apply, what APIs and configuration are relevant, and where to find current Syncfusion guidance.

Without that context, you may spend time correcting package choices, outdated API suggestions, missing configuration, or implementation based on assumptions.

Syncfusion Onboarding Skill for AI Coding Agent gives your agent that context before it starts coding — beginning with a single prompt.

One prompt to get started

Start by giving your AI coding agent this prompt:

Set up this project for Syncfusion before generating code. Fetch and follow the official instructions at https://ai.syncfusion.com, then report the detected platform, installed skill pack, MCP status, and any required licensing action.

The prompt directs your agent to the official Syncfusion onboarding instructions and gives it a consistent starting point for the project.

From there, the agent:

1. Detects your project platform from its files and structure.
2. Installs the appropriate Syncfusion skill pack for the detected platform.
3. Checks MCP and licensing requirements and identifies any action needed.
4. Reports the setup status, including the detected platform, installed skill pack, MCP status, and licensing action.

Once the setup is complete, you can start asking the agent to build with Syncfusion.

Example: Setting up Syncfusion in a React project

Imagine you’re building a React application and want to add a Syncfusion DataGrid. Before asking your AI coding agent to implement the grid, give it the Syncfusion setup prompt.

The agent first analyzes the project and completes the onboarding. An illustrative result might look like this:

Detected platform: React
Installed skill pack: React
MCP status: Not configured
Licensing action: Reported based on the project's licensing status

The agent can then use the React-specific Syncfusion skill pack when working on the DataGrid instead of relying only on its existing model knowledge.

Now you can give it a development request such as:

Build a React admin portal with a Syncfusion DataGrid that supports CRUD operations, filtering, sorting, paging, and Excel export.

The installed skill pack gives the agent Syncfusion-specific guidance for implementing the requested functionality.

Give the agent Syncfusion context first. Then ask it to build.

Why give your AI agent Syncfusion context?

Start with the right Syncfusion setup

You don’t need to determine the appropriate Syncfusion skill pack every time you start a project.

The onboarding flow examines the project, identifies the platform, and installs the relevant skill pack. This provides a consistent starting point, especially when moving between different Syncfusion technologies or working across multiple projects.

Give the agent product-specific guidance

AI coding agents can rely on pretrained knowledge that may not always reflect the latest product-specific setup or API usage.

Syncfusion Agent Skills provide structured guidance covering relevant components, packages, setup requirements, implementation patterns, and known limitations. This gives the agent more relevant Syncfusion context to work with instead of relying solely on its existing model knowledge.

Generated code should still be reviewed and tested, but giving the agent official product-specific guidance can reduce incorrect assumptions and unnecessary rework.

Surface licensing requirements early

Licensing shouldn’t become an afterthought after development is already underway. The onboarding flow checks whether any licensing action is required and reports it as part of the setup.

You can install and explore Syncfusion Agent Skills without a Syncfusion account, product license, license key, or MCP key. Standard Syncfusion product licensing still applies when Syncfusion components are used in an application.

This separation allows the agent to complete its Syncfusion setup without requiring it to handle product license credentials during Agent Skill installation.

Agent Skills and MCP: What does each one do?

Syncfusion onboarding does not require MCP.

Agent Skills and MCP serve different purposes in the AI development process:

• Agent Skills provide implementation guidance. They help your AI coding agent understand how to work with Syncfusion components, packages, APIs, configuration, and implementation patterns.
• MCP provides access to current documentation. When an MCP server is available and configured, the agent can retrieve current Syncfusion documentation and API information when it needs additional context.

MCP is therefore optional. You can complete the onboarding and use Syncfusion Agent Skills without it, while MCP can provide additional access to current documentation during development.

What Syncfusion knowledge does the agent gain?

The onboarding flow connects your coding agent with the skill pack that matches the detected Syncfusion platform.

Depending on the project, the skill pack can provide guidance about:

• Components and packages relevant to the platform.
• Platform-specific setup.
• Required configuration.
• Implementation patterns.
• Known limitations.
• Relevant Syncfusion documentation.

The onboarding ecosystem spans Syncfusion technologies across web, desktop, mobile, and document development, including React, Angular, Vue, Blazor, ASP.NET Core, .NET MAUI, WinForms, WPF, WinUI, Flutter, and Syncfusion document-processing SDKs.

The exact skill pack installed depends on the platform identified in your project.

A consistent starting point across teams

Development teams don’t always use the same AI coding agent. One developer might use Claude Code, another might prefer Cursor, while someone else works with GitHub Copilot.

Without a shared setup approach, teams may end up maintaining separate instructions for different projects and coding agents.

Syncfusion Onboarding Skill for AI Coding Agent provides a common starting point. Teams can give their supported AI coding agents the same setup prompt and let the onboarding flow determine the relevant Syncfusion configuration for each project.

This creates a more repeatable way to introduce Syncfusion-specific context across projects, regardless of which supported AI coding agent a developer prefers.

Get started in three steps

Getting started is straightforward.

1. Copy the Syncfusion setup prompt

Visit ai.syncfusion.com and copy the onboarding prompt.

2. Paste it into your AI coding agent

Give the prompt to your supported AI coding agent from within your project.

The agent follows the Syncfusion onboarding instructions, detects the project platform, installs the relevant skill pack, checks MCP and licensing status, and reports the result.

3. Start building

Once the setup is complete, describe what you want to build.

For example:

Create a Blazor admin dashboard with a Syncfusion DataGrid, charts, filtering, editing, and Excel export.

Or:

Build a React scheduling application with a Syncfusion Scheduler that supports multiple views, recurring appointments, and drag-and-drop rescheduling.

The agent can then use the installed Syncfusion skill pack while working on your request.

Give your AI agent the right context before it codes

AI coding agents are becoming increasingly capable at generating application code, but the quality of their output also depends on the product-specific context available to them.

Syncfusion Onboarding Skill for AI Coding Agent provides a simple starting point. With one prompt, your agent can identify the project platform, install the relevant Syncfusion skill pack, check setup and licensing requirements, and optionally access current documentation through MCP.

You don’t need to manually determine which Syncfusion instructions your agent needs before every project.

Give your AI agent the Syncfusion context first. Then let it build.

Ready to try it?

Visit ai.syncfusion.com, copy the setup prompt, and make your AI coding agent Syncfusion-ready before it starts generating code.