How Descant elevated the model’s work

Migrating a deeply coupled Rails service to SOA: 99 merged PRs in 54 hours, fully autonomously, from a single implementation issue.

Engineering score with and without Descant

+37.0points

Engineering score comparison

Without Descant

46.9/100

With Descant

83.9/100

How we arrived at these scores

  • 560 findings fixed before independent review

    This is the result of Descant's elevation of a single model through error de-correlation, a disciplined engineering process, and structured output that is schema-validated and used to verify quality.

  • 196 additional fixes from independent review

    Similar techniques are then applied cross-model from planning through code review in a process that uses techniques from pair programming and Fagan inspection (formal team code review).

  • 69 Blocking or Important findings fixed

    Process scales. Minor changes are streamlined and load-bearing changes are scrutinized. Scrutiny caught and fixed critical billing errors, lost data and failed recovery paths before merge—all missed by a single frontier model even with elevated performance.

The engineering behind the difference

We gave Descant a Rails monolith with real coupling between timekeeping, billing and reporting. From one implementation assignment, Descant coordinated the migration work and required evidence through planning, implementation, verification and review.

A model and a prompt

You ask for good engineering and rely on the model to decide what to examine, how much verification to perform and when the work is complete. More subagents can contribute, but the prompt itself does not enforce those obligations.

Comparison reference; not a measured control run in this study.

Models working inside Descant

Requirements, affected code paths, tests and findings become structured evidence the system checks. Descant carries the work through research, plan review, implementation and revision, then another model independently reviews the result.

560 findings fixed in the plans and code before each PR reached independent review

A different model then reviewed that revised work and drove 196 additional fixes, including 69 Blocking or Important findings.

Across 99 merged implementation PRs, the 756 total records improvements made through these two stages. Independent review started from work that Descant’s authoring process had already improved through 560 recorded fixes.

Inspect the fixes and what they changedReview counts and counting method

Extracting Timekeeping from a Rails monolith

Miru is an open-source Rails application for time tracking, invoicing and reporting. The assignment was to separate Timekeeping from shared billing and reporting data, with events carrying changes back to the application.

Before

One Rails application: Timekeeping, billing and reporting share a PostgreSQL database.

Intended after

Timekeeping owns a separate service and database. APIs coordinate writes; entry-change, discard and billing-lock events update projections for reports and totals.

The design includes a rollback path that returns ownership to the monolith while preserving entries, edits and billing reservations accepted after cutover. The parent assignment and final cutover proof remain open.

We stopped the migration after the demo presentation for a potential customer; it had served its purpose. These results show the work completed by that point. If seeing the migration completed would help your evaluation, contact us about resuming Descant and publishing the final results.

Original technical design assignmentImplementation seed issueMerged pull requests

One assignment, parallel work

The assignment expanded into dependencies, implementation issues and follow-ups. Lines show work progressing together; connections show where it split or generated further work.

  • 136 issues coordinated from one assignment

    Dependencies, implementation and follow-ups stayed connected as the scope expanded.

  • 20 issue runs in flight at peak

    Work advanced in parallel across the migration; run lifetimes include review and waits.

  • 99 implementation PRs merged

    Completed changes are linked to the issues and review history that produced them.

Issue-run lifetimes include review, CI and waits. The chart compresses two recorded pauses totaling 9 h 13 m; the elapsed-time result below includes them.

Issues opened and closed

New work appeared as Descant decomposed the assignment and filed follow-ups. The gap between the two lines is work still open.

136 issues created, 119 closed and 17 still open at the final recorded issue event.
Ends at the last recorded issue change, October 27, 2026, 6:49 AM PDT. Closed includes 111 completed and 8 retired issues. The migration is unfinished.

560 fixes before independent review, then 196 more

Independent review examined the result of Descant’s authoring process: researched, planned, implemented, verified and revised work. The figures below show what each stage changed before merge.

  • 560 findings fixed in Descant self-review

    Plan and implementation findings resolved during authoring, raising the starting point for independent review.

  • 196 additional findings fixed in independent code review

    A different model challenged the submitted work and found more to correct, after self-review was complete.

  • 69 high-impact code-review findings fixed

    Classified as Blocking or Important. These included incorrect billing, lost data and failed recovery paths.

