DEV Community: Clemente Nogueira

GitHub Copilot AI Credits Billing Explained: What's Free, What's Metered, and My Hybrid Claude Code Workflow

Clemente Nogueira — Tue, 16 Jun 2026 10:43:23 +0000

TL;DR

On June 1, 2026, GitHub Copilot switched from flat-rate pricing to a token-based "AI Credits" system, and the community forum responded with over 900 downvotes. Most of the outrage is aimed at the wrong target. Code completions are still unlimited on every plan. What actually changed is chat, agent mode, and PR review — and the real complaint isn't the price, it's the unpredictability. This article breaks down the actual numbers, what's still free, where the AI coding tools market stands in June 2026, and the hybrid Copilot + Claude Code workflow — anchored by a single AGENTS.md file — that I switched to as a result.

The problem

GitHub officially moved Copilot from a flat subscription to usage-based AI Credits on June 1. The community forum thread reacting to it crossed 900 downvotes within days. That's a strong signal, but it's worth pausing before reacting to forum sentiment alone, because a chunk of that anger is based on an incomplete picture of what actually changed.

What actually changed

The new model is straightforward on paper: one AI Credit equals one US cent, and each plan's base allowance is set above the subscription price rather than equal to it. The $10 Copilot Pro plan now comes with 1,500 AI Credits per month — worth $15 at that rate. I'm on the Pro+ tier myself, at $39/month for 7,000 credits, worth $70. On paper that's generous. In practice, it's exactly where the burn rate becomes a real concern, because the headline number looks like more room than agentic workflows actually use.

There's a second change worth flagging alongside the billing shift: GitHub deprecated GPT-4.1 across every Copilot surface on June 1 — chat, inline edits, ask mode, agent mode, and code completions. If you had a specific reason to be on that model, it's gone.

Here's the part that actually matters, though. The core complaint isn't the price — most developers won't blow through their credits under normal day-to-day use. The complaint is unpredictability. A flat rate means you know your spend before the month starts. A credit system means your spend depends on what you do, which model handles it, and how long your prompts run. Run out mid-sprint, and you're blocked until the cycle resets. That shift from certainty to metered uncertainty is the legitimate part of the frustration, and it's worth taking seriously even if the framing on the forum skews toward outrage over analysis.

What's still free vs. what burns credits

This is the detail most of the discourse is skipping past, and it changes how you should actually respond to the change.

Inline completions — ghost text, Next Edit Suggestions — are still unlimited across every paid Copilot plan. These were the original features that made Copilot what it is, and they don't touch your credit balance at all.

Three things do burn credits: chat (asking Copilot questions in the sidebar), agentic workflows (multi-step tasks run through agent mode), and code review (having Copilot review your pull requests).

So the useful question isn't "is this bad?" — it's "where do I actually spend my AI time?" If your workflow leans on ghost text with the occasional chat question, this change probably barely touches you. If you've built your workflow around agent mode for long-running, multi-step tasks — which is exactly what I had done — you'll feel it. In my case, I'd already built a library of reusable agent prompts, and under the new pricing I can no longer run them in a way that's financially sustainable.

Where the AI coding tools market stands in June 2026

The Copilot billing change doesn't exist in isolation — the whole AI coding tools landscape has shifted noticeably over the past six months.

According to JetBrains' AI Pulse survey of over 10,000 professional developers, Claude Code now holds the highest product loyalty metrics in the category: a 91% CSAT score and an NPS of 54 (NPS runs from -100 to +100, so 54 is exceptional for any developer tool). On actual workplace adoption, Claude Code and Cursor are now tied at 18% each, up from roughly 3% for Claude Code in mid-2025 — a 6x jump in six months. Copilot is still the most widely adopted tool overall at 29%, but that growth has stalled; both awareness and adoption have flattened.

Cursor has crossed $2B in annualized revenue and introduced parallel agents, letting you run up to eight agents simultaneously across different parts of your codebase through a visual dashboard. Windsurf rebranded entirely to Devin Desktop on June 2, with Cognition retiring the Windsurf brand and replacing the original local agent (Cascade) with a Rust-rewritten Devin Local.

