I've been experimenting with GitHub Copilot in a way that I think most developers haven't tried yet — and I wanted to share the workflow I've landed on. Start in the Repository. When you're building something new, go straight to your GitHub repository and describe what you want Copilot to build. From a completely empty repo. No existing code, no setup, nothing. Just tell it what you want and let it go to work. I did exactly that — brand new repository, described my app, and walked away. It scaffolded the entire thing and opened a PR for my review. Then use Issues to refine. Once you have a foundation in place, that's when GitHub Issues becomes powerful. Open an issue, type @copilot, and describe what you want changed, added, or fixed. It reads your existing code and makes targeted changes in context. So the mental model I'd suggest: New project? Start in the repository and let Copilot build the foundation Existing project? Use Issues to extend, refine, or correct Think of it like handing an architect an empty lot versus asking a contractor to renovate what's already there. Two different jobs, two different starting points. Most people are still using Copilot just for autocomplete. The real power is in delegating entire workstreams. #GitHub #GitHubCopilot #AIEngineering #DeveloperProductivity #SoftwareDevelopment #CodingSmarter #AI #DevTools #Microsoft
Byron Jacobs
3w
Great move! There's a lot more Copilot can do than most people ar aware of. I wrote a blog post about if you're interested https://byronjacobs.com/how-i-ship
How do you achieve consistency with this approach? We work off of blueprints as a start for our apps, then build on top of that. This approach helps to achieve a good starting point