DEV Community

Cover image for GitHub Coding Agent the Magical Autonomous AI: The Prequel
Ashley Childress
Ashley Childress

Posted on • Edited on • Originally published at dev.to

GitHub Coding Agent the Magical Autonomous AI: The Prequel

🦄 Alright, you made it! Thanks for stopping by. Yes, I’m a little late (again), but you’re getting the first edition of an in-depth Coding Agent adventure. Everything I wish someone had told me, plus all the misadventures that happen when you mix too much caffeine, not enough sleep, and a healthy dose of ‘what does this button do?’ energy.

Badge: This post was Human-Crafted and AI-Edited


Just a Quick Heads-Up 📌

Coding Agent is still a preview feature from GitHub and is subject to pre-license terms and frequent changes. Treat it like an enthusiastic beta test—one that keeps leveling up behind the scenes. This is not the tool to bet your workflow on (yet), but if you’re the adventurous type, you’ll have stories to tell. If not, don't worry! There's plenty of practical uses for it, too.

🫠 I know you’re not ready to run your business on it. I’m not, either! That’s half the fun of it, though!


So What Is Coding Agent? 🦾

“Agents do this.” “Agentic AI.” “Agent Mode.” “Agent search.”

That one word is like an annoying little fly that simply will not leave the conversation, no matter how many times you try to bat it away. Except this agent you're going to want to hang around.

In the IDE, you get Agent Mode—the friendly Copilot that does your bidding while you sit back and supervise.

Its cousin is Coding Agent—that’s what happens when you hand Copilot the keys and let it go wild (within reason, I promise). This is a fully autonomous, sandboxed solution you send off into the wild with a single task, powered by a dash of machine learning or a generous helping of “I wonder what this shiny new button does...” and absolutely zero risk of burning down your repo. 🧯

🦄 I'm willing to bet there's some magical things going on behind the scenes at GitHub when it comes to Coding Agent's future, too, because the updates are coming at a furious pace — quicker than I've ever seen this one updated before.

The first thing people always ask: Can I trust it?

Absolutely! If you don’t believe me, just know that I tried every trick in the book to break it. All I got was some truly creative nonsense code, but the bot never colored outside the lines. 🖍️

👌 That’s exactly what you want from an AI—brilliantly stubborn about staying in its lane, even when you're trying to tempt it off the rails.


Rapid Upgrades & Real Gotchas 🔄⚠️

You have to treat it like a beta test, really. Only this is a whole lot better than a beta test, because they've obviously been doing a ton of work on this guy. And not only that, it is changing frequently. Honestly, I was prepared to output a whole long list in this section, and I'm glad I checked first!

Most of what was on their page, even last week, has disappeared. So here are the things that still remain. And yes, most of these are true for Copilot whether it's in your IDE or out in the wild.

  • Copilot can leak any information it has access to.
    • If you care, lock it down now. This includes chat in the IDE!
  • Vulnerable to prompt injection, especially from issues or pull requests.
    • GitHub filters out hidden characters, but nothing’s truly foolproof.
  • Every response to a prompt goes into a pull request, and nowhere else.
  • Copilot might give you code that matches public repos—with zero references, even if you have the safety on.
  • AI bias and weirdness? Still here, just as much as anywhere else.

🦄 GitHub all but guarantees it won't nuke your repo. No official stamp of approval, but there are a lot of safety nets.


Safety Baked In 🛡️

You don't have to panic when the cats run across your keyboard playing whatever it is cats play while racing through the house. No matter what chaos (or wildlife) hits your desk, Coding Agent will never touch your main branch directly. It’s hardwired to make its own “copilot/” branch for every adventure.

  • Each branch is “copilot” branded—no hiding where the magic happened.
  • Copilot only works in branches it created itself. (Your leftovers are safe. For now.)
  • When it’s done, you get a draft pull request—with your name as co-author, so prompt responsibly!
  • Those required peer reviews and checks that fail out of nowhere? Yup, all the fun repo rules still apply.
  • Prompted it? Sorry, you can’t self-approve your own work. Consider it a code review, not a trust fall.
  • If you want more than repo-level access, you’ll need to do the secret handshake (read: set up a PAT token and permissions).

💡 ProTip: Coding Agent always charges exactly one premium request for every prompt. You can write a small novel if you want! Just know, it's also charging you for GitHub Actions minutes while Copilot is doing work—they add up faster than you think.


Set Yourself Up for Success 🚀