The open-source side had its own shake-up this spring. Roo Code — one of the most-loved open-source coding agents — shut down completely on May 15 and had its GitHub repo archived, with its team pointing users toward Cline and a fork called Kilo Code. A third project, OpenCode, quietly became the most-starred open-source coding agent on GitHub, north of 160,000 stars, running entirely in the terminal. Amazon also threw a free agentic IDE into the mix with Kiro.

The number that reframes the whole conversation: developers today use an average of 2.3 AI tools simultaneously. Not one tool winning everything — a combination. Which means the real question was never "which tool is best?" It's "what is each tool best at, and how do I combine them?"

My hybrid workflow: AGENTS.md + Claude Code + Copilot

Here's the setup I landed on. At the center of it is a single file called AGENTS.md, committed to the repo root, that holds the project's architecture, stack, conventions, and hard constraints — the open standard that Copilot and most other AI coding tools read directly:

# AGENTS.md

## Project
Next.js 16 app, TypeScript, Tailwind, deployed on Vercel.

## Commands
- Dev: pnpm dev
- Test: pnpm test
- Lint: pnpm lint && pnpm tsc --noEmit

## Conventions
- Named exports only, no default exports in components
- Server components are the default

## Hard constraints
- Never commit .env or .env.local

One nuance worth being precise about: Claude Code doesn't read AGENTS.md directly — it only reads CLAUDE.md. The way AGENTS.md reaches Claude Code is a one-line import inside CLAUDE.md:

See @AGENTS.md for all project rules, commands, and conventions.

Add that line once, and Claude Code loads AGENTS.md automatically at the start of every session from then on — you still never restate the rules, you just need that single bridge line in place first. That eliminates the biggest hidden productivity tax in AI-assisted work: repeating context.

The split that's worked for me: Claude Code handles the long-form, multi-step agentic work — refactors that span several files, writing a test suite, debugging something that needs a lot of context held at once. GitHub Copilot handles keystroke-level completions — ghost text, inline suggestions, boilerplate — which are still unlimited and still genuinely excellent at that specific job. The result is that my Copilot credit usage barely moves, because I've stopped routing heavy agentic work through it, and the agentic work goes to a tool that was already better suited to it.

The mistake most developers make

The instinct after a pricing change like this is to pick a side — stay on Copilot and absorb the credits, or drop it entirely for Claude Code. Both are probably the wrong move. The 2.3-tools-average stat isn't an accident; it reflects how developers who are actually productive with AI tools work in practice — one tool for fast inline work, one for deep reasoning, increasingly tied together by a shared protocol like MCP.

If anything, the billing change is a useful forcing function. It pushes you to get intentional about where your AI usage actually goes, instead of defaulting into whatever setup you happened to start with.

Key takeaways

GitHub Copilot moved to AI Credits on June 1: Pro ($10/mo) includes 1,500 credits, Pro+ ($39/mo) includes 7,000 — 1 credit = $0.01. GPT-4.1 was deprecated across all Copilot surfaces the same day.
Code completions (ghost text, Next Edit Suggestions) are still unlimited on every plan. Chat, agent mode, and code review are metered.
The real frustration is unpredictability, not price — a fair complaint, especially for anyone leaning on agent mode for heavy multi-step work.
Claude Code now leads the category on loyalty (91% CSAT, NPS 54) and has closed the adoption gap with Cursor; Copilot's growth has stalled at 29%.
Developers use an average of 2.3 AI tools — the goal isn't picking a winner, it's building a deliberate hybrid setup.
A single AGENTS.md file at the repo root keeps Claude Code and Copilot briefed on the same project context without duplicating it.

Part 2 covers two completely free, open-source AI coding agents that drop into VS Code right where Copilot Chat sits — running a real task for $0.00. Linked from the YouTube video once it's live.