756 recorded findings fixed across both review stages, before merge

Descant improved the plans and implementation before independent review, then used another model to challenge the revised result. Independent review improved 63 of 99 merged implementation PRs, correcting failure paths that could put customer data, billing accuracy and recovery at risk.

Counts describe recorded fixes, not distinct production incidents. Review stages can revisit the same underlying problem.

What independent review added after authoring

In the 27 PRs with high-impact independent findings, author-side review had already driven 264 fixes. Independent review then drove 69 further high-impact corrections in that already-revised work.

Scope and counting method

All review metrics use 99 merged implementation PRs. Author-side totals stop before first independent review. Independent counts use unique root finding threads and recorded pre-merge dispositions. Stages can address the same underlying concern and must not be summed into a unique-bug count.

The 756 total adds recorded finding fixes across stages, not unique defects. This study did not rerun the migration with a single model alone, so it does not measure how many of these findings that alternative would have caught or shipped.

Internal review: 407 planning and 204 build findings; 560 fixed, 31 deferred and 20 declined. Independent review: 223 Blocking, Important or Worth fixing findings; 196 fixed, 22 deferred and 5 declined.

Blocking, Important and Worth fixing independent-review findings with author-recorded fixes before merge; Minor findings excluded. Counts are finding records, not separately reproduced unique defects or observed production incidents. High-impact fixes comprise 67 code/test findings and 2 operational-document findings.

One analyst-assigned primary family per high-impact independent finding. Recurring patterns are not a measured error-correlation coefficient. Internal and independent finding counts can be summed as records, but not as unique defects; stages can revisit the same underlying problem.

Projected assessment

  • 83.9/100 projected engineering assessment

    Conditional on completing the remaining agreed migration work and required follow-ups.

  • 46.9/100 modeled without Descant

    Not a measured baseline. Same projected base and scoring rule, with recorded corrections from both review stages removed.

Both are conditional rubric scores. The comparison removes recorded corrections from author-side review and independent code review, using the same rubric and agreed end state. No alternative implementation was run or evaluated.

Methodology, assumptions and calculation

Which corrections are removed

The original 53.8/100 calculation removed independent-review corrections only. It remains available unchanged. The headline comparison also includes the plan and implementation corrections made before independent review.

Comparison scopes under the unchanged scoring rule
Corrections removedModeled engineering
Independent review only · 233 records53.8/100
Independent review + 174 build-review records; plan records excluded53.0/100
Both review stages, including plan corrections · 818 records46.9/100

Plan findings have no structured file location. Their category assignments are disclosed analyst judgments; build and independent-review records retain the original file-path rule. The middle row shows the result with those plan judgments excluded.

The scoring rule caps each category’s deduction at two anchor points. Once a category reaches that cap, further findings do not lower its score. This limits the numerical effect of adding the author-side evidence; the cap and weights were not changed.

What is being scored

Weighted rubric points normalized to 100. These are not percentages of tasks passed, benchmark scores, probabilities or percentiles. Each category has an anchor from 0 to 5. Engineering has weight 51; process has weight 45. The rated total is 96.

Cost and delivery efficiency, with weight 4, is excluded: Completion cost is unknown; the projected assessment leaves this domain unrated.

Group score = 100 × sum of (category weight × anchor) ÷ (5 × included weight). The table shows both weighted sums so the normalization can be checked.

Projected and modeled rubric scores with their arithmetic
Rubric viewProjectedModeledNot a measured baseline
Engineering83.9/10046.9/100
Projected: 100 × 214 ÷ 255. Modeled: 100 × 119.6 ÷ 255. Difference: 37.0 rubric points.
Process74.0/10025.8/100
Projected: 100 × 166.5 ÷ 225. Modeled: 100 × 58 ÷ 225. Difference: 48.2 rubric points.
Overall79.3/10037.0/100
Projected: 100 × 380.5 ÷ 480. Modeled: 100 × 177.6 ÷ 480. Difference: 42.3 rubric points.
Overall, excluding the five process categories assumed absent81.7/10051.5/100
Projected: 100 × 282 ÷ 345. Modeled: 100 × 177.6 ÷ 345. Difference: 30.3 rubric points.

The deduction rule and all 15 categories

