保哥：體驗未來的AI Coding新世界

1. In one sentence

Duotify turns "requirement into code" into a pipeline: a Microsoft Forms submission feeds a work item in Azure DevOps, and an "agent" they built themselves — running Claude Code underneath — opens the branch, writes the code and opens the PR, while humans only write the requirement clearly and do the final code review.

2. The session

The speaker's background, checked afterwards

The slide cover reads "多奇數位創意有限公司　技術總監　黃保翕 (Will 保哥)", the same person the host introduced as "everyone's 保哥", and the INSIDE interview introduces him with the same company and title. He has been a Google Developer Expert (GDE) for Angular and web since 2018; checking further, in 2024 he was named a GDE again for generative AI, so he holds expert status in two technical categories at once. The host said in the introduction that he had been a Microsoft MVP "for 17 consecutive years"; checking his own public profiles afterwards, the numbers are chaotic enough to be funny — the card on his blog homepage says 15, about.me says 18, his GitHub profile README says 19 (with a table reading "2006 – Present"), and one instructor page on the company site still carries an old "10 consecutive years". The MVP title renews annually with the nomination cycle, so these numbers probably sit on different snapshots in time, and the pages clearly are not kept in sync. The closest account for that day (May 2025) is the host's 17, which is what these notes use; the other versions and their links are listed in section seven for anyone who wants to check, and no ruling is made here — there is no attempt to "calibrate" a single correct answer on his behalf.

The path he drew for AI in software engineering

He opened with a roadmap, pulling software development into three stages: hand-written code (developers typing it themselves) → AI-assisted code generation (IDE IntelliSense, and in recent years GitHub Copilot, Cursor and Windsurf generating whole blocks while the engineer still watches) → outsourcing development to an agent (handing over the whole task and no longer watching line by line). He described the feeling at that turn as peculiar: you used to read the ten or twenty lines the AI generated before clicking next, but working in the agent era is more like "outsourcing a job" — you state the requirement clearly and the other party hands the result back, and whether you are satisfied depends on whether they told you *what they did*. That line foreshadows his whole session: if the agent just throws a bundle of code back and explains nothing, engineers will not dare take it on and maintain it.

How a requirement flows into the agent's hands

Duotify runs Scrum on Azure DevOps (he was careful to say GitHub, GitLab or anything else works equally well; this is just what the company happens to use). The flow:

1. The product manager or the engineer who owns the requirement opens a Task/Bug/PBI in Azure DevOps and fills in the title and the work description — those two fields are the AI's most basic context, sometimes with a screenshot attached.
2. The engineer then writes a prompt into a template he designed, saves it as a Markdown attachment (76427.md, say) and attaches it to that work item.
3. They fill in a "coding agent request form" he built (Microsoft Forms), selecting the repository to hand over (front end and back end separately), the base branch (most projects always start from a particular development branch), the target branch (a new branch name that does not exist yet, such as phase2-feature1), the work item ID, and the name of the attachment just saved.
4. On submission the agent comments on the work item to say it has started, and a few minutes later comments again to say development is complete, with a full execution summary attached.

The most interesting thing on the form is a note he wrote himself: "The clearer the requirement spec, the better the AI performs. Practise your prompting with GitHub Copilot's Agent mode first, and only hand development over to the Duotify coding agent once your prompt is reasonably reliable." In other words, GitHub Copilot's Agent mode is where engineers practise prompting inside their own IDE until they are confident, and only then do they hand real development, via the form, to the internal agent that genuinely modifies the repository, opens branches and files PRs (its display name in Azure DevOps comments is "Duotify Coding Agent"). This also echoes the point the host made in the opening: using GitHub Copilot as an MCP (Model Context Protocol) client to call their own MCP server wired into Azure DevOps, so the agent gets the work item's full context and can get on with it.

The deliberate psychology behind the form