ai #github #productivity #programming #copilot #copilotcredits

📺 Full video: Watch on YouTube

93,000 People Downloaded My Side Project — 3 Lessons About Shipping Software That Lasts

Clemente Nogueira — Thu, 04 Jun 2026 17:17:25 +0000

TL;DR

In December 2022 I shipped a Witcher 3 mod as a side project. No marketing budget. No launch strategy. Three years later it has 93,614 unique downloads, 479,000 total views on Nexus Mods, 11 community translations, and is still running at version 4.4.1.

In this article I break down the three things that made it survive — and what every developer building side projects right now should do differently from day one.

▶️ Prefer video? Watch the full story on YouTube →

The project

If you've played The Witcher 3, you know the looting loop. You fight a monster. You walk to its body. You open the loot menu. You scroll through fifteen items. You pick what to take. You close the menu. You walk to the next monster and repeat — for forty hours.

It's one of the most tedious mechanics in an otherwise extraordinary game. Several AutoLoot mods existed when I started, but none of them had survived the Next-Gen Update that CD Projekt Red shipped in 2022. I took the best existing implementation, rewrote the core for Next-Gen compatibility, and rebuilt the entire configuration system so players could change everything from inside the game menu — no config files, no command line, nothing technical.

The first version went live on December 15, 2022.

Endorsements:      3,531
Unique Downloads:  93,614
Total Downloads:   176,949
Total Views:       479,192
Community Posts:   1,546
Translations:      11 languages
Current Version:   4.4.1
Last Updated:      August 2024

Here's what made it last.

Lesson 1 — Solve the thing people are already searching for

The mod worked because it solved a pain that already existed and was already measurable. Every Witcher 3 player hit the same tedious loop. The problem needed no explanation. The value needed no selling. I just had to show the thing working.

Compare this to how most side projects start. We have an idea, we build something, and then we try to convince people they have a problem they weren't aware of. That's an extremely hard position to be in.

The mod had the opposite dynamic. People were already typing "witcher 3 autoloot mod" into a search bar. They already knew what they wanted. The project just had to be findable and better than what existed.

Those 479,000 total views came entirely from search — not from any promotion on my part. No social media campaign. No launch post. Just a real solution to a real pain point, discoverable at the exact moment someone needed it.

The question for your side project isn't "is this a cool idea?"
The question is: are people already frustrated enough to search for this?

If yes — you're in a much stronger position than you think.

Lesson 2 — Design for the community to own it

This one took me longer to understand. And it's the direct reason the mod is still alive in 2024 when I'm no longer the one maintaining it day-to-day.

Those 11 translations? People I have never spoken to, from countries I've never visited, translated the entire mod into their native language because they wanted their community to use it. I didn't ask them. I didn't hire them. The project was structured in a way that made contributing easy and meaningful.

Three things made that possible:

1. Public credit, always

Every contributor is listed by name on the mod page. This sounds small. It isn't. Public credit is the currency of open source communities. When people see their name associated with a project that tens of thousands use, they come back. They tell others. They defend the project when someone asks if it's still maintained.

2. A low contribution barrier

Translation files lived in a clearly named folder with a dead-simple structure. You didn't need to understand WitcherScript or the codebase to contribute a translation. The surface area for contribution was as small as I could make it.

3. An honest, visible changelog

Every update listed exactly what changed and why — not marketing language, actual technical notes:

v4.3.0 — Fixed exception when looting beehives with active bees
v4.2.1 — Added 3-second delay for Action Log notification after combat
v4.1.0 — Restored compatibility after TW3 patch 4.04

Specific. Real. Verifiable.

When your users can see that bugs get fixed and edge cases get handled, they trust the project. And when they trust it, they defend it in forums, recommend it to friends, and contribute back to it. Most of those 1,546 community posts aren't support tickets I had to answer — they're users helping other users.

That's the compound effect of designing for ownership. The community becomes your support layer.

Lesson 3 — Version like you mean it

