Your AI Agent Can Buy Intelligence. It Still Has to Prove the Code Works.

A coding agent can generate a plausible Spring service in minutes. It can also miss an indirect interface usage, run the wrong test configuration, or declare a fix complete without observing the failing value at runtime.

A better model may reduce some mistakes. The team still has to establish what changed, where it can break, and whether the relevant behavior holds.

Model access is becoming a commodity. For software teams, the scarce capability is a repeatable process that checks each generated change against project facts and observed behavior.

Bloisi's argument

In "Intelligence just became abundant. Now own the loop", Prosus CEO Fabricio Bloisi argues that access to a strong model is becoming widely available. In his consumer-platform context, the defensible advantage comes from connecting real customer interactions back into the product, the model, and the next decision.

That is Bloisi's thesis. The interpretation below is ours.

Software teams face a related problem, with different feedback signals. A reorder or an abandoned cart can reveal customer intent. In a Java or Kotlin repository, engineers need to know whether a symbol resolves, which implementations are affected, what an inspection reports, which test configuration reproduces a failure, and what value appears in the debugger. Coverage adds another useful fact: whether a changed branch ran at all.

Calling a model gives the agent no durable control over development. Sessions built on text retrieval and plausible diffs still leave verification to a senior developer. The team defines and controls that verification process.

Generation must be followed by verification

Model quality still matters. Models differ in reasoning, latency, context handling, and cost, so teams can choose one according to the task.

Model access alone is a weak foundation for an engineering workflow. Another agent can connect to the same API. A developer can switch providers, and a new model can raise the baseline within weeks.

The engineering work sits around the model: obtaining reliable project facts, constraining edits, running the relevant code, capturing failures, and using those results to decide what to do next.

After an AI-generated edit, senior and lead developers still have to trace framework conventions, internal libraries, module boundaries, and untested branches before they can approve it. A code snippet cannot tell you how the application behaves in production.

Build an evidence loop

A useful coding loop connects generation to evidence available inside the development environment.

request -> locate symbols -> inspect usages -> make a bounded change -> run inspections -> execute the real configuration -> observe tests and runtime state -> inspect coverage -> human approval -> next request

Each step can expose a bad assumption from an earlier one.

Symbol-aware navigation can reveal a method reached through an interface or framework convention that text search missed. IDE inspections report nullability, resource, or concurrency problems even when the code compiles; the developer decides how to address those findings. Run Configurations preserve the module, SDK, environment, and test target needed to reproduce behavior. The debugger can expose a value that invalidates the agent's hypothesis. Coverage can show that a passing suite never executed the new branch.

Human approval closes the loop. The agent proposes changes and gathers evidence with the tools available in the IDE. The developer decides whether that evidence is sufficient for the risk involved. The team owns this cycle; Explyt supports it inside JetBrains IDEs.

A Java refactor example

Consider a senior developer asking an agent to replace a legacy discount calculation in a multi-module Spring application.

The agent finds DiscountService, rewrites the method, adds a unit test, and reports success. The diff is readable. The new test passes, but the repository can still disagree with the agent's conclusion.

Another implementation of the same interface may be selected by a Spring profile in a different module. A Kotlin caller may rely on the Java method's platform type or on an exception type removed during cleanup. The relevant integration test may require a project Run Configuration with a specific environment. Even a green test task says nothing about a boundary branch that never executed.

Repository text can omit relationships that IntelliJ resolves from the configured project model. A text search for DiscountServiceImpl can find explicit names while missing injection through the DiscountService interface. IntelliJ's reference and implementation indexes can resolve the Java implementation selected through that interface and show Kotlin call sites whose nullability assumptions deserve inspection.

The team can run the refactor through a concrete sequence:

1. Resolve DiscountService as a symbol, then inspect its implementations and usages.
2. Limit the edit to the agreed files while preserving unrelated behavior.
3. Run IDE inspections over the changed code and review their findings.
4. Execute the existing unit and integration Run Configurations for the affected modules.
5. If behavior still fails, inspect the actual call path and values in the debugger.
6. Check whether coverage reaches the changed branches instead of relying on an aggregate green result.
7. Review the diff and the evidence produced by each tool, then record any remaining uncertainty before approval.

These steps inform one another. A test failure directs the next investigation. A debugger observation can overturn the proposed fix. If coverage misses a changed branch, the team has a specific test gap to address. The process collects project-specific evidence for the current change. The model's first answer remains a hypothesis until those checks support it.

The IDE holds the signals

Repository text, retrieval, shell commands, and terminal output all provide useful context. For JVM work, they can miss relationships that the IDE has already resolved.

Suppose a Java method changes from @NotNull String to an unannotated return type. Grep can list textual callers. It cannot by itself explain how IntelliJ will treat that return value at a Kotlin call site, whether the call resolves through an inherited declaration, or which inspection flags the resulting unsafe use. Symbol resolution and inspections answer those questions against the configured project model.

Explyt's position is specific: an AI coding agent working on a complex JVM project should use JetBrains IDE facts as its context and control layer. The model proposes an action. The team checks that action against symbols, inspections, real run targets, debugger state, and coverage where those signals are relevant.

This process is reproducible across tasks and model providers. It does not depend on an automatic accumulation of proprietary project knowledge. Its value comes from running the appropriate checks for each change and keeping the developer in control of the result.

What teams should measure

Generated lines and accepted completions reveal little about verification. During an evaluation, ask what happened along the path from request to approval:

• Did the agent inspect symbol-level impact before editing?
• Did the edit stay within the intended scope?
• Which inspections ran, and what did they report?
• Which Run Configurations and tests executed?
• Did the agent reproduce the reported failure?
• Did a runtime observation change its hypothesis?
• Did coverage reach the modified branches?
• What evidence was available to the human reviewer in the relevant IDE tools or chat?

These questions cannot guarantee correct software. They make the agent's claims falsifiable and give a senior developer concrete grounds to accept the work, redirect it, or reject the proposed change.

Keep the team in control

Bloisi writes about companies closing a loop between customer signals and the next decision. For software development, the useful adaptation is a controlled engineering process that connects a proposed change to evidence from the project.

Models will improve, and generated code will get cheaper. The team shipping the software will remain responsible for correctness. It should decide which checks a change requires, inspect the resulting evidence, and approve the outcome.

Explyt is built to support that process inside JetBrains IDEs. It gives an agent access to IDE-level facts and execution tools while leaving the verification criteria and final decision with the team.

Explore Explyt and evaluate your next AI-assisted change using its code and the verification evidence behind it.