The form says "each run costs roughly US$3 to US$6", and he admitted this is a deliberately inflated psychological tactic — "I wrote it expensive on purpose so they don't fill it in carelessly, otherwise every submission burns three or five dollars of mine." His blunt observation: engineers write their own prompts casually, two lines to see what happens, rewrite if it is wrong; but you cannot treat an agent that way. If you outsource a job today without stating the requirement clearly, what comes back is garbage, and neither the agent nor you will be happy. So he uses the psychological suggestion of expense to force engineers — "the clients of the future", as he calls them — to write the requirement properly.

From "started" to a human taking over

He showed an actual work item (ticket 76427, a requirement to add a "system category" dropdown): the agent took 5 minutes 14 seconds at a cost of about US$1.26 (which he converted to "under NT$40") to get the PR open. The PR shows the agent's full reasoning: which API it added, which methods it put in which controller, service and mapper, what it changed in the query and update logic — laid out step by step, satisfying the three points in the requirement. He stressed why this matters: an engineer taking that over is *happy* to see that write-up, because they do not have the usual experience of git log showing a dozen changed files with nobody explaining why — which just leaves you bewildered. A human engineer later added two fix commits on top of the agent's commit on that ticket, a textbook piece of human-machine collaboration; he also showed another case where the agent's PR was merged directly without a single line changed. He put "over 50% of pull requests are 100% correct" on the slide and showed a long list of PRs finished simultaneously and merged as-is — a picture he described as "a whole row of agents working at once", which lands harder than any single case passing cleanly.

Front-end engineers can fix back-end bugs too

This was the most interesting extension of the session. The absurd situation they used to hit: in a front-end/back-end split project, back-end bugs were often debugged by the front end. The front end only owns UI and interaction, and its only connection to the back end is calling its API — but when the API does not return the right data, which is plainly a back-end problem, the debugging pressure lands on the front end. His fix was a separate Microsoft Forms letting front-end engineers describe the problem purely from what the front end can observe: which API endpoint was called, what JSON payload was sent, that the response was HTTP 500, and then simply "observed that the API is not returning data sorted by a given parameter". The instruction to the agent is equally plain: "Find out why this can't return data by this parameter; if you can't find the exact cause, explain your investigation approach and the likely failure points; if you do find it, fix it." The front-end engineer never touches Java and never needs to know what the database looks like. He said this new flow hits the same result: over 50%, 100% correct, mergeable as-is.

The tooling underneath, and a release from the previous night

