{"id":537,"date":"2026-08-21T06:08:24","date_gmt":"2026-08-21T11:08:24","guid":{"rendered":"https:\/\/davidwdrell.net\/wordpress\/?p=537"},"modified":"2026-08-22T06:45:26","modified_gmt":"2026-08-22T11:45:26","slug":"bot-llm-workflow-for-optimal-code","status":"publish","type":"post","link":"https:\/\/davidwdrell.net\/wordpress\/?p=537","title":{"rendered":"Bot (LLM) workflow for optimal code"},"content":{"rendered":"\n

Bots will destroy your code if you let them.<\/p>\n\n\n\n

Always remember that bots have a limited memory context; the longer they work, the more they forget about the problem. You solve this by forcing them to write down information in local documents (mark downs) that you later force them to review from time-to-time.<\/p>\n\n\n\n

Also always keep in mind that they make mistakes, lots of them, depending on the quality of the model. Even the best model always makes mistakes. You fix this in two ways. 1) you the operator must be diligent to always review the design documents and the quality control documents (i.e. test plan). If you get these two right you will get a quality result. 2) The second thing you do is to get new bots to review the work
of the worker bot. The second bot always finds mistakes. At the end of this process there will always be some minor mistake around, but often much less than what a human programmer leaves around.<\/p>\n\n\n\n

You as the operator need to know good software design principles. These are too numerous to list here. Seek help on this front.<\/p>\n\n\n\n

When working in c++ (or pretty much any time you want good code), you must use the best most expensive bot available. Anything less will destroy your code or waste many, many hours (and tokens).<\/p>\n\n\n\n

Laziness as a developer results in bad code, do not get lazy on any of the required steps.<\/p>\n\n\n\n

Prompts:<\/p>\n\n\n\n

    \n
  1. Write a concise requirements document yourself. Try to think of everything about all the inputs\/outputs and states. Think about good design. If you cannot imagine a good design, do some research, find out how other people solved similar problems. Think about excellent test plans that prevent bug escape. Then ask a bot to review the requirements and expand on it. Tell the bot to ask clarifying questions. Then review the bots work. Answer its questions. Ask it questions. Bots will add fluff and create their own busy work. Reject some of its ideas. When it gets too wordy or wants to
    expand the work, pull it back. If you don’t like something, tell the bot you do not like it. Once you feel you have a tight requirements doc that does not overshoot, is not too wordy, is not pushing unnecessary fluff, then you are ready to move to the next step.<\/li>\n\n\n\n
  2. Background research is necessary for good design. Do your own research, read. Then tell the bot to list and review the relevant reference documentation. If you are working with libraries, download the library docs locally or ensure your bot can reach them on-line. If you are working with home-made libs, take the time to have your bots document them if they are not documented.<\/li>\n\n\n\n
  3. Create a design document. First start with your own words then have the bot elaborate and ask you questions. Make sure the bot draws diagrams (use mermaid) for time sequences and relationships. Review the diagrams. Ensure excellent thread design. Ensure excellent startup\/shutdown control. The design is critical. You will hold the bots accountable to the design documents for the life of the project. Get a fresh bot (no context) to do a design review. During each of the following steps, ask the bots to cofirm that other docs and code adhere to the design. Design deviations may be necessary, but they must be approved by you. At the point one of the most important and common prompts is: “You have dramatically overdesigned this. I gave you simple requirements and you exploded the project. Get another agent to review this design and find anything that is not essential to cut<\/strong>“.<\/li>\n\n\n\n
  4. Create a test plan document. The tests are the contract to make sure the software always performs as it should. Think carefully about this. Add functional stress tests (ask the bots to help you design tests that expose threading issues, expose I\/O issues, expose state issues). Review the test plan carefully, if this lets bugs escape, they will. Get a fresh bot to do a test plan review.<\/li>\n\n\n\n
  5. Ask the bots to create an implementation (milestone) plan. At each milestone there should be something testable and a final “milestone is completed when \u2026” statement. Human testing is also allowed. If possible, have the bots create test cases that intentionally fail at the start and then start passing as the code is implemented. Review the milestone plan. Get a fresh bot to review the plan. At the point one of the most important and common prompts is: “You have dramatically overdesigned this. I gave you simple requirements and you exploded the project. Get another agent to review this design and find anything that is not essential to cut<\/strong>“.<\/li>\n\n\n\n
  6. Tell the bot to implement the first milestone. When it says its done, get a fresh bot to do a code review. Make sure the reviewer knows about the requirements and design and other docs. You review the code-reviewers comments. If they are extensive, have it write them down in a code review document so it does not forget. Have the original coding bot fix the issues.<\/li>\n\n\n\n
  7. After each milestone ask the main coding bot to review the docs and to mark the milestone as completed. Go to the next milestone. Keep iterating like this over all the milestones.<\/li>\n\n\n\n
  8. When done, have the bots ensure that the local feature design doc is up to date and then have it do an upstream document review to ensure that project’s top level design documents link to the newly created feature requirements and design documents.<\/li>\n\n\n\n
  9. Finally, as part of the final code review, have the bots review the code against the original design and requirements documents. For the life of the project, this review process must be constant.<\/li>\n<\/ol>\n\n\n\n

    <\/p>\n","protected":false},"excerpt":{"rendered":"

    Bots will destroy your code if you let them. Always remember that bots have a limited memory context; the longer […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_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-537","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/davidwdrell.net\/wordpress\/index.php?rest_route=\/wp\/v2\/posts\/537","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=537"}],"version-history":[{"count":10,"href":"https:\/\/davidwdrell.net\/wordpress\/index.php?rest_route=\/wp\/v2\/posts\/537\/revisions"}],"predecessor-version":[{"id":563,"href":"https:\/\/davidwdrell.net\/wordpress\/index.php?rest_route=\/wp\/v2\/posts\/537\/revisions\/563"}],"wp:attachment":[{"href":"https:\/\/davidwdrell.net\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=537"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/davidwdrell.net\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=537"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/davidwdrell.net\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=537"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}