Share your best AI workflow. We could show it to 2M+ people.

Most AI agents are effectively static. You write their instructions, use them repeatedly, notice where they struggle, and manually tweak the prompt when something goes wrong. Valuable feedback from real work is often lost, so the same mistakes can keep happening. I created a self-improvement flywheel that uses actual agent performance data to improve agents over time. The system collects two kinds of evidence: - Task scores showing how well each agent performs across different quality dimensions - Run telemetry and review outcomes revealing recurring failures, coordination problems, and cases where actual behavior differs from expectations A scheduled weekly cycle analyzes that evidence, identifies patterns, creates improvement proposals, evaluates whether those proposals are safe and broadly applicable, updates agent instructions when appropriate, and measures whether those changes actually improve performance. The goal is not to let agents rewrite themselves freely. It is to create a controlled learning loop. Step-by-step: 1. Collect performance data while agents work. Score important outputs across consistent quality dimensions, and record useful execution telemetry such as failures, decisions, reviewer outcomes, and unexpected behavior. 2. Analyze performance trends on a recurring schedule. Calculate per-agent averages, identify weak dimensions, compare agents, and look for improvement or decline over time. 3. Mine run history for recurring patterns across multiple sessions, including agents that repeatedly struggle, low-quality runs, and cases where expected behavior differs from what actually happened. 4. Turn repeated problems into improvement proposals. Before proposing a change, inspect the agent’s current instructions so you do not add a rule that already exists. 5. Evaluate each proposal before applying it. Check whether the lesson is broadly useful, redundant with existing instructions, or in conflict with established behavior. 6. Separate low-risk and high-risk changes. Automatically apply additive or clarifying improvements. Escalate conflicting changes for human review instead of allowing the system to fundamentally change an agent’s behavior on its own. 7. Look for system-level problems. Analyze patterns across agents to identify quality gaps, missing capabilities, or coordination failures that cannot be fixed by changing one agent alone. 8. Apply approved improvements and preserve the history. Update the relevant agent instructions, archive the processed proposals, and version the changes so they remain inspectable and reversible. 9. Measure whether each change actually helped by comparing agent performance before and after the refinement. If quality does not improve, do not automatically assume the change was useful. 10. Repeat the cycle. As agents complete more real work, the system gathers more evidence and gets another opportunity to improve. Instead of treating agent instructions as static prompts, I turned them into a continuously improving system: Work → Evaluate → Find Patterns → Propose Changes → Refine → Measure → Repeat The important part is that the loop is evidence-driven and controlled. Agents improve from real usage, but low-confidence or behavior-changing updates still require judgment rather than being applied automatically.

AI agents are much more useful when they can remember important context across sessions. However, giving every agent access to one giant memory creates a different problem: irrelevant information accumulates, context becomes noisy, and agents waste time sorting through details that do not apply to their task. The challenge is not only giving AI memory. It is deciding what should be remembered, which agent should remember it, and where that memory belongs. I use a three-tier memory system that separates knowledge by scope: - Global memory: Information that should be available across the entire AI system - Agent memory: Knowledge specific to an individual specialist and how it should work - Project memory: Decisions, constraints, discoveries, and context that matter only within a particular project Instead of copying everything into every agent’s context, I store information at the narrowest level where it remains useful. Step-by-step: 1. Create a global memory layer for durable information that is useful across many agents and projects, such as important user preferences, shared conventions, and system-wide decisions. 2. Give each specialist its own memory. Store knowledge that helps a particular agent perform its role better, such as recurring preferences, domain lessons, and patterns learned from previous work. 3. Create project-specific memory for decisions, constraints, terminology, discoveries, current state, and other context that belongs with the project rather than in global memory. 4. Classify new information by scope. Whenever something worth remembering is learned, ask: - Does the whole system need this? - Does only this agent need it? - Does it matter only for this project? 5. Store the information at the narrowest useful level. Avoid promoting project-specific details into global memory unless they are genuinely reusable elsewhere. 6. Have agents load relevant memory before they work. A specialist can combine its accumulated knowledge with the current project context instead of starting every session cold. 7. Update memory as important decisions are made. Persist decisions and reusable lessons rather than relying on conversation history to remain available indefinitely. 8. Keep historical artifacts separate from active memory. Run logs, old handoffs, and detailed history can remain available for reference without automatically loading into every future interaction. Instead of treating memory as one giant bucket, I create a hierarchy: `Global → Agent → Project` Each agent gets the context it actually needs while unrelated information stays out of its working context. This provides better continuity across sessions, reduces repeated explanations, keeps context cleaner, and helps AI agents accumulate useful knowledge without requiring every agent to remember everything.

