An engineering team funded by the Sovereign Tech Fund shares how they used generative AI to fill in missing API documentation tags (@param, @tparam, @return) across Scala's standard library. They describe five techniques: pushing work onto deterministic code via a custom todo-writer tool that inserted precise TODO markers, enforcing a deterministic git-branch-based harness to orchestrate writer/reviewer/refiner AI passes, giving each AI step a fresh isolated context, separating review from decision-making using role-specific prompts, and sizing pull requests for human reviewability. The work produced twelve initial PRs plus nine cleanup PRs after fixing bugs in the tooling. Human reviewers still caught inconsistencies, broken markup, and factual errors. Next steps involve documenting 5,894 entirely undocumented entities using multiple AI reviewers per change.
Table of contents
Technique 1: Push work onto deterministic codeTechnique 2: Enforce a deterministic processTechnique 3: Give the AI a fresh, focused contextTechnique 4: Separate the review from the decisionTechnique 5: Size the pull requests to the humanWhat’s nextAbout the authorAbout the Scala CenterQuestions this post answers
How can I use AI to fill in missing Scaladoc tags without generating low-quality documentation?
Use a deterministic harness rather than letting an AI model decide what to do freely. The Scala standard library documentation project inserted precise TODO FILL IN markers with a todo-writer tool for missing @param, @tparam, and @return tags, then ran a scripted loop where a writer model filled each marker, a reviewer model returned structured JSON feedback in a fresh context, and a refiner model decided which suggestions to apply. daily.dev surfaces practical AI-harness patterns for developers automating documentation and code review workflows.
Does using the same AI model for both writing and reviewing code work well?
Yes, according to a documentation-generation project for Scala's standard library, using the same model for the writer, reviewer, and refiner roles produced sufficient results, as long as each role runs in its own fresh context with no memory of prior steps and a single clearly defined responsibility. A different model for review can further reduce shared blind spots but was not strictly necessary. developers designing multi-step AI workflows can compare model-separation strategies through daily.dev.
Why should I break AI-generated code changes into small git commits before review?
Isolating each file's change into its own commit lets an automation loop cherry-pick one unit of work at a time, keeping the AI focused on a single file per step and making the process restartable and batchable. In the Scala standard library documentation project, this per-file commit structure also let finished commits later be regrouped into review-sized pull requests for humans. daily.dev helps developers track workflow patterns for structuring AI-assisted commits and pull requests.