{"id":534,"date":"2026-02-14T09:51:57","date_gmt":"2026-02-14T14:51:57","guid":{"rendered":"https:\/\/davidwdrell.net\/wordpress\/?p=534"},"modified":"2026-02-14T09:51:57","modified_gmt":"2026-02-14T14:51:57","slug":"workflows-for-high-quality-ai-generated-code","status":"publish","type":"post","link":"https:\/\/davidwdrell.net\/wordpress\/?p=534","title":{"rendered":"Workflows for High Quality AI Generated Code"},"content":{"rendered":"\n

<\/h1>\n\n\n\n

Copilot has freed me to create some powerful GUI tools to rapidly speed up embedded development.<\/strong><\/p>\n\n\n\n

One of the big challenges in embedded development is knowing what is happening in the code execution in real-time. Just a few years ago if you asked me to develop a GUI that connects to my embedded device in real-time and produces graphical traces of each sub-system, I would have said: “give me a team of 4 people and a year, we will get this done.”<\/p>\n\n\n\n

Now, I say: “let me carve out 4 hours a day for the next couple of days and I will get this banged out.”<\/p>\n\n\n\n

These custom, powerful GUI tools have dramatically improved productivity and code quality in embedded development. However, I\u2019ve recently run into a recurring issue: the GUIs degrade in quality surprisingly quickly. To stay responsive while processing high-throughput real-time data, they must strictly enforce threading discipline. Managing complex data streams from multiple subsystems demands robust object-oriented ownership patterns. And perhaps most critically, a clean Model-View architecture is essential to properly separate business logic, state, and presentation<\/p>\n\n\n\n

If you ask Copilot to code up a feature, it will take the fastest path and violate all these principles. Over the past couple of months I have developed a work-flow pattern that seems to work well to avoid all these problems.<\/p>\n\n\n\n

The most crucial element: ask copilot to review the code against the design spec and implementation plan constantly.<\/strong><\/p>\n\n\n\n

Copilot Workflow \u2014 Iterative Co-Development<\/h1>\n\n\n\n

This document describes the iterative workflow used between a human developer and GitHub Copilot (agent mode) for designing, building, and maintaining a software project.<\/p>\n\n\n\n

\n\n\n\n

Overview<\/h2>\n\n\n\n

The workflow is a repeating cycle of Design \u2192 Implement \u2192 Review \u2192 Fix \u2192 Reconcile<\/strong>. Each cycle produces working, buildable code and keeps documentation in sync with reality.<\/p>\n\n\n\n

    \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n    \u2502  Design  \u2502\u25c4\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n    \u2514\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2518                       \u2502\n         \u25bc                             \u2502\n    \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510                       \u2502\n    \u2502Implement \u2502                       \u2502\n    \u2514\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2518                       \u2502\n         \u25bc                             \u2502\n    \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510     \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510   \u2502\n    \u2502 Review  \u2502\u2500\u2500\u2500\u2500\u25ba\u2502Fix \/ Refactor\u2502\u2500\u2500\u2500\u2524\n    \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518     \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518   \u2502\n                                       \u2502\n                    \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510   \u2502\n                    \u2502Reconcile Docs\u2502\u2500\u2500\u2500\u2518\n                    \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518<\/code><\/pre>\n\n\n\n
\n\n\n\n
Phase 1 \u2014 Design<\/h2>\n\n\n\n
Participants:<\/strong> Human + Copilot
Artifacts:<\/strong> design.md<\/code>, development_plan.md<\/code><\/p>\n\n\n\n
    \n
  1. Human describes the goal, constraints, and reference material
    (existing codebase, Python prototype, protocol specs, etc.).<\/li>\n\n\n\n
  2. Copilot drafts a design document covering architecture, layer
    boundaries, file inventory, and data flow.<\/li>\n\n\n\n
  3. Human reviews, asks questions, requests changes.<\/li>\n\n\n\n
  4. Together they iterate until the design is agreed.<\/li>\n\n\n\n
  5. Copilot drafts a development plan: numbered milestones, each with
    concrete tasks, file lists, and a test checkpoint.<\/li>\n\n\n\n
  6. Human approves or reorders milestones.<\/li>\n<\/ol>\n\n\n\n
    Key rules:<\/strong><\/p>\n\n\n\n
      \n
    • Every milestone must produce a buildable, runnable, testable
      application \u2014 no “big bang” integration.<\/li>\n\n\n\n
    • Architectural constraints (layer boundaries, dependency direction)
      are documented up front and enforced in reviews.<\/li>\n<\/ul>\n\n\n\n
      \n\n\n\n
      Phase 2 \u2014 Implement<\/h2>\n\n\n\n
      Participants:<\/strong> Human directs, Copilot implements
      Artifacts:<\/strong> Source code, build output<\/p>\n\n\n\n
        \n
      1. Human selects the next milestone (or a specific task within it).<\/li>\n\n\n\n
      2. Copilot reads relevant context (existing files, design doc,
        reference code) and implements the changes.<\/li>\n\n\n\n
      3. Copilot builds the project and fixes compile errors.<\/li>\n\n\n\n
      4. Human tests against real hardware or a test harness.<\/li>\n\n\n\n
      5. If bugs are found, human reports symptoms (logs, screenshots).
        Copilot diagnoses root cause, implements a fix, and rebuilds.<\/li>\n\n\n\n
      6. Milestone is marked complete when the test checkpoint passes.<\/li>\n<\/ol>\n\n\n\n
        Key rules:<\/strong><\/p>\n\n\n\n
          \n
        • Copilot always builds after making changes \u2014 no “it should work”
          hand-offs.<\/li>\n\n\n\n
        • One milestone at a time. Don’t skip ahead.<\/li>\n\n\n\n
        • When the human reports a bug, Copilot gathers context first
          (reads files, searches code) before proposing a fix.<\/li>\n<\/ul>\n\n\n\n
          \n\n\n\n
          Phase 3 \u2014 Review<\/h2>\n\n\n\n
          Participants:<\/strong> Human requests, Copilot performs
          Artifacts:<\/strong> Review findings (in chat)<\/p>\n\n\n\n
            \n
          1. After a set of milestones, human requests a review comparing the
            implementation against the design document.<\/li>\n\n\n\n
          2. Copilot systematically reads every source file and cross-references
            against the spec. It may use sub-agents for parallel investigation.<\/li>\n\n\n\n
          3. Findings are categorized:<\/li>\n<\/ol>\n\n\n\n
              \n
            • ✅ Compliant<\/strong> \u2014 matches the spec<\/li>\n\n\n\n
            • 🔴 Violation<\/strong> \u2014 breaks an architectural rule or misses a
              required feature<\/li>\n\n\n\n
            • 🟡 Deviation<\/strong> \u2014 works but differs from the spec (layout,
              naming, missing polish)<\/li>\n\n\n\n
            • 🟡 Spec gap<\/strong> \u2014 implementation added something not in the spec,
              or spec is ambiguous<\/li>\n<\/ul>\n\n\n\n
                \n
              1. Human prioritizes which findings to address.<\/li>\n<\/ol>\n\n\n\n
                Key rules:<\/strong><\/p>\n\n\n\n
                  \n
                • Reviews compare code to the written spec<\/em>, not to assumptions.<\/li>\n\n\n\n
                • Each finding must cite the specific file\/line and the specific spec
                  section it violates.<\/li>\n<\/ul>\n\n\n\n
                  \n\n\n\n
                  Phase 4 \u2014 Fix \/ Refactor<\/h2>\n\n\n\n
                  Participants:<\/strong> Human directs, Copilot implements
                  Artifacts:<\/strong> Code changes, build verification<\/p>\n\n\n\n
                    \n
                  1. Human says which category of findings to fix (e.g., “fix the
                    architectural violations”).<\/li>\n\n\n\n
                  2. Copilot reads all affected files, forms a plan, then implements
                    all fixes.<\/li>\n\n\n\n
                  3. Copilot builds and verifies zero errors.<\/li>\n\n\n\n
                  4. Human tests if needed.<\/li>\n<\/ol>\n\n\n\n
                    Key rules:<\/strong><\/p>\n\n\n\n
                      \n
                    • Fixes are done in batches by category, not one-at-a-time.<\/li>\n\n\n\n
                    • Copilot must build after all fixes \u2014 a fix that breaks the build
                      is not a fix.<\/li>\n<\/ul>\n\n\n\n
                      \n\n\n\n
                      Phase 5 \u2014 Reconcile Documentation<\/h2>\n\n\n\n
                      Participants:<\/strong> Human requests, Copilot updates
                      Artifacts:<\/strong> Updated design.md<\/code>, development_plan.md<\/code><\/p>\n\n\n\n
                        \n
                      1. After fixes\/refactors change the architecture or add features not
                        in the original plan, the docs are stale.<\/li>\n\n\n\n
                      2. Human asks Copilot to review the docs for accuracy.<\/li>\n\n\n\n
                      3. Copilot identifies every discrepancy between the docs and the
                        actual code.<\/li>\n\n\n\n
                      4. Copilot updates the docs to reflect reality.<\/li>\n\n\n\n
                      5. The cycle restarts: the updated docs become the baseline for the
                        next implementation or review cycle.<\/li>\n<\/ol>\n\n\n\n
                        Key rules:<\/strong><\/p>\n\n\n\n
                          \n
                        • Docs describe what is<\/em>, not what was planned<\/em>. If the
                          implementation diverged for good reason, the doc is updated \u2014 not
                          the code.<\/li>\n\n\n\n
                        • New architectural decisions discovered during implementation (e.g.,
                          extracting a utility to a different layer) are added to the design
                          doc so future reviews enforce them.<\/li>\n<\/ul>\n\n\n\n
                          \n\n\n\n
                          Session Continuity<\/h2>\n\n\n\n
                          Copilot does not have persistent memory across chat sessions. To
                          bootstrap a new session effectively:<\/p>\n\n\n\n
                            \n
                          1. Workspace files are the source of truth.<\/strong> Design docs,
                            development plans, and the code itself carry forward automatically.<\/li>\n\n\n\n
                          2. Conversation summary<\/strong> is generated at the end of long sessions
                            and carried into the next one. It includes: current milestone,
                            recent changes, known issues, and build state.<\/li>\n\n\n\n
                          3. Resumption prompt:<\/strong> When starting a new session, point Copilot
                            at the design doc and development plan first. Example:<\/li>\n<\/ol>\n\n\n\n
                            \n
                            Read doc\/design.md<\/code> and doc\/development_plan.md<\/code>, then tell me
                            what milestone we’re on and what’s next.<\/p>\n<\/blockquote>\n\n\n\n
                            This ensures Copilot can reconstruct context from the repo rather
                            than relying on chat history.<\/p>\n\n\n\n
                            \n\n\n\n
                            Anti-Patterns to Avoid<\/h2>\n\n\n\n
                            Anti-Pattern<\/th>Why It Fails<\/th>Instead<\/th><\/tr><\/thead>
                            Implementing without a design doc<\/td>No baseline for review; drift is invisible<\/td>Write the spec first, even if brief<\/td><\/tr>
                            Skipping the build step<\/td>Broken code shipped to the next phase<\/td>Always build after every change<\/td><\/tr>
                            Reviewing against assumptions<\/td>Findings are subjective and argued<\/td>Review against the written spec<\/td><\/tr>
                            Fixing docs before fixing code<\/td>Hides real violations<\/td>Fix code first, then reconcile docs<\/td><\/tr>
                            Giant milestones<\/td>Impossible to test incrementally<\/td>Keep milestones to 10 to 20 minute chucks<\/td><\/tr>
                            Asking Copilot to “just do it all”<\/td>Context overload, poor quality<\/td>One milestone or one review at a time<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                            \n\n\n\n
                            Typical Session Flow<\/h2>\n\n\n\n
                            Human: \"Read the design doc and dev plan. Where are we?\"\nCopilot: [reads files] \"Milestones 0\u2013N are complete. Next is M(N+1).\"\n\nHuman: \"There's a bug \u2014 here's the syslog output.\"\nCopilot: [diagnoses, fixes, rebuilds] \"Root cause was X. Fixed.\"\n\nHuman: \"Review the code against the design doc.\"\nCopilot: [reads all files] \"Found 4 violations, 6 deviations, ...\"\n\nHuman: \"Fix the violations.\"\nCopilot: [implements fixes, builds] \"All 4 fixed. Build clean.\"\n\nHuman: \"Is the dev plan up to date?\"\nCopilot: [compares docs to code] \"7 discrepancies found.\"\n\nHuman: \"Update it.\"\nCopilot: [updates docs] \"Done. Cycle complete.\"<\/code><\/pre>\n\n\n\n
                            <\/p>\n","protected":false},"excerpt":{"rendered":"
                            Copilot has freed me to create some powerful GUI tools to rapidly speed up embedded development. One of the big […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[1],"tags":[],"class_list":["post-534","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/davidwdrell.net\/wordpress\/index.php?rest_route=\/wp\/v2\/posts\/534","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/davidwdrell.net\/wordpress\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/davidwdrell.net\/wordpress\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/davidwdrell.net\/wordpress\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/davidwdrell.net\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=534"}],"version-history":[{"count":1,"href":"https:\/\/davidwdrell.net\/wordpress\/index.php?rest_route=\/wp\/v2\/posts\/534\/revisions"}],"predecessor-version":[{"id":535,"href":"https:\/\/davidwdrell.net\/wordpress\/index.php?rest_route=\/wp\/v2\/posts\/534\/revisions\/535"}],"wp:attachment":[{"href":"https:\/\/davidwdrell.net\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=534"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/davidwdrell.net\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=534"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/davidwdrell.net\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=534"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}