I’m Edd Wilder-James, Director of TPM at GitHub—I lead the TPM org for Copilot, and P&E. I’m a coder, but not a software engineer by role; my job is strategic and organizational.
Been around tech a long time, but I’m not shipping production code for GitHub products.
What I actually do day-to-day: understand what’s happening across initiatives, track stakeholder concerns, make sure programs are on track. The tools I needed for that didn’t exist, so I built them. Copilot made that practical.
Winter break. I had repeated focus time—multi-hour sessions without interruptions. That got me past the “quick task” mode into actually tackling harder problems.
I was building tools I needed for my job: stakeholder tracking, initiative progress. Once I saw what was possible with sustained effort, I kept going.
Building tools I need that don’t exist. Whether at work or home.
The flagship home example is Casa: a household AI assistant that lives on Matrix. It has 30 tools, E2E encryption, image vision, multi-provider calendar integration (Google + iCloud), shared lists, reminders, web search. My household uses it daily. I built it in an afternoon using the Copilot SDK.
Other recent projects:
- Meeting-notes-processor: automated pipeline from meeting recording → transcription → AI summarization → structured org-mode notes. Runs as a daemon, processes in bulk, commits to git. Wrote a blog post about it.
- Sentinel: stakeholder intelligence—tracks relationships, sentiment, interaction decay. Recently migrated to the SDK.
- epd-zg: initiative tracking CLI that queries GitHub’s work hierarchy. Added auto-freshness and staleness tracking.
- Upstream Emacs contributions: table rendering for shell-maker, live overlay fixes for md-mermaid, inline-code fence fixes. Copilot writing Elisp—a language I know but am slow in without assistance.
Local repos in ~/git/, each with an AGENTS.md for repo-specific instructions.
But the real leverage comes from *skills*—reusable context bundles in
~/.github/skills/ that any session can load. I have skills for:
org-gtd: manages my GTD system (Emacs org-mode) from Copilotpersonal-context: my bio, preferences, work style, relationshipssentinel: stakeholder intelligence queries and briefingsrelease-issues: introspects our release tracker
Skills are the difference between “start fresh every session” and “Copilot already knows how I work.”
My primary interface is the Copilot CLI in the terminal, shared about 50/50 with VS Code. Increasingly I find myself more in the CLI and less in the IDE. I also use agent-shell (an Emacs frontend to the CLI) for tighter integration with my org-mode workflow, and pretty rendering of tables and diagrams.
Yes, but task-separated. One session implementing a feature, another doing research in a different repo. They don’t step on each other’s files.
I don’t use multi-agent swarms yet. Nothing I’m working on hits production—it’s internal tooling—so I’m not quite at those advanced use cases.
What I do use is agents in different contexts centered on the same project: coding, then generating slide decks, videos, blog posts. Same project, different outputs.
Three things: AGENTS.md files per repo, skills for reusable context bundles, and generating structured output (markdown, org files) that becomes future input.
Depends on size. For shorter tasks, I use plan mode—describe what I want, iterate on the plan, then “get to work.”
For bigger projects, I still write a proper PRD and design docs. Copilot helps draft them, but I want that documentation to exist independently.
Either way, the phases are: brainstorm the idea, run experiments to test feasibility, document the approach, implement, then have Copilot act as a tester to find edge cases. I don’t let it jump ahead.
For complex multi-file coding I reach for the best reasoning model available—currently cycling through Opus 4.6 variants as we launch them.
For production uses—sentiment analysis, meeting summarization—I hand off to smaller models.
For personal projects, I use both Gemini Pro and Opus. For work, I stick to Opus.
5-10x on implementation, but the real multiplier is on ambition.
Casa went from “wouldn’t it be nice if our house had an AI assistant” to a working multi-user product with 30 tools in a few hours. That’s not a project I’d have started without agents. Same for meeting-notes-processor: end-to-end audio pipeline with transcription, diarization, AI summarization, git commits. Built it, deployed it on a home server, wrote a blog post—all in a couple afternoons.
I’m also contributing upstream to open source Emacs packages in Elisp. I know the language, but I’m slow in it. With Copilot, I can focus on the design problem and let it handle the implementation patterns.
I really like how agents let me quickly improve my own workflows’ UX.
Most of it wouldn’t exist. Casa, sentinel, meeting-notes-processor—none of these are products anyone sells. They exist because the cost of building custom tools dropped below the cost of tolerating their absence.
In many cases I can’t use SaaS solutions because of privacy and security: agents let me code my own workflows pretty quickly. I’m having more fun with tech and being more productive than ever before.
A shift I’d highlight: I’ve moved from using Copilot to building with Copilot. My projects Sentinel and Casa both embed the Copilot SDK—they’re AI applications powered by the same platform. That’s a different relationship than just agentic coding. I’m a customer and a builder at the same time.
Two things: real problems, and treating it like a collaborator.
I didn’t do tutorials—I picked something I needed and committed to shipping it. And I work with it like a junior engineer: brainstorm, run experiments, write docs, test the work. Not just “write this code.”
State across sessions is better now with skills, but still not seamless. Starting a new session means re-loading context.
The “almost right” problem—code that’s 95% correct but the 5% is subtle. This is where experience matters: knowing what to test, what to doubt.
Tooling fragmentation is real—CLI, VS Code, agent-shell are all different experiences with different capabilities. The skills system helps bridge this but the context model isn’t truly unified yet. The biggest gap is probably finding a way of scooping up a CLI session when I go mobile, so I can continue the work.
Don’t be scared, just start. Pick a real problem, not a tutorial. Have a clear outcome in mind. Write an AGENTS.md early. Review everything—it’s confident, not correct. Commit frequently. Get it working and then optimize.
My biggest lesson: don’t gatekeep Copilot. Just try it on whatever problem you have.
The arc worth noting: in two months I went from “Copilot helps me write code” to “I build AI applications that embed Copilot.”
Casa is a standalone AI product. It runs 24/7 on a home server, has its own tools, manages its own state, serves multiple users. It happens to use the Copilot SDK as its brain. Sentinel does the same for stakeholder intelligence.
This is where Copilot’s value compounds. It’s not just the productivity gain from coding faster—it’s that the platform is embeddable. You can build things with it that build things with it. That recursive leverage is what makes the usage spike sustainable: each project creates infrastructure for the next one.
The skills I built for my GTD system, my calendar, my stakeholder tracking—those now make every future session more productive. The meeting-notes-processor feeds structured data back into org-mode files that Copilot reads to enrich future work. It’s a flywheel.