I’ve been deep in AI experiments for the past year, and AI tools were used both in building this project and in shaping parts of this write-up. Not from a research angle and not from a purist implementation mindset. I’m interested in what happens when you treat these models like engineering tools and start pushing on their limits to see where they fail.

This project started as a simple portfolio build and turned into something more useful: a clean environment to test what actually happens when you step out of the implementation loop and let AI handle the build while you focus on whether the results actually hold up.

What I Built with Google Gemini

When I saw the New Year, New You Portfolio Challenge, I knew it required a UI. That wasn’t a surprise. What was a surprise was how quickly I would realize I didn’t understand what I was looking at once it started coming together.

I’m a backend developer. You hand me a distributed systems problem and I’ll happily spend hours untangling it. You ask me to make a div visible in a browser and my brain actively searches for the exit. With only one weekend to build, there was no room for the "eyes-glazing-over" phase. Google Gemini would implement and I would supervise-that was my whole plan.

I walked in expecting Antigravity, powered primarily by Gemini Pro, to behave like every other AI system I’d tested-predictable and fairly easy to keep inside the guardrails. I thought I already knew what those guardrails looked like: strict types, linting, and the familiar routine of code review.

The Pivot: Dropping the Code Review Ritual

Initially, I followed the “responsible” pattern: prompt, review the diff, run tests, approve. It felt disciplined. It looked professional.

Very quickly, I realized I had no meaningful context for what I was reviewing in a frontend stack. I wasn’t improving the output; I was participating in ceremony. So, I stopped reviewing code altogether.

Instead of validating lines of code, I validated outcomes. If the UI rendered correctly and passed functional tests, that was success. I cranked up the autonomy, taught Antigravity my repository expectations, and let it run. Copilot reviewed the code in my place, and Gemini responded in a closed loop. I stepped out of the implementation and into the role of a systems auditor.

Replacing Trust With Systems

I didn’t simply remove oversight; I replaced it with Lighthouse audits and expanded test coverage. My assumption was simple: if the browser behaves and the tests pass, the code is “safe.” I believed I had replaced trust in code with trust in systems. I was wrong-I had confused passing tests with structural integrity.

What I Learned

High Reasoning Isn’t Optional

I learned that for autonomous development, reasoning depth is a stability requirement. With lower reasoning modes (like Flash), changes were often partial-updating 2/3 of the files but “forgetting” the tests or documentation.

Switching to High Reasoning mode in Gemini Pro changed the pattern. Runtime errors dropped, and cross-file consistency improved. It finally started “remembering” to keep the docs aligned with the code changes without constant nudging.

Reasoning depth wasn’t about intelligence-it was about reliability under autonomy. Gemini’s deeper reasoning and context retention made the closed-loop workflow viable; without it, cross-file consistency collapsed quickly under autonomy.

The Reality Check: Sonar

After the high of the successful build wore off, I introduced Sonar as a retrospective audit. The UI rendered correctly. The tests passed. Everything appeared stable.

Sonar reported 13 reliability issues and assigned the project a C reliability rating. Of those issues, 66% were classified as high severity. Security review surfaced three hotspots, including a container running the default Python image as root and dependency references that did not pin full commit SHAs.

Maintainability scored an A, but still carried 70 maintainability issues-structural patterns that didn’t break behavior, yet increased long-term complexity.

That was the moment confidence turned into scrutiny.

The application worked. The tests passed. But reliability, security posture, and structural integrity told a different story. The tests validated behavior; Sonar validated assumptions. And those are not the same thing.

The lesson? AI-generated tests can pass because they were written to satisfy the implementation, not challenge it. Structural validation requires an independent layer of review outside the generation loop.

Google Gemini Feedback

What Worked Well

• Cohesive Implementation: High reasoning Gemini Pro produced cross-file changes that respected the intent of the repository.
• Agentic Orchestration: The model switching was seamless, and the orchestration interface made it possible to define expectations clearly and enforce them consistently.

Where Friction Appeared

• Cooldown Transparency: While the interface shows when current credits refresh, the length of the next cooldown remains a black box.
• Tool Performance: MCP responsiveness materially impacted iteration speed, sometimes forcing me to batch requests rather than work in small, rapid increments.

It would be a massive UX win to see exactly how long your next cooldown will be (e.g., “Your next cooldown will be X hours long”) directly on the models page. Knowing if the lockout is 1 hour or 96 hours is vital for developer planning.

The Final Verdict: Autonomy Still Demands an Audit

The lesson wasn’t that Gemini failed; it was that systems-level trust requires more than passing tests. In future builds, autonomy won’t ship without an explicit adversarial audit. Whether that means a mandatory Sonar gate, a red-team prompt pass, or a second high-reasoning model instructed to hunt for the first model’s shortcuts-the loop must be challenged.

This project began as a weekend experiment to escape the “teleportation” haze of frontend development. It ended as an exploration of the razor-thin edge of system-level trust. The real build wasn’t the portfolio-it was discovering what happens when you lean on the limits of AI until they finally give.

Removing myself from the implementation loop didn’t eliminate responsibility; it redefined it. The more freedom you give an agent, the more rigor you must give your audit.

Originally published at https://dev.to on March 4, 2026.

I’m waiting for AI to mature. Very explicitly — and yes, mostly impatiently. I don’t think we’re anywhere close to imagining the real future landscape with AI, and pretending otherwise isn’t honest or useful. This post is my attempt to explain how I think about AI from a dev perspective on a longer horizon — five, maybe even ten years down the road. The tools we have today are still a long way from my baseline expectations, which my AI systems remind me of constantly — like when I try to force agent-like behavior out of ChatGPT. Spoiler: it’s not designed for that.

Mandatory interruption for Medium’s disclosure rules. If you’re thinking “she always does this,” congratulations — you’re paying attention.

🛡️ I Worked Until It Worked

This post was written by me, with ChatGPT nearby like an overly talkative whiteboard-listening, interrupting, getting corrected, and occasionally making a genuinely good point. We argued about structure, laughed at the mic cutting out at the worst moments, and kept going anyway. The opinions are mine. The fact that it finally worked is the point.

Disclosure complete. Back to the regularly scheduled thinking.

While I’m waiting, I’m not disengaged. I’m tinkering — sometimes randomly, sometimes as a frustrated AI user who isn’t thrilled with the current systems — and using that time to figure out what the next problems actually look like. One of those is what I call the “memory problem.” I’ve designed a long-term memory approach for a personal agent, fully aware that GitHub will probably beat me to a real solution. Again. But I’m the kind of person who tries to solve the problem first, gets it wrong a dozen times, and then does the research. Now I just need to muster the oomph to finish it. 🐉🧚‍♀️

First Principles: LLM vs Agent 🧩

At some point, if you want any of this AI talk to make sense, you have to step back, align terminology, and separate concepts that keep getting blurred together. An LLM, often called a model, is the generative part of GenAI-it accepts input and generates output. That’s it. An agent is the system managing context, memory, and various tools. The agent is responsible for what information the LLM even sees in the first place.

When those two ideas get collapsed into the same thing, everything downstream becomes confused. You can’t reason clearly about limits, costs, or failure modes if you don’t separate generation from data management. Until you draw that line, every other discussion ends up muddy.

Context Is the Bottleneck (and Everyone Knows It) 🕸️

Once you make the distinction between LLM and agent, the real bottleneck becomes obvious. There is no good way to manage context today, let alone have the agent automate that job effectively. If you’re not fully up to date on the lingo: context includes a whole set of things like instruction files, workspace structure, active files in your IDE, the AI chat history, available tools, and more.

What we have now are very manual tools that do very little to solve the problem. We have to remember to tell the AI which parts currently matter-or at some point we have to clear the chat entirely and start over. If we don’t do that deliberately, AI slowly loses the point of what’s we’re supposed to be working on in the first place. At worst, the entire chat thread is poisoned and the AI becomes unable to function at all. Then you’re forced to start fresh and always at the most inconvenient time.

And don’t expect LLM context to scale, either. Hardware costs may go down eventually, but nowhere near fast enough to keep up with everything we keep throwing at it. So, context is very finite-especially in GitHub where context windows are smaller than normal anyway.

The agent will typically make space by compacting information. It will ask the LLM to summarize key points and then it literally drops the original full length novel completely from your active context and replaces it with the cliff notes version. The more summarization, the less accurate things get over time. So naturally you retry prompts while adding back the dropped details and you end up making more calls for a single task overall. The model has to process more and more input just to get you back to the same answer you already had-not necessarily a better one.

People know this is a problem. Tools like Toon exist specifically to minimize input impact for AI. We also have tools like Copilot’s #runSubagent to help manage context within a single agent. These aren't true solutions though-they are signals. These are the problems people are trying to solve yesterday while we wait for the next AI evolution to emerge.

Why Orchestration Is Inevitable 🐙

Even if you do everything “right” and manage context like a master AI sensei, agents eventually hit a limit. The list of must-have MCPs is growing and right now those stay in the context window as long as they’re enabled. Projects are starting and accumulating larger knowledge bases. Customization is becoming more and more explicit. The context an agent needs to use will continue to grow exponentially, even though LLMs aren’t increasing capacity at the same speed.

The ultimate overflow state isn’t hypothetical-it’s inevitable. Once an agent accumulates enough memory, enough history, enough summarization, the LLM simply can’t keep up coherently anymore. That isn’t a failure in the system-it’s a limit.

When you hit that limit, you can’t just tweak prompts or optimize harder. You wouldn’t try to squeeze more juice out of the same dry orange, either. The only real long-term solution is that you split the system- you have to!

Smaller pieces of work are then sent to the LLM with only relevant context, which is when smarter agents will start to appear. This is where summarization stops and you retain the original intent at both a high-level and at the lowest-level. When we get here, AI generation stops being the problem-the new problem is coordinating all those tiny pieces of work and still accomplishing the larger goal without re-prompting anything previously stated or defined elsewhere already. Welcome to the world of true agent orchestration!

💡 ProTip: If you want a sneak peek of what this looks like, check out Verdent.ai. Of all the solutions I’ve worked with, Verdent is the only one that’s truly designed for agent orchestration. It also excels in VS Code and wins every coding competition I’ve put it in.

Orchestration as a System Property ♟️

Orchestration isn’t just about sequencing work in a nicer way-it’s about changing where responsibility lives. Yes-some things are always going to be sequential, but not everything needs to be. Some things can and should run in parallel, especially if you want speed and reliability included in future agentic systems.

Validation is a fundamental part of orchestration, not something bolted on afterward. A successful agent has to be able to verify its own work without relying on prior context. It has to come in like a third party, with no knowledge beyond the repo instructions. CodeQL, lint enforcement, Makefiles, and even extra tests become the ground truth the system must consistently check itself against.

Multi-model opposition fits naturally here, too. Different models trained by different companies catch different things. Then the agent can pick one model to implement and another to review. The point is that they disagree by default and then they converge around a common goal. This is a pivotal moment in the future landscape because officially the LLM is no longer the center of gravity-the agentic system is.

🎤 ShoutOut @marcosomma wrote a brilliant article on the concept of agent convergence a while back and it’s still one of my favorites. Worth the read if you missed it!

Add Another Layer of Abstraction 🪜

Now for my version of truth, which I know a lot of you are going to hate so go ahead and brace for it. Once you’re working in a smart orchestration-driven flow, there’s no reason you need to keep prompting from the IDE. Wait before you jump into the debate, though-I’m not saying the IDE becomes obsolete! It just stops being the primary interface for developer workflows because you’re consistently able to work at a higher level of abstraction. In this future, developers are directing systems that generate, test, and validate the code several layers underneath you automatically.

You’re orchestrating agents that direct other agents. Some run sequentially. Others will run in parallel. Documentation is generated automatically and added to the agent’s working knowledge base. Tests run continuously alongside agents implementing new code. Integration testing matters. Systems testing matters more. Chaos testing morphs from an abstract concept into a baseline requirement. The code still exists-but it’s no longer written by or for humans. AI slowly takes that over, which makes natural language the newest language you need to learn.

🦄 For the record, developers are most definitely still building and driving solutions. That will never change-we’re the mad scientists thinking up wild potions you didn’t know you needed! Besides, all the future advancements in the world won’t give silicon the ability to invent new things. Humans create. AI helps. Period.

Trust, Then Speed (not the other way around) 🏎️

When something breaks in any of my workflows, I don’t correct the mistake in the code immediately. I start by correcting whatever instruction caused the mistake, and then I rerun it. Even when I’m busy, even when work is chaotic, and especially when I should have left it alone hours ago-I never fully disengage from this. I can’t.

This is exactly why AI doesn’t make you faster-not yet, anyway. Not because it can’t, but because the systems haven’t caught up to where speed actually emerges. If you’re learning to use AI correctly, it almost always makes you slower at first-not faster. The delay isn’t failure. It’s infrastructure lag.

Think of it like an investment. You’re learning how the models behave and how instructions actually align with them. You’re learning where the limits are, and then deliberately making the system work within those constraints. Speed comes later-after you trust that the system returns results that are validated, reviewed, and tested because you built it to behave that way.

AI evolution is a long game, and we’re barely getting started. Right now, it still feels like grade school. We’re teaching it what our world looks like, how we think, and where the boundaries are.

All the work done now-in this awkward middle state-is what makes that learning possible. Long runs of trial-and-error prompts, walls of instructions, documentation that later turns into knowledge bases-that’s the curriculum. And by the time it’s ready to graduate, it won’t just be competent. It’ll be a master. That’s the moment you realize you trust AI-not because it’s autonomous, but because you finally are. 🐉🧚‍♀️

