Platform · Coding

Coding agents

Batch TCAD and FEA campaigns still run on hand-written driver scripts that break the moment a mesh, material or solver flag changes. Coding agents write those drivers, run them, read the trace and repair themselves until an acceptance test passes.

01The problem

A production TCAD or FEA flow is glued together by brittle driver code, one solver dialect at a time. Synopsys Sentaurus, for example, scripts its Structure Editor in a LISP-like Scheme and reaches Python only through its calibration and API tooling, while COMSOL is driven headless through a Java API or MATLAB LiveLink. A single changed parameter can silently break a batch run and cost an engineer a day of tracing logs by hand.

SELF-REPAIR write, run, read the trace, repair until the test passestest passes: commit verified driverAcceptance test+ task specwhat it must doAgent writesdriverSentaurus SchemeCOMSOL Java / LiveLinkHeadless runbatch solverTrace + outputexit codesolver resultInspect + repairread tracepatch driveruntil the test passes
The self-repair loop around a headless solver. How a coding agent drives a batch solver such as Sentaurus or COMSOL as an example of the field: it writes the driver, runs it headless, reads the trace and repairs until the acceptance test passes.

02How we solve it

Write the driver, run it, repair it.

Agentriq treats every solver driver as code under test: the agent generates it, executes it in a sandbox, and self-repairs against a written acceptance test instead of a human reading logs.

60708090100012345dynamic-analysis gainmost text-only gain by round 2Repair roundPass rate (%)debugger-in-the-looptext-only self-repair
Where the fixes come from. Execution feedback recovers most failures within the first two rounds; adding debugger-driven dynamic analysis lifts the ceiling further, as reported across public code-repair benchmarks.

Test-driven generation with execution feedback

The agent writes the driver together with an executable acceptance test, runs it, and feeds the captured error and stack trace back in to revise the code.

Iterative self-repair and self-debugging

Failures are looped back for successive revisions; across HumanEval and MBPP this recovers a large share of first-try failures, with most of the gain landing in the first two rounds.

Debugger-in-the-loop dynamic analysis

The agent drives a live PDB or GDB session to set breakpoints and inspect runtime state, turning blind retry into systematic root-cause diagnosis.

Multi-agent repair roles

Analyzer, optimizer and coach agents split failure triage, patch synthesis and policy learning so recurring errors get fixed once rather than re-hit every run.

03What it produces

Fewer tries to a passing run.

0204060fix efficiency1.7x to 2.2x better55+5%58BigCodeBench-R30+60%48LiveCodeBench-RRepair accuracy (%)relative gain over baseline: +5% to +60%text-only baselinedebugger-in-the-loop
Debugger-guided repair beats blind retry. On public code-repair benchmarks, driving a live debugger to inspect runtime state raises repair accuracy and cuts the number of fix attempts versus text-only feedback.

It produces a version-controlled solver driver that passes its written acceptance test, generated and repaired automatically; in published debugger-in-the-loop systems this dynamic-analysis step lifts repair accuracy by up to 60% relative and fixes bugs 1.7x to 2.2x more efficiently than text-only retry.

04The agentic loop

A closed loop, spec to commit.

Agentriq wraps generation, sandboxed execution, debugger-driven root-cause analysis and a judge into one closed loop, so each driver arrives verified, traced and committed rather than hand-tuned.

EVERY RESULT becomes a decisionDriver+ acceptance testVerifyre-check, convergeRoot-cause+ Agentic RAGJudgeAcceptIterateEscalateoutcome + evidence written back to structured memory
From work to a verified decision. The same closed agent loop every Agentriq task runs: generate, verify, root-cause, judge, write back.
  1. 01Generate the solver driver and its acceptance test from the task, then execute it headless in a sandbox, capturing stdout, exit code and solver output.
  2. 02Verify the output against the acceptance test with pytest assertions on the solver result.
  3. 03On failure, root-cause via debugger-in-the-loop dynamic analysis plus Agentic RAG over solver API docs and prior fixes.
  4. 04A judge scores the repaired driver, checking for regressions and behavioral divergence before it is accepted.
  5. 05Write the verified driver, its trace and the decision back to Git as the recorded outcome.

05Tooling

Simulation, solvers & frameworks.

  • Python
  • PDB / GDB debuggers
  • pytest
  • COMSOL Java API / MATLAB LiveLink
  • Sentaurus Structure Editor (Scheme)
  • Execution sandboxes
  • Git
  • SWE-bench / LiveCodeBench

Get started

From engineering problems to autonomous solutions.