The mod is on version 4.4.1. Not 1.0.1. Not a pile of undated commits. Four major evolution cycles, each minor number a documented change.

Semantic versioning — major.minor.patch — isn't just a convention for enterprise software. It's a communication contract with your users. When someone lands on your project page and sees v4.4.1, they know:

This project has history
It's been iterated on and tested
The author takes it seriously enough to track changes
There's a reasonable chance it still works

That signal builds trust before a single line of the README gets read.

But there's something deeper than version numbers here. It's about the cadence of care.

The last update was August 2024 — nearly two years after the first release. Each update wasn't arbitrary. It responded to something real: a CD Projekt Red patch breaking compatibility, a community-reported edge case, a configuration option users kept asking for. Updates were responses, not noise.

Most side projects die because the author loses interest and stops responding. Users feel it immediately. Forum posts go unanswered. Compatibility breaks stack up. Downloads drop. Eventually the project gets archived.

The antidote isn't endless motivation. It's a low, sustainable update cadence that signals to users that the project is alive. Even a single real patch every few months — documented, communicated — keeps the trust intact.

What I'd do differently today with AI

The biggest time cost in maintaining this mod wasn't writing the code. It was re-learning the codebase every time I returned to it after weeks away.

Witcher 3 uses WitcherScript — a custom language with its own quirks, patterns, and edge cases. Every time I came back to fix something, I spent significant time just re-orienting myself. What does this function do? Why was this architectural decision made? What are the things I must not touch?

This is exactly the problem I now solve at the root of every project with a CLAUDE.md briefing file — a persistent context document that tells my AI assistant everything it needs to know about the project before we start working:

# Project: AutoLoot All-in-One NG Update
## What this is
A Witcher 3 mod that automatically loots items during gameplay.
Uses WitcherScript (`.ws` files), compiled by the W3 Script Compiler.

## Architecture
- `/mods/AutoLoot/content/scripts/` — core loot logic
- `/mods/AutoLoot/content/scripts/ui/` — in-game config menu
- `lootConfig.ws` — DO NOT REFACTOR, breaks menu bindings

## Known gotchas
- Beehive loot triggers a unique exception — see `beehive_handler.ws`
- Always test after any CD Projekt patch — hooks change frequently
- Translation files in `/translations/` — one folder per language code

## What not to touch
- Menu binding IDs — hardcoded in game engine, not in our scripts

If I had this system in 2022, every return to the codebase would have taken minutes instead of hours. The AI would have been briefed. The context persistent. The cognitive overhead of maintenance — which is the real reason most side projects die — dramatically lower.

I cover the full setup of this system in my Obsidian + VS Code AI Second Brain video.

The three things that make software last

To bring it back together:

1. Solve a pain people are already searching for — let them find you, don't chase them.

2. Design for community ownership — credit publicly, lower the contribution barrier, keep the changelog honest.

3. Version with discipline — treat version numbers as a trust signal, not a formality. Sustainable cadence beats bursts of motivation.

None of these are unique to game modding. They apply to open source libraries, dev utilities, browser extensions, SaaS tools — anything you ship and want people to still be using three years from now.

If you're building something right now — even something small — treat it like it's going to be around in three years. Because if you do it right, it will be.

📺 Full video: I Shipped a Mod 93K People Downloaded — Here's What I Learned →

🎮 The mod: AutoLoot All-in-One NG Update on Nexus Mods →

🔔 3Gear channel — AI dev workflows + Next.js tutorials: youtube.com/@3Gear

💬 Building a side project right now? Drop what it is in the comments — I read all of them.

Obsidian + VS Code Copilot: Build an AI Second Brain Per Project (Full Setup Guide)

Clemente Nogueira — Wed, 03 Jun 2026 20:02:11 +0000

TL;DR

Stop losing context every time you come back to a project. This guide shows you how to set up a per-project Obsidian vault — committed alongside your code in Git — so GitHub Copilot always knows exactly what your project is, what decisions have been made, and what it should never touch.