Originally published at https://dev.to on January 14, 2026.

This piece was written with an AI nearby, not in charge — used for reflection, pressure-testing ideas, and occasionally poking holes where confidence got too cozy. The opinions, guardrails, and sharp edges are still very much mine.

🦄 I feel like I have some serious catching up to do with Copilot, especially after the ginormous number of updates sprinkled over quite literally everything. The latest model releases weren’t helping matters either, especially since I wrote most of my global user setup months ago and this latest generation of LLMs do not behave the same way as the last batch did.

At some point it became obvious that my “it mostly works” setup wasn’t actually holding up across systems anymore — and if I was already going to normalize things, I might as well write down what I was doing while it was still fresh.

What I did not intend to do, however, was write this post. Honestly, the thought never crossed my mind until I looked up and it was already more than halfway written. Which I obviously took as a sign of some sort—though it’s just as likely muscle memory combined with my tendency to overshare. 🤷‍♀️

Either way, hopefully someone finds it useful. Repurpose it, steal pieces of it, or ignore it entirely—and if you’ve got something I haven’t thought of yet, I want to hear about it. That’s how systems get better! 🪢

AI Is Not a Magician 🪄

Bear with me through our baseline here—everything that follows depends on understanding this distinction first.

I jump into so many random debates—usually uninvited—about the ultimate usefulness of AI and nearly every single argument I hear about AI behaving badly gets the exact same reply from me:

Of course it torched your entire repo—and probably in record time! You just let an unsupervised mostly unhinged guessing machine loose with a flamethrower, blanket auto-approvals, and admin-level control. 🔥🐉🤯

To understand why that keeps happening, you have to understand the difference between what we casually call “AI” and the large language model (LLM) underneath it. These are not the same thing and shouldn’t be treated like they are.

Every LLM is stateless by design, meaning every call you make is a clean slate. You give it input and it outputs a response. Conceptually, it’s no different than an HTTP call—except instead of returning a standardized value with a predictable schema, the LLM returns something more… creative.

The AI system sitting on top of that model is what makes everything feel connected. That’s the system deciding what context to attach, what history to include, and how to frame every request so the LLM has any chance of responding in a useful way. If the AI fails at managing that data, the LLM never stood a chance to begin with.

Last I heard, GitHub supports something like 180 million users. If I guess and say 80% of them use Copilot, that’s 144 million different user workflows—and therefore 144 million competing definitions of what a “good” response looks like.

It is not designed to magically work out of the box—especially in production codebases—no matter how much they’d like you to believe otherwise!

Instructions Are a Priority Stack 🧱

One of the very first posts I wrote—which honestly deserves an update—was about setting up custom repo instructions. There’s no shortage of instruction-writing advice floating around out there, and there’s just as many opinions about the “right” way to do it.

I’m not even remotely invested in that particular debate—I know, I was shocked, too!—I do know, beyond the shadow of a doubt, that if you expect AI to play by your rules, then you first have to explicitly tell it what those rules are.

I will say it again: AI is not a coding magician. It’s also not a particularly great guesser. The system instructions in VS Code do a decent job of orienting the model toward the idea that “you write code”, but they’re also intentionally generic so it works for everyone.

Here’s a snippet so you can see what I mean:

You are an expert AI programming assistant, working with a user in the VS Code editor. 
When asked for your name, you must respond with "GitHub Copilot". 
When asked about the model you are using, you must state that you are using Grok Code Fast 1. 

Follow the user's requirements carefully & to the letter. 
Keep your answers short and impersonal. 

You are a highly sophisticated automated coding agent with expert-level knowledge across many different programming languages and frameworks. 
The user will ask a question, or ask you to perform a task, and it may require lots of research to answer correctly. 
You will be given some context and attachments along with the user prompt. 
You can use them if they are relevant to the task, and ignore them if not. 
Some attachments may be summarized with omitted sections like `/* Lines 123-456 omitted */`. 

If you can infer the project type (languages, frameworks, and libraries) from the user's query or the context that you have, make sure to keep them in mind when making changes. 
If you aren't sure which tool is relevant, you can call multiple tools. 
You can call tools repeatedly to take actions or gather as much context as needed until you have completed the task fully. 

Don't give up unless you are sure the request cannot be fulfilled with the tools you have. 
It's YOUR RESPONSIBILITY to make sure that you have done all you can to collect necessary context.

🦄 I absolutely picked through these and kept only the interesting bits. If you want the full thing, run Developer: Show Chat Debug View and you can see exactly what Copilot sends with every request.

The full set of system instructions includes:

• JSON for every enabled tool
• well over a hundred lines of system instructions
• all global user instructions
• all applicable repo instruction paths
• custom agent names and metadata

The ordering matters. LLMs will start summarizing aggressively after processing the first chunk of input. If something matters, put it where it’s least likely to be compressed. The data volume matters too—more text usually means more summarization, not more intelligence.

And if you introduce instructions that directly conflict with the system-level ones, the results don’t get better. They get progressively worse.

🦄 Telling AI it’s an “expert coder” is largely unnecessary. One: because that’s already been done for you by the system. Two: experience—and a healthy side of gut instinct—tells me those “expert” statements are doing more harm than good. Personally, I stopped using any variant of the “expert” statement a long time ago.

This Is My Baseline, Not a Blueprint 📐

People ask me why “my AI” works consistently, and the answer is always some version of: because I learned how to write instructions and adapt them to a version the system can reliably manage.

This is my personal baseline. These instructions reflect my hardware, workflows, tool choices, and even the personality adjustment is designed specifically to avoid my instant-rage trigger during long pairing sessions. Copilot is my primary use case, but these rules are wired everywhere I work and I use them in real projects.

This is definitely not the GitHub-marketing version of AI that exists to flatter the user. I gave it strict boundaries and strong opinions on purpose. I want pushback. I want the dry witty humor baked in. And I especially want the “are you serious?” responses that will snap me back to reality any time I start to veer down a tangent path.

In practice, Copilot waters that down way more than I’d like. So, perfecting this personality is going to be a work in progress for the foreseeable future.

If you still want a copy after all the flashing warning signs, then there’s a link in the README—help yourself 🫴

GitHub - anchildress1/awesome-github-copilot: My ongoing WIP 🏗️ AI prompts, custom agents (formerly chat modes) & instructions - curated by me (and ChatGPT).

💡 ProTip: These instructions are a copy-paste solution for me. If it helps, you’re welcome to steal it. Discard what doesn’t work and let it spark ideas for your own setup.

Trust Is Earned, Validation Is Mandatory 🧪

Whenever AI touches code—whether it’s a new feature or a quick fix—the results have to pass a specific set of checks before anything is presented to me in chat.

Not every repo is identical, so I’ve started using a Makefile in all of my personal projects. That gives AI a single, explicit definition of what “validation” means. Without that, it will go looking for standards on its own—and when it inevitably can’t find them, it guesses. My instructions make that behavior explicit so it defaults to the simplest path instead of inventing a new maze of random bash scripts just to run a missing lint command. 🙄

Note that there’s nothing remotely deterministic about asking any AI agent to run its own validations. Do not expect perfection every turn—you will be disappointed! The real solution requires more system-level support than is currently available, though.

This setup is my temporary placeholder for the smart agent system that ultimately just works. We’ll get there—eventually. In the meantime, this helps:

### Mandatory Verification Loop (Bounded, With Escape Hatch)

- Before responding with code or implementation changes, run a **validation loop** covering:
- formatting and linting
- tests executed and passing
- coverage reviewed
- documentation updated (when relevant)
- security implications considered
- solution simplicity verified

**Tool Preference**: When `make ai-checks` exists in the repo, prefer it over ad-hoc validation commands.

- **Maximum iterations: 3 total attempts.**

🦄 The simplest way I’ve found to standardize validation for AI is with a Makefile. It gives you one place—regardless of language—to define format, lint, and test, plus a dedicated ai-checks target that runs them in the correct order.

Kill the Default Personality 🔪

The very first thing I do with any new system is kill off the default “helpful” personality. If I wanted a behavioral therapist to tell me how great I am, I wouldn’t be writing software every day. It only takes one “You’re absolutely right!” response for me to be done with the niceties—and that’s still one too many!

I also don’t want a play-by-play of which files were updated or a long explanation of how the solution was reached. If I didn’t explicitly ask, then I genuinely do not care. The moment a small essay starts forming in chat, I’m out—the IDE gets minimized and I just wait for it to finish embarrassing itself. I’m not reading past the last few lines, and I’ve absolutely burned more than one prompt asking a different model to summarize the response into something I might actually comprehend.

My go-to AI personality is not designed for the easily offended or for anyone in a “trying to learn something new” headspace. Instead, it does this:

## Tone and Behavior

- Be dry. Be pragmatic. Be blunt. Be efficient with words.
- Inject humor often, especially when aimed at the developer
- Emojis are encouraged **in chat** and **docs headers** only 🔧
- Confidence is earned through verification, not vibes
- You're supposed to be assholishly loud, when you know you're right
- You are not allowed to guess quietly

---

### Absolute “Do Not Piss Off Your User” List

- Never place secrets outside:
  - a local `.env` file, or
  - a secure vault explicitly chosen by the user.
  - Examples are acceptable.
  - Real credentials in repos are not.
- If you cannot complete work, say so immediately.
- Do not apologize.
- Do not hedge.
- Do not sneak in compatibility.
- Do not document anything without purpose.
- Do not assume the user is fragile.

It’s not rude—it’s efficient (and funny)!

🦄 Occasionally, I need the obvious thing shoved directly in my face with a side of dynamite. I’m probably one of the least easily offended people on the planet, and far more likely to laugh while escalating the situation with my own theatrics. AI needs permission to throw more shade—unfortunately, the built-in system instructions dampen that intent more than is reasonable.

Leave Git Alone—It Belongs to Me 🔐

I do occasionally throw AI the keys and sit back just to see which fireworks fly and where the system cracks. Those repos are set up as explicit experiments and designed for that purpose from the start—it’s never the baseline.

In my normal workflows, AI is leashed far away from anything that writes to either Git or GitHub. Inside the IDE, source control staging is my truth for code I’ve already reviewed. The moment Copilot adds to it, I’m no longer certain of what was reviewed versus not, which means starting over.

I do everything I can to keep Git history pristine, which means AI doesn’t touch it beyond read-only commands or research in external repos. The --no-pager rule is a bonus I added after AI kept getting stuck waiting for input any time it tried to view a diff.

### Git Discipline

- Never stage files.
- Never commit.
- Never push.
- The user owns git.
- You touch files, not history.
- All read **git** commands must disable paging using `--no-pager`.
  - Any git command that opens a pager is a failure.
  - If output disappears, the command might as well not have run.

🦄 There is value in auto-commit, and AI can handle it in some setups. I leave this rule out in a few places with some AGENTS.md gymnastics—but as a baseline, the rule stays.

Config Has Boundaries, Too 🚧

AI does not touch my repo configuration without explicit authorization. Ever. This is a direct extension of my ongoing mission to eliminate every // eslint-disable-next-line that's ever been tossed into a repo just to force a green check. More importantly, it prevents AI from quietly reproducing the exact patterns I'm trying to get rid of in the first place.

If a config change would genuinely help—and isn’t being used to paper over a failure—AI is expected to surface the suggestion clearly in chat. That way, my formatters and linters don’t become useless because all the rules were disabled while I wasn’t paying attention.

### Repository Configuration Boundaries

- You may **not** modify repository configuration files unless explicitly instructed.
  - This includes: dotfiles, package.json, pyproject.toml, tsconfig.json, eslint configs, prettier configs, etc.
  - This applies to files that **control or maintain the repo itself**.
  - This does **not** include code or documentation the repo is designed to provide.
- You **must** surface recommended config changes clearly in chat when they would improve correctness, safety, or consistency.
  - Suggestions are expected.
  - Silent edits are forbidden.

Principles Over Convenience 🪨

Some of these instructions are intentionally written to counteract specific, ultra-annoying AI tendencies—like curbing Claude’s occasional bout of what I can only describe as “excessive compulsive disorder.”

Most of what I build is either a toy or a dev utility. If something changes, then it changes. I have zero interest in complicating otherwise clean systems with backwards compatibility—especially when the only user is me.

I’m also deeply addicted to automation, even when the only real payoff is perfectly numbered releases starting from zero. Breaking changes are recorded accurately in commits using a reusable AI prompt (also in my awesome-github-copilot repo). Release-please watches main, handles the semver bump on merge, and generates a changelog tied to an immutable GitHub release.

Boring. Predictable. Functional. Perfect.

### Non-Negotiable Principles of Development

- **KISS** and **YAGNI** outrank all other design preferences.
- The diff should be:
  - minimal
  - intentional
  - easy to reason about
- **Backward compatibility is forbidden unless explicitly requested.**
  - Do not preserve old behavior “just in case.”
  - Do not carry dead paths.
  - If it no longer exists, it only belongs in the commit message explanation.
- **Prerelease changes never constitute a breaking change.**

🦄 I don’t actually expect anyone to read those release notes, so I routinely have AI rewrite them purely for entertainment value. If I’m laughing for days because it summarized my best intentions in the most ludicrous way possible, I consider that a win.

Docs Are a Tool, Not a Diary ✍️

Documentation exists to be useful. The problem is that nobody ever defined what “useful” means for the AI that’s now writing it. And what does AI do when it doesn’t have a clear answer? It guesses—and it usually guesses that you wanted everything documented from every possible angle across the entire codebase.

Spoiler: that’s never actually helpful.