Setting up a code-generating robot should be as easy as flipping a switch, right? Well... almost. In reality, it's more like trying to train a particularly smart, but very distractible, golden retriever.

Give it the right setup, the right instructions, and crystal-clear boundaries—or you’ll be chasing down its “creative solutions” all week.

If you’ve already got instructions dialed in, you’re golden! If not, check out my post on custom instructions, because everything works better when you lay the ground rules.

If your instructions are for a different agent? Hang tight—you’ll want to read the next bit.

🎟️ Side note: If you’re not using VS Code, you are absolutely missing out. If you want the shiniest new Copilot features, install Insiders too. Yes, it’s a little buggy, but you’ll never be bored!


Instructions, Instructions, Instructions! 📝

As of last week, GitHub lets Coding Agent gobble up just about any custom instructions it can find in addition to the usual .github/copilot-instructions.md file. Now is a great time to start using .github/instructions/*.instructions.md, if you're not already. Think of it as a your laser-focused playbook pointing at exactly which files apply. Use YAML frontmatter with applyTo glob patterns, just like the .gitignore.

For example:

--- applyTo: frontend/**/* --- # Frontend Instructions 
Enter fullscreen mode Exit fullscreen mode

Coding Agent will also happily read AGENTS.md, CLAUDE.md, and GEMINI.md. This is great for one-off tests, but if you have different instructions for different bots? Welcome to the "land where instructions collide"! If you’re not careful, your instructions can cross streams and leave you with some wild results.

🦄 On the plus side, it’s a huge leap toward standardization that we desperately need. At the same time, it’s a whole new way to find edge cases nobody saw coming.


Settings & Environment Setup ⚙️

Custom Firewall Rules 🔥

Work in a locked-down org? Yeah, me too. Your firewall is probably less “security theater” and more “impenetrable fortress.” so don't be surprised if you get this message in your Coding Agent response:

Screenshot GitHub.com warning displayed when Coding Agent is blocked by the firewall

Good news: You don’t have to turn it off—just add the right URLs to your Copilot allow list under repo settings.

Screenshot GitHub.com repo settings for configuring Coding Agent firewall allow list

🦄 And yes, I forget this step every single time and wonder why nothing works for half an hour.


MCP Servers + Playwright Integration 🤖

By default, GitHub’s MCP and Playwright are ready to go—zero extra setup. If you need to talk to something outside the box (looking at you, Jira), add it under repo settings.

For real magic, use Context7. While it draws the line at spelunking in stack overflow, it's an absolute game-changer when it comes to literally every other form of documentation you could possibly need. Skeptical? Check the official docs.

{ "mcpServers": { "context7": { "type": "http", "url": "https://mcp.context7.com/mcp", "headers": { "CONTEXT7_API_KEY": "YOUR_API_KEY" }, "tools": ["get-library-docs", "resolve-library-id"] } } } 
Enter fullscreen mode Exit fullscreen mode

🦄 Context7 is a lifesaver, but be warned: unless you specify a library-id, response times can go from “speedy” to “waiting for a train that might never come.” I keep a list of IDs in the repo and reference it in the instructions. It saves you the cost of a lookup call every time Copilot needs to pull documentation. 😉


Secrets & More Settings 🔑

MCP is plug-and-play, but by default, Copilot can only see the current repo. To grant it superpowers, make a PAT token starting with COPILOT_MCP_ and add it to your Copilot environment variables.

If you haven’t poked around GitHub environments before, now’s the time. There’s some weirdly powerful stuff in there! 🧙

Screenshot GitHub.com repo settings, Copilot environment

💡 ProTip: Name your secret wrong and Coding Agent just shrugs and ignores you. And yes, it took me way longer than it should have to figure that one out!


Customizing the Workspace 🧑‍💻

Do you have custom workflows that make it seem like your AI’s about to start freelancing for a competition? Then you’ll want the Copilot Steps workflow—your way to build a fully custom, hands-off dev environment for the AI.

  • The file must be .github/workflows/copilot-setup-steps.yml
  • The job? Always copilot-setup-steps, or it’s invisible.
  • You can’t change everything; only certain fields count (steps, permissions, runs-on, container, services, snapshot, timeout-minutes). Anything else, and Copilot pretends like it's not even there.

Here’s a sample workflow (straight from GitHub’s docs):