▶️ Prefer video? Watch the full tutorial on YouTube →

The Problem

I built this after wasting too much time watching AI agents lose context at the worst possible moments. This is my approach — a work in progress, and every developer will adapt it to their own style, but it should give you a solid starting point.

Most developers work like this: Notion open in one tab, the repo in another, and the AI has no clue what either of them contains.

You come back to a project after two weeks, and the first 20 minutes are wasted re-explaining the context — to yourself, and to Copilot. You type "look at my codebase and tell me what this does" and get a generic response because the AI has no history, no decisions, no current state.

One giant vault for everything makes it worse. You're searching through 500 notes to find the one that belongs to this client or this project. The context is diluted.

There's a better way: one vault, per project, committed to the same Git repo as the code.

The Architecture

Here's the structure you're going to build:

my-project/
├── src/                    ← your code
├── .obsidian-vault/        ← your project brain
│   ├── .obsidian/          ← Obsidian settings (auto-created)
│   ├── decisions/          ← Architecture Decision Records
│   ├── specs/              ← Feature specs and API contracts
│   ├── bugs/               ← Issue investigations
│   ├── daily/              ← Quick standup notes
│   ├── retro/              ← Milestone reflections
│   ├── templates/          ← ADR, spec, bug templates
│   ├── 00-inbox.md         ← Capture zone
│   ├── Dashboard.md        ← Your project home screen
│   └── CLAUDE.md           ← AI briefing file ← the most important file
├── .gitignore
└── project.code-workspace

Everything lives in one directory. Obsidian reads the vault. VS Code reads the code. Copilot reads both. Git versions all of it together.

Step 1 — Create the Folder Structure

Open your terminal and run:

mkdir my-project && cd my-project
mkdir .obsidian-vault && cd .obsidian-vault
mkdir -p decisions specs bugs daily retro templates
touch 00-inbox.md CLAUDE.md Dashboard.md
cd ..

The dot prefix on .obsidian-vault keeps it visually separate from your source folders. It's still committed to Git — we just want it to sit apart from /src.

Step 2 — Write the CLAUDE.md Briefing File

This is the most important file in the entire system.

CLAUDE.md is a plain-text briefing document. Every time Copilot (or Claude, or any AI agent) opens this project, it reads this file first. Write it like you're briefing a new developer joining the team.

Here's the structure:

# Project Name

## What this is
[One or two plain sentences. No jargon.]

## Tech stack
- Language: TypeScript
- Framework: Next.js 16
- Deployment: Vercel
- Database: Supabase (Postgres)

