Gemini 4 Carbon in programming: bug-fixing test, agentic development, and task costs

Gemini 4 Carbon is designed for complex software development, multi-stage debugging, and agentic workflows. It is particularly useful for tasks where code generation alone is not enough: the agent needs to examine the repository, change several components, run the project, find a bug, and check the result again.

Bottom line: Carbon shows strong results in refactoring, finding the causes of failures, and testing web applications. It does not eliminate developer review.

What tasks were tested in practical trials

The trials covered more than just writing individual functions. Developers asked Gemini 4 Carbon to work with several software components at once, migrate a project between libraries, investigate a chain of dependencies, and rework large sections of code. They also tested whether the model could run a web application, fix errors after a build, and compare the source code with what appears in the browser.

This scenario differs from an ordinary chatbot conversation. The model gets access to tools, a repository, and a test environment, then works in iterations: it makes a plan, applies changes, runs a command, analyzes the log, and continues after finding a failure. The result depends not only on Carbon's reasoning, but also on the available tools, environment isolation, test quality, and precision of the original task.

HubX result: 94% of bugs fixed with no new failures

In the HubX trial, Gemini 4 Carbon fixed 94% of 16 real bugs in a project that already had 14 000 automated tests. The experiment description says that no new failures appeared after the changes were made. For this kind of task, the proposed patch is not the only thing that matters: the model must keep the rest of the system working.

The figure of 94% does not mean that Carbon fixes 94% of bugs in every project. The sample consisted of 16 defects, and the conditions of code access, test structure, and nature of the bugs influence the outcome at least as much as the model itself. This figure should be treated as the result of a specific HubX trial, not as a universal probability of successful repair.

Why does the no-new-failures measure matter? Fixing a defect often affects shared code, module interfaces, or exception handling. A local patch removes the original bug but can also break another scenario if the team checks only one test. A large suite of automated tests reduces this risk, but does not replace requirements analysis, data validation, and manual review of the changes.

What the OpenCode experiment showed

In the OpenCode team's experiment, Carbon processed a list of requirements overnight, created a user interface library, rewrote a desktop application to use an existing component system, and prepared a working demo. The account of the experience shows the model's strength: it keeps several related tasks in context and moves between architecture, code, and checking the result.

An overnight cycle does not, by itself, prove that a product is ready for release. A demo may show a successful scenario, while a production system has additional requirements for data migrations, backward compatibility, logging, performance, resilience, and security. The completion time also cannot be applied to other projects without qualification: duration depends on repository size, environment speed, number of iterations, and number of connected tools.

Working with multiple components, libraries, and interfaces

Developers who tested Carbon considered its progress compared with Gemini 4 Argon. Some participants also noted a different problem-solving style compared with Claude and GPT. These are subjective observations by practitioners, not a formal universal measure, but they help explain the model's character: Carbon is geared toward a long chain of actions that involves examining a system, changing several subsystems, and checking the consequences.

Migrating a project between libraries is especially revealing with legacy code. The agent must map old interfaces to new ones, find incompatible types, preserve the application's behavior, and update tests. If the model sees only an individual file, it cannot reliably assess the architectural consequences. Carbon shows its advantages in an environment where it can access the project tree, dependency documentation, build commands, and automated check results.

In web development, the model analyzes two layers of the result: the implementation and the page's appearance. This approach helps find discrepancies between the design and the actual interface, check responsiveness, and detect errors that are not visible in the source code. Visual assessment is still less formal than an API test or type check, and developers separately noted that Carbon sometimes needs more detailed requirements to produce a good design.

Cost comparison with Claude Fable 5.2

In a direct comparison with Claude Fable 5.2, the two models produced similar results, but completing tasks with Carbon, according to the cited estimate, cost almost two-thirds less. Materials on the CursorBench 4.0, Perplexity WANDR, and Zapier AutomationBench benchmarks also claim that Carbon ranked first and had more than a twofold cost advantage per task over the next external model.

Compare the cost of a completed task, not just the price of one token. An expensive model may need fewer attempts, find the cause of a failure faster, and reduce manual review. A cheaper model, by contrast, may generate more intermediate fixes and increase costs for running tests, maintaining environments, and engineering time. The overall economics depend on context length, number of iterations, reasoning mode, and the autonomy limit that is set.

Which tasks still require developer oversight

A person should approve architectural changes, check the agent's access permissions, and review the final diff. Migrations, authorization, payments, personal data processing, cryptography, and code that interacts with external systems require special attention. Automated tests show that known scenarios have not broken, but do not prove that there are no logical vulnerabilities or errors in the requirements.

What if the build log shows a green status but the application still behaves incorrectly? This happens when tests do not cover a user scenario, a visual defect, or a rare sequence of actions. Developers check not only that tests pass, but also that the product meets business rules, security constraints, and user expectations.

• Separate permissions for reading, modifying files, running commands, and publishing results.
• Run the agent in an isolated environment with a backup of the repository.
• Ask the model to describe the cause of the error, the files changed, and the checks it passed.
• Keep command logs, dependency versions, and test results.
• Review the code and conduct a separate security check before merging changes.

Final assessment of Gemini 4 Carbon for development

Based on the trials described, Gemini 4 Carbon is suitable for complex refactoring, debugging across multiple files, migrating between libraries, and agentic web application development. The HubX result shows that the model can work with real defects when a large test suite is available, while the OpenCode experiment demonstrates its ability to handle a long process, from requirements to a working demo.

Carbon's main advantage lies not in an individual piece of code, but in the cycle of “investigate, change, run, check.” For teams, this may lower the cost of some engineering tasks, especially if the model has good tools and limited permissions. The developer makes the final decision and remains responsible for architecture, security, compatibility, and product release.

Frequently asked questions

Can Carbon be asked to fix a project without manual review?

No. Even the successful HubX test applies to a specific sample and environment. Changes need to be reviewed, independent checks run, and compliance with requirements assessed.

Is the model suitable for completely rewriting an application?

Carbon can help with major rewrites and project migrations, but it is safer to divide the work into stages with fixed checkpoints, tests, and the ability to roll back.

Why is the cost of a task more important than the price of a token?

The total cost includes repeated requests, output tokens, running tools, and engineering time spent fixing unsuccessful iterations. Comparing a single API rate gives an incomplete picture.