Most AI agents start with someone writing a prompt from scratch. I wanted a better way. So I built an Agent Creator. I describe the kind of agent I need, and it determines whether I actually need a new one, figures out how that agent should work, creates it, and adds it to the rest of my agent team. Step-by-step: 1. I describe what I need by telling the Agent Creator what I want the new agent to do. 2. It checks what already exists by reviewing my existing agents and skills. If something already does most of the job, it recommends improving or reusing that instead of creating another overlapping agent. 3. If a new skill is needed, it researches the role, including current best practices, common mistakes, useful tools, and what good work looks like in that area. 4. It creates the agent by defining its job, required information, outputs, available tools, and the steps it should follow. 5. It gives the agent the right skills by creating or reusing supporting skills, including examples, reference material, and checks that help it work consistently. 6. It sets clear boundaries so the agent knows what it should handle, what it should not handle, and when another agent should take over. 7. If the new agent belongs in an existing workflow, it adds the agent to the team by updating the handoffs so the other agents know when to use it. 8. Before finishing, it checks the agent’s work by running validation checks to confirm that the new agent follows the standards I’ve set for the whole team. The result is that I don’t have to manually design every new agent from scratch. I can describe the kind of help I need, and one agent can research the role, create the new specialist, connect it to the rest of the system, and make sure it’s ready to use. In other words, I built an AI agent that can help grow its own team.

AI coding tools can build quickly, but they can also build the wrong thing quickly. Starting implementation from a vague feature request leaves important decisions about scope, architecture, edge cases, success criteria, and expected behavior to be made implicitly during coding. I created a spec-generator agent that sits between an idea and implementation. I give it a feature request, product vision, or rough description of what I want to build. It investigates the existing project, identifies missing decisions and constraints, researches external dependencies when necessary, and turns the request into a detailed specification that another AI agent can implement without having to guess what I meant. The finished specification becomes the source of truth for the rest of the development workflow. Step-by-step: 1. I give the spec-generator the feature or product idea I want to build, along with any existing requirements, vision documents, or constraints. 2. I have it inspect the existing project before proposing a solution. It needs to understand the current architecture, conventions, capabilities, and relevant prior decisions rather than designing the feature in isolation. 3. I have it identify ambiguities and missing decisions, including questions about users, behavior, scope, dependencies, edge cases, data requirements, integrations, and what is explicitly out of scope. 4. I have it research external technologies, APIs, libraries, or platform capabilities when the design depends on facts that cannot be determined from the repository alone. 5. I have it translate the idea into a layered specification: first the product purpose and desired outcomes, then the technical architecture, and finally the detailed implementation requirements. 6. I have it define measurable success criteria and acceptance tests so that “done” means something concrete rather than simply “the code was written.” 7. I have it persist the finished specification in the project so developers or coding agents can treat it as the source of truth during implementation. 8. I pass the specification through a separate review or validation step before coding begins, resolving gaps or contradictions in the spec rather than discovering them halfway through implementation. Instead of asking an AI coding agent to interpret a rough idea while it writes code, I separate figuring out what should be built from building it.

This workflow keeps software development human-led while using AI without giving up engineering control. Step-by-step: 1. Inspect the real project: its current behavior, architecture, constraints, repository state, and existing tests. 2. Define one observable outcome, along with acceptance criteria, scope, non-goals, risks, and stop conditions. 3. Decide where the change belongs architecturally before asking an AI assistant to write code. Record consequential decisions. 4. Split the goal into the smallest independently useful, reviewable, and reversible vertical slice. Keep refactoring and unrelated cleanup separate. 5. Give the AI assistant one bounded implementation prompt. Require it to follow existing conventions, add focused tests, report assumptions, and stop if it discovers conflicting requirements or broader scope. 6. Run targeted tests and relevant regression checks. Validate the change in the environment that matters, clearly distinguishing automated checks from manual or real-world acceptance. 7. Have a human review the actual diff, evidence, error paths, security implications, and documentation. AI output remains a proposal until a person accepts it. 8. Update the documentation with the behavior, decisions, limitations, and validation evidence. 9. Create one coherent, reversible commit, then repeat the loop for the next small slice. The complete methodology, reusable prompts, templates, examples, and release checklist are published at https://github.com/d-wendel/human-led-ai-engineering