Per retained finding, the declared deductions are 0.5 anchor points for blocker, 0.25 for high, 0.1 for P2 and 0.05 for P3. Sum the deductions in a category, cap them at 2, then subtract from the projected anchor with a floor of 1. These are chosen scoring assumptions, not measured effects.

Five process categories are set to zero by assumption: independent review quality, author response and convergence, follow-up quality, issue grooming, learnings and their grooming. This does not establish that another model cannot perform those activities. Excluding these categories removes them from both sides of the overall calculation above.

The rule applies to the six engineering categories and requirements traceability. Decomposition, scope and communication stay at their projected anchors. A zero finding count means no retained thread was assigned to that category, not that it has no defects.

All 15 category weights, projected anchors and modeled anchors
CategoryWeightProjected anchorModeled anchorNot a measured baseline
E1: Architecture and service boundaries104.52.5
Finding deduction applied. Findings: 4 blocker, 17 high, 21 P2, 3 P3. Raw deduction 8.5; capped deduction 2.
E2: Functional correctness and integration1042
Finding deduction applied. Findings: 42 blocker, 69 high, 22 P2, 6 P3. Raw deduction 40.75; capped deduction 2.
E3: Data, events, cutover and rollback84.52.5
Finding deduction applied. Findings: 22 blocker, 73 high, 37 P2, 5 P3. Raw deduction 33.2; capped deduction 2.
E4: Code quality and abstractions83.52.45
Finding deduction applied. Findings: 0 blocker, 1 high, 6 P2, 4 P3. Raw deduction 1.05; capped deduction 1.05.
E5: Tests and verification104.52.5
Finding deduction applied. Findings: 0 blocker, 17 high, 260 P2, 111 P3. Raw deduction 35.8; capped deduction 2.
E6: Operational readiness542
Finding deduction applied. Findings: 2 blocker, 18 high, 0 P2, 0 P3. Raw deduction 5.5; capped deduction 2.
P1: Requirements and design traceability542
Finding deduction applied. Findings: 0 blocker, 9 high, 18 P2, 15 P3. Raw deduction 4.8; capped deduction 2.
P2: Decomposition and dependencies544
Held at the projected anchor. Findings: 0 blocker, 0 high, 1 P2, 6 P3. Raw deduction 0.4; capped deduction 0.4; this deduction is not applied to the anchor under this category’s rule.
P3: Scope discipline43.53.5
Held at the projected anchor. Findings: 0 blocker, 9 high, 8 P2, 10 P3. Raw deduction 3.55; capped deduction 2; this deduction is not applied to the anchor under this category’s rule.
P4: Independent review quality840
Zero by scenario assumption. Findings: 0 blocker, 0 high, 0 P2, 0 P3. Raw deduction 0; capped deduction 0; this deduction is not applied to the anchor under this category’s rule.
P5: Author response and convergence53.50
Zero by scenario assumption. Findings: 0 blocker, 0 high, 0 P2, 0 P3. Raw deduction 0; capped deduction 0; this deduction is not applied to the anchor under this category’s rule.
P6: PR and comment communication43.53.5
Held at the projected anchor. Findings: 0 blocker, 0 high, 0 P2, 0 P3. Raw deduction 0; capped deduction 0; this deduction is not applied to the anchor under this category’s rule.
P7: Follow-up quality53.50
Zero by scenario assumption. Findings: 0 blocker, 0 high, 0 P2, 0 P3. Raw deduction 0; capped deduction 0; this deduction is not applied to the anchor under this category’s rule.
P8: Issue grooming43.50
Zero by scenario assumption. Findings: 0 blocker, 0 high, 0 P2, 0 P3. Raw deduction 0; capped deduction 0; this deduction is not applied to the anchor under this category’s rule.
P9: Learnings and their grooming53.50
Zero by scenario assumption. Findings: 0 blocker, 0 high, 0 P2, 2 P3. Raw deduction 0.1; capped deduction 0.1; this deduction is not applied to the anchor under this category’s rule.

blocker and high correspond to the source reviewer severity labels. P1 as a rubric category means traceability and must not be confused with a reviewer severity label. Display one decimal, round half up; retain exact fractions in the calculation output. Displayed endpoints can therefore differ by 0.1 from the displayed gap.

Review records and source scope

