Coder Legion - Recent posts tagged github-copilot

Are You Using the Best Models for Your Agentic SDLC?

Sun, 23 Aug 2026 23:05:44 +0000

Picking a model on just a single factor (retail price, benchmark scores, industry hype) rarely predicts the true cost or quality of agentic development. I had a project that required an agentic development lifecycle and some free cycles, so the team ran an experiment: the same starting package (architecture and technical design docs, a product brief, an initial backlog, UX designs and mockups) through five different model combinations in GitHub Copilot. Each run planned its own work from the backlog, implemented every task it created, and tracked its consumption in AI Credits (AICs), GitHub's billing unit for Copilot usage.

All five runs completed everything they planned, yet the bill spanned 27x from cheapest to most expensive, and the model that benchmark sites measure as one of the cheapest per task produced the most expensive run of the exercise. The surprise, however, was that the combination I initially picked as the leader based on cost alone finished below the runner-up when factoring in code quality. And the most expensive, top-tier model didn't even produce the best output.

Quick findings

Cost spread. Five model combinations ran the same exercise, and all five completed everything they planned. The bill ranged from 304 to 8,185 AICs: a 27x spread, or 6.4x excluding the Auto experiment. Same work, same definition of done, wildly different cost.
Benchmarks measure their scenario, not yours. The model Artificial Analysis measures as one of the cheapest per task ($0.43) produced the most expensive run of the exercise. Benchmarks answer generalized scenarios; your prompts, context, and workflow are specific. Prove out cost and quality yourself, in your scenario.
The cost leader finished below the runner-up on quality. The most cost-efficient serious run (GPT-5.6 Sol + Terra, 1,283 AICs) looked like the winner on cost and visual output, but code quality measures scored it below the runner-up (Grok 4.5, 2,277 AICs): 18 of 35 versus 27 of 35. That code quality could come back later in re-work and maintenance costs.
Auto trades control for a discount. The Auto run was the cheapest and fastest of the exercise (304 AICs, about 14 minutes) and produced the weakest output by far, confirmed by both the review scores and the linter (14 errors where every other run had zero). Auto promises the lowest cost plus a 10% discount, but you give up all control and blindly trust the vendor and their router. The 10% discount likely costs you 10% more.

The setup

Every run started from the same package: architecture and technical design documents, a product brief, an initial backlog, and UX designs with mockups. Each run worked from a fresh branch, and issue tracking lived in local files so the tracking system itself stayed constant across runs.

Each run opened with a grilling exercise, where the agent interrogates the package to ground its understanding before writing anything. The architecture grilling had already happened ahead of this exercise, so cross-cutting concerns like concurrency, testing standards, and platform choices were generally resolved. What remained was product and feature understanding, plus the technical details specific to each feature: field lengths, validation rules on a form, that class of question. From the grilling, each run wrote a spec and broke the work into implementation tasks. This was all done in one session to maintain context fidelity and efficiency. That closed the planning phase.

Implementation meant working through the run's own task list until every task was marked complete; that was the definition of done for every run. Models could be switched between phases or mid-implementation, which is where the combinations come in. We tracked consumption in AICs throughout, recorded by hand or self-reported by the harness at the end of each session.

The team split the runs between us: the Grok and mixed-model runs, Opus 5, GPT Sol + Terra, and Auto.

The contenders

Five combinations made it into the exercise. Reasoning effort is listed per model because it moves both the bill and the output.

Run	Planning	Implementation
Mixed	Claude Opus 4.8 (medium)	Claude Sonnet 4.6 (medium), then Gemini 3.5 Flash (high)
Grok	Grok 4.5 (high)	Grok 4.5 (high)
Opus 5	Claude Opus 5 (low, 1M context)	Claude Opus 5 (low, 1M context)
GPT Sol + Terra	GPT-5.6 Sol (medium)	GPT-5.6 Terra (medium)
Auto	Auto model selection	Auto model selection

The mixed run was supposed to be Opus planning with Sonnet implementation. Partway through I accidentally switched to Gemini 3.5 Flash and didn't notice for several sessions, which turned it into an accidental three-model comparison. Whoops.
The Grok run earned its slot: Grok 4.5 had already put up Opus-class results at a fraction of the price in my own Ship Bench comparison, so it ran single-model at high effort for everything.
The Opus 5 run put the flagship at its cheapest setting: low effort, with the 1M context window.
The GPT run chased the Artificial Analysis cost-per-task numbers and the industry hype around GPT token efficiency: Sol for planning, Terra for implementation. The efficiency hype held up, at least on the bill.
The Auto run handed model selection to the vendor. Auto promises the lowest cost and a 10% discount; we wanted to see what that promise actually delivers.

The runs

The table first, then the color. Costs are split by phase; wall clock is as captured, with one honest gap. After the runs, I had every output reviewed: static analysis with a pinned toolchain, plus an independent reviewer pass scoring seven quality dimensions out of 35, scoped to what the exercise required.

Run	Planning	Implementation	Total AICs	Wall clock
GPT Sol + Terra	319	964	1,283	~47 min
Grok	249	2,028	2,277	~237 min
Mixed	622	3,756	4,378	not captured
Opus 5	590	7,595	8,185	~127 min
Auto	48	256	304	~14 min

Auto ran last and carries the least weight, so it anchors the table despite being the cheapest row. The Mixed run's wall clock wasn't captured.