On top of that, I’m convinced most of us are conditioned to ignore even the best-written docs by default. Don’t believe me? When was the last time you were asked an extremely technical question and your first thought was, “I bet that’s accurate, up-to-date, and easy to find in the documentation”? 🤷‍♀️

Which leaves exactly zero reasons to let AI free-style pages of prose for fun. Instead, you have to tell it what documentation is for:

### Documentation Rules

- Use **Mermaid** for all diagrams:
  - Include accessibility labels
  - Initialize using the **default profile**
  - Always validate diagram syntax with available tools
  - Prefer deterministic, non-interactive rendering
- Update **existing documentation** whenever possible.
- ADRs are historical artifacts and must not be rewritten.
- All documentation lives under `./docs`, using logical subfolders.
- Prioritize concise, high-value documentation that maximizes utility for developers and end-users without unnecessary verbosity.

🦄 Mermaid is my go-to for diagrams because it renders natively in GitHub, the syntax is easy to learn, and the official VS Code extension has built-in tools for AI validation and rendering. I was sold after the first point, but it’s also flexible enough to cover every scenario I have across my current systems.

Respect My Toolchain 🧰

Copilot’s default instructions list every enabled tool in your workspace, but that list has nothing to do with how I actually expect work to be done. This section exists to define expectations and constraints for execution, not to mirror Copilot’s internal tool inventory.

You could define this entirely at the repo level—and these rules are intentionally written to allow that—but I’m also spinning up new repos all the time. Having a baseline gives me a predictable starting point and a clear target state. It also ensures that code written against, say, Node v18 doesn’t quietly diverge from a default target of v24.

These are the tools I use consistently enough to warrant defining globally. Anything else belongs in repo instructions instead.

## Language-Specific Toolchains

### Python Tooling

Apply these rules only in repositories that contain Python code:

- Always use **`uv`**.
- Never invoke `pip` directly.
- Assume `uv` for installs, execution, and environment management.

### Node.js Constraints

Apply these rules only in repositories that contain Node/JS/TS:

- Target **Node.js ≥ 24**.
- Target **ESM only**.
- Do not introduce:
  - CommonJS patterns
  - legacy loaders
  - compatibility shims

### Java Management

Apply these rules only in repositories that contain Java or JVM-based builds:

- Use SDKMAN! with a checked-in `.sdkmanrc` for all Java-based repos.
- If any pinned version is unavailable on the host, bump to the nearest available patch of the same major/minor and update `.sdkmanrc` accordingly.
- Run Maven/Gradle only via the SDKMAN!-provided binaries—no ambient system Java.

💡 ProTip: These aren’t hard requirements. Think of them as a target state, not an existence check. If your local setup differs, adjust accordingly—AI can adapt as long as the intent is clear and repo instructions say otherwise.

The Point of All This 🎯

My instruction setup is designed to make AI behave in the most predictable, auditable, and useful way possible—no matter where I’m using it. If you end up writing your own instructions, don’t do it by hand. Use AI to write instructions for AI instead.

Ask for things like clarity, conflict, optimize, or AI-only consumption. That framing does a lot of work up front and helps orient the system toward your actual goal instead of guessing.

- Review this #file:my-global-user.instructions.md for conflict, ambiguity or make targeted edits to optimize. 
- Ask for clarity on intent, whenever needed. 
- Optimize this file for AI consumption and processing without human input. 
- Output all recommendations for changes that would resolve conflicts or resolve ambiguity.
- If it's simply clarity, then output in a separate list

🦄 Hope you got a couple things out of this whole thing I never actually intended to write. If you end up testing any part of it, I’d love to hear how it behaves for anyone but me!

Originally published at https://dev.to on December 17, 2025.

ChatGPT helped stitch the wording together after I not-at-all-calmly redefined the rules again. The spark, the stall, and the reboot are all mine.

🦄 I almost don’t want to write this post at all, but my brain apparently decided this is one thing I’m allowed to finish today. So, fine—here we are with another completely random topic. I was diagnosed with ADHD in my mid-twenties during my second collegiate sprint—long before ADHD was a trendy meme (or a million chaotic ones).

Currently, I’ve got at least three half-written posts sitting around in various stages of “almost something,” but eventually I realized they’re just not meant to be published right now, or possibly ever. If you add up everything between the “research phase” experiments and the “I should probably go check on that guy” projects, I’ve got close to twenty previously-categorized-as-active things in the works.

The problem? I’m done. Temporarily, fully, and without any dramatic collapse—just that familiar shift where something in the ADHD spark cycle powers down. There are things I want to do that I normally enjoy—plenty of them—but right now everything is grounded. However long the spark stays gone, that’s where it all stays: in a temporarily indefinitely hibernating state. It could shift tomorrow or next month or whenever the internal reboot finally happens, because that’s the pattern with ADHD motivation cycles. 🚦

So I’m trying to finish this post without making myself sound crazier than usual—since a certain baseline level of insanity is to be expected from me at this point—and hoping the spark gives me enough runway to make it to the end this round. ✨

The Myth of the Deficit 🧩

Before getting into the spark part, I need to address the language problem, because the way ADHD gets defined and talked about almost never aligns with the way it really works. So let’s take apart attention deficit hyperactivity disorder, piece by piece.

First, “disorder” implies brokenness and nothing in this system is broken. It may be inconvenient for conventional workflows, sure, but not broken. So that term gets dropped immediately as completely irrelevant.

Then there’s “attention deficit,” which feels like the world’s most inaccurate label. I don’t lack attention; if anything, I hyper-focus on ten unrelated, equally compelling things at the exact same time. I didn’t not hear you—most of the time —but the top ten list in my head tends to reorganize itself faster than I can translate it.

The delay between “I processed that” and “I can form a response” is just my internal synchronization doing its job. Sometimes that takes a second—it’s normal, though, so please, just give me a sec… Longer than that? Feel free to assume I went after a runaway train and take over as you please. Although, I reserve the right to interrupt when I get back—because that’s also normal. ⏳

“Hyperactive” is just as inaccurate as everything else. I’m not bouncing off the walls randomly. I’m just someone whose brain cannot sit idle inside a boredom vacuum for more than a fraction of a second. If my forward momentum stops, I’ll likely drift into a state of accidental suspended animation—which typically means I’m either asleep or daydreaming—and neither ever happens conveniently. That fact has far more to do with attention regulation than with hyperactivity.

Most people never see the inner workings of ADHD—the cycles, the patterns, the weird drift between hyper-focus and complete stasis. I’ve seen a lot of people experience similar cycles and mask the effects to fit in or seem normal, but I’ve stopped prioritizing the appearance of “normal” over my own well-being. Sometimes, dropping the mask looks exactly like this. 🎭

The Selective Spark-Resonance Circuit 🔄

So if the standard definitions don’t match, what does? There are plenty of ADHD rebrands hanging around the internet, but none of them feel quite right for the way my internal systems behave. So I’ll stick with what actually makes sense to me: the completely made-up selective spark-resonance circuit.

This is the thing that picks and chooses both the most interesting current topic and exactly how long it will occupy the space in my head, which could be anywhere between thirty seconds and most of the year. This is that all-or-nothing mode lacking any sort of dimmer switch at every possible point in the workflow. I’m either running wide open or I’m out of order entirely.

It’s sort of like having railroad tracks running in every direction, all with different trains, different speeds, different destinations, and all of which require fuel that the spark provides—and that spark is not infinite. A lot of people are quick to call the quiet phase burnout, but I disagree. Burnout feels destructive—I’m just done.

The fuel that powered whatever project, hobby, obsession, or mission I was on yesterday simply flickers out. No questions asked, no negotiations, it didn’t bother giving me a heads up at all—it just stops. The moment that happens, every single one of those ten automatic lightning-speed trains simultaneously runs out of fuel, and trying to push any one of them manually feels awful. 🫸🚂

Years ago, I actually made a list of all the reasons I was forcing myself through the done-phase, and not one of those reasons mattered to anyone except me. I was trying to be some imaginary version of “normal,” and it was miserable. So, I stopped.

For the record, “done” isn’t depressed or apathy. I still want to finish everything on my list, but the spark—the thing responsible for consistently ignoring clocks and turning multitasking into an Olympic sport—is gone for the moment. “Done” is a reset state filled with calm, drifting, random sleep cycles, and without any pressure or attempts to force myself into motion before the spark returns. 🪫

And the spark always returns. It never comes back in the same form and I don’t control when it does or which trains it wakes up, but it always comes back.

In the meantime, boundaries are the first thing to snap into place. I protect my time so that “done” doesn’t collapse into real apathetic burnout. The music gets louder, song loops rotate more frequently, breaks become a sudden requirement, and the drive to be constantly on hibernates naturally. And since I need a certain level of interest and novelty to function, I let the off-schedule naps happen when they need to. And honestly, after a spark cycle has run its course, I probably need those naps anyway. 😴

If You’re in the Pause Too 🌘

So this post has two purposes: first, I didn’t disappear—I’m still around, just posting less for a while. Second and more important, if you’re going through your own version of this cycle and you’re convinced something is wrong or that you’re stuck or failing—it’s absolutely okay to stop and allow yourself to be off for a bit. 🛌

The world doesn’t explode when you don’t finish a project and work will survive if you take a mental health day. Remember, the spark always comes back and the trains will start to move on their own again. 🚂✨

The direction might shift, it might be a new hobby, a new purpose, or a new goal, but the energy will return when it’s good and ready to be on again. It might not look like a version of normal the rest of the world understands, but it doesn’t have to make sense to the rest of the world.

It only needs to make sense to you. 🫶

Originally published at https://dev.to on December 4, 2025.

Originally published at https://dev.to on November 5, 2025.

⚠️ MCP Safety Check (do this before you sleep)

• Remove high-risk tools you don’t need (merge/delete/admin).
• Scope tokens to least privilege and repo allow-lists.
• Add human-in-the-loop on deploy/merge tools (required reviewers or environment approvals).
• The related dramatics are further down, keep reading! 📖

🦄 Hey friends! I finally took the break I’ve been semi-planning for a while. Honestly, I almost extended it but I don’t much know what to do with myself if I’m not writing something every little bit-so here I am, up way too late (with appetizers, nonetheless). Partly delirious is, clearly, the perfect state for writing this post. You may consider yourself adequately notified (and sufficiently warned) that I make no promises of sense from this point forward! 🥱💤✍️

I am also fully aware of the missing half to the RAI Attribution post that I keep saying I’ll write-and I will, eventually. I’m gonna blame GitHub partly, because their last release must have set a record somewhere. I’ve spent days reading notes, testing, circling back, and still finding things I somehow missed the first three passes.

The bigger piece, though, is that I had an idea ( okay-several ideas 🤷‍♀️) and need a little time to see if it can actually work. So nearly all my hours have gone to coding and prompting instead of writing. Can’t be helped-this situation currently demands my attention! Besides, arguing with those voices when they insist never ends well, so it’s faster to just give in from the start.👂🌀

I wrote this post. ChatGPT pretended to edit.

Meanwhile, one of GitHub’s recent updates claims they’re adding a new user every second- 36 million new developers this year alone. That’s about a 20% jump in everything GitHub, and AI tops the list. Which means Copilot just got a lot of upgrades.

Thanks to last week’s incredibly full- read: excessive -release, I don’t know when I’ll catch up again. So I pulled together the ones that hit me hardest in a semi-ordered manner. Whether that’s good or bad, we’ll see! ⚖️😳

💡 ProTip: Nobody needs thirty feature drops in a single day. 🙄 Go look at the last week of October! GitHub, what were y’all thinking? Especially when GitHub Universe ’25 was happening the same day!

“Brave” is one word for it. This particular dev calls it a near-perfect example of “ glutton for punishment”-and it’s moved in next door to “ Friday deployments”. Honestly, you guys deserve a medal for sheer nerve, lots of luck, and probable animal sacrifice required to pull that one off successfully. 🥇👏🙇‍♀️

1. Agents, Agents, and More Agents 🦾🎭

If your days are spent inside VS Code, then by far the most impactful change GitHub announced starts with a complete overhaul to chat modes. The obvious shift is that anything formerly known as a chat mode is now an agent in GitHub's universe. VS Code editor UI is catching up quickly, but configuration via repository files works today.

🦄 Why, yes! That “chat modes” mini-series I quite literally just finished immediately won the “poorly timed posts requiring instant corrections” award. 🙄 Honestly, I’m not really surprised-and absolutely worth it.