I never ask AI to “build the app.” I move the work through a fixed assembly line, and the most valuable stations are the ones whose only job is to attack what came out of the previous station. I’m a solo developer, and this is how I build and ship software for paying clients without a team to catch my mistakes. I choose the next chunk of work—a “phase”—and run one command. Each phase gets its own fresh context window, which matters more than any single agent because a long-running session gradually forgets its own rules. Step-by-step: 1. I discuss the phase with an agent that interrogates me until every gray area is decided. The decisions go into a file instead of staying in chat, where they can get lost. 2. A planner writes an executable plan covering the tasks, files to be changed, a threat model, and the acceptance checks that will prove the work succeeded. 3. A different agent, working from a fresh context, checks the plan by working backward from the goal and trying to prove that the plan will not achieve it. This agent can block the phase, and regularly does. 4. I execute the plan task by task, making one atomic commit for each task so the changes can be reverted cleanly. 5. I send the diff to a different model than the one that wrote it. I run Codex and CodeRabbit alongside Claude. This is the highest-value station in the line: my own tests verify only what I thought to check, while an independent model can catch the class of problem I did not anticipate. 6. An agent verifies whether the phase goal was achieved by re-deriving it from the actual code. “All tasks completed” and “the thing works” are different claims. Treating them as the same is how you ship a green checklist on top of a broken feature. 7. Before anything reaches a client, I run a security and handoff audit in a real browser against a throwaway clone of the production database. I check every page, every button, and every empty and error state. The part that compounds is what happens when a bug reaches me anyway—whether I find it in production or, worse, a client reports it. I log it as an escape, then walk the chain backward and ask each gate why it missed the problem: the planner, plan checker, executor, both reviewers, verifier, security check, and handoff audit. A one-off escape becomes a written rule. A repeat becomes a change to the gate itself. I have 42 logged escapes. That file is the most valuable thing I own because every entry represents a hole that is now closed. The pipeline I run today is mostly shaped by bugs that got past the pipeline I ran a year ago. The results so far: 29 projects, 17,657 commits, and 574 phase folders. I’ve completed six client engagements, with apps live in production and handed off to their owners, as well as mobile apps built and pushed through App Store review—all as one person, with no team. There are real costs and failure modes. A phase with every gate enabled costs meaningfully more tokens than simply asking a model for the code. That is worth it on client work, where a bug can cost me a relationship, but it is overkill for a throwaway script, so I turn the gates off for those. Gates can also be confidently wrong. My most expensive recurring failure is a check that passes on a signal adjacent to the thing it claims to verify—a green light that means nothing. My rule now is that I do not trust a new check until I have watched it fail against known-bad input. A green result you have never seen turn red is not evidence. A green test suite is not the same as a working feature. Nearly every bug that escaped me was covered by a passing test whose mock had quietly pre-satisfied the exact condition under test. Testing the real boundary is the only thing that catches those failures. This process is not hands-off. I deliberately run one phase per session, and I read what comes back. Anyone selling a fully autonomous overnight build is selling a merge conflict plus a confident summary of work that did not happen. If you want to take one idea from this, it is not the framework. The agent that writes the work must never be the one that approves it. Keep a running log of everything that gets through anyway, then fix the checkpoint that let it through instead of only fixing the bug.

