Prompt-Driven Development: Building with GitHub Copilot Coding Agents

At 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.

Hackathons 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.

AI is beginning to change that.

For 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.

The AI generated the code, but I wouldn't describe what we did as vibe coding.

We 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.

The 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.

What is prompt-driven development?

This got me thinking about a post that I read lately from Laurie Voss 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.

I'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.

Prompt-driven development isn't a universally agreed methodology. It's the phrase I've started using to describe the way we worked:

Prompt-driven development uses structured natural-language instructions to direct coding agents, while tests, guardrails, and human review continuously verify the result.

The important part of that definition isn't the prompt. It's everything surrounding it.

If 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.

In prompt-driven development, the prompt starts the work. It doesn't decide whether the work is finished.

A 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.

The AI writes the code inside a system that the team has deliberately designed.

A prompt could be surprisingly simple

During the Hackathon, one of the features we needed was the ability to filter a collection of data. The request was roughly:

Add dropdown filters for location and project.

On 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.

However, the agent wasn't starting with an empty chat window.

We had already added repository custom instructions that explained how the project should be developed. We also had agent skills that gave Copilot a repeatable workflow for particular tasks.

Most importantly, the project followed test-driven development:

That 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.

I've previously written about 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.

The real instruction wasn't one sentence. It was the prompt plus the codebase, tests, instructions, and skills.

Building as a distributed team

Our 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.

Coding 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.

This didn't remove the need to communicate. It changed where that communication happened.

Instead of knowledge living only in a call or chat message, more of it became part of the repository:

• The prompt recorded the intended outcome.
• The instructions and skills recorded how the agent should work.
• The tests recorded the expected behaviour.
• The pull request recorded what changed and why.
• The review recorded the questions and issues that still needed attention.

That 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.

The tests became a shared safety net

Our 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.

This 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.

Tests didn't prove that every change was perfect. They did give both the people and the agents a safer place to work.

Pull requests became our handoff

Instead 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.

We also requested GitHub Copilot code reviews on the pull requests. The reviews picked up real issues and helped us correct them before merging.

For 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.

That 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.

The workflow looked something like this:

1. A team member described the behaviour they wanted.
2. The coding agent created a branch and implemented the change.
3. The repository instructions and skills guided how it worked.
4. Unit tests checked the new and existing behaviour.
5. The agent opened a pull request.
6. Copilot reviewed the change and identified potential issues.
7. We addressed the feedback before merging.

Non-technical didn't mean non-contributing

One of the most interesting parts of the hackathon was seeing how much a non-technical colleague could contribute.

They 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.

With coding agents, they could express that intent directly.

This 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.

But once that paved path existed, more people could safely move along it.

I 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.

Why I don't call this vibe coding

The 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.

The difference was how we decided to trust a change.

We 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.

For me, prompt-driven development has four parts:

Remove the verification and review, and prompt-driven development can quickly collapse into vibe coding with a more professional name.

What I'd take into the next hackathon

The biggest lesson wasn't that AI could generate an entire application. I expected the agents to write code.

What 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.

If I were starting another prompt-driven project, I would establish those foundations before asking an agent to build features:

1. Write down the project's coding and architectural rules.
2. Give agents a repeatable test-driven workflow.
3. Protect the main branch and make changes through pull requests.
4. Run the complete test suite for every change.
5. Use code review, but don't treat an AI review as unquestionable.
6. Make the expected behaviour understandable to technical and non-technical contributors.

AI 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.

The AI wrote the code, but the best part was that the team still engineered the application.