name: "Copilot Setup Steps" # Automatically run the setup steps when they are changed to allow for easy validation, and # allow manual testing through the repository's "Actions" tab on: workflow_dispatch: push: paths: - .github/workflows/copilot-setup-steps.yml pull_request: paths: - .github/workflows/copilot-setup-steps.yml jobs: # The job MUST be called `copilot-setup-steps` or it will not be picked up by Copilot. copilot-setup-steps: runs-on: ubuntu-latest # Set the permissions to the lowest permissions possible needed for your steps. # Copilot will be given its own token for its operations. permissions: # If you want to clone the repository as part of your setup steps, for example to install dependencies, you'll need the `contents: read` permission. If you don't clone the repository in your setup steps, Copilot will do this for you automatically after the steps complete. contents: read # You can define any steps you want, and they will run before the agent starts. # If you do not check out your code, Copilot will do this for you. steps: - name: Checkout code uses: actions/checkout@v5 - name: Set up Node.js uses: actions/setup-node@v4 with: node-version: "20" cache: "npm" - name: Install JavaScript dependencies run: npm ci 
Enter fullscreen mode Exit fullscreen mode

🦄 This actually works. I know, I was shocked too. Get creative with it—multiple repos, wild setups, whatever. Let me know how it goes!


Wait, That’s It? 🤔

Yeah, I know—you expected another ten pages. But in the time it took me to write this, argue with ChatGPT and Gemini, play with Leonardo, and still make it to work on time? GitHub probably pushed three more features and fixed half the bugs I was going to joke about anyway.

So instead, here are the weirdest, most useful things I've learned about Coding Agent so far:

  1. Can I change the model? Nope. Coding Agent = Claude Sonnet 4. You can't change it, but at least they picked a good model for the job.
  2. How much does it cost? Every prompt equals exactly one premium, plus GHA minutes equal to run time.
  3. How should I review the PR? Add comments in the Files changed tab so they’re submitted together as a batch. One batch is also equal to one premium request 😀 Anywhere else, go nuts giving it all the information you can.
  4. Why won’t it work on my PR? It only works on PRs and branches it created with the “copilot” prefix. Start there if you want to use it.
  5. Why won’t it respond? Use @copilot in every comment. Still nothing? Don’t spam—try a normal comment as a reply and watch for the eyes emoji 👀.
  6. Workflow stuck? Be patient. Coding Agent likes to take coffee breaks between sprints. If you’re done waiting, you can cancel it—it won’t break anything, but you'll probably lose all the work it's done so far.
  7. How good are the results? It’s only as good as your prompt. If you want A+ output, nail the instructions and follow PRIOR. (you can skip the P, unless you’re feeling dramatic.)

🦄 If you’re stuck, confused, or just want to swap horror stories, leave a comment or DM me anywhere. It may take me a bit, but I’ll answer (eventually).


🛡️ The robots helped, but less than usual.

ChatGPT and Gemini are both in the time out corner. No Copilots were harmed in the making of this post—but there were some loud sighs, at least one new colorful expression, and a mild existential crisis while I debated the sanity of my choices.

Top comments (8)

Collapse
 
guypowell profile image
Guy

Cool article, thanks for writing it. Seeing GitHub Coding Agent through your lens made me rethink some assumptions, especially around how autonomous “agentic” workflows still need orchestration guardrails. When I built ScrumBuddy, one of my biggest headaches was getting code agents (or when I tried stitching Claude in) to respect conventions & boundaries. Things like which files to touch, PR branch naming, and how much context they should pull in before acting.

What stood out in yours is how Coding Agent creates its own “copilot/” branch for adventures, never directly hitting main, and always gives draft PRs you review. That’s exactly where integrity lives. It’s not sexy, but it’s the kind of detail that makes these tools safe to lean on in production.

When you’ve used the Agent, have you found its default instructions/instruction collisions to be a source of drift? I’ve seen agents pull in conflicting repo-level rules or custom instructions and then produce results that “look valid” but violate my architecture conventions. Would love to hear how you’ve navigated that.

Collapse
 
anchildress1 profile image
Ashley Childress

Agreed! I hated it at first because I had a whole system set up for my instructions but I had also turned the agent loose on my computer, which is not at all recommended 🤣 I had also done so after weeks of testing it in Codespaces, so I was fairly confident in what it was going to do at that point.

First, where I'm at doesn't use org instructions at all for that reason. Second, I try to keep my personal instructions under 5 lines and always pointing to things that would apply everywhere. Something like "output answers in a single sentence or as a concise bulleted list, keeping it under 200 characters each line". Then everything else goes in the repo. If you find yourself duplicating a ton of information, consolidate in a shared internal/private repo and reference it with a link. Yes, I know GitHub says no links at all, but that's not technically true. It just keeps things speeding along.

