{"slug": "ai-made-me-faster-at-building-but-it-also-gave-me-more-to-supervise", "title": "AI Made Me Faster at Building—But It Also Gave Me More to Supervise", "summary": "A developer with over 35 years in IT built Issue Flow, an agent-orchestration workflow that takes a vague bug report or enhancement from initial description toward production, gathering evidence such as screenshots, network activity and logs, identifying the likely root cause and responsible repository, and creating sub-issues while accounting for dependencies and concurrency. The developer says existing tools like Copilot agents, Cursor and Kiro each solved only part of the problem, and that AI-assisted coding shifted the bottleneck from code generation to supervising and coordinating agent work. Issue Flow was treated as a product in its own right by May 2026, after earlier versions suffered agent crashes, unreliable task-completion detection and inconsistent capacity management.", "body_md": "I did not set out to build Issue Flow as a product.\n\nI built it because I was frustrated...\n\nIn September 2025, I was developing a large product while working a demanding full-time job. This is a product I was planning to build for a long tine, but never had the bandwidth. AI had opened up a new kind of possibility: I could make meaningful progress in the limited time I had outside work. With an IDE, a chat interface, and early coding agents, I started building piece by piece.\n\nBut as development accelerated, a different problem appeared.\n\nThe agents could help write code. They could help investigate. They could help with individual tasks.\n\nWhat they could not do was run my entire development process in a way I trusted. With over 35 years in IT, I have my quality requirements I did not want to compromise on.\n\nI tried the tools that were emerging at the time: Copilot agents, Cursor, the Kiro, and others. Each solved part of the problem. But none gave me what I actually needed: a way to orchestrate work from ideation through deployment, while involving me only when my judgment was truly needed. Later, when the product was testable, the problem increased - bug reports came with very vague language, so I had to replicate them one by one to recreate the issue myself.\n\nI did not want to spend my limited time babysitting prompts.\n\nI wanted to decide where the human checkpoints belonged. I wanted agents to keep moving through clear work and call my attention when there was a decision, a blocker, a quality concern, or a meaningful tradeoff.\n\nThat was the beginning of Issue Flow.\n\nWhen people talk about AI-assisted development, the conversation often centers on how quickly an agent can generate code.\n\nThat matters. But once you are working on a real product, code generation is only one small part of the process.\n\nSomeone still has to understand an issue. Someone has to determine which repository owns it. Someone has to investigate the root cause, consider dependencies, sequence work, validate the result, and decide whether it is ready for production.\n\nNew features came with their own challenges: intent alignment, business value, multi-repo coordination, understanding the persona, and other challenges the AI could not do on its own - not at the quality I needed.\n\nFor a builder with limited time, this coordination becomes the bottleneck.\n\nAt first, I created something simple for my own workflow: a way to orchestrate agents around the steps I was already taking. I designed it to stay flexible because I knew my process would evolve as the product evolved.\n\nAnd it did.\n\nThe early versions had plenty of problems. Agents could crash. Detecting a completed task was not always reliable. Capacity management was inconsistent. Each failure exposed another part of the workflow that needed to become more resilient.\n\nBy May 2026, I realized I needed to take it seriously as a product in its own right.\n\nI gave it a name: Issue Flow.\n\nThe need became even clearer when my original product, Aligned on Purpose, reached the stage where testers could use it.\n\nTesters reported issues from their own perspective, as they should. But a report such as “this screen is not working correctly” does not tell a developer whether the problem lives. Is it in the frontend, the backend, an API contract, or a different repository altogether?\n\nI found myself doing so much manual research that it sometimes felt faster to test the whole product myself.\n\nSo I expanded Issue Flow.\n\nIt could take a vague issue, gather available evidence such as screenshots, network activity, and logs, determine the likely root cause and responsible repository, and create the appropriate sub-issues. It could account for dependencies and concurrency before moving work into the system.\n\nOver time, it became a workflow that could take a bug report or enhancement from the initial description toward production, while bringing me in only where I could contribute real value.\n\n**That distinction matters.**\n\nThe goal is not to remove humans from development. The goal is to make human involvement intentional.\n\nAs Issue Flow became more capable, I ran into another challenge: cost.\n\nMore automation meant more work could move at once. More work meant more token usage. Eventually, a quota limit could stop a workflow in the middle of its progress.\n\nSo I added another layer of orchestration: choosing models based on issue complexity, recognizing quota limits, and switching to another available agentic framework when appropriate.\n\nIssue Flow is not meant to lock people into one AI provider or one way of working.\n\nWhether someone prefers Gemini, Copilot, Claude, Cursor, OpenCode, or another framework, they should be able to design a workflow that matches how they work. They should be able to define their own quality gates, approval points, escalation paths, and budget controls—without maintaining a maze of configuration files.\n\nToday, I use Issue Flow to build Aligned on Purpose.\n\nI also use Issue Flow to build Issue Flow itself.\n\nThat is the most meaningful validation I could ask for. What started as a personal solution for building alongside a full-time job has become a product for other developers and teams facing the same reality.\n\nAI can make us dramatically faster.\n\nBut speed alone is not the answer.\n\nThe real opportunity is to build workflows where quality stays protected, budgets stay visible, and people are involved exactly where their experience and judgment matter most.\n\nThat is why I built Issue Flow.", "url": "https://wpnews.pro/news/ai-made-me-faster-at-building-but-it-also-gave-me-more-to-supervise", "canonical_source": "https://dev.to/mottych/ai-made-me-faster-at-building-but-it-also-gave-me-more-to-supervise-l22", "published_at": "2026-09-25 15:34:06+00:00", "updated_at": "2026-09-25 16:01:21.953676+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "mlops", "ai-products"], "entities": ["Issue Flow", "Aligned on Purpose", "GitHub Copilot", "Cursor", "Kiro"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/ai-made-me-faster-at-building-but-it-also-gave-me-more-to-supervise", "markdown": "https://wpnews.pro/news/ai-made-me-faster-at-building-but-it-also-gave-me-more-to-supervise.md", "text": "https://wpnews.pro/news/ai-made-me-faster-at-building-but-it-also-gave-me-more-to-supervise.txt", "jsonld": "https://wpnews.pro/news/ai-made-me-faster-at-building-but-it-also-gave-me-more-to-supervise.jsonld"}}