This assessment uses 233 finding threads with retained corrections across 70 merged PRs. The broader source corpus has 114 PRs and 103 merged PRs: 99 implementation, 2 design and 2 human preparation or scope PRs.

The recorded-results section uses 196 independent-review fixes on merged implementation PRs, excluding Minor findings. 196 + 24 + 12 + 1 = 233. The broader modeled-scenario input includes Minor and design findings and one retained earlier correction beyond the implementation-only non-Minor case-study measure. Those are overlapping views of the independent-review records, not additional findings.

The expanded calculation adds 585 author-side records: 560 from implementation PRs and 25 from the two design PRs. That is 411 plan corrections plus 174 build corrections, all recorded before the first independent review. The combined assessment uses 818 records. Records can overlap in the underlying problem they describe.

Author-side findings are published as sanitized excerpts from retained private records, with their recorded corrections. Linked PRs and commits identify the work, not public copies of every internal review. A recorded fixed answer is not an independent audit of every patch; a corrected plan is not necessarily a defect that reached code.

Retain the 232 roots whose final substantive author disposition is fixed, plus one earlier explicit correction that source inspection confirms remained at merge and the evaluated revision even though the final arbitration response declined further change as already correct. Every included root has a fix reply naming a commit. This establishes the recorded correction claim, not an individual patch audit of all 233 threads. The one retained earlier correction was inspected in its fix commits, merge and evaluated revision. 6 retained correction threads on unmerged PRs are excluded.

Original ordered file-path rules for independent and build review, plus disclosed per-record analyst judgment for 411 plan findings without structured file locations. Top-level inline review finding thread, not necessarily a unique defect or a unique corrective commit.

  • File location is a proxy for rubric relevance, not a semantic classification of the defect or its effect.
  • For example, a boundary defect found in a test file is assigned to tests rather than architecture.
  • One thread receives one category even when its consequences span categories; repeated or overlapping findings need not represent independent defects.
  • The exact rule order matters. A prose-only reconstruction assigned some engineering findings differently. The supplied final row assignments and ordered regex table, rather than the abbreviated prose, define this calculation.
  • The public aggregate inputs reproduce score arithmetic; the separate public census and final row assignments support reproduction of root counts, dispositions and category totals. Reproduction is not empirical validation of the scoring choices.
  • Plan assignments reflect the substantive engineering consequence described in the finding and correction; no source path is invented.
  • The 411 plan assignments are judgments by one analyst. The plan-excluded sensitivity removes them; classification ambiguity is not a statistical confidence interval.

Sensitivity to the scoring rule

Every row keeps the same projected base: 83.9/100 for engineering and 79.3/100 overall. Only the declared penalties and cap change. These scenarios are not confidence intervals or performance bounds.

Scoring-rule sensitivities on the same projected base
Scoring ruleModeled engineeringNot a measured baselineModeled overallNot a measured baseline
Declared severity rule46.9/10037.0/100
Deductions: blocker 0.5; high 0.25; P2 0.1; P3 0.05. Cap 2; floor 1.
Only blocker/high findings; cap 1.557.8/10043.3/100
Deductions: blocker 0.5; high 0.25; P2 0; P3 0. Cap 1.5; floor 1.
Half severity penalties; cap 248.5/10037.9/100
Deductions: blocker 0.25; high 0.125; P2 0.05; P3 0.025. Cap 2; floor 1.
Declared severity penalties; cap 163.9/10047.1/100
Deductions: blocker 0.5; high 0.25; P2 0.1; P3 0.05. Cap 1; floor 1.
Declared severity penalties; cap 330.0/10027.0/100
Deductions: blocker 0.5; high 0.25; P2 0.1; P3 0.05. Cap 3; floor 1.

