Coding agents need immediate checks that identify defects while code is being written, rather than relying on a late pull request review.
2
Planning, project documentation, strict style rules, linting, tests, and LLM-based checks can reduce defects in AI-generated code.
3
Good sandboxing lets teams run many agent attempts safely, while functional code and meaningful integration tests make failures easier to detect and fix.
Summary
Josh Albrecht describes Imbue's Sculptor as an experimental coding-agent environment for closing the gap between generated prototypes and software that can be shipped. He defines high-quality code through the problems it avoids, then argues that those problems should be found immediately after a change, when both the developer and the agent can still fix them. Sculptor supports research, forced planning workflows, maintained specifications, strict style guidance, linting, generated tests, sandboxed execution, and configurable LLM checks. Albrecht is especially direct about testing. AI makes it cheap to generate many unhappy-path tests, but teams should decide which generated tests are worth keeping. He also recommends functional code, meaningful integration tests, and coverage information. Once a problem is clearly described, repeated agent attempts can often fix it, provided execution is isolated from secrets and dangerous side effects. Sculptor remains a research preview, so its features may change.
Coding agents need a third option between reviewing every line and blindly merging
Albrecht starts from the familiar experience of vibe coding. An agent returns a diff, perhaps with 59 new lines, and the developer must either inspect every line or merge while hoping for the best. Sculptor adds another option: an AI system examines the change for defects such as race conditions or exposed API keys. Albrecht connects this idea to a practical definition of software quality. Quality depends on identifying defects, fixing them, and preventing them from reaching production. The review should happen synchronously, immediately after a line or block changes, because the problem is easier for both the developer and the agent to understand at that point.
Teams should build around their specific software problem instead of rebuilding general infrastructure
Albrecht says coding-tool builders could spend their time improving large context windows, lowering cost, speeding up systems, or parsing model output. He expects models and general coding agents to improve those areas over the next 3 to 24 months. His advice is to focus on the part of the problem that matters to a particular business or domain, in the same way that a company would normally use a database rather than build one. For Imbue, that specific problem is helping people decide whether an agent-generated diff is safe and correct. Sculptor is built around finding problems in code and giving developers more information before they merge.
A reliable agent workflow starts with research, a forced plan, project documents, and strict style rules
Albrecht presents four ways to prevent mistakes before code is written. Sculptor can research technologies and similar solutions so an agent does not repeat existing work. A workflow can force the agent to write a plan before it writes code, then switch its system prompt and let it implement the plan. Project specifications and documentation give the agent context that it cannot reliably obtain from email or Slack. Sculptor can detect outdated code and documentation, and it can find conflicting specifications. A strict style guide also constrains the agent. Imbue encourages functional, immutable code because that can prevent some race conditions, and it is developing guidance tailored to common AI mistakes.
Linting is more practical when the agent fixes small errors and preserves the baseline
Albrecht mentions tools such as Ruff and Pylint for detecting classes of errors automatically. Human developers often avoid keeping linting clean because small corrections create churn and extra work. Coding agents are well suited to making those repetitive fixes. Sculptor tracks which lint errors existed before the agent started and which remain afterward. That distinction matters in an imperfect codebase. It prevents an agent from quietly adding more errors even when the project does not begin with zero lint failures. The system therefore treats linting as a source of immediate feedback and an automated repair task, rather than as a gate that developers must manually maintain in perfect condition.
AI-generated tests make broad unhappy-path testing cheap enough to use routinely
Albrecht says he avoided tests for years because they took effort to write and maintain, even when the code already appeared to work. AI changes that tradeoff. An agent can generate many tests, discard the ones that fail when the implementation is correct, and keep the passing cases. Functional code with few side effects makes this process safer and easier to interpret. Albrecht separates happy-path tests, which need only a small number of examples, from unhappy-path tests, which help find bugs. An LLM can generate hundreds or thousands of possible inputs, inspect the results, and identify behavior that looks strange. That strange case can become a regression test.
Generated tests should be treated as disposable evidence when their behavior is not important
Albrecht challenges the assumption that every unit test should remain forever. If an LLM can regenerate a suite from scratch, teams may choose to discard tests for behavior they do not care about. Keeping too many generated tests can confuse the LLM when the intended behavior changes. Some tests can instead be refactored into maintainable cases, while others can be removed. He does not present deletion as a universal rule. The point is to reconsider the cost of preserving tests now that generation is easy, and to distinguish tests that protect meaningful behavior from tests that merely record an old implementation detail.
Meaningful integration tests and coverage data tell developers whether a change works for users
Albrecht recommends focusing on integration tests that describe user-visible behavior. A test plan might state that clicking an add-to-cart button puts an item in the cart, followed by a plan for removing it. Agents can often turn these statements into working tests, allowing developers to write tests at the level of meaning. Coverage then answers a separate question: whether enough of the system is tested. A passing test suite alone is not enough. Albrecht imagines a diff accompanied by full coverage, passing tests, and an assessment that the tests are reasonable. Sculptor also runs tests in sandboxes without secrets where possible, reducing the risk of destructive side effects and flaky tests.
Clear error descriptions and safe parallel execution make repeated repair attempts useful
Albrecht spends less time on repair because agents are often better at fixing a well-described problem than developers expect. He uses the idea that a well-stated problem is half solved. Simple strategies such as trying again, even with a different agent, can work when the failure is understood. Sandboxing makes repeated attempts safer because agents can run in parallel without access to live systems or secrets. If one attempt succeeds, its solution can be selected. This approach depends on execution isolation and cost limits. It also changes the role of the checking system: it does not need to solve every defect itself if it can describe the defect clearly enough for another agent to repair it.
"Right now you have an awkward choice between either looking at each of the lines yourself or just hitting merge and kind of hoping for the best."02:43
Who should watch
You are building an AI coding agent and need ideas for checks that happen during editing rather than after a pull request is opened.
Your team uses generated code in an established codebase and wants a practical approach to linting, documentation, tests, and sandboxed execution.
You are deciding which generated tests to keep and need a case for prioritizing user-level integration behavior over implementation details.