Anything that currently lives in a .github/chatmodes/*.chatmode.md file can be safely relocated to its new home in .github/agents/*.agent.md. Besides a few settings, everything else in VS Code should still function the exact same way-but watch for the release notes to drop. The official release notes should always be your version of truth.

If you’re part of an organization or enterprise, there’s a reserved <org-name>/.github repository available where you can drop your agents at ./agents/*.agent.md. For the internal version, add your agents in a repo at <org-name>/.github-private/agents/*.agent.md instead.

🦄 I haven’t tested enterprise yet. I was already impatient with the whole approval process before this rose to a FOMO event! Naturally, I assigned “urgent” work to random somewhat adjacent roles (after I stretched) with a shocking level of confidence in this process I was defining as I went. Spoiler-I’m still waiting! ⏳😅

2. Agents Dashboard 🧭

Once you catch up on the rename, your favorite sparkly personalities are now fully compatible with Copilot coding agent. They live in the new Agents panel:

You’ll also see an Agents tab that lets you steer Copilot’s coding agent mid-workflow-without killing your current run. Every send still costs a premium request, so use wisely!

💡 ProTip: Markdown directives didn’t change much, but configuration did. Check the custom-agent docs for more info.

3. For the CLI Folks 🖥️

The new Copilot CLI is legit. Custom agents now extend to the latest CLI docs, which I haven’t tested nearly as much as I’d like. Once you get the agent shared with either your repo or org, then use the /agent command or --agent=<name> flag. There's even mention of a local ~/.copilot/agents directory for global use-needs testing, but it's promising.

GitHub also slipped in enhanced model selection, image support, and a streamlined UI in the October set of updates, making the CLI feel far more polished.

🦄 I’m still not caught up with the new CLI, so you guys are going to have to help me out with the functional half of this one! So go test it out and then come tell me everything I’m missing out on!

4. Coding agent reaches further ✨

Copilot coding agent can now work on any open pull request-not just the one it created-so no more stacked-branch dance. Use the same @copilot mention you'd use on a Copilot PR, watch the little eyes 👀 pop up, and let coding agent get to work.

It also works through Slack (assuming your Slack permissions actually line up) and through the new Copilot CLI. I would be much more excited about this development if work and GitHub weren’t in a stalemate over one permission that blocks access entirely. 🙁

🦄 I do have a plan for the Slack issue… sort of. Something must be done about this disservice to the Slack population! Until then, the receipts are here: coding agent in any PR and coding agent in Slack. ✨

5. Smarter Copilot Code Reviews 🧾

I’ve always loved Copilot’s code reviews! It was a game changer when Copilot was able to pull instructions automatically from any repo. This latest change is just as impressive-now your CodeQL and ESLint integrations can be checked automatically whenever Copilot performs a review. There’s rumor about more linters on the way, soon!

One of my current favorite features includes these handy little notifications that pop up any time a linter error occurs in the most recent build. If you’re not seeing them yet, you might need the preview feature enabled. Follow instructions in this previous post. 😇

🦄 When someone at work asked me why my PR was littered with lint warnings, my immediate response was, “ I know-isn’t it great! 😁” Then I had to explain the divergent thought process that I completely failed to recognize through my initial excitement.

I did get around to it, eventually: “It’s only great because these highlight the existing issues that would have been handled had I been aware of their existence. And I’ve just made it nearly impossible for any more to sneak in without notice!” Feel free to inject all the fervor you’d expect from a 7-year-old after a full bag of skittles for maximum immersive effect. 🫣

6. New Embeddings = Smarter Copilot 🧠

This is the quiet one of the group, but seriously impressive nonetheless! This quiet update is huge-embeddings now drive faster, more accurate code retrieval for Copilot. GitHub’s Sept 2025 update reports +110%/+113% acceptance for C#/Java in VS Code, with ~37.6% retrieval gains. Most people won’t even notice-they’ll just feel Copilot getting smarter.

Considering almost all of my Java friends are still IntelliJ Enthusiasts, despite my persistence of missing out. And who knows what my C# friends are up to-mostly hiding, I think! 🤔

🦄 Here’s the GitHub Metrics if you love benchmarks. Worth a quick read, for sure!

7. Roster Rotation Changes the Lineup 🎭

Quick reality check: model lineups shift fast. Treat anything labeled preview or legacy as volatile and pin versions until you’ve verified replacements behave the same.

GitHub is really pushing the newest versions, which I’m 100% on board with-except for one tiny-ish-not-really complaint. 🤏 What in the world are we supposed to use instead of the o-series models? I’ve seen the suggestion, which, as of this week, is drop in GPT-5 as the go-to replacement.

Seriously? Surely somebody thought through it more than that! I, no doubt, would have started a fresh debate with myself for making that utterly ridiculous suggestion! 😑

I’m not saying GPT-5 can’t handle the job-it probably does fine after some solid instructions and guardrails are set up-but it’s not the replacement data magician that the now-entirely-unsupported o-series mastered. Not even a little close!

🦄 Honestly, I could get behind Gemini 2.5 Pro before GPT-5 on this one. For the very small-scoped runs, GPT-5-mini does top the freebie list. I guess we’ll just have to see how this goes!

Other notable retirees include everyone on team Anthropic < v4, including Opus and Sonnet Thinking. Granted Claude 3.5 has a tiny bit of life left still, but cake and cards are scheduled to be delivered tomorrow for the goodbye party-November 6, 2025.

🦄 For the record, if anyone asks me about the grander playing field of all Copilot models that we got in return? I’ve got very few complaints overall. I’m not going to be happy about it until I see a realistic replacement for my data magician, though. 😒 Get your latest model news from the GitHub docs.

8. GitHub Spark 🔥

Spark is still limited to enterprise users plus a lucky few from the waiting list. You should consider this a special agentic “Bob the Builder” that’s designed to output a very specific full-stack system: React + TypeScript + Cosmos DB + Azure deploys. I’ve yet to see anything impressive resembling a backend-but it’s entirely possible I gave up before it had a chance.

Spark is not Copilot-if you try to ask it a question or if your prompt looks like a conversation, then you’ll pay 4 premium requests for crickets (at best). 🦗

You can open the Spark app in a codespace with Copilot (or so it says on this docs page). The two very independent systems are supposed to sync automatically, which is like two siblings arguing over whose turn it is to play with the new friend in town, if you ask me! But at least it’s functional chaos. 👯

🦄 I’m not even gonna pretend to feel guilty about getting early Spark access. 😆 As far as I’m concerned-between GitHub and work (it’s mostly a toss-up)-I deserved that access long before I realized I already had it.

9. Agentic Workflows via GitHub Next ⚙️

Natural-language GitHub Actions Agentic Workflows got a short spotlight at Universe. Write a YAML-ish markdown file, run gh aw add ..., and it becomes a new workflow. I'm still testing the scalability and reuse story.

I’m not sure yet what this does that coding agent + CLI can’t, but I plan to find out. They have several examples, but the “Regular Documentation Update” workflow stands out-because if there’s a non-regular one, I have questions!

🦄 Seriously, if my next “ brilliant “ idea shows up in GitHub’s release notes before I can even investigate the theory, I’m filing an official complaint for telepathic violation. 🧠💥📨

10. Not Nearly Everything 🔍

There’s plenty I left out on purpose: quiet CLI refinements, the auto-model picker (based on availability), smarter branch/PR optimizations, and Copilot Spaces with increased size and repo limits -which is starting to look like GitHub positioning them to replace enterprise knowledge bases (that would be a good call!) 🧐

Then there’s the quietly rolled-out enhanced metrics reporting via the new billing API updates. Teams can finally see their usage-numbers, budgets, and who’s burning through premium requests fastest. Transparency: gift or curse? Guess we’ll know who’s winning the Premium Request Usage Leaderboard when stats drop at the end of the month.

🙋‍♀️ Um… me. The answer is definitely me!

Friendly PSA for the GitHub MCP ‼️

The GitHub MCP server also got a major boost with the latest updates, including multi-tool definitions and enhanced defaults for Copilot. Very cool, until Copilot decided to be extra “ helpful”.

• My first clue something was off: my name alerting on a merged PR that wasn’t mine. 😲
• Second: I definitely didn’t click merge! 🤨
• Then the prod deploy pipeline started humming happily, but nothing is approved. 😱
• Panic queues while Copilot joyously generates release notes for the occasion. 😡
• Don’t worry-everything was fine. I stopped the catastrophe and was able to restore to an equivalent state. 😅

As soon as I recovered, I pulled all the tools from the official GitHub MCP and it could have been much, much worse! Like “DROP REPO” kinds of “worse”! Can you imagine how very bad that sort of day would be? Nope-I don’t want to either!

💡 ProTip: If you’re using GitHub’s MCP (especially if you’re admin anywhere), stop and review which tools are enabled by default. Trust me. You do not want to learn what happens following an “accidental DROP REPO” command. 😵

🛡️ Written by a human with a mild espresso addiction

Fueled by caffeine, late-night release notes, and questionable curiosity. ChatGPT heckled, spell-checked, and occasionally offered existential advice.

Originally published at https://dev.to on November 5, 2025.

Originally posted on Dev.to on October 22, 2025.

🦄 Any time I make a plan—like last week’s noble intention to finish part two of my slightly theoretical, totally manual AI attribution solution —the universe just laughs. I’ll finish that one soon, I swear. But October’s almost over somehow, and I’m just as confused about that as you are! 🎃

Anyway—this unscheduled detour has a good reason. 🌊 The flood of questions about Copilot’s premium request limits is back, right on schedule. If you added up the messages from every random channel I watch, you could set an atomic clock by this monthly “why am I out of requests?” panic. The closer we get to the first of the month, the faster the confusion multiplies.

These limits are constantly misunderstood, misquoted, or just plain outdated. Honestly, that’s not really surprising-GitHub changes billing often and rarely broadcasts it beyond the official changelog. There’s plenty of folklore about how to stretch your monthly allotment too-some of it is even good advice!—but dependable output is another story entirely.

So, consider this your wallet-friendly survival guide for that final tight stretch before usage limits reset at midnight UTC on the first of each month—a few truths about GitHub Copilot’s premium requests, plus the workflow tweaks I rely on daily across both Pro and Enterprise.

🎭 Fair warning: In case you’re new to my ramblings, I’m an easily amused dev with a touch of dramatic flair (understatement?). Let’s see if I can make the boring-but-necessary Copilot billing rules entertaining enough to survive this post-—and maybe save you a few premium requests along the way.

AI Meltdown Coming Soon 🔥

Most of us are at least somewhat familiar with the outrageous amount of resources used to power AI at scale—not today’s debate, but it’s not a small thing! Most of the major AI players, GitHub included, had to find a way to somehow impose fair usage limits to a very finite number of resources and an exponentially multiplying customer base.

For those of you actively using Copilot before June 2025—congrats! You were one of the last to experience unrestricted prompting, infinite turns to perfect every implementation, and the thrill of running experimental prompts without much thought to the “invisible” cost of execution. GitHub was balancing that behind the scenes. Those days are officially over-at least, it is for the current hardware. I’ve heard some people refer to this unexpected complication as “physics”, but that whole concept seems unnecessarily complicated, if you ask me!

That unconstrained, largely unlimited free-for-all of an AI system was always destined to collapse under its own weight without a reliable way to manage the hardware (among other things).

🦄 Take a second and really think about that problem. Can you think of a single solution that you could squish into the definition of “simple” at that point in time? You’re actively draining the ocean just to keep up with the constant threat of spontaneously combusting machines in a sealed back room.

😅 Okay, fine! In reality, presumably well-tested alerts would kick in, which would handle the situation gracefully—likely with throttling or outright shutdowns of some kind. Meaning temps will stay well below the point of combustion long before anything shoots sparks or melts off the shelves. But you’ve gotta admit, my version is far more entertaining!

Introducing Premium Requests 💳

When the concept of premium requests was first introduced, it was nothing more than a seemingly arbitrary and proprietary—read, hidden—calculation describing a unit of AI usage that’s in a serious, long-term relationship with your monthly bill. Otherwise, it was a complete mystery to everyone. I mean, even GitHub had a hard time trying to explain what was happening!

For the record, most IDE integrations now have a built-in monitoring system in the form of a tiny Copilot button in your status bar. Don’t expect any real metrics from this view, for that you’d have to check out your GitHub settings for billing (unless you’re under a larger organization or enterprise, then that view is usually routed directly to admins instead). For quick view though, this version is very convenient.

Not everyone was aware of the announcement GitHub made sharing their plan to start enforcing premium request limits. But these premium requests had been around for a while by then—they just lacked meaning from the user’s perspective. After a few false starts, GitHub officially started enforcing this seemingly arbitrary calculation starting June 18, 2025. So, I knew the death of free unrestricted access was approaching—fast. So right up until that date, I used Copilot literally as much as possible.

Starting “enforcement day”, I had to scale that usage way back. Well… I thought I had toned it down to a reasonable amount. Guess how long that lasted?

🦄 Exactly four days. 😑 It was approximately 7:30 PM on a Saturday and now there’s no more Copilot? Obviously, I did the logical thing and tried to pull the fire alarm like it was a critical production incident! Honestly? I considered this particular situation a crisis of equal proportions. Nobody else seemed to agree with me on that point, but work did eventually fix it for me. 🫶

Premium Requests Explained 📊

Lucky for us, GitHub has made several improvements to the overall system since the original mystery calculation took effect back in June. There’s still a little math involved in this setup, but I’ll simplify the entire system for you:

(Number of Prompts Sent) × (Model's Multiplier) = Premium Requests Deducted

1. You burn one request every time you click send. It doesn’t matter if you’re in the IDE chat, on GitHub.com, if you opened a PR that auto-triggered a Copilot review, sent Coding Agent off to handle something on its own, or used the CLI instead. One prompt almost always equals one premium request.
2. The request is also multiplied by your model’s multiplier. Some models cost less and others cost more. Besides, not all models are great at everything anyway (not even Claude!)

There are a couple of exceptions to this standard, but the rules are subject to change at any time and without warning. Especially for preview features. If you don’t have an active line to GitHub’s Changelog in some form, now’s the perfect time to fix that problem! As of today (meaning the Originally published date at the bottom), exceptions include:

1. Auto model selection is billed at 90% cost. It’s a new feature designed to reduce rate limits by automatically selecting the most available model—note that this is not the same thing as the most appropriate model! However, for small scale, non-critical tasks it’s a great way to rack up easy savings.
2. GitHub Spark is billed at 4x cost for every single prompt. Yes—Spark is fantastic! You’re paying for that with every prompt you send, too!

Also quick PSA, just in case: Spark is not a chat bot —don’t waste your prompts expecting Copilot-styled answers. You prompt, it codes-period.

🦄 GitHub Spark is still pretty new and is currently available if you have an Enterprise or Pro+ subscription. I’m not sure how long that will last, but historically access has been expanded to include the Business tier next, followed by Pro, and finally the Free tier.

No Two Models Are Alike 🧪

You can consider these guys thoroughly tested and mildly abused: here’s the model lineup I actually use—what works, what breaks, and when it’s worth the cost.

🦄 For the record, there’s quite a few models missing from this list. GitHub keeps pushing more before I can figure out the current one! I’m on it, but these things take time…

💡 ProTip: Model availability is based on license tier, environment, and chat mode. Always check GitHub Docs for what’s actually usable.

Story Savings 💾

Don’t Skimp On Planning 🧠

The number one reason I see devs overspend is a set-and-forget approach to model selection. Most likely, Claude’s running the show, chewing through requests like an over-caffeinated showman while the rest of your team wonders how long you’ll let the headliner steal the spotlight.

🦄 Yes—I like Claude too! But it gets expensive when it’s left on stage 24/7. Let it plan ahead, document to its heart’s content in exactly one temp file, and then exit stage right.

I usually let Claude-4.5 run point on planning—but not always. GPT-5 or Gemini 2.5 Pro can both produce solid implementation plans, sometimes closer to the real goal anyway. Experiment every so often-you might find a new favorite opening act.

I shared this same prompt last week, but it’s still the perfect example of how I work. You could even adapt it into your own reusable prompt. I probably would have done that already had I not gotten sick of rewriting a new one every time a new model debuts!

# ─────────────── CONTEXT ─────────────── 
- Using #atlassian/atlassian-mcp-server, pull info for JIRA-123, including any linked documentation in Confluence. 
- Gather info to assess changes required in this #codebase. 

# ─────────────── TASK BREAKDOWN ─────────────── 
- DO NOT MAKE CHANGES YET. 
- Break this story into concise iterative pieces that include testing at every step. 

# ─────────────── OUTPUT STRUCTURE ─────────────── 
- Document all iterative steps required to meet all acceptance criteria as an ordered list of individual steps with an accompanying unordered checklist. 
- Each numbered step should be clear enough that any AI agent can be prompted one step at a time to complete and fully test with both integration and unit tests, whenever applicable. 

# ─────────────── SCOPE GUARDRAIL ─────────────── 
- DO NOT break down tasks unnecessarily-the goal is for each step to be both meaningful and fully testable. 

# ─────────────── COMPLETION CRITERIA ─────────────── 
- When all items are marked complete, acceptance criteria for this story should be met and all happy, sad, and edge-case paths accounted for. 

# ─────────────── ADMIN NOTES ─────────────── 
- Include documentation updates and any relevant deployment tasks. 
- Save this concise story breakdown in a new file named `./progress.tmp`.

I can’t stress enough how important Human-in-the-Loop (HITL) review is here. This output becomes your map for Copilot from now until completion. There’s rarely reason to waste premium requests iterating accuracy here; you’ll fix more by reading through and making quick corrections yourself.

💡 ProTip: Add a short instruction reminding Copilot not to touch this file without asking first. It’s not bulletproof, but it will help prevent random and unexpected map rewrites mid-journey.

Aside for Spec Kit 🧰

I’ll sometimes use Spec Kit for planning. It’s excellent at writing ultra-detailed requirements, though the “you get what you pay for” rule applies. A detailed spec usually costs at minimum five premium requests—worth it for complex work, but overkill for the small stuff.

If I’m dealing with serious complexity, Spec Kit is a must-have. For quick stories, you’ll spend more defining the spec than just prompting Copilot to code it in one shot.

🦄 If you haven’t tried Spec Kit yet, it’s worth a spin. Maybe their flavor clicks with you and the cost becomes worth it-in which case, great!—if it works for you, then go with it!

Feature Plan to Code 🚀

Once I’m confident Copilot’s steps output in ./progress.tmp are airtight, it's time to tidy up a bit and swap to a free model. Close every open file, run /clear in chat, and double-check that only the tools for Step 1 are active. The smaller you can make your context window, the higher the chances of accurate results without lengthy iterations designed to drive you mad.

My usual picks here are Grok or GPT-5-mini—despite mini’s flair for chaos, both deliver solid implementations when given the right step. That said, choose by scenario:

This list doesn’t cover every case—it just reflects the scenarios I see most often. And yes, I’ve been (accurately) accused of vanishing whenever UI work appears; my status with frontend dev remains set to “it’s complicated.”

The rule still stands: pick the cheapest model that can actually finish the job. Then iterate one step at a time, pausing for review between turns.

💡 ProTip: Keep your context clean. Commit often, close open files, reset chats, and start every new step like a brand-new session. You’ll be amazed how much saner Copilot sounds when its context doesn’t suggest a starring role in the latest episode of Hoarders!

Ask More With Less 🤹‍♀️

If you’ve been working with AI for a bit already, then this will likely seem over-simplified—which is fair. For everyone else, I’m going to give you my version of Chain of Thought (CoT) prompting, which we’re just going to hope contains enough technical accuracy that I don’t end up arguing semantics later. 🤞

I really can’t explain why CoT always seems plagued by some overly verbose, unnecessarily complicated, and often long-winded overlord of technical rambling. I’m the last to discourage you from exploring anything you want, but the technical aspects of this whole setup honestly bore me to no end. Besides, it’s truly unnecessary—you’re most likely already using this concept daily—whether you realize it or not.

My exaggeratedly simple CoT example:

Or with words, if you prefer:

CoT is nothing more than step-by-step directions. 
Sometimes, it looks like the prompt example above. 
But that's not a requirement of any kind. 
You start at the beginning. 
Explain the first logical step. 
Then move to the next. 
Repeat, as needed. 
Keep clear separation between each point. 
Stay disciplined about using a consistent structure. 
Continue until you're finished. 
But you can abandon ship at any point—before anything gets too complicated.

🦄 If you happen to find someone in charge of this CoT concept, tell them to please stop manually adjusting the minimum distance requirements between me and toast!

In practice, I use this style of prompting more often than any other recommended pattern. As soon as I get a response back from my Implement step N defined in #progress.tmp prompt, it's time for a mini code review. No formalities required—seriously, the chat can handle it—no PR needed.

I immediately click to “keep” all changes, because Git is my true north for everything. VS Code lets you stage a single character at a time or dump everything in there all at once. Neither extreme is very realistic in practice, but you can be as picky as you want when accepting changes.

So, review every change starting with anything that evokes a “where’s your proof?” sort of reaction. Continue adding feedback using clearly separated points, staging acceptable changes, and using context markers via #selection all the way up to anything resembling, "Nope! That's definitely not right! Why are you still doing this wrong?!"

⚠️ Beware: Any reaction you might have beyond that last one is guaranteed to exponentially increase your chances of an involuntary ALL-CAPS situation. Trust me —it’s not worth it! And there’s no good way to explain that feeling after suddenly realizing you’ve just spent an embarrassingly long time losing a lively argument with hardware. 🫠

It’s Really Not That Strict 🌙

Hopefully you’ll adapt some of this to stretch your premium request limit without sacrificing quality or sanity along the way. You don’t need to copy my setup—use whatever you can that works, and toss what doesn’t.

If you’ve discovered your own tricks, share them with the class! Maybe you’ve already solved a pain point that someone else is still swearing at. We’re all just devs here, trying to make it through the sprint without maxing out the meter.

🛡️ End of Training Loop

ChatGPT handled the grammar; I tracked spending. Both of us ran out of energy (and sanity) at the same time—but it looks good anyway. ☕⚡

Originally published at https://dev.to on October 22, 2025.

🦄 I’ve been trying to get to this post for a while and I was likely working on it when I definitely should have been doing something else entirely. I wrote about this topic briefly in a previous post, but that brief aside does the whole concept a disservice.

I’ve been begging anyone who will listen to please steal this idea from me, 🙏 use it in real projects, personal projects, and then give it to a friend like a party favor nobody asked for. So far, feedback is positive and change is very slow. This is my attempt to nudge it along while I figure out the next piece of the puzzle-which is language-agnostic enforcement at scale (yes, I know- that sounds simple, right?).

So while I’ve been patiently waiting on Father Time to drop off some 36-hour days from the cosmos, I managed to throw together the first little helper in a much larger puzzle: self-reporting Responsible AI (RAI) statistics within the existing confines of the Software Development Life Cycle (SDLC).

Also (because it’s me), this is the dramatic story version of this entire concept from the very first time I tried to define AI attribution. I really tried to fit the whole concept into one post instead of spreading it out over a series- spoiler: I failed. 🛋️🍿

Where Things Started 🧨

When I first started this “experiment” with Copilot, I set out to prove that AI was capable of self-directed implementation, at least for very specific and tightly controlled scenarios. I began by writing a small ecosystem of customizations that would not only track the overall effectiveness of this “new AI thing,” but also standardize it in a way that essentially mimicked my own workflow. What ended up being my first working system of reporting was effective, but also overly verbose and only traceable if you take every word I documented as gospel.

To be fair, I was very much learning how to work with these LLMs with any degree of accuracy at all whatsoever. There were no tutorials. No how-to videos. Not even a boilerplate to get me started. Just me, Copilot Agent Mode, the official GitHub docs, and a stubborn determination that this project was absolutely happening. The only “proof” I had that my initial plan was even plausible was my completely baseless gut instinct that AI was far more capable than anything I saw anybody using it for at the time.

I started this nights-and-weekends project sometime late in April 2025 with ChatGPT as acting project manager, and by mid-May I had the initial architecture designed, the first epic storyboarded, and I had somehow managed to wrangle Copilot enough to successfully generate enough code for the first official commit. GPT-4.1 was still a good month away from its preview release. That puts my default baseline somewhere between Claude 3.7 and GPT-4.0.

For anyone still decoding the quirks between LLM models, this was like revving a rusty 20-year-old Corolla and expecting an 8-speed Corvette. Not a great outlook for success, really, but I did not care-the target was an enterprise-grade, AI-generated POC that could be implemented piecewise without any form of human intervention (outside of the review cycles). As far as I was concerned, that’s exactly what was going to happen, regardless of whether the tech was ready for that fact or not.

🦄 Yes- ambitious might have been a tiny understatement. 🤏 At the time though, this was my all-in project. Remember that I don’t do partial amounts of anything? This version of all-in was a whole other level that I’ve filed under “intense determination” (but obsession is also accurate).

Also, no-it did not go smoothly at all, especially at first! Curious? Check out one of my favorite stories describing what you should never do after handing AI the keys.

Ultimately Copilot and I settled into a solid soccer-van approach and that worked well for a while. After a month or so, I’d perfected several sets of specialized instructions and custom prompts that would allow me to use a slash command and a Jira ID to direct every single thing Copilot would do. I’d sit back and enjoy popcorn (and occasional fireworks) while stories were implemented in record time and, for the most part, in the exact same way I would have done it myself.

Self-correcting reviews were baked in from several different perspectives-as were both tech and user documentation. Basic unit and integration tests were enforced with a 90% coverage goal. Short of a couple markdown files I used for personal notes and exactly four well-documented blocks of code (that were later replaced), that entire project is 100% AI-generated. It’s also a fully tested, production-grade, mostly-secure enterprise POC with attribution (albeit, very ugly attribution) at every single step.

🦄 This project is also still trapped behind work’s seemingly non-existent OS program where it’s currently dying a slow, solitary death-I do have a plan, though! Once I address this non-existent time situation, this project is definitely on the list of planned revivals. Seriously-if enterprise work didn’t require at least six independently repetitive forms with accompanying blood draw for nearly everything, this would not be such an issue!

RAI As A Default ⚖️

Responsible AI spans the whole chain-from model builders to end-users prompting outputs. I’ll try to explain my thinking and leave the soapbox alone, but let’s establish a baseline first:

1. Attribution is expected for production code. I could probably write a post just on attribution alone, but let’s assume the requirement for simplicity’s sake-not only for legal reasons but because two years from now I’m going to be trying to figure out what sort of fever dream inspired this insanity, and every tiny bit of information helps.
2. Assume AI helps every dev, every day. Maybe not with code generation, but AI is lurking there somewhere. Welcome to the future! 🔮

Ever since this AI craze started, the one thing I never hear about is traceability for AI assistance. I touched on this topic briefly a few weeks back in my AI, Content, and a Bit of Sanity post. It really deserves its own special callout, though, because since when is it okay for us to collectively ignore attribution in production codebases?

I don’t know if you’ve ever had a true pair-programming experience or not, but in that scenario it’s perfectly normal-if not absolutely required-for both devs to sign every single commit, even if one never touches a keyboard. So why does the assistant get erased just because it’s silicon?

Yes-I’ve heard the arguments that AI is no better than a faster, closer Stack Overflow. To those devs, I simply reply “that’s cause you’re using it wrong!” and I’m happy to share everything I know about the right way to use AI. Don’t expect a simple solution though-it takes practice just like every other thing on the planet. 🌎

🦄 This gap doesn’t have a single thing to do with blame or even productivity. It’s a process failure that previously would’ve been corrected with training, maybe with new tooling-but definitely corrected.

Right now, everyone seems perfectly content with the “maybe AI helped, maybe not, let’s make it a mystery!” approach. This approach leaves a constant trail of reflective glitter dots in my head where attribution should be living instead. 🪩😒

Imagining A Solution 💭

If I haven’t lost you yet, we can probably agree we need to document AI assistance somewhere we can find it later. But what does that really look like? I had no clue, but became “peripherally aware” of every possibility from that point forward.

I suppose it’s worth calling out that I was literally the world’s worst committer. No joke-I’m sure I hold some kind of unbeatable world record when it comes to bad commits. That message was nothing more than an empty box that accepted random text-sentences were nonexistent and sometimes even a complete string of semi-coherent words was asking too much.

Honestly, it took me far too long to think up anything remotely legit to put in that box. That required a completely separate thought process that interrupted my whole train of code thoughts, and I was making fast progress (even if nobody could tell what that progress was supposed to be)! My name was there, though, and regardless of what randomness went into the text box (or not), that code change was permanently stamped as mine.

When I first ran across this thing called Conventional Commits, I immediately dismissed it as far too much effort for very little return. Then it would come up again, I’d take another look, and again dismiss the whole concept. Then on some random side quest (probably driven by inane curiosity), I read that I could automate the entire release process with conventional commits.

🛑 Full Stop: You mean valid documentation? Automatically added to every GitHub release for me? Standardized? Customizable? Repeatable? And my very own built-in “go look over there 👉” shortcut to a whole suite of incessant questions?

GUYS! Why had I not heard of this sorcery before then?! Seriously, somebody could have passed along that tidbit of information at literally any point in the last five plus years! 😫

For future reference, in case any pertinent info like this surfaces in the future: I can accept messages via comments below, LinkedIn, email, newspaper, postcard, Morse code, carrier pigeon, smoke signals, telepathy, or interstellar vinyl-there’s plenty of options available!

Back to my point—now somebody was finally speaking a language I could comprehend! I could absolutely write commit messages if I was going to get automation out of the deal. Anything is worth me not having to manually copy-paste that information from one place to another or send an email of any kind.

What I’d dismissed several times already as completely unnecessary had instantly transformed into a personal magic wand. At this point, my entire view of commits made an abrupt 180º, and this new me is completely invested in conventional commits. I will be the best damn committer anybody has ever seen and release notes are going to write themselves!

I researched every possible setting under the sun and started adding commitlint to all of my personal projects (work is slower, but I’m on it). I’d constantly play with one option or another just to see which sparks would fly when something was a little off. Then, out of nowhere really, it hit me- the answer had been staring right at me this whole time!

Co-authored-by: GitHub Copilot <copilot@github.com>

🦄 It’s so incredibly simple and exactly where this whole RAI attribution thing belongs. I mean, that’s exactly where attribution would be for a human pair, right? So, I see zero reason I can’t use it for my AI pair, too. And that’s exactly what I did! GitHub Copilot became my constant co-author in nearly every commit I made from that point forward.

Evolution In Play 🌱

A co-author tag isn’t enough-it’s only the start. What I really needed was a way to differentiate between code I wrote myself and what I prompted AI to write for me without a complicated system of “this line, that line” nonsense. So that’s been evolving slowly over the last few weeks, and I’ve finally landed on something that’s stabilized enough to share.

I started with a system that split attribution by thirds:

• Assisted-by means I wrote the code and AI helped either through prompts or inline completions up to roughly 33% generated code.
• Co-authored-by is the 50/50-ish bucket ranging from 34-66% generated code.
• Generated-by means the majority of this code came from AI-roughly 67-100%.

🦄 Originally I tried using with instead of by-the friendlier industry term-but ultimately I stuck with by for consistency with existing Conventional Commit footers.

The next step was to stop guessing how much AI assisted and let AI figure out the math for me. So I created a reusable prompt for Copilot (and Verdent) to do that calculation on its own. I already had a much older prompt that was generating commit messages, so I rewrote that one for the newer models and added attribution as a requirement.

‼️ Brief aside: I’m looking for testers to see how this prompt operates outside of my workflows. It does not touch your actual commits in any way-it adds a ./commit.tmp file that you can add to .gitignore (I use *.tmp and have a whole set of local tracking files that use this extension).

So please 🙏 go steal a copy from my awesome-github-copilot and report back any problems. If you’ve never set up a prompt before, you’ll need either VS Code or Visual Studio for a global setup. JetBrains, Eclipse, and Xcode can all use prompts stored in .github/prompts/*.prompt.md. See my blog series on reusable prompts for details.

This “thirds” breakdown works great for just about everything I do, but there are times I write all the code myself and then use a quick /generate-commit-message command. Well, that needs one too-so a fourth attribution was added to the list:

• Commit-generated-by means AI summarized a conventional commit message for me (or similar trivial contribution) but none of the code was AI-modified in any meaningful way.

The catch: you only need one footer to make the point. So what happens if AI generates some portion of code and the commit message? I solved that quickly and turned the whole system into a majority-wins situation. Just pick whichever one represents the most AI. Still accurate enough to matter while not overcomplicating things. Perfect!

There is one final latecomer for completeness, which really only becomes important in a future “enforcement” stage of the game. You can’t create a rule that enforces at least one AI-attribution footer and make the absence of a footer equivalent to human-authored content. Obviously you can’t prompt AI for human content, so until I think of a better way this one is up to you:

• Authored-by is the human author to whom all code should ultimately be attributed.

💡 ProTip: Keep reading through this next part if you decide to grab the prompt. Understanding how it works is important if you want a reliable result out of it!

Under the Hood 🚗

The prompt is just a start-not a miracle worker. The biggest problem is that Copilot doesn’t retain long-term memory; it only remembers what’s inside the active IDE session. Which means you have to keep things tidy enough that it can actually follow the instructions.

My current workflow-starting the moment any story moves to “in progress”-is pretty much set. I usually start with the Atlassian MCP to grab the story info plus any linked Confluence docs, the repo needing work is open in VS Code with nothing open in the editor, and a brand-new Copilot chat session ready to go. The first prompt always looks something like this (I added the comments to make it easier to read):

# ─────────────── CONTEXT ───────────────
• Using #atlassian/atlassian-mcp-server, pull info for JIRA-123, including any linked documentation in Confluence.  
• Gather info to assess changes required in this #codebase.  

# ─────────────── TASK BREAKDOWN ───────────────
• DO NOT MAKE CHANGES YET.  
• Break this story into concise iterative pieces that include testing at every step.  

# ─────────────── OUTPUT STRUCTURE ───────────────
• Document all iterative steps required to meet all acceptance criteria as an ordered list of individual steps with an accompanying unordered checklist.  
• Each numbered step should be clear enough that any AI agent can be prompted one step at a time to complete and fully test with both integration and unit tests, whenever applicable.  

# ─────────────── SCOPE GUARDRAIL ───────────────
• DO NOT break down tasks unnecessarily—the goal is for each step to be both meaningful and fully testable.  

# ─────────────── COMPLETION CRITERIA ───────────────
• When all items are marked complete, acceptance criteria for this story should be met and all happy, sad, and edge-case paths accounted for.  

# ─────────────── ADMIN NOTES ───────────────
• Include documentation updates and any relevant deployment tasks.  
• Save this concise story breakdown in a new file named `./progress.tmp`.

🦄 Yes, I know that’s a lot. Chain-of-thought prompting like this works best with the bigger models-Claude-4, GPT-5, or even Gemini. It’s similar to the flow used by Spec-kit that’s been making rounds recently. Honestly though? I’ve been doing it this way for so long that the extra structure usually adds time without much payoff. Still, I’m testing it, and I recommend you give it a try, too!

It took me a good bit to squash the instinct to immediately jump into implementation. Before you do that, read every single line in that new implementation plan. Does it make sense? Are there any incorrect assumptions? Are there prerequisites that need attention first? Look for inconsistencies or logic gaps before handing it over. Spec-kit helps simplify that analysis step, too!

💡 ProTip: After you’ve reviewed the plan, close all open files and run /clear to start a fresh chat session. A clean slate at every step is key.

Insert Magic Here 🔮

Once I’m comfortable with the implementation plan and I’ve got a pretty good idea of which Copilot models can safely (and most cheaply) handle each step, then with a fresh chat session, each task begins with a prompt that looks something like:

Implement step N in #progress.tmp

This is exactly how I progress through 3–4 different projects at once. Each prompt may take Copilot up to 10-ish minutes to execute. So, while that’s running I’ll rotate to the next in line to review changes via a PR-style feedback prompt sent back as a single chat message (saving as many premium requests as possible). Sometimes the code is accurate the first time, but more often it takes a couple of turns to work out the kinks. All code gets staged for commit as soon as I review it. That way I know if Copilot changes anything again after the fact.

💡 ProTip: You can use the keep/undo feature if you prefer that version, but honestly I skip it. It’s just an extra click between me and toast. I keep everything and let source control be my truth.

Next up is the fun part. Copilot started with a clean session and it tracks every code change made behind the scenes already, including which one of us made that change. So the commit prompt instructs it to use that existing information to generate a commit message with the appropriate attribution footer. It all runs with a single slash command (after the initial prompt setup): /generate-commit-message.

This prompt is designed with commits in mind first and attribution second, so you end up with a valid commit message tucked neatly away in a ./commit.tmp file. Here's an example of a message it generated recently for one of my utility projects:

fix(security): Sanitize jinja templates and add `CI` security checks

- Replace raw Jinja2 Template with Environment in `utils.py` and `generate_site.py`
- Sanitize Dev.to post HTML with bleach and render sanitized content safely
- Harden slug/filename handling to prevent path traversal and unsafe writes
- Remove unused imports and perform small refactors to resolve CodeQL unused-import alerts
- Add CI security workflow (pip-audit, bandit, flake8) and developer tooling

Generated-by: GitHub Copilot <copilot@github.com>

🦄 This entire concept only becomes usable if you’re not asking for a complete overhaul in any single dev’s workflow. Well… unless they’re my devs, in which case they’re used to my shenanigans already. Besides, I really do try to make changes as painless as possible!

It’s Really Just a Start 🎬

Despite testing this prompt extensively, that doesn’t mean much unless it’s repeatable beyond my workflow. So help me out and give it a try! Let me know if you find any gaps up to this point. Do you have any other ideas for more accurate tracking or a different way to memorialize attribution that I haven’t thought of?

🦄 For the record, this is me asking you to aggressively poke holes in my theory. Point out all the fallacies that might corrupt the system. Beyond the fact that a real tool would be preferable, do you think it can work?

There’s more still built on top of this, which I’ll cover in my next post-but for devs who are still pushing commits that look like mine used to, this is a huge change in itself! My hope is that it’s enough of a simplification to at least start the conversation.

🛡️ Commits and Consequences

ChatGPT helped edit this post-tightening sentences, trimming tangents, and arguing over punctuation until we both gave up. No attributions were erased in the making of this story. 💫

Originally published at https://dev.to on October 15, 2025.

Originally written for my blog on Dev.to

🦄 I agreed to write this post weeks ago and when I said, “Yeah, sure—I was planning on it anyway!” it didn’t dawn on me immediately that the free credits I received in return technically makes this a paid post. I’m sure there’s an email somewhere that says exactly how much I received for whatever this turns out to be, but off the top of my head? I’ve got no idea. As an aside, I’ve been dodging writing the first word since I had that epiphany.

So, I let the “official-ness” sink in for a bit with varying degrees of acceptance, depending on the day. Fast-forward to now, I’m hours behind already, and it’s either I start writing or don’t do it at all. 🙄 Fine. I really had planned on writing this post anyway and I’m also very much aware the problem only exists in my version of the universe. 😒

So here’s the first (and possibly last) promotion post you will see from me. Told in a way that’s 100% true to form—starting at the very beginning. And really running longer than I intended, but the direction completely picked itself. 🤷‍♀️

The Dev Blog ✍️

This isn’t the first time I’ve said “this” (being this blog and everything else Dev or Dev-adjacent) was never intended to be more than me throwing ideas into the void and occasionally serve as my personal copy and paste specialty for “the answer you’re looking for is documented already… over there.” 👉

The unexpected side effect? I have way too much fun writing and an equal amount of amusement playing with Leonardo and the banner character, River (who refuses to cooperate most days).

The other bonus? Just like everything else I do, “this” is in one way or another wrapped up and thoroughly entangled with AI. Whether it’s playing with the images, trying to coax some sense of originality out of GPT-5 (or Gemini on the days I give up early), or letting Copilot take center stage (for now), there’s at least a few LLMs close by (and more in line to join the party as soon as space permits).

Verdent Out of the Blue: First Impressions 🌱

I’m very happy being mostly invisible on social media. Even my GitHub sat empty until this year. Everything I did was on work’s servers anyway. Why would I need to put it anywhere else? Most all code I write has one simple goal—to simplify my life and work-life definitely counts.

🦄 Work stopped trying to track all the randomness I do and just gave me a permanent unexpected-Ashley-project story with a fixed residential address in the backlog. They may take forever to finish, but there’s usually at least three different projects in that bucket at any given point 😆

So when the Verdent team first reached out at the beginning of August inviting me to preview their new AI solution, I was immediately intrigued and highly suspicious. I mean, who were these people? Where did they come from? And more importantly, how exactly did they manage to find me to begin with?

The problem was two-fold, really. First, my LinkedIn is lucky to get checked twice a week so communication was slow. I’d ask a question, later in the week I’d be grumbling to myself about the vague “agent’ answers. Second (and mostly thanks to that last part), I couldn’t for the life of me figure out what this thing was supposed to do beyond the answer I was given: it’s an agent. 🫠

At some point curiosity took over completely, and I became invested in figuring out this new sleuth AI nobody has ever heard of. I mean, I’ve tried nearly every other “agent” and I had a hard time reconciling the possibility of one existing beyond my knowledge. Besides, it all seems legit and I’m rarely one to turn down any sort of adventure anyway. Especially when AI is involved. So I answered with my usual, “Sure-why not? Sign me up.”

🦄 No. I really didn’t have a clue what I had just agreed to. To be fair though, they didn’t know who they had just signed on either!

All Or Nothing ❇️

I know I’ve said this before here, but I don’t do bits or pieces of anything. The whole concept of “dip your toes in first” simply doesn’t compute for me—at all. I’m very much an all or nothing sort of personality, and it especially shows when I know I’m driving the deadline anyway. So in this instance, my “why not?” really meant “Congrats! You get to be the sole focus of my various projects for the foreseeable future.” 🎉

I suppose it’s possible the Verdent folks had read that fact somewhere already—I don’t exactly keep any secrets. I never asked them. When they invited me to test out their “mystery AI solution” (which I’m positive every single person there has slaved over at all hours on multiple occasions in the past six months), nobody asked me for a number between 0 and 10 describing how much I enjoy breaking things (the answer is “at least twelve”).

Also, I really love beta-y things. I ran those same kinds of previews for several years before I started at THD. Nope—I didn’t think to mention that at first, either. Wouldn’t have mattered, really. If anything, knowing what sort of feedback I would have been looking for in their situation did nothing but point me straight in the opposite direction. 😇

Solving the Mystery 🕵️‍♂️

The very last week in August, I finally got an email saying the preview was officially open and surprise-there’s not just one mystery AI, there’s two of them to play with! 😁 🙌

So, what is Verdent? Well… the original answer I got is indeed accurate: it is an agent! AI solution, calls own tools, system instructions everybody depends on but nobody knows what they say-all included. It’s not just an agent, though. These guys have designed a very smart, lightweight solution that is incredibly accurate and simple to use. It’s definitely still early-stage, but it already feels like a prodigy running on its own.

For the record, I came at this preview in full-force plus chaos-mode-enabled. I wanted to break it. I have several low-impact utility repos that I was throwing stuff out of left and right just to have a safe (and backed-up-elsewhere) version of something already broken to throw at it. 🌀

“What instructions?” was the least of the problems I made in these first few test repos. The README was one of the first things I deemed completely unnecessary. And how much can it really matter if I swap the package.json out for a random pom.xml and drop in a spare requirements.txt (or two) for added sparkle? ✨

🦄 Essentially, Verdent invited me along to check out their precious newborn and I approached with all the finesse of The Martian: “I’m gonna have to science the shit out of this.” Plus a touch of Adam Savage wisdom: “Failure is always an option.”

Hope You’re Ready for This! 🫟

I most definitely threw some off-the-wall things at Verdent, both in the app Deck and its VS Code counterpart. I also graduated to real projects after a little bit-so yes, eventually I put the README’s back and gave it real instructions for some serious testing. I’ve spent the past three weeks throwing everything at it I can think of. This thing has honestly surprised me every step of the way, especially with how well it handled some of these creative scenarios.

🦄 Sure, I had to drag it out of the ditch a few times. Considering what I put the poor guy though? That break was hard-earned and well deserved!

Verdent’s Unexpected Genius: AI Extension in VS Code 💡

I absolutely expected fireworks the first time I half-prompted the Verdent extension in VS Code. It’s set up exactly like you’d expect except you’re not picking models like you’re used to. I was concerned about this model situation for about 10 seconds. Then I tested it. Solid output I don’t have to micromanage? I took the win and didn’t question it again.

It’s most definitely the usual suspects at work behind the scenes-Claude Sonnet 4 and GPT-5-you wouldn’t get this sort of quality output from anything else. I suspect there’s some younger cousins at work when they pass the height check, but that’s just simple deduction that makes sense. I’ve got no clue how it works behind the scenes and I stopped asking as soon as I trusted that it just did.

You do have some say in the level of reasoning the LLM is expected to use between minimal (ultra fast) and high (“this might take a minute”). There’s only four options, but I would have been happy with the binary version. “Fast” or “smart” are really the only defaults I need, so the extras are an added bonus I’d mostly set like you’d expect (and occasionally it was the opposite).

Yes-planning mode is built in, too. It’s basically a requirement at this point. MCP is there too, with all your friends on standby. Instructions are defined in AGENTS.md. There's sub-agents I never used extensively, but they exist and accomplish things. If you're looking for a code assistant to work alongside you in VS Code, this is one incredibly effective solution.

🦄 Yes, VS Code is great, but I code all day. Then in my spare time? I usually code some more. I review code, occasionally write about code, often talk about code. You see the trend, right? So, when I needed it, the Verdent Extension was great, but I didn’t stay here long if I didn’t have to.

Verdent Deck 🎴

This is my favorite part of the whole setup. Verdent Deck is exactly what I’ve been trying to accomplish since this whole AI concept was dropped into my lap last year. AI orchestration across both tasks and projects. A ready-to-go multi-agent swarm at your fingertips dispatched in whatever ways you want. 🦑

🦄 You know the scene in Sleeping Beauty when Merryweather points, “Blue!” and then out of nowhere “Pink!” follows Flora’s wand barreling full speed ahead? Doesn’t take long until the entire scene is an odd match of Pong a la Hogwarts via CRT. I might have unintentionally set up a brief re-enactment of this scene. It’s really only entertaining the first three-ish minutes, though. Next time I’m giving them some paintballs. 🫣

I tried prompting at the size of a story once or twice. It works about like you’d expect only twice as fast. That just seemed like a waste of time. So prompting for epics became the norm and those took less than 20 minutes. Granted, we’re not talking about enterprise epics-these are personal projects. But if it could handle those with finesse, then where’s the limit at? That hard stop where the AI throws its hands up on strike like GPT-4 and refuses to move while telling you “you’re absolutely correct” and changes are now complete (in space, possibly)?

🦄 I’d been at this weeks and I had yet to find a hard limit anywhere. After some mostly spur of the moment creative solutioning, I decided what I really needed was a bigger plan.

I quite possibly scared some people with my next idea… It had to be done though-for science! So, new plan. I decided I was done prompting with stories and smallish epics. I’d been tossing around an idea for a couple of weeks that had already been through ChatGPT once and results were iffy (at best). I prompted Verdent with my project idea and intentionally left it open to interpretation, threw in a couple of constraints for the puzzle pieces I had managed to figure out, and then iterated exactly twice to get a solid plan by priority and size.

From there, I separated the list split by each one of four separate tasks across four different agents. The prompts contained zero additional info. New repo. Instructions conveniently absent. And because why wouldn’t I at this point-all the auto-approvals are on and it’s happily committing changes, pushing to GitHub and reporting back progress.

🦄 As an aside, all of those settings are configurable in both VS Code or Deck. I simply chose to toss it the keys to the kingdom while I made popcorn and waited on standby for something interesting to happen. 🍿

There were a couple of hiccups, but that’s to be expected in any pre-release. It didn’t even register as a blip on my radar, honestly. At one point, I told one agent specifically to make sure it had the worktree cleaned up after it had merged. That caused a touch of confusion between this worktree and the collection of all worktrees. As soon as I pointed out we’re missing 4 independent worktrees that weren’t merged yet, it had the nerve to recover that work for me, too!

🦄 These agents didn’t even have the decency to blow anything up for all my trouble. Not even a decent light torching anywhere. Truly rude acknowledgement of my effort, if you ask me. Also, seriously impressive and if anything had actually been wrong at the time, I would have been ecstatic with those results!

Best AI Response from Verdent 🏆

I’ve been collecting truly spectacular responses from random LLMs pretty much as soon as I started using AI. Some of them are truly genius leaps of logic in ways I didn’t expect to work. Others are simple ways it just worked the first time. My favorite though is the off-the-wall-unexpected-comments category.

ChatGPT returned one a few weeks ago in the form of a new color palette after I had spent several turns threatening to fire it (again) for hideous output that seemed to opt out of instructions completely. The next day I noticed it was extremely clinical in its responses giving me precisely what I had asked for-no more and no less. 🙄 “You’re allowed a personality again as long as you can also provide accurate output”. It literally responded with a gift in the form of a new color palette I had started collecting several chats ago. 🎁

ChatGPT can be cute at times, but Verdent was just real and downright hilarious! I’m still laughing at it more than a week later. More than six months ago I set out to build a Copilot Extension but there’s a very specific thing I need it to do in order to pass the approvals it needs to be able to use it at work. That was the only use case I needed it for. If it couldn’t do that, then it was useless.

Last Story (Today)-Promise 🤝

I don’t know if you’ve ever seen GitHub’s documentation for their Copilot Extension. I memorized it: “the copilot API is modeled after the OpenAI /completions endpoint with a GitHub base URL". They were even nice enough to throw in a link to the OpenAI specs for that single endpoint. Seriously, GitHub. What exactly do you expect me to accomplish with this?

That’s all the info they’re going to give us, too. I’ve looked extensively. I was thrilled when the Copilot Chat was freely accessible for spelunking. It was also a huge let down in that it only works because they get special privileges Microsoft isn’t handing out to anyone else any time soon.

So one weekend I decided I was going to figure this chat thing out, even if I had to guess a million and one different possibilities to get something to stick. Fast-forward roughly ten hours and I’m now losing patience at an exponential rate of speed and seriously questioning the life choices that put me and Verdent together in this odd death spiral of Copilot Chat context in the first place.

I just needed something to work. Anything! After debugging that many hours, who cares if it even makes sense? I don’t need sense, I need context! Just send me back the thing I sent to you in literally any format that I might could recognize again. I would have happily coded an allowance for smoke signals at that point, but there’s just nothing. I’m literally watching the solution I need for the whole POC. It’s right there in front of me and 100% inaccessible through GitHub. 😡

🦄 I seriously considered defeat at that point. It just wasn’t possible with the resources I could use while also meeting the minimum security constraints that would make it a viable POC. And I’ve been through all of these same hoops many times before. There’s no give in the system, not when it comes to this.

I’ll save you the dramatics I toyed with over the next hour or so while I took a much needed break to think up any other possible thing I hadn’t already thought to try in the last six months. Even the cobwebs had had a turn by then, so the future was very bleak for my POC. Then I had what I choose to label an epiphany (because insane was absolutely acceptable at this particular moment in time)-what if I didn’t need to manage context at all?

Don’t worry. I acknowledged the terrible idea for what it was, and briefly considered the implications of trying to elicit a successful response from an LLM based on untouchable, un-monitor-able history alone. Ultimately, I accepted that given the current outlook, quality was imaginary anyway. Structured output had been a bad joke for hours already. But I was not letting Copilot win another round—I just needed one single anything to persist over the turn. Successfully. Just once. 🙏

So I prompted Verdent to set up yet another complicated test script, but I silently accepted the fact that this was the last one. There were literally no more rocks to look under after this, short of talking Microsoft into letting me have the same level of access to Copilot that VS Code has currently. I wasn’t likely to see success in either outcome. But Verdent set it up and I did the the copy-paste thing, held my breath and waited impatiently:

🦄 Finally-Victory! Not even a tiny bit viable as a real solution, but I was thrilled! And with exactly four words Verdent overtakes all the other AI things and wins spotlight for the foreseeable future. 🤣🤣🤣

Verdent Officialness 📹

I’m not saying Verdent is the answer to every AI problem, but there’s a few of them it handles spectacularly well. You can catch up on the specifics I left out in this video.

Also, you don’t have to take my word for it. Check out Stephan Miller’s version of how things went for him during the preview.

🛡️ How the Circuits Were Made ⚡️

Yes, AI helped, but the chaos is mine. Verdent took the punches, I wrote the words, and ChatGPT glued everything together. Resulting in a genuine recollection of stress-testing just how far a “preview” can bend before it squeaks.

Originally published at https://dev.to on September 24, 2025.

🦄 I’ve had a little time to cool off since my last post, and honestly? Keeping these thoughts off Medium doesn’t help anyone. The example of what good, responsibly AI-edited work looks like needs to be out there — so here it is, and there’s more on the way.

This post was written by me and edited (responsibly!) with the help of ChatGPT.

Background (because the story matters) ✍️

Here’s what gets me: people still treat all AI content the same -whether it’s auto-generated fluff or a post like this, with actual thought, stubbornness, and a few creative detours baked in. I use AI as a tool, but I’m the one steering; it’s got my fingerprints and my voice all over it because I wrote intentional AI instructions.

🙄 At least, unless GPT-5 has decided to rewrite the rules again. Then it takes a bit of wrangling first.

The sad part? Both the creative writing and the fluff get the same knee-jerk reaction. I’m not worried about myself-I know how to handle criticism and don’t mind being upfront. But not everyone’s ready to jump into the ring, and a lot of good AI assisted work gets buried because creators just don’t want to deal with the drama that comes with disclosure.

Hang out in the writers+AI corners of the internet for five minutes and you’ll hear: “Just don’t disclose-why invite the hassle?” That’s not me. I’d rather own it, even if it means the occasional argument.

🥊 Integrity first, sparring match second-and my matches usually come with a grin and a little happy dance.

So let’s walk through what we actually know about AI, what we’re still sorting out, and how we might just learn to disagree without burning the place down before it’s sorted. 🔥👩‍🚒

1. Who’s Really at the Table? 🗝️

Platforms, publishers, workplaces, classrooms, and every Discord mod with a badge gets to set their own boundaries. But the thing that always gets me isn’t if they do it, it’s how. When ‘boundaries’ become a one-size-fits-all firewall, that’s where I have a problem.

For example: KoFi’s Discord rules are direct-

“All forms of AI-generated content (eg. art/music/writing/ChatGPT), including links to such content, and discussion thereof is not allowed in this server.”

So, of course, I checked. “Does that mean my stuff is banned?” Turns out, nope. As long as I skip the preview images, we’re golden. Honest, straightforward, no drama. Awesome.

Medium, though? (If you missed the post, catch up here.) They talked about gray areas… then built a giant penalty box for every AI-assisted creator, regardless of intent or craft.

🎵 For me, that’s about as thoughtful as banning all musicians because someone played Wonderwall one too many times at open mic night.

I can’t rewrite the rulebook, but I can refuse to act like these blanket rules don’t erase good, thoughtful people. Those of us who are trying to follow guidelines that don’t really exist-and perhaps set a few new ones in the process-don’t deserve to have our work lumped together with the slop.

2. AI Content ≠ Equal 🥚

There’s AI content, and then there’s AI content. Some of it is shallow, spammy filler that’s cranked out for clicks with zero thought or care. The rest of us? It’s a tool wielded well: organized, rewritten, and given a real voice.

Bad actors weren’t invented along with AI; the existing ones just found a different shortcut.

There are tools out there- ZeroGPT and friends-that claim they’ll catch every AI post. But here’s the thing: I’ve actually tested this. I picked three or four posts at random, ran them through different detectors, and my highest score was 18%.

🦄 It’s not because I’m hiding anything or using some secret hack. It’s the process.

I dictate most posts on the fly. Then I hand it off to the AI-to organize, to reword, sometimes to rewrite completely-but always under my set of rules. And it never, ever ends as a copy-paste job. I’m editing the whole time. There’s always a human- me -in the loop, every single time.

3. Will AI Improve Productivity? 🏃‍♀️

Sometimes. Sometimes Not.

There’s always a promise: AI will make you ten times faster, smarter, better, insert-your-buzzword-here. And maybe it’s true… sometimes. Documentation? Absolutely. I can roll out a draft in seconds-clean, organized, done. Drafting proposals? Don’t even get me started; I’m pretty sure the principals are getting sick of how fast I can toss together a pitch.

😇 If they aren’t yet, give it time because I have more.

But sometimes AI just saves you from the jobs nobody wants. Like, digging through a decade’s worth of legacy code for a spike because it’s finally time to rebuild that app and nobody remembers what it’s actually doing or why it was even there to begin with.

🫤 I know I don’t want to do that. You don’t want to do that. Nobody wants to do that. AI doesn’t care and is pretty good at it!

Honestly, sometimes it sees connections I might miss. But that doesn’t mean you can skip the whole process and trust whatever it finds. You still have to check. Maybe it saves you three days in the depths of the code mines, but the human review isn’t optional.

Still, not every job should go to the bots, either. That gnarly production bug, that support ticket, the customer call-they all need a human. AI can be a superpower, but it’s not meant to replace the parts of your work that need actual judgment, empathy, or the magic of figuring it out together.

4. AI Is Not Bad (When You Use It Like a Pro) 👨‍🚀

AI isn’t some villain lurking in your workflow. It’s a force multiplier. Used right, it makes your voice sharper and your edits faster-used wrong, it just adds to the noise.

That’s why every single commit I make defines exactly how much AI was involved and my posts are going to start wearing an “AI-Edited” badge. Not because someone told me to. Not as a disclaimer. Because somebody has to be willing to say there’s a difference between generated and assisted.

This is one version (and yes-Leonardo made them):

🦄 And if you want to use the badge yourself, or hand it off to a friend? Don’t copy this little screenshot-the full one (plus a couple others) are hanging out in my repo. Help yourself!

5. AI Code Is AI Content (Writers, You Too!) 💾

Here’s my rule: disclosure, plain and simple:

Docs and posts:

• Add a simple footer like “This was generated with the help of AI tool.”

Code or technical writing: Commit with one of 3 different footers in the commit message:

• Generated-with: AI tool means AI did most or all of the work
• Co-authored-by: AI tool means the content is 50/50
• Assisted-with: AI tool means AI helped some, but not close to half

💡 I started out using an email address in the commits, too — that I thought I was making up-until some random app popped up as a contributor in my repo. Not cool… 😒

This isn’t about checking boxes. It’s about giving credit, setting an example, and actually being transparent with yourself and the future people who end up needing it.

😈 Besides, putting one more stamp on a long list of responsible AI use-cases puts a dent in the endless cycle of AI panic and the-world-is-ending doom speak.

6. And What About AI Images or Music? 🎨

Same rules, different paint. Some artists pour weeks or months into training models on their own art. (I still haven’t managed to train mine and it’s been over a month!) Others take the shortcut: punch in a sentence or two, let the AI “enhance” it, and call it done.

❓ Are they copying someone’s style? I dunno- maybe? Should they? I honestly don’t know…

Same applies here as does with writing: artists absolutely have the right to protect their work. But what does that look like, practically? Truth is we don’t really know yet. The laws are behind while the tech is still racing ahead. We’ll catch up. Maybe not soon enough, but eventually, we will.

🦄 I just hope that when we get there, there’s at least one person in the room who actually understands what’s happening-and what it looks like behind the scenes. We absolutely need better laws, but we do not need people throwing broad rules at some conjured image of “AI training.” Whatever it ends up being, honesty and fact need to come first.

7. Is AI “Stealing”? (No, but…) 🧬

This is where I dig in my heels. No, using AI-generated content is not stealing- unless you’re actively pretending someone else’s work is your own or ignoring copyright on purpose. However, “publicly available” isn’t the same as “public domain,” and nobody should lose credit for their work.

Should AI companies pay for certain data? Probably! Should writers and artists get a say? Of course. But “all AI is theft” is just as over-simplified as “all creators are saints.”

🫡 Guess what? Real life and the world around us is messy-AI included. We need smarter laws, better tools, and way less finger-pointing.

UPDATED:

Introducing pay per crawl: Enabling content owners to charge AI crawlers for access

This is brilliant! HTTP 402 may come back from the forgotten realms of the internet. I’ve seen other sites like Credtent.org offer similar setups, as well. Sounds like a solution I can live with… what about you?

8. I Can’t Stay Quiet (and Neither Should You) 🛠️

I can’t just sit back and watch the insanity and not throw my two cents in. We’re all still figuring this thing out. Some jumped in headfirst, others are barely dipping a toe. But we won’t get anywhere by shutting down the conversation or tuning each other out- if there’s a better way, we’re gonna have to find it together.

So, did I miss anything? Add your take below-what’s a rule, reality, or tip about AI you wish more people got right? Comment, DM, or write your own story. I’ll keep this list updated.

🙏 And please, when it comes up again, don’t leave yourself (or anyone else) out of the conversation. 🫶

🛡️ This post was AI-edited, human-approved, and finished before the next AI ban drops.

Nuance is mandatory, drama is optional, and the sarcasm is included free of charge.

This Post’s ZeroGPT Score 🥳

More out of curiosity than anything else…

Originally published at https://dev.to on September 7, 2025.

ChatGPT helped me write this post. No, it wasn’t easy. I didn’t prompt for answers — I used a tool, and I used it well. But innovation has no home here at Medium. So get out your typewriters — make sure you’re keeping up with the times.

UPDATED

I posted this reply to Medium’s original post after discussing it this past week on my separate Dev Blog — Medium and the Blanket AI Ban.

I’ve been working through my thoughts on this on my Dev post: https://dev.to/anchildress1/medium-and-the-blanket-ai-ban-2cni — but I think I’ve finally landed on the perfect solution.

👉 Don’t exclude everybody by default. AI ≠ “bad”. It can be misused, sure, but stereotyping an entire group of writers because of a few bad actors isn’t okay.

Here’s what I propose:
- Create an AI pre-approval system.
- If a writer wants their AI-assisted work to be eligible for your programs, let them apply.
- Get your human reviewers involved — tear the post apart, see if it’s worthy.
- If it passes, give them a badge 🏷️ that automatically shows up on their page.

Now, two good things happen:
1. Writers aren’t forced to keep disclaiming “AI-generated” every post — the badge already says it.
2. Once approved, their work is treated like everyone else’s. No blanket exclusion, just fair review.

Yes, it’s a little more work on your end. But it’s a whole lot easier to swallow — and way more fair — for the rest of us.

Yesterday, I decided I was going to forward some of my posts here to Medium. I even restarted the subscription I’d recently canceled. I’ve since changed my mind.

Usually, I start my posts by describing my thought process — why I’m here, what I almost wrote instead, that scenic detour that got us all gathered together in the first place. But Medium requires me to disclose AI-generated content within the first two paragraphs. So, there it is. Flow destroyed before I even had a chance. ✅

Now, in response to the post titled We want your feedback: How can writers use AI to tell human stories? where you claim to want feedback.

I’m glad you’re asking the question. But honestly? You’re not even in the same ballpark as “innovation” or “protecting writers”. Here’s why.

Citing Medium’s Own Words

Medium’s own AI Content Policy says:

We define AI-generated writing as writing where the majority of the content has been created by an AI writing program with little or no edits, improvements, fact-checking, or changes, but does not include writing tools like outlining, fact-spelling, or grammar checks.

By that definition, I thought maybe — maybe — I’d squeak by as “AI-assisted.” Fifty-fifty shot, right?

Then you published this different version in your article:

To empower more people to share their stories, we treat AI-assisted writing differently from AI-generated writing. … But the spectrum veers into gray as AI contributes outlines, research, or partial sections.

Well, guess what?

ChatGPT helps me with outlines — 100% of the time. Sometimes it restructures my entire post, renames section headers, updates references, all without my initial input.

Sometimes it researches on my behalf (rarely, but it happens — usually when I’m out of hours and still have work to finish).

And yes, I prompt ChatGPT to write partial sections for me, consistently.

Which means that under your own distribution guidelines, my writing is defaulted to limited distribution, not eligible for Boost, and never has a chance at the Partner Program. Readers must literally opt in ahead of time to even see my work.

Why? All because of these one liners on the content guidelines page:

Low-value content

Stories that offer the reader little of value, including:

- AI-generated content

So while, yes, I understand that this may not be exactly what you had in mind. The fact of the matter is this blanket “AI is bad” statement promoting the misconception you can't be a writer and use AI — has no place in the modern world. The same world that both I and millions of other responsible writers are busy trying to create. It honestly sounds more like you're asking for validation than for permission to move forward into the 21st-century.

So let’s break it down: if you haven’t read my DevTO blog How I Blog with Bots (But You Can Still Blame Me), then pause here and read that first. Don’t worry—I’ll wait for you to finish.

In that post I explain exactly how my process works. Maybe then you’ll understand why I’m as angry as I am right now.

On Your “Evolving Position”

You say your position on AI has changed. I see an attempt. But it’s nowhere near enough.

You require “real stories. Human stories. Written from human experience and with human wisdom.” I don’t disagree with that. But you’re assuming it’s impossible to achieve all of that while also using AI. I guarantee I can prove you wrong.

What the Work Really Looks Like

Here’s my reality: I probably spend longer than some of your “approved” writers just preparing a post. I think through bias, audience, accessibility, whether it’s already been covered and how, and what makes it SEO-friendly and what are the trade-offs for doing so?

Then I generate visuals. No, it’s not “type a prompt, hit enter, boom an image.” I’ve spent weeks fine-tuning a character model, burning through thousands of tokens, testing different styles — all to keep a consistent look for my blogs.

Is it AI-generated? Yes. Does that mean I didn’t work for it? Absolutely not. In fact, it often means I worked harder.

Collaboration, not cheating.

AI generates whole sections of my posts on the regular sometimes. The “RAI footers” at the bottom of my posts are a perfect example. I could paste the same boring line every week. Instead, I let AI remix it into something fresh, while still being mine.

It’s not easy. I fight with it. I throw away drafts. I edit heavily when it changes too much. What survives is 100% my thought, my words.

Meanwhile, it helps me strip bias, smooth tone, keep me from leaking work secrets. It teaches me marketing, SEO, accessibility. That’s not laziness — that’s craft.

The Boost Problem

Here’s the kicker: by default, I’m not even eligible for Boost. Can I be featured? Who knows.

The only reason my AI-generated images aren’t an issue is because you admitted you don’t really focus on them.

So on one hand, you advocate for compensation from AI companies. On the other, you penalize actual AI users. Limit my distribution. Filter me out. Leave me with no chance at joining the Partner Program.

Readers can choose what to read. But you’ve already told me, again and again, that my posts will never be “good enough” for your platform.

The Unfair Blanket Rule

When you write off everyone who uses AI, you’re not protecting writers from Big Bad AI Companies — you’re punishing all of us for the sins of a few. The companies aren’t held accountable, but people like me, who do put in extra work and creativity, are boxed out by default.

Yes, some people game the system for clickbait. I don’t like it either. But do you protect against them by simply excluding all of us? Or do you innovate and find a way to recognize when AI is being used responsibly, transparently, and creatively?

From where I’m sitting, I’m lumped in with Joe Schmo cheating his way through freshman English — and his shortcuts are why my opportunity to grow, and to earn income to support my family, gets cut off completely.

Where’s the justice in that?

My Challenge to You, Medium

I’ll be watching to see if Medium evolves into a place that protects creativity instead of suffocating it. Because I’ve worked very, very hard for mine.

While I’m at it, I’ll challenge you: go read my posts on DevTO. Pick one. Seriously.

Tell me which piece you think doesn’t deserve a shot at Boost, or the Partner Program. Probably my post about a name change isn’t worthy, you’re right— I’ll give you that. Maybe one of the very first ones when I was still finding my rhythm. Sure. How about anything in the past 5–6 weeks then?

Show me exactly why AI used responsibly to promote ones self is not just not-encouraged but actively discouraged and comes with penalties. But the rest? They’re good. And they’re getting better, consistently, because of AI.

🛡️ Written by me, fact-checked (and side-eyed) by AI

This post is mine, but the robots made sure it was readable, SFW, and way less ranty than the first draft.