He named the tool running underneath directly: Claude Code (Anthropic's terminal- and IDE-integrated coding agent). He also ran through the contemporaneous competition: when OpenAI Codex CLI shipped about three weeks earlier he thought it was "no different from garbage, too many bugs and too slow", while the version released the previous week was considerably better. And the night before he went on stage, Anthropic had released a new model generation he called "Claude 4.0" — verified afterwards as Claude Opus 4 and Claude Sonnet 4, released on 22 May 2025, exactly the night before he spoke on 23 May. He admitted on stage he had not had time to test it.

Next: skip the form, tag the agent in the work item

He previewed an optimisation in progress: today you still have to fill in the form to submit a requirement, but from the following week you will be able to tag his coding agent with an @ in a comment on the Azure DevOps work item, write the problem there, and press enter to save — no separate form run. He framed the point of this direction as "who gets to participate in software development": product managers, planners, front-end engineers, back-end engineers and testers can each assign tasks to the agent directly in this flow and contribute their own value, rather than development being driven only by people who write code. He also mentioned an advanced course he was running the following Wednesday, on how to optimise this approach further.

Filled in afterwards: how he frames this elsewhere

In his INSIDE interview he puts the attitude behind this session more plainly: he sees plenty of engineers resisting or misunderstanding AI tools, still using them for fiddly details rather than for the higher-abstraction work they should be doing. He argues the developer's role is shifting from "writing code" to "reviewing AI-produced code", but the responsibility has not shifted with it — whether or not the code was AI-generated, if it goes out under your name you have to understand it and answer for it. He also offered a bleaker observation: junior engineers may find it harder to get hired, because they often cannot articulate a requirement and over-reliance on AI has eroded the very skill of describing a problem precisely. That is the same logic as his repeated insistence in this session that you cannot write sloppy prompts for an agent, seen from the other side.

3. Figures and cases

• The form estimates US$3 to US$6 per run (speaker's own account, no external source — a deliberately designed psychological figure).
• Ticket 76427 (adding a system category dropdown): the agent ran for 5 minutes 14 seconds at a cost of about US$1.26 (speaker's own account, no external source).
• "Over 50% of pull requests are 100% correct" and mergeable as-is, repeated for both the general case and the front-end-covering-back-end debugging case (speaker's own account, no external source).
• Claude Opus 4 and Claude Sonnet 4 were released on 22 May 2025 (Anthropic announcement), matching his "last night".
• Angular/web GDE since 2018, plus a 2024 GDE for generative AI (blog.miniasp.com; about.me).
• Consecutive years as a Microsoft MVP, with four public sources disagreeing: the host said 17 on stage, the card on his blog homepage says 15, about.me says 18, his GitHub profile says 19 (table marked 2006 – Present); another instructor page on the company site still carries an old "10 consecutive years".

4. Lines worth keeping

• "If what comes back from your outsourcing is only a pile of code, are you going to be happy?"
• "In a moment you'll see how our company does it: all code development originates from a requirement."
• "I wrote it expensive on purpose so they don't fill it in carelessly."
• "Today one ticket — the AI finished it and it merged straight away, not a line of code changed. How does that feel?"
• "A whole row of agents starting work at once — *that's* the feeling."
• "If you're outsourcing to an agent, you have to write the requirement clearly, right?"
• "Who gets to participate in software development? Product managers, planners, front-end engineers, back-end engineers, testers — everyone can contribute their value inside our software development process."

5. Tools and terms mentioned

• **GitHub Copilot and Agent mode**: GitHub's AI coding assistant; Agent mode lets it modify code across files, run terminal commands, call external tools and support MCP servers. He recommends practising prompting in this mode first.
• **Model Context Protocol (MCP)**: the open protocol connecting AI applications to external data and tools; he described it as the interface foundation of his whole agent architecture, and it is the technical background to the host's remark about "GitHub Copilot as an MCP client calling a self-built MCP server".
• Duotify Coding Agent: the automated coding agent his company built internally, wired into Azure DevOps work items and Microsoft Forms, with Claude Code as the execution engine.
• **Claude Code**: Anthropic's agentic coding tool, which he named directly as the engine behind the internal agent.
• **OpenAI Codex CLI**: OpenAI's terminal coding agent, which he compared against Claude Code.
• **Claude Opus 4 / Claude Sonnet 4**: the new model generation Anthropic released the night before he spoke, his "Claude 4.0".
• Cursor, Windsurf: two other AI-assisted coding IDEs he mentioned as examples of how tooling has evolved in recent years.
• Azure DevOps: Microsoft's DevOps platform, which Duotify uses to manage Scrum work items (Task/Bug/PBI), branches and pull requests.
• Scrum: the agile framework the company adopted ten years ago, on which all their project processes are built.

6. Wider observations

The real point here is not "AI can write code" but that he turned the whole thing into an enterprise-grade pipeline with financial incentives and review gates: the form deliberately overstates the cost so engineers write the requirement seriously, the agent must leave a readable account of its reasoning so a human dares take it on, and code review is always the last gate. That is nothing like the community narrative of "one person builds an entire product alone with AI"; it is much more like taking the rules an organisation already knows about working with an outsourced team and applying them, unchanged, to working with an AI agent. The segment where a front-end engineer can get a back-end bug fixed with a form that only describes symptoms was the most practical demonstration of the day: separating "the technical detail you don't need to know" from "the information the AI needs" solves the problem faster than forcing everyone to become a full-stack engineer.

7. Sources