Nine years ago, I built two versions of Highlander: an original jQuery application and a React/Redux version that used the same backend concepts. After successfully reviving and deploying the jQuery version, I turned to Highlander-react-redux.
The goal was not simply to make an old repository run again. I wanted to improve the product, modernize its architecture without rewriting everything, and deploy something people could actually explore. This time, I used Turtle AI: a plan-driven engineering workflow built around Codex. It gave the AI explicit phases for planning, implementation, verification, testing, documentation, security review, and performance review.
The process worked—but it also taught me that more guardrails do not automatically create a more efficient workflow.
The Problem: More Than an Old React App
The application had the typical problems of a nine-year-old project:
- Legacy React class components
- Complicated Redux connections
- Hardcoded localhost API URLs
- Authentication state disappearing after refresh
- Unprotected client routes
- Large Express route files mixing routing and business logic
- Inconsistent API errors
- No API versioning
- Limited filtering and pagination
- Outdated deployment assumptions
- UX gaps for demo users
The app also had useful product ideas that had never been fully developed. Coaches could manage teams, players, and stats, but the experience needed stronger analytics, season support, collaboration, and more reliable workflows.
I did not want to throw away the existing application and replace it with a new stack. The challenge was to preserve its original value while making targeted improvements.
The Approach: Plan-Driven Product Engineering
My previous Highlander revival prioritized:
- Get the app running locally
- Stabilize authentication and data
- Improve the demo experience
- Harden security
- Deploy
For the React/Redux version, I followed a more structured workflow:
- Analyze the repository
- Create an implementation plan for one feature
- Implement one plan step at a time
- Verify the change
- Confirm that I understood the implementation
- Add or update tests
- Review security and performance
- Document the completed feature
- Move to the next backlog item
That sequence made the work deliberate. It prevented the AI from treating the repository like an unlimited refactoring exercise.
Introducing Turtle AI
Turtle AI is a workflow I created around one principle: build with AI without losing understanding.
Most AI coding workflows optimize for generating code quickly. Turtle AI instead optimizes for engineer comprehension, controlled progress, and long-term ownership of the codebase. The engineer remains the source of truth, while the AI operates as a constrained implementation partner.
Turtle AI runs as a collection of repository-scoped Codex skills. Each feature begins with repository analysis and a written plan. Every implementation step then moves through a controlled loop:
EXECUTE → VERIFY → ENGINEER CHECKPOINT → TEST → DEBUG → PLAN STEP UPDATE
The Engineer Checkpoint is what makes the workflow different. Before moving forward, the developer must explain what changed, why it works, how it fits into the system, and what risks remain. This is intended to prevent a common problem with AI-assisted development: shipping increasingly large amounts of code while gradually losing understanding of the application.
The workflow also includes dedicated skills for backlog management, architecture documentation, security review, performance review, feature documentation, and commit preparation.
Highlander-react-redux became the first large project where I used Turtle AI from planning through deployment. It gave me an opportunity to test the workflow against a real legacy application—not just demonstrate it with isolated coding exercises.
The project is open source on GitHub: heriberto-codes/turtle_ai.
That experience showed me both why the workflow is valuable and where its current design needs to improve.
What Turtle AI Helped Me Ship
Product Features
The application gained several capabilities that made it more useful for coaches:
- Derived player analytics, including batting average, home-run rate, ERA, and strikeouts per inning
- Season-aware teams and statistics
- Game-based stat entry
- Search and filtering
- A clearer demo-account experience
These features extended existing workflows instead of creating disconnected pages or parallel APIs.
Deployment to Fly.io
The production deployment includes:
- A multi-stage Docker build
- A Fly.io application configuration
- HTTPS enforcement
- A health-check endpoint
- PostgreSQL-backed sessions
- Automatic database migrations during releases
- Production demo seed data
- A demo-account notice in the UI
The deployed application serves the React build and Express API from the same origin. This simplifies cookies, API requests, and CORS behavior.
What I Learned from Turtle AI
The most valuable part of Turtle AI was not the code it generated. It was how the workflow forced me to engage with that code. After implementing a plan step, the Engineer Checkpoint asked me to explain:
- What changed
- Why the change was needed
- Which files were involved
- How the important logic worked
- What risks or assumptions remained
- What should be tested next
This turned the AI workflow into a learning tool. Instead of accepting generated code and moving on, I had to demonstrate that I understood the behavior. When my answer was incomplete, the checkpoint could ask me to retry, review the implementation, or rebuild my explanation.
That process helped me practice reviewing code, explaining architectural decisions, identifying risks, and thinking like the engineer responsible for maintaining the system.
For learning, this was extremely useful.
Where Turtle AI Became Too Heavy
The Engineer Checkpoint was also the biggest weakness in the workflow.
Depending on the complexity of a change, it could ask four to eight questions for every individual plan step. Each question required the session to retain or reload:
- The implementation plan
- The active step
- The files that changed
- Verification findings
- Test results
- Previous answers
- Confidence scores
- Retry and recovery state
That consumed the context window quickly.
On a long feature, the checkpoint process could use more context than the implementation itself. The same information was often repeated across the plan, verification, checkpoint, tests, security review, performance review, and final documentation.
Eventually, the context window could become so overloaded that the workflow designed to protect quality started making the AI less effective.
The AI had less room for the repository, product decisions, and active implementation because so much of the available context was occupied by process.
Turtle AI as a Learning Tool, Not My Default Production Workflow
My main takeaway is that Turtle AI currently makes more sense to me as a learning tool than as a default workflow for production application development.
It is useful when the goal is to slow down, study a codebase, understand every change, and practice explaining engineering decisions. The checkpoints make it difficult to remain passive while the AI writes the application.
That is a strength for:
- Students
- Junior engineers
- Developers learning an unfamiliar stack
- Engineers practicing code review
- People rebuilding confidence in an older codebase
- Anyone who wants AI assistance without giving up technical understanding
For production work, however, the context cost is difficult to justify.
A large company may be able to provide access to models with very large or effectively unlimited context windows. In that environment, a highly structured workflow with repeated checkpoints may be practical.
For an individual developer working within normal context limits, it can become expensive, slow, and repetitive. Production work usually requires faster iteration and more selective controls.
I would not remove the guardrails completely. I would make them proportional to the risk:
- Use lightweight checkpoints for copy and presentation changes
- Use standard checkpoints for normal application behavior
- Reserve deep checkpoints for authentication, authorization, database, and architecture changes
- Run checkpoints after meaningful feature slices instead of every small plan step
- Store compact summaries between phases
- Avoid repeating information already proven by tests and verification
- Start a fresh context window at clear feature boundaries
The checkpoint should confirm understanding. It should not consume so much context that it interferes with the work it was designed to protect.
The Result
This project became more than a migration from jQuery to React.
It became an exercise in:
- Recovering a legacy system
- Preserving working contracts
- Improving product value incrementally
- Modernizing React and Redux patterns
- Strengthening authentication and authorization
- Building deployment infrastructure
- Using AI as an engineering learning tool
- Recognizing when AI guardrails create their own complexity
The original jQuery revival demonstrated how quickly an application can be restored with focused AI assistance.
The React/Redux revival demonstrated something different: a structured AI workflow can help a developer deeply understand and evolve an application, but that educational value comes with a substantial context and productivity cost.
Turtle AI made me more involved in the engineering process. It also taught me that the best AI workflow is not necessarily the one with the most steps or guardrails.
It is the one that applies the right amount of structure for the risk, the developer, and the environment.
Highlander React/Redux Project
Demo: https://highlander-react-redux-demo.fly.dev
GitHub: https://github.com/heriberto-codes/highlander-react-redux