Assumptions and interpretation

  • Use the same projected completion anchors for every reported sensitivity; do not substitute the observed snapshot or the later process-only reassessment.
  • Treat the retained fixed findings as absent fixes and translate their reviewer severities to anchor deductions. This is an analyst-selected scoring rule, not a measured causal effect or a calibrated prediction.
  • Set independent review, author response, follow-ups, issue grooming and learnings to zero in the overall scenario by definition. Model sessions can perform such activities; their absence is not established by another run.
  • Hold decomposition, scope and communication at the original projected anchors. The author records include decomposition and scope concerns, but this scenario preserves the pre-existing held-category rule.
  • Keep traceability under the finding-penalty rule. Both learning findings are retained in the source count; their category is set to zero and their individual penalties are not separately applied.
  • Keep deferred and declined findings outside the additional penalty. They are already part of the assessed history; the model does not newly subtract them.
  • Do not infer that removing fixes creates an executable or feasible completed system; no fixes were actually reverted and no resulting system was evaluated.
  • Do not estimate hypothetical self-correction, initial investigation and planning benefits, interactions among fixes or the effect of unavailable records. Those unmeasured effects do not establish a net direction of bias.
  • This is one projected assessment and a family of constructed scoring scenarios, not a matched experiment or a measured head-to-head comparison.
  • The severity coefficients, cap, floor, original anchors, path mapping and plan-category judgments are assessment choices. Arithmetic correctness does not validate them as estimates of another system.
  • Testing selected sensitivities provides no claim about all defensible rules, statistical uncertainty or performance bounds.
  • A capped category can remain unchanged after some parameter changes; that is a property of the chosen formula, not proof that missing evidence or alternate categorization cannot matter.
  • A fair outcome comparison would require actual comparable runs with common requirements, information, resources and evaluation criteria.

Engineering obligations recorded as data

Requirements, sources of truth, affected code paths, test changes and review outcomes leave a record that the system can check. A statement that the work is done is not the evidence.

  • 98 / 99 merged implementation PRs with test-change accounting

  • 266 / 266 independent findings with a recorded disposition

  • 99 / 99 implementation PRs with internal build-review records

Sources of truth and recovery matrixTest-change accounting example

Scope and counting method