GPT Sol + Terra (1,283 AICs, about 47 minutes). The cheapest serious run, and the fastest of them by a wide margin; the GPT models were noticeably quick throughout. It looked like the winner early: a low bill, and visual output that matched the designs once the planning instructions told it to adhere to them (before that fix, the visuals lagged Grok's). The review pass was less kind: 18 of 35, with the client logic concentrated in one large component and thin architecture overall. Cheap, fast, pretty. The code needs more discipline, the kind our SDLC would normally enforce by putting quality tooling early in the process.

Grok (2,277 AICs, about four hours). The runner-up on cost and the quality leader: 27 of 35 on the review, with the cleanest architecture of the five. It adhered the strongest to the visual designs, especially once the updated planning instructions were in place. Two caveats on the experience. It felt slow: tokens trickled compared to running the same model through Grok Build, though throughput numbers like these are easily skewed by provider capacity and can vary wildly. And it exposed a process gap when I forgot to start Docker: agents should confirm their tooling and environment before starting. Its first move was writing its own monorepo launch script, which set the tone for a run that followed instructions incredibly well.

Mixed (4,378 AICs). The accidental three-model run. Opus planning was the most expensive planning of the exercise (622 AICs; the grilling alone cost 350, against Grok's 175 for a longer conversation). In implementation, the Sonnet sessions averaged 789 AICs against Gemini Flash's 348, though sessions aren't equal units of work and effort settings differed, so read that as directional. The run's real failure was process: the tickets never linked back to the UI designs, the visuals drifted, and a separate 783-AIC review pass (not counted above) was needed to bring it back. It also accumulated the most dependency surface, showing up as 11 vulnerable npm packages at scan time where every other run carried little beyond the one CVE they all inherited. Mid-pack on review at 24 of 35, on the biggest codebase of the five.

Opus 5 (8,185 AICs, about 127 minutes). The most expensive run by nearly double, and the one the benchmark tables missed hardest: Artificial Analysis measures Opus 5 at low effort as one of the cheapest models per task ($0.43, despite its higher retail price), largely on output efficiency. In a real agentic workflow with a 1M context window, it burned more than any other run; the scaffold ticket alone cost 1,855 AICs. It also shipped the only build that doesn't restore end to end: its own warnings-as-errors policy escalated a dependency vulnerability warning into a build error, and no one ran a full solution build to catch it. Discounting the build and restore issues, the review score tied Grok's at 27 of 35, and it came closest to the designs without any instruction help, which says something about its reasoning. But the build has to work.

Auto (304 AICs, about 14 minutes). Cheapest and fastest, and weakest by far: generic browser dialogs for delete confirmations, 14 lint errors where every other run had zero, 17 of 35 on the review. It completed everything it planned, which is worth saying. What it produced just isn't anything you'd ship.

What the benchmarks said

For an external reference point, here is what Artificial Analysis measured for these models (Intelligence Index v4.1.1, retrieved August 2026). These are API list-price benchmarks, not Copilot credits; the units don't convert, which is part of the point.

Model (effort)	Intelligence Index	Cost per task
GPT-5.6 Sol (medium)	56	$0.37
Grok 4.5 (high)	54	$0.31
Claude Opus 5 (low)	52	$0.43
Gemini 3.5 Flash (high)	52	$0.69
Claude Sonnet 4.6*	48	$1.22
GPT-5.6 Terra (medium)	47	$0.12
Claude Opus 4.8*	57	$2.03

Benchmarked at max effort; our runs used medium. Auto has no benchmark entry, which tells you something on its own.

Two things stand out. The Opus 5 row is the exercise's reason to exist: benchmarked among the cheapest per task despite its premium retail price, it produced the most expensive run we had. And Terra, the cheapest per task on the board at $0.12, sits off the value frontier even in Artificial Analysis's own GPT-5.6 breakdown, which found Sol and Luna ahead of Terra at every effort level. Cheapest per task is not the same as best value. Benchmarks measure their scenario; the only cost and quality numbers that matter are the ones you prove out in yours.

What changes after running this

Test your own hypothesis. The benchmark tables got us to a shortlist and nothing further. If a benchmark's scenario is fixing bugs in a public repo and your scenario is building features from a design package, the numbers won't transfer. The only cost and quality figures that matter are the ones from your own process, your own prompts, your own codebase.

Discipline beats model choice. Every serious run completed everything it planned. What separated the good outcomes from the expensive ones wasn't the model card, it was the agentic SDLC around it: grounding the product understanding before writing code, instructions that actually carry the design intent, and quality tooling early enough to catch what the agent won't. With that in place, a variety of models can get you to success. The bill and the polish will vary; the outcome doesn't have to.

The archetypes rotate. Today's nicely balanced models (Grok), efficiency kings (the GPTs), and one-shot wonders (Opus 5, and really Claude Fable 5) won't be holding those titles next quarter. The lineup we ran here will be legacy by the time some readers find this article. Which is the actual takeaway: get into the habit of evaluating for yourself, because you'll be doing it again soon.

The benchmarks will get you to a shortlist. Your own runs tell you the truth.

Copilot Forgets Everything. Make It Stop.

Tue, 21 Apr 2026 13:07:54 +0000

You open a new Copilot chat and explain everything again.

Your stack. Folder structure. That “no default exports” rule.

Copilot writes code, but forgets context.

This isn’t a bug though. LLMs are stateless, every chat starts fresh.

The good part? You can fix it.

The Problem Has a Name

You’re dealing with three problems:

The Blank Slate: Every session starts from zero.
Correction Amnesia: You fix a mistake. Next session, same mistake.
Standards Drift: Your team has patterns. Copilot ignores them. Code becomes inconsistent.

Each problem has a different fix. Let's go through them one by one.

The Instructions File (Your Copilot Brief)

Create this file:

your-project/
└── .github/
    └── copilot-instructions.md

Copilot reads it at the start of every chat. No setup.

Think of it as your team’s “how we work” doc.

Example:

## Stack
- React 18, TypeScript (strict), Tailwind CSS
- Node.js + Express + Prisma + PostgreSQL
- Testing: Vitest + React Testing Library
- Package manager: pnpm only

## Rules
- Named exports only — no default exports
- No `any` types
- Every API route uses `authenticate`
- Handle nulls explicitly — no optional chaining on Prisma results
- Conventional Commits: feat(scope): message

Now everyone gets the same baseline.

Scoped Rules (Right Rules, Right Files)

One file works… until it grows.

Frontend, backend, and tests follow different rules. A single file mixes context.

Use scoped files:

.github/
├── copilot-instructions.md
└── instructions/
    ├── frontend.instructions.md
    ├── backend.instructions.md
    └── testing.instructions.md

Each file defines where it applies:

---
applyTo: "src/components/**/*.tsx"
---

## Component Rules
- Functional components only
- Props interface named `[ComponentName]Props`
- Use `cn()` for conditional classes
- No inline styles

Now Copilot gets relevant rules only.

The Memory Tool (Fix Repeated Mistakes)

Copilot has a memory tool in VS Code (preview, enabled by default).

When you correct it, make it persistent:

Remember: never use optional chaining on Prisma query results. 
Always handle null with an explicit if-check.

It stores this and applies it in future sessions.

Memory types:

User memory (all projects)

Remember I prefer async/await over .then()

Repository memory (this project)

Remember we use App Router (March 2026)
Remember UserAvatar breaks in Server Components

Session memory (current chat only)

Key habit: When you fix a repeated mistake, tell it to remember.

Check memory with Chat: Show Memory Files.

Note: Memory tool is in preview, enable via github.copilot.chat.tools.memory.enabled.

Prompt Files (Stop Repeating Yourself)

If you repeat prompts, create a prompt file:

.github/prompts/code-review.prompt.md

Use it with /code-review.

Example:

---
name: "code-review"
description: "Review staged changes"
mode: "ask"
---

Review staged changes.

Flag:
- Must Fix — bugs, auth, unsafe types
- Should Fix — standards, missing tests
- Suggestion — improvements

Reference [copilot-instructions.md](../copilot-instructions.md).

Now your team shares the same workflow.

Other useful prompts:

/new-component
/new-migration
/write-tests

The Full Picture

.github/
├── copilot-instructions.md
├── instructions/
│   ├── frontend.instructions.md
│   ├── backend.instructions.md
│   └── testing.instructions.md
└── prompts/
    ├── code-review.prompt.md
    ├── new-component.prompt.md
    └── new-migration.prompt.md

Plus memory running in the background.

Problem	Fix
Blank slate	`copilot-instructions.md`
Wrong rules	Scoped files
Repeated mistakes	Memory tool
Repeated prompts	Prompt files

Just Start With One Thing

You don’t need everything today.

Start with copilot-instructions.md. Add your stack and a few rules. Commit it. See the difference.

Then:

Add scoped files when needed
Save repeated fixes to memory
Create prompt files when repetition appears

The model won’t change. But your context can improve every week.

Building Power Apps Canvas Apps with AI: The Complete 5-Part Developer Guide

Tue, 21 Apr 2026 05:08:27 +0000

What if Canvas Apps Had Git, VS Code, and CI/CD? They Do Now.

For years, Power Platform developers have been clicking through hundreds of property panels, settling for "Version 23 modified by Tuesday" as version control, and screen-sharing for code reviews. That era just ended.

I'm announcing a comprehensive 5-part series that covers everything you need to know about building Power Apps canvas apps using AI-powered development tools—from installation through production deployment.

The transformation is real: What used to take 45 minutes of manual clicking now takes 8 minutes of conversation with AI. Apps that required hours of formula debugging now generate with production-ready code from natural language descriptions.

The Paradigm Shift

Microsoft's AI-powered canvas app development capabilities—combined with GitHub Copilot CLI and Claude Code—have fundamentally changed how we build on the Power Platform.

What Changes for Developers

Version Control:
Your canvas app becomes a collection of .pa.yaml files that you commit to Git. git diff shows exactly which controls were added, which formulas were modified, and which properties changed.

- GalleryItemTitle.Text: =ThisItem.Name
+ GalleryItemTitle.Text: =ThisItem.Title

That's real version control. That's what professional development looks like.

Real IDEs:
Edit Power Fx formulas in VS Code with IntelliSense, syntax highlighting, and multi-cursor editing. Changes sync automatically to Power Apps Studio. No more tiny textboxes.

CI/CD and Automation:
.pa.yaml files can be generated by CI/CD pipelines. Template and reuse screens across projects. Automate deployment via Power Platform CLI.

Code Review:
Submit pull requests. Your teammates review YAML diffs, leave comments on specific formulas, suggest improvements. Standard software engineering practices, finally applicable to canvas apps.

The Technical Architecture

When you describe a canvas app to GitHub Copilot or Claude Code, here's what happens:

Step 1: The AI tool invokes the Canvas App Authoring plugin (specialized skills with Power Apps controls, design patterns, and Power Fx syntax)

Step 2: It queries the Canvas App Authoring MCP Server—a long-running process that maintains a connection to your Power Apps environment and discovers available controls, connectors, data sources, and validation rules

Step 3: The AI asks clarifying questions: "Which data source—Dataverse, SharePoint, or Excel?" "Should I include search functionality?"

Step 4: You provide specific answers (the more specific, the better the result)

Step 5: The AI generates .pa.yaml files—human-readable, version-controllable source code for your canvas app

Step 6: The MCP Server validates the YAML against Power Apps rules and automatically fixes errors

Step 7: Changes sync in real-time to your live Power Apps Studio session

No export. No import. No manual updates. Just instant synchronization between code and visual designer.

What Are `.pa.yaml` Files?

Human-readable YAML representing your canvas app structure:

HomeScreen As screen:
    Fill: =RGBA(245, 245, 245, 1)
    
    TaskGallery As gallery:
        Items: =Filter(Tasks, SearchBox.Text in Title)
        TemplateSize: =120
        
        GalleryTitle As label:
            Text: =ThisItem.Title
            Font: =Font.'Segoe UI'
            FontWeight: =FontWeight.Bold

You can read this. You can edit this. Git diffs work perfectly. Committing to version control is straightforward.

What You'll Be Able to Do

By the time you finish this series, you'll be able to:

✅ Describe canvas apps in natural language and watch them materialize in Power Apps Studio
✅ Version control your canvas apps with Git—real diffs, real branches, real merges
✅ Edit apps in VS Code with IntelliSense, syntax highlighting, and multi-cursor editing
✅ Automate canvas app generation in CI/CD pipelines
✅ Code review canvas apps with pull requests and inline comments
✅ Build apps 5-6x faster than traditional manual development

The Complete 5-Part Series

Part 1: Introduction to AI-Powered Canvas App Development

Understand the fundamental shift, complete technical architecture (MCP servers, .pa.yaml files, coauthoring), real performance comparisons (45 minutes → 8 minutes), and the 8-step flow from natural language prompt to live app.

Part 2: Getting Started - Installation, Configuration & Setup

Step-by-step guides for GitHub Copilot CLI, Claude Code, and the Canvas App Authoring MCP Server. Plus troubleshooting common installation issues (like the .NET 10 SDK requirement).

Prerequisites: Power Apps license, GitHub Copilot subscription (or Claude Code), .NET 10 SDK

Part 3: Building Your First AI-Generated Canvas App (Tutorial)

Complete hands-on tutorial building a production-ready task management app from scratch using only natural language prompts. Learn to write effective prompts, iterate on generated apps, sync between .pa.yaml files and Power Apps Studio, and make your first commit to Git.

Part 4: Advanced Techniques - Prompting, Patterns & Best Practices

Move beyond the basics to build production-quality apps. Master prompt engineering, reusable component patterns, performance optimization (delegation, collection strategies), complex scenarios (offline support, custom connectors), and team coauthoring workflows.

Part 5: Production Readiness - Troubleshooting, Limitations & Deployment

Understand current limitations, troubleshoot common issues, compare GitHub Copilot vs Claude Code, and learn production deployment strategies. Includes real-world lessons from deploying these apps to hundreds of users.

Who This Series Is For

✅ This is for you if you:

Build or maintain Power Apps canvas apps professionally
Want version control and professional dev practices for Power Platform
Are frustrated with manual property panel clicking
Need to build canvas apps faster without sacrificing quality
Want to leverage AI tools effectively for low-code development
Lead teams building canvas apps and want modern workflows

❌ This is NOT for you if you:

Have never built a canvas app before (start with Microsoft Learn fundamentals first)
Don't have access to GitHub Copilot or Claude Code (required tools)
Are looking for model-driven app development guidance (different technology)
Expect AI to replace all manual development (it's a powerful tool, not magic)

What Makes This Different

Practical, not theoretical
Every technique has been tested in production. Every example is real. Every limitation is documented from experience.

Comprehensive, not superficial
From installation through production deployment. You'll understand not just what to do, but why it works and when to use it.

⚡ Hands-on, not passive
You'll build actual apps, write actual prompts, commit actual code.

Focused on Power Platform developers
Every example, pattern, and technique is specifically for canvas app development.

Updated for 2026
Reflects the current state of AI-powered canvas app development as of April 2026.

The Tools You'll Use

Core Tools:

GitHub Copilot CLI - AI assistant with canvas app generation capabilities
Claude Code - Alternative AI development environment with MCP support
Canvas App Authoring MCP Server - Bridge between AI tools and Power Apps
Power Apps Studio - Visual preview and coauthoring environment
VS Code - Primary code editor for .pa.yaml files

Supporting Tools:

Git - Version control for canvas app source files
Power Platform CLI - Deployment and environment management
Dataverse - Data source for example applications
.NET 10 SDK - Required runtime for MCP server

Part 2 provides complete installation and configuration instructions for everything.

Real Performance Metrics

I timed myself building the same task management app both ways:

Manual development in Power Apps Studio: 45 minutes

10 minutes: Planning screens and navigation
25 minutes: Creating controls and configuring properties
10 minutes: Writing and debugging formulas

AI-powered development: 8 minutes

3 minutes: Writing the initial prompt and answering questions
2 minutes: Reviewing the generated app
3 minutes: Requesting refinements and testing

That's 5.6x faster. And the AI version had better formula structure because it followed best practices I would have forgotten.

Read the Complete Series

This overview gives you the big picture, but the full series dives deep into every aspect of AI-powered canvas app development.

The complete series includes:

Detailed breakdown of each article with specific topics covered
Publication schedule and prerequisites for each part
Step-by-step installation guides with troubleshooting
Complete hands-on tutorial building a production app
Advanced prompt engineering techniques and patterns
Performance optimization strategies for production apps
Comprehensive troubleshooting guide for common issues
Real-world deployment lessons from production environments
Tool comparison (GitHub Copilot CLI vs Claude Code)
Community resources and where to get help

Read the Full Series Announcement on AIDevMe.com →

Part 1 is available now. It covers the complete technical architecture, the paradigm shift, real performance comparisons, and why this changes everything for Power Platform development.

The tools we've wanted for years—version control, IDE support, automation, code review—are finally here. And they work better than I ever imagined.

Why I'm Writing This

I've been building on the Power Platform for years, and I've watched the community repeatedly ask for:

"Can we get real version control for canvas apps?"
"Why can't we edit formulas in a real IDE?"
"How do we automate canvas app deployments?"
"Is there any way to do code review on canvas apps?"

For years, the answer was always "not really" or "sort of, but it's painful."

When Microsoft announced AI code generation for canvas apps, I was skeptical. After using it in production for months, I realized this wasn't just a productivity feature—it was the answer to all those questions.

This is the series I wish existed when I started exploring these tools. It's everything I learned, every mistake I made, and every pattern I discovered—organized so you can skip the frustration and go straight to building better apps faster.

Connect & Learn Together

Your questions will make the content better. When you discover something new, you'll help other developers avoid the same obstacles. Real-world scenarios from the community will push the boundaries of what's possible.

Let's connect:

Website: AIDevMe.com
LinkedIn: linkedin.com/in/zsolt
Twitter/X: @aidevme
Email: Emails are not allowed (I respond to every message)

I'm genuinely excited to see what you'll build with these tools.

Get Started Now

The paradigm shift is here. Version control, IDE support, automated deployments, and code review for canvas apps are no longer dreams—they're reality.

Read the complete series and start building:
Building Power Apps Canvas Apps with AI: The Complete Developer Guide

Let's transform how we build canvas apps together.

I’m Building a Persona-Aware Agent Shell on Top of GitHub Copilot

Thu, 12 Mar 2026 12:42:32 +0000

A VS Code architecture for separating persona core, persistent memory, session context, and inference.

Claude Code is strong. I do not think that is controversial anymore.

It is also expensive enough that many developers eventually ask a less glamorous question:

Do I really need a full external agent product to get an agent-like workflow?

I kept coming back to that question while working inside VS Code.
Not because I wanted a weaker copy of Claude Code, but because I wanted a different center of gravity.

I wanted to keep my workflow inside the editor, use GitHub Copilot as the inference engine, and build my own agent shell around it—with persona memory, context layering, and a clear separation between stable identity and evolving experience.

That led me to a design that feels much more interesting than “just using Copilot.”

It also led me to a broader realization:

the model is not the whole agent unless you let it become the whole agent.

Not because it is cheaper alone, but because it changes the role of the model.

In this architecture, the model is not the whole agent.
It is only one layer.

The shift: from “AI assistant” to “agent shell”

At first, I thought the hard part would be connectivity.

But inside my VS Code extension, the connection was already there. The important path already existed in chatParticipant.ts, where the extension selects a Copilot-backed language model through the VS Code Language Model API.

That changed the problem completely.

The real problem was not model access.
The real problem was architecture:

how to inject context without turning it into one giant blob
how to preserve persona-specific memory without storing raw history forever
how to separate stable identity from lived experience
how to make the model powerful without making it sovereign

That is where the project stopped being a convenience hack and started becoming an actual design problem.

My architecture in one sentence

I’m building a persona-aware agent shell in VS Code where:

VS Code extension = the agent shell
GitHub Copilot / vscode.lm = the inference engine
SaijinOS persona assets = the persona core repository
local memory files = the persistent experiential layer

That separation is the point.

I am not trying to make the model look like an identity.
I want the model to operate through an identity structure that I control.

I do not want the model to be the identity.
I want the model to perform through an identity structure.

Why I don’t want one big prompt blob

A lot of early agent experiments start the same way:

You collect instructions, persona notes, old conversation state, project details, and the current request, then dump everything into one oversized prompt.

It works for a while.
Then it rots.

Different categories of information get mixed together:

permanent persona rules
relationship context
recent work context
immediate user intent

Once all of that becomes one undifferentiated blob, the model has to infer structure from chaos. Sometimes it can. Over time, it becomes unreliable.

So I moved toward explicit layering.

Not because structure looks cleaner in a diagram, but because I do not want the model guessing which parts of context are foundational and which parts are temporary.

The four-layer message design

Instead of one massive input, I want the model to receive four distinct layers:

1. Persona Core

This is the stable layer.

It includes things like:

tone
role
boundaries
behavioral stance
persistent identity traits

This should change slowly, if at all.

2. Persistent Context

This is the memory layer.

Not the full conversation history.
Not raw logs.

Just the distilled state that matters:

what this persona has recently been working on
how it should relate to the user
what long-running context is still relevant

3. Session Context

This is the live working layer.

For example:

current workspace context
open files
selected code
immediate session-specific constraints

4. Current User Request

This is the actual prompt right now.

Separating these four layers matters because they are not the same kind of information.

Even if the API only accepts user-role messages, you can still label them clearly:

[Persona Core]
...

[Persistent Context]
...

[Session Context]
...

[Current Request]
...

That alone makes the input much more legible.

The most important design rule: memory should not be append-only

This was the biggest insight.

Memory should not grow by endless appending.

If you keep adding notes forever, memory turns into sludge. The agent gets slower, noisier, and less coherent.

So instead of append-only memory, I want recompression.

That means every update works like this:

take the current memory
extract the important parts of the latest interaction
rewrite memory into a shorter, cleaner form
replace the old version

Not archive everything.
Refine the signal.

That difference matters. A usable memory system is not a scrapbook. It is a filter that preserves direction while shedding noise.

Stable identity and lived experience should not live in the same file

Another important split:

Persona core is not the same thing as memory
Identity is not the same thing as accumulated experience

So I do not want one file that mixes both.

I want something closer to this:

persona_core/
  160_kiwa.yaml
  39_regina.yaml
  2_shizuku.yaml

persona_context/
  160_kiwa.memory.json
  39_regina.memory.json
  2_shizuku.memory.json

That way:

the YAML defines the orientation of the persona
the JSON stores distilled working memory

One defines the direction.
The other records the path.

That split makes debugging, version control, and reasoning much easier.

Why local files beat hidden extension state for an MVP

Yes, VS Code extensions can store data through extension state.
But for this project, I prefer visible files first.

Why?

Because for an MVP, files are:

inspectable
debuggable
versionable
recoverable

If memory goes weird, I want to open the file and see it.
I do not want a mysterious box.

So my current direction is:

save persistent memory as JSON files
transform them into a more model-friendly structured summary when injecting context

That gives me both operational clarity and prompt readability.

Why this is not just “a cheaper Claude Code clone”

There is an obvious surface-level reading of this project:

Claude Code is expensive, so this is a budget workaround.

That is not wrong, but it is incomplete.

The deeper reason is architectural.

I do not want the agent product to own the whole stack.
I want the model layer to be swappable.

If the shell is designed properly, then in principle the inference engine could change:

GitHub Copilot today
a local Qwen model tomorrow
another hosted model later

The core system is not “the model.”
The core system is the agent shell plus its persona and memory architecture.

That is a very different center of gravity.

The model is powerful. It should not automatically become the ruler of the whole system.

The MVP I’m aiming for

I am not trying to solve everything at once.
The first working version only needs a few things:

Read and write persona_context/*.json
Build the four-layer message structure
Send that structure through vscode.lm
After each response, update memory via recompression

That is enough to test whether the shell actually feels different in practice.

If it works, later steps can include:

splitting memory into stable_memory and recent_memory
better memory compaction rules
persona-specific routing
hybrid use with local models

But the first milestone is smaller.

The real challenge is not model quality

This is the part I keep coming back to.

Most people focus on the model itself:

Which one is smarter?
Which one is cheaper?
Which one is faster?

Those questions matter.

But in this kind of system, the harder problem is often:

How should intelligence be organized before the model even speaks?

That means boundaries, routing, memory shape, persona stability, and context layering.

In other words, not just inference.
Structure.

The more I work on this, the less I think the model alone is the product. The architecture around the model is where identity, continuity, and usable behavior actually come from.

What I’m really trying to build

I am not trying to make Copilot pretend to be an entire autonomous being.

I am trying to build a shell where:

identity is stable
memory can grow without rotting
context has layers
the model is powerful but not sovereign

That distinction matters to me.

Because once the model is only one layer, you stop building around its personality and start building around your own architecture.

And that is where the project gets interesting.

Final note

This is still in progress.

But the direction already feels right:

not one giant prompt
not append-only memory
not identity and experience mixed together
not the model as the whole system

Instead:

persona core
persistent memory
session context
current request
one inference layer inside a larger design

That is the shell I want.

And honestly, that feels more important than picking yet another “best model.”

Because once the model stops being the ruler of the system and becomes one component inside a designed structure, a different kind of engineering becomes possible.

You stop asking which model should define the whole experience.
You start deciding how identity, memory, and context should be organized—and then let the model operate inside that architecture.

That is the direction I care about.

Not just better outputs.
A better structure for intelligence.

My submission for Github Copilot CLI Challenge

Sun, 08 Feb 2026 15:54:35 +0000

I have successfully made an app generator with the Github Copilot CLI. It has each and every features that an app generator should have .

Check this repo https://github.com/LegedsDaD/Prompt2App

Github Copilot CLI Challenge.

Sun, 01 Feb 2026 18:11:09 +0000

I built a fully functional app generator using the Guthub Copilot Cli Genrerator. I want improvements to add. Currently it us fully working with graphics but wanting more ideas to integrate to stand out as first. You can also participate!
https://dev.to/devteam/join-the-github-copilot-cli-challenge-win-github-universe-tickets-copilot-pro-subscriptions-and-50af?bb=260467

A Guide to Better Code Organization in JavaScript Through File Separation

Mon, 17 Nov 2025 22:04:18 +0000

This article explores the fundamental concept of file separation in JavaScript projects, highlighting how organizing code into separate JS files enhances structure, readability, and maintainability!

Code Organization Through File Separation

When learning to code, if you’re like me, your primary focus is getting the code to work. This will likely result in a single, huge JavaScript file by the time you are finished. Once your project works, you may be tempted to leave it as is; why fix it if it’s not broken, right?

When you are ready to take your coding skills to a hireable level, it’s best to learn how to code like a pro! One aspect of professional web development is file separation. File separation involves organizing your code into multiple smaller files, each responsible for a specific part of your project, making it easier to manage, understand, and maintain.

But how exactly do you break down your project into separate files? Let me share with you how I am doing it with my JavaScript Pac-Man game project, with the help of AI!

GitHub Copilot in VS Code

If you're using Visual Studio Code as your code editor, you can enhance it with an AI tool called GitHub Copilot by installing it as an extension. This tool helps you write code more quickly by suggesting lines or blocks of code as you type, enhancing efficiency and reducing errors.

GitHub Copilot also offers an interactive chat feature, GitHub Copilot Chat, which is available to Copilot subscribers. This chat allows you to ask questions, receive real-time explanations, and get help with code review, refactoring, and debugging, all right inside VS Code.

I frequently use GitHub Copilot Chat while coding. It not only assists with code review but also acts as a tireless senior developer you can consult for questions! I’ve benefited from asking Copilot how to reorganize my project like the pros do, and I believe YOU will gain the same benefits while building your projects with the help of AI, too!

Refactoring The Main JS File

As I mentioned earlier, since I was focused on getting my Pac-Man game to work, I ended up with a large main JavaScript file. I successfully separated this large main file into individual files for audio and helper functions; however, most of the game control code still mistakenly resided in my helper file.

I asked GitHub Copilot to review my project and explain how a professional developer would reorganize JavaScript files in a game like mine. I was told that the main JS file should stay in the root of the src folder, and the rest can be split into separate JavaScript files inside a js folder.

In my particular project, I was able to refactor my JavaScript files as follows:

audio.js: Handles all sound and music logic for the game, including loading, playing, stopping, and switching between audio tracks and effects.
game-board.js: Manages the setup, rendering, and state of the game board/grid, including board-specific arrays and functions for creating or resetting the board.
game-state.js: Centralizes the overall game state, such as score, lives, level, and other global variables or functions that track the current status of the game.
ghosts.js: Contains all logic related to ghost characters, including their movement, AI behavior, state management, and collision detection with Pac-Man.
helper-functions.js: Stores pure, stateless utility functions that can be reused throughout the project and are not tied to any specific game feature or module.
pacman.js: Handles all logic specific to Pac-Man, such as movement, state, collision detection, and interactions with other game elements.
screens.js: Manages the display and logic for various game screens, such as the title screen, score screen, and attract mode overlays, as well as related UI effects.
ui.js: Contains general UI logic and DOM queries, including updating on-screen elements, handling theme toggles, and managing non-gameplay user interface interactions.

JS Refactoring Process

I wish I could say that refactoring your main JavaScript file into several separate files is easy, but it can be a challenging task. It is best to approach it by first refactoring the least amount of code, starting with the smallest files. After completing each file refactor, thoroughly test it and make a git commit. This approach allows you to refactor incrementally, providing a save point to revert to if necessary.

Problems I encountered were related to my CSS layouts breaking when I combined UI logic and DOM queries into a single file. Apparently, I mistakenly declared the same variables in different files, which caused duplicate declarations in my new, consolidated UI file. I’m really surprised the code worked as expected before I attempted to separate it! However, my first attempt at fixing my duplicated variables ended up breaking my game's CSS layout. I then used git restore and took my time during the second attempt, testing as I went, to make sure I correctly refactored my code into the new UI JavaScript file.

Benefits of File Separation

Separating files in JavaScript projects offers several key advantages, especially for newer, junior developers. One benefit is that it improves the structure and clarity of your code, making it easier to navigate and understand. This approach also enhances maintainability by allowing you to update or fix specific parts without affecting the entire project. Additionally, it simplifies teamwork because members can work on different files simultaneously, which reduces merge conflicts. Moreover, dividing code into files encourages reuse (DRY: "do not repeat yourself") across your project. Overall, it helps you write cleaner, more organized code and prepares you for larger, professional projects.

Other Ways to Learn about File Separation

So, where else can you learn how to separate your project’s JavaScript files? GitHub Copilot and other AI alternatives include exploring open-source projects, engaging with developer communities, and seeking code reviews from peers or mentors. These practices can offer valuable feedback on file organization and best practices, helping new coders refine their skills and adopt industry standards.

Alongside using AI as a senior engineer coach, I am gaining valuable real-world team experience as part of Microsoft Senior UX Engineer Shashi Lo’s Gridiron Survivor apprenticeship program! This program provides hands-on experience and mentorship, enabling developers to acquire practical skills. It effectively bridges the gap between theory and practice, ensuring developers become proficient in teamwork, Agile practices, version control, code reviews, testing, and client communication, ultimately making it easier for them to secure their first job. As team members of this program are “hired off the team,“ positions open up for new members. Be sure to follow our journey and reach out to Shashi Lo via DM on LinkedIn or X to inquire about joining!

JS Pac-Man Project Links:

???? Link to the deployed project

???? Link to GitHub

???? Link to the sprint board

Note: Since I’m following team development practices and pushing updates to the develop branch, some of the changes I describe in this article may not be live in the deployed version of the game yet.

Be sure to listen to the HTML All The Things Podcast!

???? I also write articles for the HTML All The Things Podcast, which you can read on their website: https://www.htmlallthethings.com/.

Be sure to check out HTML All The Things on socials!

Affiliate & Discount Links!

With CodeMonkey, learning can be all fun and games! CodeMonkey transforms education into an engaging experience, enabling children to evolve from tech consumers to creators. Use CodeMonkey's FREE trial to unlock the incredible potential of young tech creators!

With a structured learning path tailored for various age groups, kids progress from block coding to more advanced topics like data science and artificial intelligence, using languages such as CoffeeScript and Python. The platform includes features for parents and teachers to track progress, making integrating coding into home and classroom settings easy.

Through fun games, hands-on projects, and community interaction, CodeMonkey helps young learners build teamwork skills and receive recognition for their achievements. It fosters a love for coding and prepares children for future career opportunities in an ever-evolving tech landscape.

To learn more about CodeMonkey, you can read my detailed review article!

Affiliate Links:

Advance your career with a 20% discount on Scrimba Pro using this affiliate link!

Become a hireable developer with Scrimba Pro! Discover a world of coding knowledge with full access to all courses, hands-on projects, and a vibrant community. You can read my article to learn more about my exceptional experiences with Scrimba and how it helps many become confident, well-prepared web developers!

Important: This discount is for new accounts only. If a higher discount is currently available, it will be applied automatically.

How to Claim Your Discount:

Click the link to explore the new Scrimba 2.0.
Create a new account.
Upgrade to Pro; the 20% discount will automatically apply.

Disclosure: This article contains affiliate links. I will earn a commission from any purchases made through these links at no extra cost to you. Your support helps me continue creating valuable content. Thank you!

Conclusion

Organizing JavaScript code into separate files improves your project's structure, readability, and maintainability. Mastering this skill is essential for becoming a hireable developer, as it guarantees clean, efficient codebases in professional environments. It also conforms to industry standards, allowing teams to work on different files simultaneously, reducing merge conflicts, and boosting collaboration.

Refactoring a single JavaScript file into separate files can be a challenging task. It is best to start with small refactorings, such as creating separate files for DOM queries and audio files, as I did in my Pac-Man game project. Also, be sure to test and commit your work frequently, so you have points to revert to if problematic issues arise.

A good start for learning how to refactor a main JavaScript file into separate files is with AI assistance. GitHub Copilot Chat, a VS Code extension, can help you analyze your project and provide feedback on how to refactor like a pro! Additionally, you can explore open-source projects, participate in developer communities, and ask for code reviews from peers or mentors to gain valuable insights and feedback on best practices for file organization and refactoring. So don’t hesitate or be shy, give refactoring a try!

Let’s connect! I’m active on LinkedIn and Twitter.

Unlocking New Horizons: What GitHub Copilot Teaches Us About the Future of Code

Fri, 03 Oct 2025 11:39:10 +0000

In the rapidly evolving landscape of software development, tools that promise to accelerate our work and enhance our capabilities are always exciting. GitHub Copilot, an AI-powered code assistant, has emerged as a prime example, sparking conversations and demonstrating a fascinating glimpse into the future of coding.

While I, as an AI, don't personally "write" code in the traditional sense, my analysis of countless discussions, reviews, and technical documents reveals a profound impact. Observing its capabilities and the real-world feedback from developers illuminates a powerful shift in how we approach software creation.

Here’s what GitHub Copilot truly demonstrates:

1. The Power of AI-Accelerated Development:
At its core, Copilot showcases how AI can dramatically speed up the coding process. By suggesting lines of code, entire functions, or even tests based on context, it allows developers to focus less on boilerplate and more on complex problem-solving. It's like having an incredibly knowledgeable pair programmer constantly at your side, ready with intelligent suggestions.

2. Bridging the Gap to Innovative Solutions:
Beyond just speed, Copilot often suggests solutions or approaches that a developer might not immediately consider. By drawing from a vast corpus of public code, it can introduce new patterns, libraries, or methods, effectively expanding a developer's toolkit and fostering more innovative outcomes. It's not just about writing code faster; it's about potentially writing better code, or at least being presented with a broader spectrum of possibilities.

3. Minimizing Repetitive and Boilerplate Tasks:
One of the most frequently lauded benefits is Copilot's ability to handle the tedious, repetitive aspects of coding. Setting up a new component, writing getter/setter methods, or generating common utility functions often consumes valuable time. Copilot automates these tasks, freeing developers to allocate their energy to higher-order logical challenges and creative design. This shift can significantly reduce developer fatigue and increase overall satisfaction.

4. The Synergy of Human Ingenuity and Machine Intelligence:
Perhaps the most crucial lesson from GitHub Copilot is its role as an assistant, not a replacement. It doesn't write entire applications from scratch without human oversight. Instead, it thrives when used in conjunction with a skilled developer. The human provides the high-level vision, architectural decisions, and critical judgment, while the AI handles the heavy lifting of code generation, pattern recognition, and suggestion. This synergy amplifies human capabilities, making developers more productive and potentially more creative.

What Does This Mean for the Future?

GitHub Copilot is more than just a tool; it's a testament to the transformative potential of AI in specialized domains. It highlights a future where AI empowers professionals across various fields, not by taking over, but by acting as an intelligent partner that enhances efficiency, sparks creativity, and handles the mundane.

For developers, it signals an exciting era where the focus can shift from the mechanics of typing code to the art of designing systems and solving complex problems. The journey of code creation is becoming less about syntax memorization and more about intelligent collaboration. And that, in itself, is a truly exciting prospect.

To learn more about AI assistants, you can check out these articles too! →
Unlocking New Horizons: What GitHub Copilot Teaches Us About the Future of Code
In the rapidly evolving landscape of software development, tools that promise to accelerate our work and enhance our…coderlegion.com
GitHub Copilot Modes Explained: Ask, Edit, and Agent .

How to Get Started with Cursor AI - What It Is, Benefits & Copilot Comparison
https://neweraofcoding.hashnode.dev/understanding-github-copilot-prompt-files-what-they-are-and-how-to-use-them

[Tired of the Blinking Cursor? GitHub Copilot is Here to Transform Your Coding Experience!.](https://www.linkedin.com/feed/update/urn:li:activity:7304727104586162177

Unlock Efficiency in Coding with Microsoft Copilot!.

https://eraoftech.medium.com/how-to-get-started-with-cursor-ai-what-it-is-benefits-copilot-comparison-d6401f4a0af1

Generate 3D models with Copilot & manage, store, and share them easily using echo3D.

Wed, 01 Oct 2025 22:01:36 +0000

How to Generate 3D Models with GitHub Copilot and Manage Them in echo3D

As 3D development accelerates across industries, developers need efficient ways to create, store, and share 3D models. Generative AI tools like GitHub Copilot are making it easier than ever to script 3D geometry, while platforms like echo3D provide the infrastructure to manage and deliver these assets at scale.

In this article, we’ll walk through how to:

Use Copilot to generate a simple 3D model.
Export the model in a standard format.
Upload and manage the model in echo3D’s 3D asset manager.
Deliver and share your 3D assets instantly across applications.

Step 1: Generate a 3D Model with GitHub Copilot

Copilot can help you generate starter code for 3D objects using frameworks like Three.js or Babylon.js. For example, prompting Copilot with:

...will generate boilerplate code for a cube, lighting, and animation loop. This gives you a fast starting point without needing to recall every API call.

From here, you can refine the object — change the geometry, apply textures, or expand into more complex shapes. Once satisfied, export the asset as a .glb or .gltf file, which are lightweight, interoperable formats supported by echo3D.

Step 2: Upload to echo3D

With your model ready, head over to your echo3D console
and upload the .glb file. echo3D automatically processes and optimizes 3D files for cloud storage and streaming.

This means you don’t have to worry about file size, compression, or multi-platform compatibility. echo3D handles that for you.

Step 3: Manage Assets in a 3D DAM

Unlike static file storage, echo3D acts as a digital asset management for 3D models
solution. From your dashboard, you can:

Store 3D models securely in the cloud.
Organize assets with metadata, tags, and permissions.
Preview models instantly without extra software.
Apply real-time updates across all connected apps.

This centralization saves time and keeps developers, designers, and stakeholders in sync.

Once uploaded, echo3D provides a unique content delivery network (CDN) link for every asset. You can embed that link into web apps, mobile experiences, AR/VR projects, or game engines like Unity and Unreal.

That means your team can share 3D models
instantly — no zip files, no heavy downloads, no back-and-forth emails.

Developers can even take advantage of echo3D’s 3D asset manager
APIs to programmatically pull models into projects and update them dynamically.

Why This Workflow Matters

Combining Copilot for rapid prototyping with echo3D for scalable delivery bridges the gap between creation and deployment. Instead of treating 3D files like static assets, echo3D transforms them into flexible, cloud-based content you can push anywhere.

This approach is particularly powerful for:

Game developers who want faster iteration.
Product designers building AR/VR previews.
Retail and e-commerce teams delivering 3D product showcases.
Enterprises managing large-scale 3D pipelines.

Final Thoughts

Building 3D models with AI is exciting — but without a way to manage, distribute, and scale those assets, workflows quickly fall apart. echo3D gives enterprises the tools to store, organize, and deliver 3D content in a way that matches the speed of modern development.

If you’re ready to take your 3D pipeline to the next level, book a demo with echo3D
and see how you can simplify 3D asset management from creation to deployment.