{"slug": "prompt-driven-development-building-with-github-copilot-coding-agents", "title": "Prompt-Driven Development: Building with GitHub Copilot Coding Agents", "summary": "Microsoft engineer Dean Hume used GitHub Copilot coding agents to build a working application with colleagues across time zones at Microsoft's annual global hackathon, including contributors who were not developers, and said the result was \"not that far off from launch.\" Hume described the approach as \"prompt-driven development\" — structured natural-language instructions that direct coding agents while unit tests, repository custom instructions, agent skills, pull requests and Copilot code review verify the output — distinguishing it from vibe coding. He credited the practice to a post by Laurie Voss arguing that AI users are \"all product engineers now\" because the cost of writing code has collapsed.", "body_md": "23 September 2026 · Dean Hume\n\n# Prompt-Driven Development: Building with GitHub Copilot Coding Agents\n\nAt Microsoft, we host a global hackathon once a year. It's a great opportunity for people to come together, experiment with ideas, and build things that might make life a little easier.\n\nHackathons have traditionally attracted people who are comfortable writing code. You might have a designer or subject matter expert on the team, but sooner or later an idea would need to pass through a developer before it became a working feature.\n\nAI is beginning to change that.\n\nFor our most recent hackathon, I worked with colleagues in different time zones to build an application using GitHub Copilot coding agents. Some of the people contributing weren't developers, yet they were still able to take an idea, describe the behaviour they wanted, and turn it into working software.\n\nThe AI generated the code, but I wouldn't describe what we did as vibe coding.\n\nWe had unit tests. We had repository instructions and skills. We worked through pull requests, and we used GitHub Copilot to review the changes before they were merged.\n\nThe prompts might have driven the development, but engineering practices kept it on the road. At the end of the Hackathon, I was proud to say that we had a working product that wasn't that far off from launch.\n\n## What is prompt-driven development?\n\nThis got me thinking about a post that I read lately from [Laurie Voss](https://seldo.com/posts/we-are-all-product-engineers-now/) where he suggests how those of us who use AI to build are all product engineers now, whether we like it or not. The cost of writing code has collapsed, and the way we used to produce it no longer exists in the same way it did before AI.\n\nI've been using this term \"prompt driven development\" for a while now and I feel like it perfectly describes how a lot of modern AI first development takes place.\n\nPrompt-driven development isn't a universally agreed methodology. It's the phrase I've started using to describe the way we worked:\n\nPrompt-driven development uses structured natural-language instructions to direct coding agents, while tests, guardrails, and human review continuously verify the result.\n\nThe important part of that definition isn't the prompt. It's everything surrounding it.\n\nIf I ask an agent to build a feature and merge whatever it produces without understanding or verifying it, that's much closer to vibe coding. I am trusting the output because it looks plausible and the application appears to work.\n\nIn prompt-driven development, the prompt starts the work. It doesn't decide whether the work is finished.\n\nA useful prompt still needs a clear outcome. The repository supplies the coding standards and constraints. Automated tests check the behaviour. A pull request makes the change visible, and a review gives the team another opportunity to find problems.\n\nThe AI writes the code inside a system that the team has deliberately designed.\n\n## A prompt could be surprisingly simple\n\nDuring the Hackathon, one of the features we needed was the ability to filter a collection of data. The request was roughly:\n\nAdd dropdown filters for location and project.\n\nOn its own, that isn't a detailed software specification. It doesn't describe the framework, file structure, naming conventions, test runner, or how the filters should interact.\n\nHowever, the agent wasn't starting with an empty chat window.\n\nWe had already added [repository custom instructions](https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/add-custom-instructions/add-repository-instructions) that explained how the project should be developed. We also had [agent skills](https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/customize-cloud-agent/add-skills) that gave Copilot a repeatable workflow for particular tasks.\n\nMost importantly, the project followed test-driven development:\n\nThat context turned a short prompt into a constrained task. The agent knew that it couldn't simply add a couple of dropdowns and declare victory. It first needed to express the behaviour in a test, then produce an implementation that satisfied it.\n\nI've previously written about why [short AI coding prompts can cost you more time](https://deanhume.com/why-short-ai-coding-prompts-can-cost-you-more-time/). This experience didn't change my mind about that. A short prompt only worked here because the missing context already existed in the repository.\n\nThe real instruction wasn't one sentence. It was the prompt plus the codebase, tests, instructions, and skills.\n\n## Building as a distributed team\n\nOur team was spread across different time zones, so we couldn't rely on everyone being online together. The project needed to make sense to somebody arriving several hours after a decision had been made.\n\nCoding agents helped reduce that dependency on real-time collaboration. A team member could describe a feature, ask the agent to implement it, and leave the resulting tests and pull request for the next person to review. The next colleague didn't need a meeting before they could understand what had changed or continue the work.\n\nThis didn't remove the need to communicate. It changed where that communication happened.\n\nInstead of knowledge living only in a call or chat message, more of it became part of the repository:\n\n- The prompt recorded the intended outcome.\n- The instructions and skills recorded how the agent should work.\n- The tests recorded the expected behaviour.\n- The pull request recorded what changed and why.\n- The review recorded the questions and issues that still needed attention.\n\nThat made the repository a shared workspace for both people and agents. It gave us a common source of context when our working hours only partially overlapped.\n\n## The tests became a shared safety net\n\nOur tests gave us a shared definition of what the application was supposed to do. When an agent added a feature, it had to preserve the behaviour that was already covered.\n\nThis was especially important because not everyone on the team was technical. A colleague didn't need to inspect every implementation detail to see whether a change had broken an existing feature. The test suite gave them an immediate signal.\n\nTests didn't prove that every change was perfect. They did give both the people and the agents a safer place to work.\n\n## Pull requests became our handoff\n\nInstead of allowing agents to change the main branch directly, each piece of work arrived as a pull request. It captured the code, the tests, and the reason for the change in one visible proposal.\n\nWe also requested [GitHub Copilot code reviews](https://docs.github.com/en/copilot/concepts/agents/code-review) on the pull requests. The reviews picked up real issues and helped us correct them before merging.\n\nFor non-technical members of the team, this added another useful layer. They could ask the agent to implement a feature, then use Copilot code review to examine the result. They didn't need to pretend that they understood every line of code, and they weren't limited to accepting the first output the agent produced.\n\nThat doesn't mean an AI review makes human review unnecessary. AI-generated code deserves the same scrutiny as any other contribution. However, during a time-limited hackathon, Copilot gave the whole team access to feedback that might otherwise have depended on one technical person being online.\n\nThe workflow looked something like this:\n\n1. A team member described the behaviour they wanted.\n2. The coding agent created a branch and implemented the change.\n3. The repository instructions and skills guided how it worked.\n4. Unit tests checked the new and existing behaviour.\n5. The agent opened a pull request.\n6. Copilot reviewed the change and identified potential issues.\n7. We addressed the feedback before merging.\n\n## Non-technical didn't mean non-contributing\n\nOne of the most interesting parts of the hackathon was seeing how much a non-technical colleague could contribute.\n\nThey understood the problem we were trying to solve. They knew what information people needed, which workflows felt awkward, and what useful behaviour should look like. Previously, that knowledge might have been written into a requirement and passed to a developer.\n\nWith coding agents, they could express that intent directly.\n\nThis didn't suddenly turn every team member into a software engineer, and it didn't remove the value of technical experience. Somebody still needed to create the initial structure, choose the testing approach, and put the guardrails in place.\n\nBut once that paved path existed, more people could safely move along it.\n\nI think this is one of the most useful possibilities opened up by coding agents. They don't just help experienced developers write code faster. They can shorten the distance between somebody who understands a problem and a working version of their idea.\n\n## Why I don't call this vibe coding\n\nThe distinction isn't whether AI wrote some of the code or all of it. In our case, AI generated the code, but that tells you very little about the quality of the development process.\n\nThe difference was how we decided to trust a change.\n\nWe didn't trust it because the agent sounded confident. We didn't trust it because the interface looked right in a quick demo. We trusted it enough to continue because the expected behaviour had been written down, the tests passed, the existing tests still passed, and the change had gone through a pull request and review.\n\nFor me, prompt-driven development has four parts:\n\nRemove the verification and review, and prompt-driven development can quickly collapse into vibe coding with a more professional name.\n\n## What I'd take into the next hackathon\n\nThe biggest lesson wasn't that AI could generate an entire application. I expected the agents to write code.\n\nWhat surprised me was how effectively people with different levels of technical experience could work together when the repository contained the right boundaries. The instructions, skills, tests, and pull-request workflow gave us a common way of working, even when we weren't online at the same time.\n\nIf I were starting another prompt-driven project, I would establish those foundations before asking an agent to build features:\n\n1. Write down the project's coding and architectural rules.\n2. Give agents a repeatable test-driven workflow.\n3. Protect the main branch and make changes through pull requests.\n4. Run the complete test suite for every change.\n5. Use code review, but don't treat an AI review as unquestionable.\n6. Make the expected behaviour understandable to technical and non-technical contributors.\n\nAI made our hackathon more accessible, but the guardrails made that access useful. At the end of the hackathon, we had a project that was solid and could actually be used going forward instead of a sloppy vibe coded project.\n\nThe AI wrote the code, but the best part was that the team still engineered the application.", "url": "https://wpnews.pro/news/prompt-driven-development-building-with-github-copilot-coding-agents", "canonical_source": "https://deanhume.com/prompt-driven-development-building-with-github-copilot-coding-agents/", "published_at": "2026-09-23 17:52:00+00:00", "updated_at": "2026-09-29 10:49:49.953353+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "artificial-intelligence"], "entities": ["Microsoft", "GitHub Copilot", "Dean Hume", "Laurie Voss"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/prompt-driven-development-building-with-github-copilot-coding-agents", "markdown": "https://wpnews.pro/news/prompt-driven-development-building-with-github-copilot-coding-agents.md", "text": "https://wpnews.pro/news/prompt-driven-development-building-with-github-copilot-coding-agents.txt", "jsonld": "https://wpnews.pro/news/prompt-driven-development-building-with-github-copilot-coding-agents.jsonld"}}