---
id: "lib-2026-11-03-ai-assisted-development-or-how-not-to-waste-a-lot"
type: "library"
title: "AI-assisted development, or how not to waste a lot of time reviewing agent code (AI Assisted Development или как не убить кучу времени на код-ревью агентов)"
lang: "RU"
org: "Haulmont"
source_type: "Practitioner post"
date: "2026-11-03"
week: "2026-W45"
url: "https://nosov.ai/library/lib-2026-11-03-ai-assisted-development-or-how-not-to-waste-a-lot/"
original_url: "https://habr.com/ru/companies/haulmont/articles/1101452/"
tier: "B"
tier_name: "Useful, limited"
tier_reason: "Haulmont's Jmix team reconstructs a real agent-built feature from its commit history and turns it into six working practices, citing SmartBear, DORA, METR and Anthropic sources with care; a single team's experience without measured time per task."
summary_basis: "full-text"
original_minutes: "20"
tags: ["future of work", "enablement", "coding agents", "code ownership", "review bottleneck"]
frames: ["verification-capacity"]
---

# AI-assisted development, or how not to waste a lot of time reviewing agent code (AI Assisted Development или как не убить кучу времени на код-ревью агентов)

Tier B (Useful, limited): Haulmont's Jmix team reconstructs a real agent-built feature from its commit history and turns it into six working practices, citing SmartBear, DORA, METR and Anthropic sources with care; a single team's experience without measured time per task.

Summary based on the full text.

## In short

A Habr post (3 November 2026) on the Haulmont company blog by the team behind Jmix, an open-source Java platform. They rebuilt their assistant's search index with Claude Code in three days, then needed almost three more weeks before anyone could answer for the code. The authors separate two timers: until working code exists, and until a person understands it well enough to fix it from memory ("code adoption"). Agents shortened the first; the post describes six practices to start the second one earlier.

## Key numbers

- 3 days, 44 commits: time for Claude Fable 5 (with GPT-5.6 Sol cross-checking) to produce a working RAG search rewrite
- 122 files, about 15,000 lines: size of the agent-generated diff (about 12,000 after excluding HTML fixtures)
- almost 3 weeks, 100 commits: further time before one team member could own the code (53 + 47 commits)
- 30-45 hours: pure reading time the team estimates for 12,000 lines at SmartBear's 400 lines per session

## What it reports

- Claude Fable 5 generated the code and GPT-5.6 Sol independently cross-checked parts. The diff: 122 files, almost 15,000 lines; review was expected to take two or three days.
- Commit history: 44 commits in the first 3 days, 53 in the next week and a half (reverting unrequested changes, fixing search and checks), 47 in the last nine days (late changes and re-checks).
- Unrequested changes included dropping support for several Jmix versions and changing the /api/search response format (later moved to /api/v2/search), plus 3.5 MB of screenshots and dumps and Playwright logs committed with the code. For almost a week commits were titled "Restore ... as in main".
- Reading alone does not explain three weeks: at SmartBear's 200-400 lines per 60-90 minute session, 12,000 lines is about 30-45 hours.
- Four tests of code adoption: trace data from input to output, explain invariants, predict which scenarios a change affects, change a contract knowing what to re-check, all without the agent except for navigation.
- The agent explains with the same confidence whether right or wrong, so explanations must be checked against the code.
- Practices include: separate delivery, agent iteration and adoption boundaries; define each iteration by one property with a counterexample and a confirming test; give a fresh verifier the spec, diff and checks but not the generator's conversation, and let it only verify, not fix; bring in the future module owner straight after each stable slice; finish with full integration acceptance.
- Where it does not pay: one-screen changes, and code that follows a known structure (entities and migrations were accepted quickly).

## How they got it

A retrospective by the team, built from Git history rather than timed tasks, with external evidence cited: the SmartBear and Cisco review study, Google's review guidelines, DORA 2024 and 2025, METR's developer experiment and its February 2026 follow-up, and Anthropic and OpenAI engineering posts.

## Limits

- One feature, one team; days per task were not recorded.
- The six practices are presented as current working rules, not yet measured against the first attempt.
- The authors note the SmartBear data is almost twenty years old and measures defect finding, not ownership.

## Why it matters for companies

Generation speed is now cheap; the cost has moved to the point where a person can own the code. Firms that measure agent productivity by time-to-working-code will overstate the gain unless they also track time to ownership. The practical rules are usable as policy: define done before generation, use a verifier without the generator's context, and schedule the future owner's review time after each slice rather than at the end.

## Key passages in translation

> Агенты здорово ускорили первую половину работы, когда код пишется, а вот вторую, когда его надо прочитать, понять и взять на себя, почти не тронули.

Agents sped up the first half of the work, when the code is written, but barely touched the second, when it has to be read, understood and taken on.

> Агент объясняет одинаково уверенно, прав он или нет.

The agent explains with the same confidence whether it is right or not.

> Если на это нет времени, скорость агента просто превращается в очередь непрочитанных диффов.

If there is no time for that, the agent's speed simply turns into a queue of unread diffs.

Original: https://habr.com/ru/companies/haulmont/articles/1101452/