This Codex-driven workflow takes a software request from problem understanding through implementation, validation, review, and delivery evidence. Instead of asking an AI coding agent to simply “build the feature,” it gives the agent an explicit development lifecycle with defined responsibilities, deterministic validation gates, repair loops, and human checkpoints. The goal is to make AI-assisted development more structured, observable, and recoverable. It can be used for new feature implementation, bug fixing, refactoring, test creation and improvement, code quality and security hardening, and documentation and automation changes. The core principle is simple: Don't give the AI only a coding task. Give it an engineering lifecycle to work on. Step-by-step: 1. Understand the problem. Clarify the request, identify the desired outcome, define the scope, and surface ambiguity before implementation begins. The output is problem understanding and scope. 2. Define constraints. Identify technical, functional, non-functional, compatibility, and out-of-scope constraints. The output is a constraint set. 3. Plan. Analyze implementation options, select an appropriate approach, break the work into tasks, and define acceptance criteria. The output is an implementation plan. 4. Inspect the existing system. Review the relevant codebase, dependencies, current behavior, and affected components before making changes. The output is system context. 5. Implement. Make the smallest appropriate code changes while following the existing project’s conventions and the approved plan. The output is code changes. 6. Run deterministic validation. Run tools that can objectively validate the implementation, including formatting, linting, type checks, builds, unit tests, and other available automated checks. The output is validation results. 7. Review. Evaluate the implementation against the original requirement, the plan, code quality expectations, security considerations, and potential regressions. The output is review findings. 8. Repair and iterate. If validation or review identifies problems, diagnose the issue, make the required correction, and repeat validation. The output is a corrected implementation. 9. Verify. Confirm that the acceptance criteria are satisfied and that the relevant tests and checks provide sufficient evidence for completion. The output is a verification result. 10. Produce delivery evidence and handoff. Summarize what changed, what was tested, what passed, known limitations, and any remaining decisions requiring human attention. The output is delivery evidence and a human handoff. The core loop is: Implement → Validate → Review → Repair → Validate → Verify. Testing and review are treated as part of development rather than activities performed only after coding is “finished.” AI coding agents are increasingly capable of inspecting repositories, writing code, running commands, and responding to failures. The problem is that capability alone does not provide an engineering process. This workflow separates the responsibilities an AI coding agent performs into explicit stages. It applies several principles: - Problem before implementation: Understand what needs to change before writing code. - WHY before HOW: Establish the intent and constraints before choosing an implementation. - Single responsibility per stage: Give each stage a defined purpose and output. - Deterministic validation first: Use tests, linters, type checkers, builds, and other deterministic tools wherever they can establish correctness. - Failure localization: When something fails, identify which stage or assumption needs correction. - Evidence-based completion: Support completion with validation and review evidence rather than an AI declaration that the task is finished. - Human checkpoints: Use automation to accelerate execution without removing human judgment from important decisions. The broader idea is: The AI should participate in the engineering system, not become the engineering system.

I have a Daily Brief agent on Codex with access to my Slack, Gmail, Notion, and Google Drive that checks everything that happened in the last 24 hours on request. It sends me the brief through Slack, and I do maybe 10% of the final manual editing. I also gave it several examples of before/after editing, so now it sends messages in my exact voice and style. Step-by-step: 1. I connected my Daily Brief agent in Codex to Slack, Gmail, Notion, and Google Drive. 2. I told it to review activity from the last 24 hours and pull out the items that actually needed attention. 3. I structured the output as a concise brief and had Codex deliver it through Slack. 4. I manually reviewed the draft and made the final edits before using it. 5. I gave the agent before-and-after examples of those edits so future briefs would sound more like my own voice.

AI agents can generate impressive work quickly, but the agent that created something is not necessarily the best judge of whether it is correct, complete, secure, or ready to move forward. Without an independent review step, mistakes can compound as later stages build on work that was never properly validated. I created a system of specialized AI review agents that act as quality gates between stages of work. Instead of letting the agent that performed the work decide whether it is finished, a separate reviewer evaluates the output against explicit criteria and makes a gate decision: PASS or NEEDS REVISION. Different reviewers focus on different dimensions. In my software development workflow, I use reviewers for implementation fidelity, code quality, security, performance, and specification compliance. A feature does not advance until the required reviewers have passed it. Step-by-step: 1. Define what “good” means before the work starts. Give reviewers an explicit source of truth, such as a specification, plan, acceptance criteria, coding standards, security rules, or quality rubric. 2. Separate execution from evaluation. The agent that performs the work should not be the only agent deciding whether that work is acceptable. 3. Create specialized reviewers for important quality dimensions. For software, this might include implementation, code quality, security, performance, and specification reviewers. The same pattern can be used for research, writing, factuality, compliance, financial analysis, or brand review. 4. Run the appropriate reviewers when a stage is complete. Each reviewer independently inspects the work from its assigned perspective and actively looks for reasons it should not advance. 5. Require an explicit gate decision. A reviewer must return either PASS or NEEDS REVISION, along with concrete findings and recommended fixes. In my workflow, reviewers can block progression for issues such as missing tests, even when the underlying implementation appears correct. 6. Route failed work back to the appropriate agent. The worker fixes the identified problems and submits the work for review again. 7. Advance only after the required gates pass. Later stages should not build on work that still has unresolved review findings. 8. Keep humans at consequential decision points. AI reviewers can determine whether work satisfies their assigned criteria, but important actions such as merging, deploying, publishing, or otherwise committing the result can remain human decisions. Instead of treating AI-generated work as complete simply because an agent produced it, I create a controlled loop: Build → Review → Fix → Re-review → Pass → Advance The result is a more reliable workflow where specialized agents perform the work, independent agents challenge it, and errors are caught before they propagate into later stages.