Even with all of that? The level of complexity you can give to Coding Agent is limited. I use it every chance I get, and there's one or two projects I'll prompt and let it run free cause I just need a quick utility and how doesn't matter. The majority of my projects I watch like a hawk and have a lot harder time trusting it to do anything without me.

My next big task is trying to figure out how to keep things from escalating quickly in a single commit. It's much easier to review 5 small changes than the 30 I currently have cause I decided it would be a good time to split my "small UI" to have it's own dedicated backend. 😅🤣

Collapse
 
guypowell profile image
Guy

Yeah, I hear you on that! I made the same mistake early on of giving an agent way too much rope and then watching it do things I’d never sign off on if I were in the loop. It’s why in ScrumBuddy I ended up baking orchestration right into the workflow: keep global instructions lightweight, push all the heavy conventions and guardrails into the repo itself, and let the agent consume just enough context at the right time. That way it behaves like a junior dev reading project docs, not a rogue script with root access.

You’re spot on about trust too. For quick utilities, I’ll let an agent run wild if the blast radius is small, but for anything tied to a product or team workflow, I keep it under close watch. The “30 changes in one commit” problem is a classic example, it’s not that the agent is wrong, it’s that it doesn’t have a sense of incremental discipline. That’s exactly where orchestration comes in: forcing it to slice work into atomic steps and PRs you can review without drowning.

I’m curious, have you tried layering a pre-commit gate or an orchestrator step that enforces that kind of chunking? I’ve found that once the system itself demands smaller commits, both the AI and the humans fall into line.

Thread Thread
 
anchildress1 profile image
Ashley Childress

I have another post coming out next week on a new solution that I think is on track to fix that orchestration thing for us. I got wrapped up in their beta testing and it's on the right track! I'm dying to throw it against Kiro, too, but I haven't made it that far yet.

Right now, my hooks related to size are strictly warnings—it's on the list, though. Took me a minute to figure out why Copilot kept trying to sign my commits for me. 🤨😆 Lefthook seems to be a good solution for them though. I switched my JS projects to that from Husky already, and the Java ones seem to be handling it well, so far. It's still early, but promising.

The other problem is Coding Agent will run the manual commands individually, but not the whole pre/post suite in the same order they're defined in. So it's workflow will pass fine and it reports everything's good. However, the actual build workflow is screaming at me that something is wrong. It lacks the ability to follow up on itself though and half the time directing it causes more issues than fixes anyway... Also on the never-ending list of things I want to figure out!

Thread Thread
 
guypowell profile image
Guy

That sounds exciting! I’ll definitely keep an eye out for your next post. I’ve found the same thing with agent workflows: they’re great at running isolated commands, but the moment you need them to respect a full pre/post suite in sequence, the cracks show. It’s like they don’t have the muscle memory of a real dev to follow through once the first green checkmark appears.

In ScrumBuddy, I tackled that by baking validation and sequencing into the orchestration itself, so instead of the agent just “checking off” steps, it’s forced to move in atomic increments that mirror how you’d guide a junior dev. That way when something fails downstream, you already know which chunk caused it, and you’re not cleaning up a mystery mess after the fact.

Really curious to see how your beta testing pans out, especially if you throw it against Kiro. If it smooths over those sequencing gaps, that could be a big win for anyone trying to trust these tools in real workflows.

Collapse
 
prime_1 profile image
Roshan Sharma

Awesome write-up, I really like how it uses its own branches and draft PRs to stay safe and respect repo rules. Quick question
How does it handle conflicts if multiple .instructions.md files give different directions (say frontend vs backend)?

Collapse
 
anchildress1 profile image
Ashley Childress • Edited

If you're using the .github/instructions/*.instructions.md files, then it only picks them up at all if it has the applyTo in the yaml frontmatter. So if it has multiple instructions in context for one file, it assumes they were put there on purpose and it all goes into context. GitHub recently implemented a sort-of priority system where user instructions theoretically have more weight than repo than org... I really haven't put them to the test to know how it reacts IRL to that system though.

Collapse
 
corporateoptics profile image
Corporate Optics

Good for use!

Some comments may only be visible to logged-in visitors. Sign in to view all comments. Some comments have been hidden by the post's author - find out more