An AI-native development environment
built around team constraints

01

Designing around team constraints

The goal was to build an environment for developing with AI that fit the conditions in which the team worked.

The team had nine developers but only four PCs available. Policy required using only the headquarters database, and local tests also needed database access. Issues, designs and key decisions were scattered across conversations and internal messages, so people had to find them again when starting or taking over work.

I configured an execution environment that allowed development to continue across PCs, and connected the rationale for requests and decisions to issues and topic-based notes. I made this knowledge available to AI and designed and implemented recurring management automation alongside human review procedures.

02

Problems and improvements from real use

Revising version rules that caused repeated conflicts

Version bumps in every feature merge request (MR) repeatedly caused merge conflicts in the same files. I proposed recording feature changes separately and updating the version only in release merge requests.

The old rule came from an architecture that detected updates by version number, but detection had already moved to commit hashes. The revised rules use one version source, regenerate related files and combine feature change notes at release time.

The merge driver for generated files copies the file from the other branch; regenerating related files from the source is a separate step. The merged MR reports that checks and the release flow passed with the driver, while a control run without it reproduced the conflict.

An approval input missing from the records

In real work, the system rejected an approval even though the user had approved it. A SQLite write lock had caused the user’s input to go unrecorded. I documented the issue and specified preserving the input time, accepting the approval and recording failures independently of the database lock as completion criteria.

The revised implementation stores the input time and identifying information in a file before opening the database, then applies the input with its original timestamp and without duplicates once the lock clears. It also stores failure records outside the database and separates write operations for background collection. To distinguish causes, measurement records first had to preserve actual user input.

The merged change records report 13 passing checks, including database-lock reproduction, and validation of the Windows PowerShell invocation. Deployment to every PC and reduced recurrence in real work remain unverified.

03

Recording requests and decisions

I organized scattered work knowledge and development standards into topic-based Markdown notes so people and AI could consult the same evidence. Each note covered one topic and recorded facts established through questions, along with sources, verification dates and the relevant work area.

Concise shared rules

I kept the rules that always apply concise, and separated detailed work knowledge so it could be found through an index when needed.

Updating and reviewing source documents

I configured note changes to pass through index generation and consistency checks before being submitted as a merge request (MR).

Synchronizing the team environment

I installed and synchronized team skills, agents and hooks alongside the knowledge base so people could work to the same standards on different PCs.

04

Automation from issue to release

Connecting change records to releases

I used GitLab CI and the team harness to automate issue management, tag and release registration, and patch-note drafting. The tools check the inputs required for each task and compare code with records.

Creating an issue

Check the work target, current state, expected result, reproduction steps and background. Ask the requester for missing information before creating the issue.

Drafting a release

Compare issues, merge requests and code changes since the previous tag. For each item, document the change, path, inputs, expected results to check and deployment considerations in the patch notes.

Registering after approval

I defined a procedure in which a person reviews and approves the draft before tags and releases are registered.

05

AI execution and human review

For web-system development, the workflow retrieves the issue, existing state and relevant knowledge, then prepares a workspace and Tomcat environment. I connected this preparation to AI implementation, checks and screen-evidence collection.

I required the person doing the work to check screens and behavior against the issue’s intent before opening an MR. A reviewer then examines the changes in the MR. This sequence connects AI implementation and checks with human confirmation of intent and review of changes.

Measuring specification and design errors separately from AI implementation failures

The purpose of measurement was to distinguish developer specification or design errors from Claude’s failure to implement requirements. In v2.7, I designed and implemented records of first-pass acceptance by the person doing the work, rejection at final review, clarification questions and reasons for rework.

The system compares the original request, answers provided before work and agreed criteria with the implementation to record the basis for a judgment. When causes overlap or remain unclear, it also records contributing causes, unknowns and disagreements.

06

Work environments and resuming work

Policy permitted only the headquarters database, and local tests also needed database access. That access had to remain available when moving to another PC.

I used Tailscale routing to provide database access without connecting each PC directly to the headquarters LAN. This allowed team members to continue development and local tests when moving between PCs.

I separated files, Tomcat settings and ports by Git worktree while sharing the database as required by policy. I implemented a flow that keeps the environment available while review is pending and sends the person responsible the screen URL and issue link.

When moving between PCs, uncommitted changes and handover notes are saved in a separate Git snapshot and stored in a remote repository. I also established a flow for resuming work on another PC after checking the handover document and diff.

07

Implementation, rollout and evidence scope