Customer events trigger AI workflows that classify requests, automate actions, update systems, and keep teams in sync without manual intervention. Step-by-step: 1. Customer events trigger the AI workflows. 2. The workflows classify requests. 3. They automate actions and update systems. 4. They keep teams in sync without manual intervention.

Having a team of specialized AI agents creates a new problem: someone still needs to decide which agents should work on a project, what order they should work in, what each one needs from the others, and whether the project is actually finished. Without coordination, the human becomes the project manager, manually moving context and outputs between agents. I created a project-manager agent that acts as the orchestrator for my AI team. I give it an objective, and it determines what work needs to happen, selects the appropriate specialist agents, sequences their work based on dependencies, and presents the execution plan to me before anything starts. Once I approve the plan, it coordinates the agents, manages their handoffs, tracks project state, and maintains enough persistent context for the work to continue across sessions. Step-by-step: 1. I create several specialized agents with clearly defined responsibilities, capabilities, and expected outputs. 2. I create a project-manager agent that knows what each specialist does and is instructed to orchestrate the work rather than perform specialist work itself. 3. I give the project manager a high-level objective. It analyzes the goal, inspects the project context, identifies the required work, and selects the appropriate agents. 4. I have it create an execution plan showing which agents will be used, what each one will do, their dependencies, and the order of execution. 5. I require human approval before execution begins. I can approve the plan, narrow the scope, change the sequence, or redirect the project as needed. 6. Once the plan is approved, I let the project manager delegate each task to the appropriate specialist and pass relevant context and prior outputs between agents through structured handoffs. 7. I track progress and project state as the agents complete their assignments. If an agent uncovers new work, fails review, or changes the project assumptions, the project manager updates the plan and routes the next work accordingly. 8. At the end of the session, I save the current state, completed work, important decisions, and next actions so another session can continue without reconstructing the project from scratch. Instead of personally coordinating every AI agent, I manage the project at a higher level: I define the objective, approve the plan, review important decisions, and evaluate the result. The AI project manager handles the coordination layer, turning a collection of specialized agents into a team that can execute complex, multistep projects coherently.

I created an agent collaboration system called duo-agents that pairs Claude and Codex to work together on coding tasks... Claude acts as the implementer (coder), then Codex acts as the reviewer (checks and makes edits). They alternate in rounds, communicating through a shared file. The key difference: both agents actually edit files — the reviewer doesn't just leave comments, they make the fixes themselves. Describe your task and watch them iterate until the code is solid. Step-by-step: 1. I created a shared file that both coding agents could use to pass context and decisions back and forth. 2. I assigned Claude the implementer role and had it build the requested change directly in the codebase. 3. I assigned Codex the reviewer role and had it inspect the implementation for problems. 4. Instead of leaving comments, Codex edited the files and made the fixes itself. 5. I alternated the two agents in rounds until the shared task was complete and the code was solid.

Michigan Campaign Finance Explorer turns public Michigan campaign-finance records into a user-friendly, searchable research tool. It automatically collects and validates official filings, then lets users compare candidates, trace transactions, explore races on a map, and visualize how money moves between campaigns, PACs, donors, and vendors—all with links back to the original records. The current public system only allows you to look up records one at a time, and you have to know what you’re looking for. I built a tool called Filing Radar to make that process more useful. Every 20 minutes, it searches all filings using Python’s built-in `urllib.request`. It compares filing IDs with those saved during the previous check. If a filing is new, it downloads it; otherwise, it moves on. For each new download, a parser built with `pypdf` processes the PDF and sends the data to a local SQLite database. I was concerned about overloading the public website with requests, so I also built a circuit breaker and added a limit on requests per second. I also built another tool called Vendor Resolver. Campaigns often record the same vendors in slightly different ways, such as “Little Caesars” and “Little Caesar’s.” Vendor Resolver groups transactions that are likely associated with the same entity and assigns a confidence score. It then ranks the groups by impact so the most useful matches are easier to review manually. Together, these tools make the site more useful when I’m trying to determine which PACs are connected to particular campaigns. Step-by-step: 1. I searched all filings every 20 minutes with Python’s built-in `urllib.request`. 2. I compared the filing IDs with those saved during the previous check and downloaded only new filings. 3. I processed each new PDF with `pypdf` and stored the results in a local SQLite database. 4. I used a circuit breaker and a requests-per-second limit to avoid overloading the public website. 5. I grouped differently named vendors, such as “Little Caesars” and “Little Caesar’s,” and assigned confidence scores to likely matches. 6. I ranked those matches by impact so I could review the most useful ones manually. 7. I used the resulting data to identify connections between PACs and campaigns.