## Current state
[What's working. What's broken. What you're focused on right now.]
[Update this every time you return after a break. Takes 30 seconds. Saves 5 minutes.]

## Key decisions made
These are settled — not open for discussion:
- [Decision 1: e.g. "Server components for all data fetching — no client-side useEffect fetches"]
- [Decision 2: e.g. "Zod for all form validation, no exceptions"]

## File map
- `src/app/` — Next.js App Router pages
- `src/components/ui/` — shadcn/ui components, do not modify these manually
- `src/lib/db/` — all database queries live here

## DO NOT
- Do not suggest React Query — we use server components and Next.js cache
- Do not modify `src/components/ui/` without reading `decisions/001-design-system.md` first
- Do not add new environment variables without updating `.env.example`

The DO NOT section is what separates a good briefing from a great one. It prevents Copilot from helpfully "fixing" something you deliberately designed a certain way for a reason that isn't obvious from the code alone.

Step 3 — Open the Vault in Obsidian

Launch Obsidian
Click the vault icon in the bottom-left corner
Click "Open folder as vault"
Select your .obsidian-vault folder (not the project root — the vault folder specifically)
Click Open

Obsidian initialises the vault and creates .obsidian/ inside it for settings and plugins.

Step 4 — Install the Four Essential Plugins

Go to Settings → Community Plugins → Browse, then install and enable:

Plugin	Why
Templater	Dynamic templates with date variables — you'll use this for ADRs, specs, and bugs
Dataview	Database-style queries across notes — powers your project dashboard
Obsidian Git	Auto-commits notes with your code on a timer
Linter	Keeps frontmatter consistent across all notes

Step 5 — Wire Up Git

At your project root (not the vault folder):

git init

Create your .gitignore:

# Obsidian workspace state (device-specific, don't commit)
.obsidian-vault/.obsidian/workspace.json
.obsidian-vault/.obsidian/workspace-mobile.json

Everything else in the vault — plugin settings, themes, all your notes — gets committed. This is intentional.

Initial commit:

git add .
git commit -m "init: project with obsidian vault"
git remote add origin git@github.com:your-username/your-project.git
git push -u origin main

Now configure the Obsidian Git plugin:

Settings → Obsidian Git
Auto commit-and-sync interval: 10 minutes
Enable: auto commit after stopping file edits
Merge strategy: Merge

Your notes now commit with your code. Every git log shows both. When you look at a commit from six months ago, you'll also see the decision record that motivated it.

Step 6 — Set Up Templates

In Obsidian, go to Settings → Templater and set the templates folder to templates.

Architecture Decision Record (`templates/_template-adr.md`)

---
title: <% tp.file.title %>
date: <% tp.date.now("YYYY-MM-DD") %>
status: Proposed
---

## Context
[Why was this decision needed?]

## Decision
[What was chosen?]

## Consequences
[What changes as a result?]

Feature Spec (`templates/_template-spec.md`)

---
title: <% tp.file.title %>
date: <% tp.date.now("YYYY-MM-DD") %>
status: Draft
---

## Goal
[What are we trying to achieve?]

## Acceptance Criteria
- [ ] Criterion 1
- [ ] Criterion 2

## Out of Scope
[What this spec deliberately does not cover]

Bug Investigation (`templates/_template-bug.md`)

---
title: <% tp.file.title %>
date: <% tp.date.now("YYYY-MM-DD") %>
status: Open
---

## Steps to Reproduce
1. 

## Expected Behaviour

## Actual Behaviour

## Root Cause
[Fill this in when found]

Step 7 — Connect VS Code and Copilot Agent Mode

Create a workspace file at the project root (project.code-workspace):

{
  "folders": [
    { "path": "." }
  ],
  "settings": {
    "files.exclude": {
      "**/.obsidian": true
    }
  }
}

Open this file with File → Open Workspace from File instead of opening the folder directly. This gives you a clean explorer view and ensures Copilot sees the entire workspace including the vault.

Enable Copilot Agent Mode:

Open Copilot chat: Ctrl+Shift+I (or Cmd+Shift+I on Mac)
Click the mode selector at the top of the chat panel
Switch from Ask to Agent

Now test it. Type into Copilot:

Read .obsidian-vault/CLAUDE.md and give me a summary of the current project state.

Copilot reads your briefing file and responds with a summary. From this point on, every agent session starts with that context — no copy-paste, no re-explaining.

You can also tell Copilot to write back into the vault:

Summarise the change we just made and write an ADR to 
.obsidian-vault/decisions/001-auth-strategy.md using the template 
at .obsidian-vault/templates/_template-adr.md

Copilot reads the template, generates the ADR, writes the file. Next commit: decision record and code go together.

Step 8 — Build Your Project Dashboard

Create Dashboard.md at the vault root with Dataview queries:

# Project Dashboard

## 🐛 Open Bugs
```dataview
TABLE status, file.mtime as "Last updated"
FROM "bugs"
WHERE status = "Open"
SORT file.mtime DESC
```

## 📋 Open Specs
```dataview
TABLE status
FROM "specs"
WHERE status != "Done"
```

## 🗺️ Recent Decisions
```dataview
TABLE file.mday as "Date"
FROM "decisions"
SORT file.mday DESC
LIMIT 5
```

Set Dashboard.md as your default file in Obsidian settings. Every time you open the vault, in 30 seconds you know exactly where you left off.

What a Real Session Looks Like

You haven't touched this project in two weeks.

Open Obsidian → switch to the project vault → open Dashboard.md
Two open bugs. One spec in progress. Good.
Check 00-inbox.md — you left a note: "look into partial fill edge case in risk manager"
Open VS Code → Copilot agent mode on
Type: "Read CLAUDE.md and bugs/partial-fill-issue.md and help me investigate the root cause"
Copilot reads both files, understands the context, starts reasoning with you
As you work, you drop quick notes into 00-inbox.md
Root cause found → update the bug note, mark status: Fixed
Before closing: update the Current State section of CLAUDE.md. Two sentences. What you fixed. What's next.
Commit. Notes and code together.

Tomorrow, in two weeks, in six months — you're back in context within 60 seconds.

Switching Between Projects

This is where the per-project vault model really shines.

In Obsidian: click the vault icon → select a different project vault. Each vault has its own plugins, its own dashboard, its own graph view. Zero bleed-through between projects.

In VS Code: close the current workspace, open the other project folder. Copilot's context resets automatically.

You're never reading notes from one project while working on another. Each project is an island — isolated, focused, self-contained.

Key Takeaways

One vault per project — not one vault for your life
CLAUDE.md is the most important file — it's your AI briefing document, update it every session
The DO NOT section prevents AI from "helpfully" breaking things you designed on purpose
Same Git repo — code and notes are versioned together, always in sync
Copilot in agent mode can read and write your vault — it's not just reading your code anymore
Dashboard.md + Dataview — you're back in context within 60 seconds every time

What to expect

The second part will cover GitHub Copilot instructions, agents, skills, prompts, and MCP files — so don't worry if this feels incomplete for now.

Next Steps

Once this is running, the natural progression is Claude Code — a terminal-based agent that reads the same CLAUDE.md file and can run commands across the project. It's built for exactly this kind of project-scoped context.

📺 Full video walkthrough (16 min): Obsidian + VS Code Copilot: AI Second Brain Per Project Setup →

🗂️ Template files (CLAUDE.md starter + ADR/Spec/Bug templates): drop a comment below or on the video and I'll link them

💬 Questions? Leave them in the comments below or on the YouTube video — what part of your dev workflow are you trying to fix? Best questions become future videos.

DEV Community: Clemente Nogueira

GitHub Copilot AI Credits Billing Explained: What's Free, What's Metered, and My Hybrid Claude Code Workflow

TL;DR

The problem

What actually changed

What's still free vs. what burns credits

Where the AI coding tools market stands in June 2026

My hybrid workflow: AGENTS.md + Claude Code + Copilot

The mistake most developers make

Key takeaways

ai #github #productivity #programming #copilot #copilotcredits

93,000 People Downloaded My Side Project — 3 Lessons About Shipping Software That Lasts

TL;DR

The project

Lesson 1 — Solve the thing people are already searching for

Lesson 2 — Design for the community to own it

Lesson 3 — Version like you mean it

What I'd do differently today with AI

The three things that make software last

Obsidian + VS Code Copilot: Build an AI Second Brain Per Project (Full Setup Guide)

TL;DR

The Problem

The Architecture

Step 1 — Create the Folder Structure

Step 2 — Write the CLAUDE.md Briefing File

Step 3 — Open the Vault in Obsidian

Step 4 — Install the Four Essential Plugins

Step 5 — Wire Up Git

Step 6 — Set Up Templates

Architecture Decision Record (templates/_template-adr.md)

Feature Spec (templates/_template-spec.md)

Bug Investigation (templates/_template-bug.md)

Step 7 — Connect VS Code and Copilot Agent Mode

Step 8 — Build Your Project Dashboard

What a Real Session Looks Like

Switching Between Projects

Key Takeaways

What to expect

Next Steps

Architecture Decision Record (`templates/_template-adr.md`)

Feature Spec (`templates/_template-spec.md`)

Bug Investigation (`templates/_template-bug.md`)