{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidf5kgxrmeqklarrpzthvqyxuraj2ot6tyjjonwtry3lke52pvy4a",
    "uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3mowibz75bb42"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreih3sqgjpbvjdsgfm6746q2sfzkpljfwvrdqneem3nnpq2ozrbxj6e"
    },
    "mimeType": "image/webp",
    "size": 79494
  },
  "path": "/heriberto_codes/i-revived-my-reactredux-app-with-turtle-ai-and-learned-where-ai-guardrails-can-go-too-far-1o34",
  "publishedAt": "2026-06-23T03:29:34.000Z",
  "site": "https://dev.to",
  "tags": [
    "ai",
    "programming",
    "webdev",
    "openai",
    "heriberto-codes/turtle_ai",
    "https://highlander-react-redux-demo.fly.dev",
    "https://github.com/heriberto-codes/highlander-react-redux",
    "https://github.com/heriberto-codes/turtle_ai"
  ],
  "textContent": "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.\n\nThe 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.\n\nThe process worked—but it also taught me that more guardrails do not automatically create a more efficient workflow.\n\n##  The Problem: More Than an Old React App\n\nThe application had the typical problems of a nine-year-old project:\n\n  * Legacy React class components\n  * Complicated Redux connections\n  * Hardcoded localhost API URLs\n  * Authentication state disappearing after refresh\n  * Unprotected client routes\n  * Large Express route files mixing routing and business logic\n  * Inconsistent API errors\n  * No API versioning\n  * Limited filtering and pagination\n  * Outdated deployment assumptions\n  * UX gaps for demo users\n\n\n\nThe 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.\n\nI 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.\n\n##  The Approach: Plan-Driven Product Engineering\n\nMy previous Highlander revival prioritized:\n\n  * Get the app running locally\n  * Stabilize authentication and data\n  * Improve the demo experience\n  * Harden security\n  * Deploy\n\n\n\nFor the React/Redux version, I followed a more structured workflow:\n\n  * Analyze the repository\n  * Create an implementation plan for one feature\n  * Implement one plan step at a time\n  * Verify the change\n  * Confirm that I understood the implementation\n  * Add or update tests\n  * Review security and performance\n  * Document the completed feature\n  * Move to the next backlog item\n\n\n\nThat sequence made the work deliberate. It prevented the AI from treating the repository like an unlimited refactoring exercise.\n\n##  Introducing Turtle AI\n\nTurtle AI is a workflow I created around one principle: build with AI without losing understanding.\n\nMost 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.\n\nTurtle 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:\n\n**EXECUTE → VERIFY → ENGINEER CHECKPOINT → TEST → DEBUG → PLAN STEP UPDATE**\n\nThe 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.\n\nThe workflow also includes dedicated skills for backlog management, architecture documentation, security review, performance review, feature documentation, and commit preparation.\n\nHighlander-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.\n\nThe project is open source on GitHub: heriberto-codes/turtle_ai.\n\nThat experience showed me both why the workflow is valuable and where its current design needs to improve.\n\n##  What Turtle AI Helped Me Ship\n\n**_Product Features_**\n\nThe application gained several capabilities that made it more useful for coaches:\n\n  * Derived player analytics, including batting average, home-run rate, ERA, and strikeouts per inning\n  * Season-aware teams and statistics\n  * Game-based stat entry\n  * Search and filtering\n  * A clearer demo-account experience\n\n\n\nThese features extended existing workflows instead of creating disconnected pages or parallel APIs.\n\n**_Deployment to Fly.io_**\n\nThe production deployment includes:\n\n  * A multi-stage Docker build\n  * A Fly.io application configuration\n  * HTTPS enforcement\n  * A health-check endpoint\n  * PostgreSQL-backed sessions\n  * Automatic database migrations during releases\n  * Production demo seed data\n  * A demo-account notice in the UI\n\n\n\nThe deployed application serves the React build and Express API from the same origin. This simplifies cookies, API requests, and CORS behavior.\n\n##  What I Learned from Turtle AI\n\nThe 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:\n\n  * What changed\n  * Why the change was needed\n  * Which files were involved\n  * How the important logic worked\n  * What risks or assumptions remained\n  * What should be tested next\n\n\n\nThis 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.\n\nThat process helped me practice reviewing code, explaining architectural decisions, identifying risks, and thinking like the engineer responsible for maintaining the system.\n\nFor learning, this was extremely useful.\n\n##  Where Turtle AI Became Too Heavy\n\nThe Engineer Checkpoint was also the biggest weakness in the workflow.\n\nDepending 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:\n\n  * The implementation plan\n  * The active step\n  * The files that changed\n  * Verification findings\n  * Test results\n  * Previous answers\n  * Confidence scores\n  * Retry and recovery state\n\n\n\nThat consumed the context window quickly.\n\nOn 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.\n\nEventually, the context window could become so overloaded that the workflow designed to protect quality started making the AI less effective.\n\nThe AI had less room for the repository, product decisions, and active implementation because so much of the available context was occupied by process.\n\n##  Turtle AI as a Learning Tool, Not My Default Production Workflow\n\nMy 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.\n\nIt 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.\n\nThat is a strength for:\n\n  * Students\n  * Junior engineers\n  * Developers learning an unfamiliar stack\n  * Engineers practicing code review\n  * People rebuilding confidence in an older codebase\n  * Anyone who wants AI assistance without giving up technical understanding\n\n\n\nFor production work, however, the context cost is difficult to justify.\n\nA 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.\n\nFor 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.\n\nI would not remove the guardrails completely. I would make them proportional to the risk:\n\n  * Use lightweight checkpoints for copy and presentation changes\n  * Use standard checkpoints for normal application behavior\n  * Reserve deep checkpoints for authentication, authorization, database, and architecture changes\n  * Run checkpoints after meaningful feature slices instead of every small plan step\n  * Store compact summaries between phases\n  * Avoid repeating information already proven by tests and verification\n  * Start a fresh context window at clear feature boundaries\n\n\n\nThe checkpoint should confirm understanding. It should not consume so much context that it interferes with the work it was designed to protect.\n\n##  The Result\n\nThis project became more than a migration from jQuery to React.\n\nIt became an exercise in:\n\n  * Recovering a legacy system\n  * Preserving working contracts\n  * Improving product value incrementally\n  * Modernizing React and Redux patterns\n  * Strengthening authentication and authorization\n  * Building deployment infrastructure\n  * Using AI as an engineering learning tool\n  * Recognizing when AI guardrails create their own complexity\n\n\n\nThe original jQuery revival demonstrated how quickly an application can be restored with focused AI assistance.\n\nThe 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.\n\nTurtle 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.\n\nIt is the one that applies the right amount of structure for the risk, the developer, and the environment.\n\n##  Highlander React/Redux Project\n\nDemo: https://highlander-react-redux-demo.fly.dev\nGitHub: https://github.com/heriberto-codes/highlander-react-redux\n\n##  Turtle AI\n\nGithub: https://github.com/heriberto-codes/turtle_ai",
  "title": "I Revived My React/Redux App with Turtle AI and Learned Where AI Guardrails Can Go Too Far"
}