Beyond the Prototype: Using AI to Write High-Quality Code

You give a coding agent a task. It produces a pile of code, and the prototype looks finished. What would make that code ready to ship into a larger, established codebase? That gap motivates Sculptor, the experimental coding-agent environment introduced by Josh Albrecht, CTO of Imbue. The version shown in this recording was a research preview, with features still subject to change.

There are many possible places to improve an agent: larger context windows, lower cost, faster responses, or more reliable output parsing. Albrecht recommends concentrating instead on problems specific to the developer’s domain. His expectation was that upstream model and agent improvements would address many generic limitations over roughly three to twenty-four months. That is a forecast about where to invest engineering effort, much like choosing an existing database instead of building one yourself. The durable work is the part that matters specifically to your product and organization.

An agent reports that it added 59 lines. That tells you how much code changed, but little about whether the change is good. You can inspect every line yourself, or merge and hope. Sculptor explores a third option: have another AI system examine the change for concrete problems, such as race conditions or an exposed API key. Generating code and building trust in code are separate jobs. The illustrated Slack extraction change makes the missing evidence visible: a diff summary is not a quality assessment.

The working definition of quality here is defect-oriented: how many problems exist, how long they take to fix, and how many a particular technique catches. That makes the timing of feedback consequential. Sculptor is positioned inside the editing loop, rather than as a pull-request review tool. As soon as an agent generates code—or a developer changes a line—the environment should surface problems while the relevant context is still available. Immediate feedback makes correction easier for both the developer and the agent.

The prevention side of that loop begins with four practices: learn what already exists, plan before implementing, write specifications, and enforce a strict style guide. Each gives the agent a better-defined problem before it starts producing changes.

Before asking an agent to implement something, ask what technologies already solve the problem and how other developers have approached similar work. Sculptor supports questions and research as part of development, so discovering an existing solution can happen before unnecessary reimplementation begins.

The Scrabble solver demonstration then separates deciding what to build from writing it:

1. Give the agent the solver task, with a system prompt requiring a plan and forbidding code generation.
2. Let it produce the plan.
3. Change the system prompt to permit implementation.
4. Extend the workflow with a checking stage after code generation.

The important control is the ability to change the agent’s operating instructions between phases. Albrecht presents editing the system prompt as stronger steering than simply adding a request to the conversation. Customized agents can make the sequence repeatable: plan, implement, then run checks.

Specifications and documentation are expensive when someone must continually keep them synchronized with implementation. But agents need the context those documents provide. They may not have access to the email or Slack conversation where a decision happened; even with access, they may not infer its intended consequences for the code. Writing that intent down makes it available as a development input.

Sculptor tries to reduce the maintenance burden by detecting drift between code, documentation, and docstrings, and helping fix the inconsistencies. It can also flag requirements that conflict with one another. These are different checks: one asks whether implementation matches its description; the other asks whether the description is internally coherent before implementation begins.

A strict style guide supplies another kind of context: constraints on how the team wants software constructed. In the demonstrated suggestion, Sculptor recommends making a class immutable, reflecting Imbue’s preference for functional, immutable code to avoid classes of errors involving shared mutable state. The guidance applies to human teammates as well as agents. An additional style guide tailored specifically to common AI-agent mistakes was still under development.

Prevention will not eliminate mistakes. The next layer combines three detection methods: automated analysis, tests, and LLM checks. The named Python tools include Ruff, mypy, Pylint, and Pyre. Collectively these are linters and static type checkers, with complementary responsibilities. Small diagnostics can create tedious work for developers, but they also give an agent specific issues to fix. Sculptor connects detection to automatic repair so the developer need not handle every minor violation.

An established repository may already contain many diagnostics. Requiring the agent to make the entire repository clean would mix the requested task with unrelated cleanup. Sculptor instead records which issues existed before the agent started and compares them with the issues afterward. The immediate requirement is to avoid introducing new errors. Existing debt does not have to block that improvement.

For example, the comparison can be expressed in Python using normalized diagnostic identities:

from dataclasses import dataclass


@dataclass(frozen=True)
class Diagnostic:
    path: str
    symbol: str
    rule: str


before = {
    Diagnostic("legacy.py", "load_config", "unused-import"),
}
after = {
    Diagnostic("legacy.py", "load_config", "unused-import"),
    Diagnostic("solver.py", "solve", "undefined-name"),
}

introduced = after - before
resolved = before - after

assert introduced == {
    Diagnostic("solver.py", "solve", "undefined-name"),
}
assert resolved == set()