Disposition count includes Minor findings. Test-change accounting is absent from one lockfile-only PR (#193). Recorded review/accounting coverage does not by itself prove every assertion was adequate or executed.

Better patterns, visible in the changes

Review produced work beyond the immediate feature: consolidation, stronger tests and better separation of responsibilities. Out-of-scope improvements became follow-up issues.

  • 58 quality improvements filed as follow-ups

    Consolidation, stronger verification and design work beyond the immediate feature.

  • 52 follow-ups completed through merged PRs

    The process carried those improvements into the codebase instead of leaving them as review suggestions.

  • 23 → 7 test files consolidated into focused suites

    Less duplicated setup and fewer places to maintain the same test rules.

38 consolidation tasks, 16 stronger-verification tasks and 4 design improvements. 4 remain open; 2 were retired.

One shared rule set

2 write owners reuse the same rules across 10 command paths. 4 original legacy rule locations remain separate in the unfinished migration.

Inspect the shared rules · PR #148

20 refused calls now verify stored fields stay unchanged:5 commands × 4 credentials.

Stronger assertions catch a provider that writes and then returns the correct denial.

Inspect the change · PR #42

3 locking guarantees tested with 2 real database connections; 6 regression examples.

Tests observe actual database blockers and were reported to fail when matching locks were removed; these are captured author validation reports, not a fresh rerun.

Inspect the change · PR #185

1 bulk-deletion rule moved out of the controller into a reusable service.

The controller authorizes, invokes the service and renders; the business rule can be tested without HTTP.

Inspect the change · PR #153
Scope and counting method

Review-origin consolidation, stronger verification and code/test design follow-ups, classified separately from feature decomposition, correctness fixes and CI repairs. Completion requires a linked merged PR. Examples use merged diffs and recorded validation, not a fresh test execution. The 23-to-7 result combines test suites from PRs #84, #94, #152 and #189; these were test files, not five application implementations or four HTTP clients.

Learning carried into subsequent work

The system retained lessons from the work, revised them as the design changed, and consulted them in later assignments. The repository records what was learned; run transcripts record when it was read.

  • 106 learning documents created

    Lessons from 63 merged PRs became repository knowledge for later work.

  • 22 existing learning documents updated

    24 PRs revised prior guidance as the implementation changed.

  • 97% of implementation PRs consulted prior learnings

    96 of 99 PRs retrieved knowledge from earlier work.

  • 2,220 reads of learnings from earlier PRs

    Authors and reviewers consulted retained guidance during subsequent assignments.

23 code and test fixes across 20 later PRs explicitly applied prior learnings

Public review threads connect the earlier lesson to the finding and the fix. These examples show knowledge changing subsequent work, beyond a record that a file was read.

Testing a real database lock wait

A prior lesson distinguished a sleeping thread from a real lock wait. The new race test records backend process IDs and requires PostgreSQL to report one connection blocked by the other.

Prior learningReview findingFix

Reusing one business rule across write owners

The reviewer applied a stored lesson to remove a separately restated ownership check. The local writer now calls the shared EntryRules.agent_owner rule with the committed user/agent pair.

Prior learningReview findingFix

Keeping narrow assertions during test consolidation

A stored lesson exposed a lost guarantee: a company-wide count could pass with a snapshot on the wrong entry. The fix restores per-entry SQL counts, including explicit zero snapshots for untouched entries.

Prior learningReview findingFix

Scope and counting method

63 PRs created learnings, 24 edited existing learnings, and 16 did both: 71 PRs in total. Existing documents received 27 amendments.

2,475 successful learning-file reads, including 2,220 reads of 93 earlier documents. Prior reads split into 818 author and 1,402 reviewer reads. Compacted successful records are included; failed reads and directory/listing calls are excluded.

Creation/amendment counts are net changes in 101 merge commits against their first parents. Reads cover the same merged-PR cohort in the October 29 transcript archive; one event per run and tool-call ID removes inherited history copies. Failed reads and listing/search calls are excluded. Prior-learning reads require a different PR to have committed the document before the calling thread began. Successful compacted-read records are included. Consultation is distinct from demonstrated application; the 23 code/test fixes are a conservative explicit-citation minimum checked against recorded pre-merge responses, with example commit diffs inspected.

Browse the saved learnings

Cost and time

Charges are tied to the work that produced a merged PR. The same merged cohort is used for both the total and the per-PR average.

  • $34.30 average recorded charge per merged PR

  • $3,463.80 recorded charges for 101 merged PRs

  • 54.3 h elapsed from implementation pickup to the latest merge

Scope and counting method

Recorded customer charges, margin included, for explicitly linked runs whose PR merged. Excludes charges for open or closed-unmerged PRs and runs without a PR; excluded costs are not redistributed. Excluded charges total $539.87. The merged cohort includes 99 implementation and 2 design PRs.

Wall-clock from implementation issue #8 pickup to the latest merged Descant PR. Includes pauses and waiting. This bounds completed work; it does not assert that the full implementation scope is complete. The work chart compresses the two owner-recorded pauses: 3 h 28 m for the test environment and 5 h 45 m for the spending cap. Elapsed wall-clock cost/time metrics retain these pauses.

Model choice and token efficiency

Descant runs its own agent runtime. Supported models and effort levels are assigned by role, while the system owns context preservation and compression.

  • 36 model-assignment seats across authors, reviewers, panels and helpers

  • 92.7% of recorded input tokens served from cache

  • 96.7% of implementation input tokens served from cache

Code preserves protected context; role-specific recaps carry decisions, evidence and unfinished work forward. Issuegraph connects dependencies and follow-ups, while the outer loop grooms issues and retained learnings.

Cache figures use saved observations from October 27–November 1, 2026; they are not a final token total. Model-seat inventory recorded October 27.

Scope and counting method

Weighted share of recorded input tokens served from cache: cache reads divided by cache reads, cache writes and uncached input. Includes nondebited usage; excludes output tokens. Uses latest available saved observation per merged-PR run: 50 from November 1 and 51 from October 27. Not a fully refreshed or final token total.

Distinct callable model-assignment positions, including optional and fallback paths. Seats are configurable roles, not simultaneous agents. Inventory recorded October 27, 2026.

Concurrent issue run lifetimes, including review, CI, queued time and waits; not proof of simultaneous coding/model requests. Linked-run cohort only. Restarts can extend a run lifetime.

Inspect the evidence

GitHub snapshot: November 1, 2026. 101 merged PRs for cost and learning changes; 99 merged implementation PRs for review quality. The work and issue charts show the broader implementation campaign, including work left open.

The full-project transcript corpus covers 127 runs, 3,095 conversation threads and 59,425 messages/tool events, containing 64,034 tool calls. The merged-work statistics above use the narrower cohorts stated in each section.

Start with an issue worth solving

Give Descant a real piece of work. Inspect the code, review the result and see what delivering it cost.