# How to Enhance AI Agents for Structured Codebases > Source: > Published: 2026-07-19 03:13:08+00:00 This is the workflow I follow *before* I use AI agents to implement any feature or bug fix. ๐Ÿงญ Requirements/Specification โ†“ Design/Architecture โ†“ AI Code Generation โ†“ Human Review โ†“ Build & Static Analysis โ†“ Testing & Validation โ†“ Defect Resolution โ†“ Security & Compliance Review โ†“ Release โ†“ Production Monitoring vs Claude Code โ†“ Implements feature โ†“ Codex QA Agent โ†“ Runs application โ†“ Tests happy path โ†“ Tests edge cases โ†“ Tests error handling โ†“ Produces QA report This will resolve the self-review bias, confirmation bias, or AI-to-AI bias. Before touching any code, I try to understand **what** I'm building and **why**. I usually start by reading: `specs//-.md` `plan//-.md` `status.md` Then I review the project conventions: `specs/CONVENTIONS.md` `specs/conventions/core-porting.md` Finally, I read the existing implementation (entities, services, mappers, etc.) so my changes follow the existing architecture instead of introducing a new style. Once I understand the requirements, I identify which architectural layers are affected. I always respect the dependency order: ``` Schema / Entities / DAOs โ†“ Mappers / DTOs โ†“ Service Layer โ†“ Application Layer โ†“ Controllers I don't jump ahead of dependencies. If a change is complicated or ambiguous, I document the approach before writing code. --- ## 3๏ธโƒฃ Write the Code While implementing, I follow the repository's rules. Some examples: | Rule | Detail |---|---|---| | DTOs | Generated from `schema.yml` โ€” never handwritten | | Status values | Sourced only from the Core Porting specification | | Traceability | Every ported behavior includes a source citation | Citation formats I use: - `โ† Source ` - `โ† PS ยง...` - `โ† BR-###` Beyond repository rules, I also try to: - โœ… Match existing naming conventions - โœ… Keep comments minimal and meaningful - โœ… Make small, focused changes instead of massive rewrites --- ## 4๏ธโƒฃ Verify Everything After implementation comes verification. I run the relevant module tests: ``` bash mvn -pl test ``` Locally I usually include `-am`, since Liquibase is disabled and schema changes need to be applied first. Because this repository doesn't currently have independent QA, I also: - Verify that all tests pass - Run mutation tests if coverage is uncertain - Exercise the runtime flow instead of relying only on successful compilation If something fails, **I report it honestly** rather than hiding the failure. ๐Ÿ› ๏ธ --- ## 5๏ธโƒฃ Finish Cleanly Before considering the work complete, I: - Reference the requirement or rule IDs implemented - Update `status.md` only after owner approval - Commit and push only when requested - Create an ADR if I intentionally deviate from established conventions If there's an exception, it should be **documented โ€” not silently introduced**. --- ## ๐Ÿ” The Entire Workflow ``` plaintext Read the specification โ†“ Read the conventions โ†“ Understand the existing code โ†“ Plan the implementation โ†“ Write minimal changes โ†“ Test and verify โ†“ Report results honestly ``` Following this process helps me write code that integrates naturally with the existing codebase, minimizes regressions, and makes future maintenance much easier. --- *If you follow a similar workflow (or have tweaks that work better for your team), I'd love to hear about it in the comments!* ๐Ÿ‘‡ ```