The old legacy.py issue remains, while the new solver.py issue becomes a repair target. A real integration needs diagnostic matching that survives ordinary edits; shifted line numbers alone should not make an old issue appear new.

Test generation changes the economics of preserving behavior. Writing and maintaining tests used to require substantial effort after the implementation was already working. Agents reduce the initial writing cost. For code already assumed correct, Albrecht suggests generating tests, discarding those that fail, and retaining those that pass. That captures accepted behavior; it does not independently establish that the implementation is correct.

The reason to retain those tests becomes stronger when agents can make broad changes quickly. A regression suite expresses behavior you do not want an agent to alter unexpectedly. Albrecht invokes Google’s testing slogan to make the point: behavior that matters deserves a test, because confidence in today’s implementation does not protect it from tomorrow’s edit.

Good tests start with code that is easy and safe to exercise. Put most logic into functional transformations without side effects, and isolate the operations that touch external systems. Albrecht’s cautionary example is a test with access to a live Gmail account: one mistake could delete real email. Separating decision logic from external actions lets an agent explore the logic without exposing the live account to every experiment.

Different tests then serve different purposes:

For functional code, Albrecht proposes generating hundreds or thousands of candidate inputs, running them, and asking an LLM which outputs look abnormal. An abnormal result is a lead to investigate, not proof by itself. Once confirmed as a bug, the input supplies a concrete, reproducible test case.

Cheap generation also changes which unit tests deserve permanent maintenance. A generated suite may encode incidental behavior that the team does not care about preserving. Albrecht suggests considering whether to discard those tests, regenerate them later, or consolidate them into a more maintainable suite. Tests that insist on obsolete behavior can confuse an agent asked to change that behavior. The distinction is between durable regression protection and disposable exploration: preserve the contracts you care about, and deliberately curate the rest.

Integration tests move the focus from individual functions to observable user behavior. A shopping-cart test plan can state that clicking to add an item makes it appear in the cart. The complementary plan says that removing the item makes it disappear. Writing these plans first gives the agent a meaningful behavioral target to translate into tests. The developer can reason about the product interaction instead of specifying every implementation detail of the test.

Passing tests are only one part of the evidence. When Claude Code writes a change, you also need to ask whether enough of that change is tested. In Albrecht’s hypothetical merge decision, 100% test coverage, passing tests, and a review finding the tests reasonable provide more confidence than a line-count summary alone. This is not a measured Sculptor result or a correctness guarantee: coverage records execution, while useful assertions and missing edge cases still need scrutiny.

Finally, make tests easy to run in sandboxes and without secrets wherever possible. Isolation reduces the chance that testing will cause accidental external effects, and helps avoid dependencies that make tests flaky. It also makes the repeated execution needed for agent-driven repairs more practical.

The third detection method is to ask an LLM questions that go beyond conventional diagnostics:

• Change review: Are there issues in the current uncommitted change or elsewhere in the branch?
• Intent: Does the requested task make sense?
• Design constraints: Does the implementation violate the style guide or architecture documents?
• Specification completeness: Are necessary details missing, requirements unimplemented, or behavior insufficiently tested?

These checks compare code with the project’s intended meaning, not just the language’s rules. Sculptor’s extension goal is to let teams add their own checks so codebase-specific practices are examined continually.

Once a problem has been identified precisely, repair becomes easier. Albrecht spends comparatively little time on this stage because, in his experience, coding agents can often fix an issue once they understand what went wrong. A specific defect gives them a concrete target instead of an open-ended instruction to improve the code.

Repeated attempts are one repair strategy; Albrecht even suggests trying a hundred times with a different agent. He provides no measured success rate for that suggestion. The enabling mechanism is sandboxing: safely isolated agents can attempt repairs in parallel, subject to cost constraints, and a successful candidate can supply the solution. That makes clear failure detection valuable twice—first for identifying the problem, then for judging whether an attempted fix resolves it.

The same approach can extend past implementation and deployment. Debugging, logging, tracing, and profiling offer further places for specialized tools to help. Automated QA agents can navigate a website and check whether a user can complete an intended task. Other tools can generate code from visual designs, while better contextual search can serve both developers and their agents.

Better base models are part of this picture, alongside integrations between specialized developer tools. Albrecht closes by inviting builders of those adjacent capabilities to integrate with Sculptor, anticipating that more of them would become accessible over the following year or two. The proposed development environment connects those capabilities across the workflow: discovering what to build, checking what changed, repairing failures, and examining how the software behaves after deployment.