DEV Community: Emanuele Bartolesi

I can build the product with AI. Getting the first users is harder.

Emanuele Bartolesi — Tue, 10 Nov 2026 20:37:14 +0000

With Brainy and MoneyBrain, getting the first users and growing monthly recurring revenue has been harder than building the software.

November 12, 2026 update. After a reader asked how people outside my network found the product, I added what happened after I worked on SEO with dotcraft. I also added a Brainy example covering keyword research in Semrush, tracking search clicks and sign-ups, and using Microsoft Clarity to see where visitors drop off. Jump to the SEO update

At the beginning, I used my circles on LinkedIn. It gave me somewhere to start talking about the products. Expanding beyond that network has been difficult, especially without a large budget.

That is where I want to pick up from my previous post about building products with AI. In that post, I described how I move from a brainstorm to requirements, GitHub issues, implementation, and a reviewed pull request. I can give the implementation work a scope and check the result against it.

Finding users leaves me with questions I am still working through: where to reach people who need the product, and why they would try it, return, and eventually pay.

My network gave me a place to start

Talking about Brainy and MoneyBrain on LinkedIn was a reasonable first step. I already had people I could reach there, rather than starting with an empty account and hoping someone would find a product announcement.

But a professional network is a particular audience. Someone can be interested in how I build software without needing either product. A post about my AI workflow and a post explaining why someone should use an application ask for different kinds of attention.

More visibility for me would be useful, but I also need to understand which people have the problem the product addresses. Otherwise, I could spend more time promoting it and still learn very little about demand.

A screenshot of a SaaS advice post brought this back into focus. It covered familiar recommendations: promote the product, talk to users, keep the first version small, use it yourself, and pay attention to people who leave.

Reading those points alongside my experience, I kept returning to the difficulty of reaching the next group of people without a large budget.

The post puts most of the work after launch into marketing. I would not assign a fixed percentage to it, but I agree with the underlying reminder: launching leaves a substantial amount of work ahead. For my current goal of finding users, time spent explaining the product and following up with people deserves a place in the schedule alongside implementation. Another completed issue does not tell me whether anyone new understood the offer.

Some users found me through search

A reader asked whether anyone outside my network had found one of the products. Yes. I spent a lot of time on SEO for the public website, including using the seo skill in dotcraft to guide that work. After that, people outside my LinkedIn circles found the site through organic search and became users. dotcraft

That gave me a way to reach someone who was already looking for a solution. On LinkedIn, people often know me for how I build software. A visitor arriving from search has a different starting point. They want to know whether the product solves the problem they searched for.

How I would research one page for Brainy

Say I want to reach someone who keeps project notes in one app and tracks the follow-up tasks somewhere else. Here's how I'd research a page for that person.

Start with the problem. I'd put organize project notes into Semrush's Keyword Magic Tool, select the country I'm targeting, and use the Questions filter to find more specific ways people ask about the problem. I'd use the estimated search volume and keyword difficulty to shortlist terms, then search for those terms myself. If the results are mostly tutorials, I'd write a guide. If they're mostly comparisons, I'd expect readers to want help choosing an app. Semrush Keyword Magic Tool
Give the page one job. For a query like how to turn project notes into tasks, I'd write a short walkthrough using a sample project. I'd show where I capture a meeting note in Brainy, how I connect it to the project, and where I put the next task. I'd use dotcraft's seo skill to review whether the title matches the walkthrough and whether the page can be indexed.
See what happens after the click. In Google Search Console, I'd filter the Search results report to that page and look at the queries, impressions, and clicks. If I already had a site with search traffic, those queries could also give me a starting list for step one. Separately, I'd use site or product analytics to see whether visitors from organic search sign up and complete the task the guide demonstrates. That tells me whether the page is bringing in people who go on to use the product. Search Console performance report · Search Console and Analytics
Look at where visitors drop off. I also use Microsoft Clarity to see how visitors move through the public website. Heatmaps show where they click and how far they scroll, and session recordings let me look more closely at what happened before they left. For the Brainy example, I'd set up a funnel from the guide to the sign-up page to a completed sign-up. Clarity shows the count and percentage of sessions that stop at each step. If people leave the guide before reaching the sign-up link, I'd check the scroll map and watch a few recordings to see whether the link is easy to miss. Clarity funnels · Clarity heatmaps

Screenshot of the public Microsoft Clarity homepage. The dashboard figures shown are part of Microsoft's demo. Microsoft Clarity

Reaching outside my LinkedIn circles

The encouragement to promote the product openly is useful. Staying entirely within my familiar LinkedIn circles would leave the same audience boundary in place. I need to be willing to explain what I have built somewhere people do not already know me, and to hear that it may not be relevant to them.

I could make a long list of places to post. Each one would take time to understand, participate in, and follow up on. I would also have to decide what to say there, because a product announcement that makes sense to my LinkedIn contacts may mean very little to a stranger.

For Brainy and MoneyBrain, I would rather make the next attempt narrow enough to learn from. Pick one product, one specific problem, and one place where people already discuss that problem. Then explain or demonstrate the part of the product that addresses it.

I also need to make that choice separately for each product. The fact that I built both does not mean the same people need both, or that the same explanation will persuade them. Putting their names into one announcement is convenient for me; a potential user needs a reason to care about the particular application in front of them.

I could examine the result: did people recognize the problem, ask how the product handles their situation, or try it?

If the only response is interest in the technology behind it, that would tell me something too. I might have reached other builders, or explained the implementation more clearly than the reason to use the product.

I feel the budget constraint, but I do not want to turn that into a conclusion that growth requires a large advertising spend. I have not established that. Before spending more, I want a clearer idea of whom I am trying to reach and what I can show them.

A useful next asset could be a short walkthrough of one task, using demonstration data and showing the result. I could use it in a relevant conversation, give the landing page something concrete to show, and learn which part needs more explanation. A tutorial answering a question prospective users already ask could also become something they can find or share later. These would give me more to work with than repeatedly announcing that the product exists.

A community, a search-focused article, or a collaboration needs to earn the time I put into it. A channel with no advertising bill still costs time. Participating well in a community means reading the discussions, respecting its rules, and contributing something useful before expecting attention for my application.

The alternative is often something people already do

Before writing that walkthrough, I need to understand what the person would replace. They might already have a tool, a document, or a routine that handles the task adequately. Moving to my product could mean learning another interface and spending time setting it up before they see a benefit.

My own move from Notion to Brainy is a useful example of an existing workflow being involved. It gives me a case to examine, but another person's reasons to change could be different. I need to ask which part of their current approach is frustrating enough to justify the effort of switching.

That should shape the product description. Explaining the task someone can complete gives them a way to judge the offer. Describing my AI-assisted development process tells them how I made it. I enjoy talking about that process, and it belongs in the previous post, but it may have little bearing on a person's decision to use Brainy or MoneyBrain.

Even the comparison with competitors needs this context. A competing subscription price tells me one thing about the market; a person's current workaround tells me what I would have to improve. If their approach is already good enough, I need to understand that answer instead of assuming another feature will persuade them.

The first visit needs somewhere useful to go

Someone outside my network needs to understand the product without knowing my background. That makes the advice about the landing page and sign-up process more relevant.

A useful check would be to ask someone unfamiliar with the project to look at the page and explain what they think it does. Then ask them to attempt its main task. I would want to see where they hesitate before adding another feature to the backlog.

That is how I read the advice to make a landing page clean, fast, and convincing. Keep the page focused, check how it loads on a phone, and show a concrete use of the product. A polished layout still needs to help that unfamiliar visitor decide whether to try it.

Google login might remove a step for some people. It cannot explain an unclear product promise, and I would not treat it as an automatic requirement for every audience. The question I want to investigate is where a prospective user gets stuck between understanding the offer and experiencing something useful.

Using my own product regularly gives me a way to notice friction in ordinary tasks. In my earlier post about moving to European digital services, I described replacing Notion with Brainy. That is a useful starting point for testing a real workflow. But I know the product's intended behavior and can navigate around something that another person would find confusing. My familiarity is a reason to get an outside view, especially when I am asking that person to trust a new product.

Keeping the minimum viable product small belongs in this discussion too. I want enough functionality to let someone complete the task that brought them there. Adding features before understanding that task could make both the explanation and the first visit more complicated.

The screenshot names MoSCoW as a way to keep that scope under control: Must Have, Should Have, Could Have, and Won't Have this time. The Agile Business Consortium explains those priorities. For a first release, I would ask whether leaving a feature out prevents the intended user from completing the core task. If it does not, I need a good reason to put it ahead of learning from users.

For the first users, I would also consider helping them through that task personally. Paul Graham's essay on doing things that don't scale argues for recruiting early users manually and paying close attention to their experience. I can see a practical application here: offer a short walkthrough, watch where the person needs help, and use that observation to improve the next attempt.

If I have to explain the same step to everyone, that gives me something specific to investigate in the interface or instructions. If each person wants a completely different outcome, I need to revisit the audience and scope. Automating the welcome messages before understanding those differences could leave me sending more people through a confusing experience.

Trust is part of the first useful experience

There is another reason someone might hesitate even after understanding the product: they have to decide whether to put their information into it. A demonstration with sample data can reduce the effort needed to evaluate the workflow, but using the application for real asks for more trust.

For any task involving personal or financial information, I would want the product to explain what it stores, what happens to that information, and how a person can leave. Those explanations need to match the actual implementation. I cannot make a privacy or security promise simply because it would look reassuring on the landing page.

Support belongs in that decision too. A person should be able to find a way to report a problem and understand what help they can reasonably expect. As an independent builder, I need to be honest about that commitment. Offering personal onboarding is useful only if I leave enough time to follow through.

This is part of what makes a small MVP a serious product decision. I can defer optional features while still needing a dependable core workflow. If the application loses the work someone just entered, a smaller backlog does not make their experience acceptable. The scope has to include the behavior people rely on, and I need to check it before asking them to move a real task into the application.

Growing MRR asks more than whether someone signed up

The screenshot recommends charging from day one instead of offering free trials. There is a useful question behind that advice: will someone pay for the outcome? A payment is more direct evidence of willingness to pay than an encouraging comment on LinkedIn.

I would still make the trial decision around the product. If someone needs to use it with their own information or across several days to judge the benefit, a trial could help them decide. If the value can be demonstrated clearly before purchase, charging immediately may make sense. I would not dismiss every free user as unserious; their experience can reveal a problem that also affects paying users.

Monthly recurring revenue is an objective I care about. To make progress toward it, I need to understand what would justify an ongoing payment from the people I am trying to reach. Choosing a price or removing a free trial does not answer that question on its own.

The advice to price based on value is more useful to me than copying another application's subscription page. I would want to ask about the task a person is doing now: how they handle it, what is frustrating, and what a useful improvement would look like. Time saved, a recurring task made easier, or a mistake avoided could give the discussion a concrete basis. Those are possibilities to investigate, not benefits I can assign a monetary value to without talking to people.

Those conversations could happen through a DM, an email, or a short call, depending on what the person prefers. A focused question about what they tried to do would give me more to work with than asking whether they like the product. I would also want to hear from someone who created an account and then stopped, rather than only from people willing to praise it.

This is where retention belongs alongside the work of finding new users. If people try the product and do not return, reaching a larger audience leaves that question unresolved. I would want to understand repeated use before scaling the same acquisition attempt. For a recurring subscription, whether people keep finding a reason to use the product matters to the revenue goal too.

If a person leaves, an optional conversation could help explain what happened. I would make unsubscribing or cancelling straightforward, and respect a person who does not want to explain. An email opt-out might mean they want fewer messages; a product cancellation asks a different question. Either can be feedback, but neither gives me a reason to argue with their decision.

I also need to understand the expected frequency of the task. Someone may get value from a product every week or at a particular point in the month. Daily activity would be a poor way to judge that experience if daily use was never the goal. I would look for people returning when the need occurs and completing the task they came for.

Feedback from those conversations needs a decision attached to it. A request for another feature might reveal a missing step in the core workflow, or it might describe a different product. I would record what the person was trying to accomplish before putting the request into the backlog. That gives me a way to compare it with other needs instead of letting the most recent message determine the next epic.

I need to know where the attempt stops working

Once I start trying channels outside LinkedIn, a total sign-up count will leave too much unexplained. I want enough visibility to distinguish a message that people never saw from a product they tried and then abandoned.

A simple record could follow the path from first contact to continued use:

Step	What I would try to learn
Someone encounters the product	Which conversation, post, article, or recommendation brought them there?
They visit the page	Can they understand the problem it addresses and the next action?
They create an account	Where do they hesitate or leave during registration?
They complete the main task	Do they get the outcome that made them try it?
They return when needed	Does the product fit an ongoing need?
They begin or continue paying	What makes the ongoing price worthwhile to them?

That main task needs a definition for each product before its completion becomes a useful signal. Opening a dashboard might only show that registration worked. The meaningful action should reflect what the person wanted to accomplish, and any measurement should collect only the information needed to understand that behavior.

With a small number of users, raw counts and conversations need to sit alongside any percentages. A few people leaving at one step would justify looking at it; it would not give me a reliable explanation of why everyone leaves. The channel context matters too. People arriving from my existing network may behave differently from people encountering the product for the first time.

This could make the next decision more specific. If people understand the offer but cannot finish the task, I have something to investigate in the product. If the people I reach do not recognize the problem, I need to examine the audience or message. Changing both at once would make it harder to understand what helped.

The costs behind the MRR goal

MRR also needs more detail than one rising total. Stripe's explanation of monthly recurring revenue separates growth from new subscriptions and existing customers increasing their subscriptions, and reductions from cancellations or downgrades. Those movements describe different situations that I would want to understand separately.

For example, new subscriptions could increase the total while existing subscribers leave. I would want to see both movements before deciding to repeat the acquisition effort. A larger total on its own would not explain whether the product is keeping the users it already reached.

Then I need to compare recurring revenue with the costs of providing the service. Hosting, payment processing, and support take resources. Where a product uses paid external services, their usage belongs in that calculation too. MRR measures recurring revenue; it does not show what remains after those costs.

The implementation workflow has costs as well, and the time spent helping users has to fit into the week. Even if AI makes an implementation task cheaper for me, I still need to maintain the behavior it introduces and answer questions about it. That is another reason to keep the scope of a growth experiment manageable.

A lifetime deal offered simply to produce early cash would deserve particular scrutiny. An ongoing service creates ongoing work, while a one-time payment has a different revenue shape from a recurring subscription. Before making that offer, I need to understand the support commitment it would create. This is a possible decision to examine; I am not reporting a pricing change to either product.

Ambition needs a reason to continue

The post also encourages builders to aim beyond their first revenue milestone. I like the challenge to think about what a product could become. At the same time, a larger MRR target needs some basis: who else could benefit, how I could reach them, and whether they would keep using it. Changing the number in a goal would leave my current acquisition problem untouched.

For Brainy and MoneyBrain, I want the next milestone to answer one of those questions while leaving room for a bigger ambition.

What I want to do with the next cycle of work

My next useful step would be to give one attempt at finding users the same attention I give an implementation task. Choose a specific audience and problem, make a small attempt to reach them, and leave time to follow up with anyone who tries the product.

A short note for each attempt could record the audience, the message, where I shared it, and what happened afterward. Including the effort spent, even if no money changed hands, would give me something to compare when deciding what to repeat.

For this purpose, focusing on one product at a time would make the follow-up easier to manage. Brainy and MoneyBrain can both remain part of my work, but trying a new audience and message for both simultaneously would divide that attention. AI gives me a way to move implementation forward; I still have to make room in the week to understand the people using the result.

I would set a review point before starting. With a limited budget, I need to consider the time spent as well as the money. Continuing an experiment should depend on what I learn from it; persistence alone would not tell me whether to repeat it, change it, or stop.

That connects two pieces of advice in the screenshot: stay in the game, and consider moving on when the product does not make money. If the goal is a business, revenue and costs need an honest review. Personal usefulness can be a separate reason to maintain it, but it does not establish commercial demand. I want to give a promising idea a fair test without treating every additional month of work as evidence that it will succeed.

I still value the workflow from the previous post. It helps me turn a product idea into software I can review. With Brainy and MoneyBrain, my immediate challenge is to take the next step beyond my LinkedIn circles and learn why someone unfamiliar with me would choose to use what I built.

AI assisted with drafting and editing this post and generating the cover image.

GitHub Universe 2026: Announcements, Sessions, and My Technical Takeaways

Emanuele Bartolesi — Thu, 05 Nov 2026 12:13:42 +0000

I attended GitHub Universe 2026 in person at Fort Mason in San Francisco. The keynotes alone packed an immense amount of platform changes, but the fuller picture comes together across the 27 videos in the official conference playlist: keynotes, technical sessions, panels, and shorter videos.

Beyond the headlines of multi-model routing and agentic coding, what emerged across the stages was a fundamental restructuring of the software delivery lifecycle (SDLC). We are moving from the era of "AI writes lines of code" to "humans orchestrate agent fleets against deterministic platform primitives."

Here is my technical breakdown of the announcements and sessions that stood out, organized by architectural layer. Product availability and examples below were checked against GitHub's documentation on November 2; session lessons are attributed to their speakers.

Git infrastructure
Copilot models, context, and MCP
Stacked PRs and session continuity
Hardware hacking with Copilot CLI
Enterprise case studies
Security updates
The future of AI-assisted development
Open source and developer craft
Technical lead checklist
Catching up with Italian friends
My fifth GitHub Universe

1. The Core Platform Overhaul: Git Rebuilt for Agent Scale

The opening keynote delivered by Jay Parikh (Head of Core AI at Microsoft & GitHub) and April Leonard established the driving motivation for the platform changes: telemetry.

2026 Octoverse metric	Reported activity
Global developers	More than 225 million; one new developer every second
Code pushes	17.9 billion, more than 2024 and 2025 combined
Commits	34.3 billion, more than three times the level two years earlier
Merged pull requests	1.3 billion, around 3.5 million daily
Actions execution volume	1,440 jobs per second, about 124 million daily
Agent-started first drafts	More than 40% of PRs by September
New repositories with agent configuration files	Eight times as many commits on average as new repositories without them

The Octoverse reporting window is October 1, 2025, through September 30, 2026. The commit comparison measures activity, not productivity or a causal effect of agents.

When more than four out of ten pull requests start with an agent's first draft, the pressure reaches well beyond the editor. Every additional branch, push, and verification run depends on infrastructure that can keep up.

Next-Generation Git Architecture

April Leonard detailed the rebuild of GitHub's core Git storage subsystem, designed around three principles:

Decouple compute from storage: Azure Blob Storage holds the durable source of truth. Ephemeral serving nodes cache repository data and scale with demand.
Minimize coordination: A specialized replicated log service handles the small reference transaction that remains on the write path.
Simplify the primitives: Separate durable data from the compute serving Git operations, reducing the coordination needed as agent activity grows.

The benchmark numbers shared on stage demonstrate what this means in practice:

Write throughput: GitHub reported 7,200 writes per second with 5,000 agents targeting one repository, about 180 times current throughput.
Traffic replay: The team replayed 24 hours of traffic from its busiest open-source repository in one minute.
Rollout: GitHub expects the new architecture and broader multi-region Azure migration to reach users by early 2027. These are reported tests and rollout plans, not throughput or availability guarantees for every repository. The opening keynote and written announcement explain the work.

2. Copilot Under the Hood: Model Optimization, Context, and Protocols

Two of the most valuable breakout sessions pulled back the curtain on how GitHub optimizes models internally and connects agents to external tooling.

How GitHub Optimizes Copilot for Every New Model

In “How we optimize GitHub Copilot for every new model”, Julia Kasper explained why a stronger foundation model does not automatically produce a better coding experience when dropped into an unchanged harness.

The evaluation process continues before and after a model launches:

Offline evaluation: Benchmarks and internal use help the team assess behavior before release.
Online experiments: A/B testing and weekly reporting show how changes behave in actual use.
Model-specific tuning: The harness and product need to accommodate differences between models; model choice is only part of the engineering work.

That makes Copilot Fusion, introduced in the keynote, an interesting next step. Instead of asking developers to choose a model for every task, it chooses among three execution patterns:

Single: One model handles the task.
Cascade: A model drafts a result, a judge evaluates it, and the system can escalate to a stronger model.
Critique: Other models review a draft and their feedback informs a revision.

Developers choose Standard, High, or Max effort. Fusion respects plan and administrator model policies and bills for the models it uses; it does not itself launch subagents. For me, the useful comparison is whether that orchestration improves the result on my own repositories, at an acceptable cost.

Connecting Local Agents to External Tools via MCP

In “A pixel dog that writes songs: lessons from my first MCP server with GitHub Copilot”, independent product builder Yunika Liu showed how the Model Context Protocol (MCP) can connect a coding agent to something much more playful than a business API.

MCP gives agents a standard way to discover and call tools exposed by a server. That can mean a database or a service catalog; in this session, it meant Coco, a pixel golden retriever with a desktop presence and an LED display.

Liu described building the project in a week, connecting animation triggers, music composition, and WebSocket synchronization. It is a memorable example because the protocol serves a specific idea. For engineering leads, the same approach can expose useful internal tools to agents, but authentication, permissions, and credential handling still need to be designed; MCP does not provide those guarantees by itself.

3. Advanced Delivery Workflows: Stacked PRs GA and Cross-Surface Flow

Stacked pull requests were one of the delivery improvements I wanted to understand properly. They reached general availability on October 6, before Universe; the conference session made the review workflow concrete.

Stacked Pull Requests: Solving the Review Bottleneck

As coding agents generate features faster, human reviewers become the critical path. When an agent opens an 800-line diff across backend, database, and frontend layers, reviews stall for days.

In “How to use GitHub stacked PRs to speed up code reviews”, the team demonstrated the native workflow:

CLI stacking: Install the github/gh-stack extension, then create dependent branches with gh stack. The quickstart requires GitHub CLI 2.90 or later and Git 2.20 or later. Here is an illustrative data/service/UI stack; implement and stage each layer where indicated:

  gh extension install github/gh-stack
  # Start from your repository's current default branch.
  gh stack init
  # At the prompt, name the first branch: feature/data-schema
  # Implement and stage the data changes before committing.
  git commit -m "db: add user tenant table"

  gh stack add feature/service-layer
  # Implement and stage the service changes before committing.
  git commit -m "service: implement tenant isolation"

  gh stack add feature/ui-selector
  # Implement and stage the UI changes before committing.
  git commit -m "ui: tenant switcher component"

  gh stack push
  gh stack submit
  gh stack view

Web navigation: GitHub displays the relationships between pull requests in a stack, helping reviewers inspect each layer and understand its dependencies.

Merging from the bottom: Merge the whole stack or a contiguous group starting at the bottom, once the required reviews and checks pass. Linear-history rules apply, and some changes still require a rebase. The merge documentation describes those conditions.

One rollout detail needs care: the GA release note described staged auto-merge availability, while the merge documentation still lists it as unsupported. I would verify availability in the target repository. Agent Merge is separate and currently excludes stacked PRs.

Cross-Surface Continuity: App, IDE, CLI, Mobile, and Slack

In “Work together, your way, with GitHub Copilot”, Pierce Boggan, Burke Holland, Julia Kasper, Katie Savage, and James Montemagno explored working across Copilot surfaces.

The core architectural improvement is session persistence across client boundaries:

GitHub Copilot App & Projects: A standalone desktop app brings sessions and tools together, while Projects coordinates work across repositories. In the keynote, Burke attached design mockups and team discussions to a multi-repository feature. Projects is in public preview.
Copilot CLI (copilot): The terminal is another surface for an interactive agent session. It belongs in the same delivery workflow as the app and IDE; it is not the old gh copilot command.

Mobile and connected services: Mobile makes it possible to pick up work away from the desktop, while services such as Slack can supply context. A concrete keynote example came from Damian Brady: he started a fix on his phone and continued the same cloud session in VS Code.

4. Hardware Hacking with Copilot CLI: Event-Driven Agent State

In “Hardware hacking with GitHub Copilot: building an AI indicator lamp”, Beatris Mendez Gandica took agent interaction into physical hardware.

Using the Octolamp handed out at Universe 2025, Mendez Gandica demonstrated how to hook into the execution lifecycle of the GitHub Copilot CLI to reflect agent states on physical LEDs.

Copilot CLI Hook Architecture

The session's hook configuration used documented lifecycle events:

userPromptSubmitted: A prompt has been submitted.
errorOccurred: An error has occurred.
Stop and sessionEnd: The agent has finished responding, or the session has ended. Stop is an alias for agentStop; neither event proves that tests passed.

The hook schema uses version 1 and arrays of command objects. This example shows the wiring, not a ready-to-run lamp driver: first provide the two adapter scripts for your operating systems, accepting the states busy, error, done, and idle. They must translate those states to your device's supported API.

{
  "version": 1,
  "hooks": {
    "userPromptSubmitted": [
      {
        "type": "command",
        "bash": "./scripts/lamp-status.sh busy",
        "powershell": "./scripts/lamp-status.ps1 -Status busy"
      }
    ],
    "errorOccurred": [
      {
        "type": "command",
        "bash": "./scripts/lamp-status.sh error",
        "powershell": "./scripts/lamp-status.ps1 -Status error"
      }
    ],
    "Stop": [
      {
        "type": "command",
        "bash": "./scripts/lamp-status.sh done",
        "powershell": "./scripts/lamp-status.ps1 -Status done"
      }
    ],
    "sessionEnd": [
      {
        "type": "command",
        "bash": "./scripts/lamp-status.sh idle",
        "powershell": "./scripts/lamp-status.ps1 -Status idle"
      }
    ]
  }
}

The session also covered the less glamorous work: network problems, race conditions, and fallback states. That is part of what made the example useful. Ambient feedback can spare us from watching a terminal spinner, but the lamp still needs to behave sensibly when connectivity fails.

5. Enterprise Case Studies: Real Governance at Scale

The enterprise sessions showed how engineering organizations are applying agents to specific operational problems. The outcomes below are the speakers' reports, with lessons I would test in my own environment.

Trimble: Building a Governance Tool for 436 Repositories in Four Days

In “Four days, zero lines: the AI force multiplier with GitHub Copilot”, Jeff Doolittle of Trimble shared the story of building OSS Overseer.

The scale was 436 repositories. The problem was familiar: audits nobody runs, policies nobody enforces, and onboarding nobody automates. Writing a policy is much easier than making it part of daily repository maintenance.

Doolittle reported building OSS Overseer in four days without manually writing the code. What interested me was how the talk connected that speed to decisions about enforcement and repository-owner control.

Key takeaways from Trimble's deployment:

Human judgment sets policy: Someone still has to decide what compliance means and which actions the tool may take.
Reversible enforcement: The safeguards shown included two warnings, self-service extensions, nothing ever deleted, and dry-run behavior by default.
Self-service remediation: Repository owners need a way to respond to findings and handle exceptions without turning the platform team into a bottleneck.
Reported outcome: Doolittle described reaching 100% compliance across 436 repositories. The four-day figure refers to building the tool; it should not be read as a promise that every organization's backlog can be cleared in four days.

Slack: Turning a Personal AI Hack into an Organization-Wide Standard

In “How a personal AI productivity hack became Slack's internal tool”, Frances Coronel shared how organic developer innovation scaled into corporate infrastructure.

The problem was discovering and sharing useful AI tools across an engineering organization. A personal setup can work well for one developer while remaining invisible to everyone else.

Her catalog brought together MCP servers, skills, and Copilot agents:

Shared discovery: Give engineers a place to find reusable tools and capabilities instead of rebuilding their own collection.
Adoption visibility: Use a dashboard to understand which capabilities people are using, giving the team evidence for where to invest next.

NVIDIA: Domain-Specific AI Agents for Hardware Reliability

In “Building domain-specific AI agents for hardware reliability at NVIDIA”, Maria Victoria Gromysch described applying agents to hardware engineering and validation.

One concrete example was a Handover Agent. It gathered evidence from product communications in Microsoft Teams and Outlook, alongside factory and release data from Splunk and diagnostics. The output was a report and filed issues that engineers could act on.

The slide reported 60% less review time, faster issue resolution, and earlier detection of yield issues. For me, the practical lesson is the domain context: collecting the right evidence and making ownership clear can be as valuable as generating code. These are reported results from NVIDIA's workflow, not a general claim about predicting GPU failures.

6. Security: AI Scan, Secret Push Protection, and Package Firewalls

The GitHub Security Lab session alongside product announcements demonstrated how GitHub is hardening both code and the open source software supply chain.

Key security updates announced at Universe:

AI Scan: PR scanning adds selected languages and frameworks beyond CodeQL, including PHP, Bash, Terraform, Dockerfiles, JSP, and Blazor. Findings are advisory and cannot currently enforce a merge requirement through a ruleset; fork and Dependabot PRs are excluded. Whole-repository scanning is a separate preview, with broader language coverage. Security licensing and AI usage billing matter for adoption.
AI Push Protection for Unstructured Secrets: Pattern matching catches known token formats, but passwords and other unstructured secrets need different detection. AI push protection is in public preview, requires the relevant security entitlement and enabled settings, and consumes AI credits.
npm Package Firewall & Reachability Analysis: Package firewall applies policies when configured endpoints install npm packages. Separately, reachability analysis uses static call paths to help prioritize Dependabot alerts in JavaScript and TypeScript repositories. Both are in preview; reachability is currently a free preview for GitHub Enterprise Cloud. A potential call path does not establish production execution or exploitability.

My takeaway from putting the research session alongside these product changes is that finding more vulnerabilities creates another responsibility: give maintainers evidence they can investigate and fixes they can verify.

7. The Frontier Horizon: Where AI-Assisted Development is Heading

One of the standout panels brought together April Leonard from GitHub, Angela Jiang from Anthropic, Richard Seroter from Google Cloud, and Rohan Varma from OpenAI for “The next two years of AI-assisted development”.

Questions I Am Taking Away from the Panel

Where does human judgment matter most? That was an explicit topic of the discussion. My concern is whether a team can explain the decisions behind a change, even when an agent produces most of the code.
Where are we over- or under-investing? The panel explored that question across the AI development ecosystem. For my teams, I would apply it to verification and review capacity as well as model access.
Which skills should developers build next? The future-skills discussion is a useful prompt to look beyond prompting: problem formulation, domain knowledge, and evaluating results all deserve deliberate practice.

Humans Set Direction. Agents Close the Loop.

In “Humans set direction. Agents close the loop”, the discussion returned to the role of developers as more implementation work moves to agents.

The danger of agentic coding is unconstrained autonomous drift. When agents generate code without verification gates, technical debt accumulates faster than humans can review it.

The engineering loop I would take back to a team has three concrete boundaries:

Direction: Humans provide architectural intent, constraints, and non-negotiable boundaries.
Loop Execution: Agents explore implementations, run tests, and refine diffs inside isolated sandboxes.
Verification Gate: Passing deterministic CI tests, linting, security scans, and human code review before any branch merges to production.

8. Open Source Governance, Developer Joy, and the Craft of Code

The closing keynote and breakout tracks brought the conversation back to the human heart of software development.

Home Assistant: Building in the Open

In “Code is the easy part: building Home Assistant in the open”, Franck Nijhof explained that transparency is about decision-making, not just repository visibility.

The session followed design and architecture decisions through GitHub Discussions, Issues, and Projects. Examples included encrypted backups, the login experience, and public epics—work where the discussion matters before implementation begins.

That is the part I want to carry into team practice: make the reasoning visible early enough for someone to challenge a flawed assumption, while changing direction is still relatively cheap.

Agents in CI/CD: The CNCF & Project Bluefin Experience

In “What open source can teach us about agents in CI/CD”, Jorge Castro from the CNCF discussed Project Bluefin, Hive, and the operational work surrounding open-source development.

That work sits alongside the challenge Martin raised in the closing keynote: unsolicited, unverified AI pull requests can overwhelm maintainers. Producing more changes is only useful if the project can evaluate and maintain them.

My recommendations for applying these ideas—not a description of Bluefin's enforced policies—are:

Give agent workflows explicit permissions and spending limits.
Run appropriate automated checks before asking maintainers to review a change.
Keep human review for changes where domain judgment is essential, especially security-sensitive behavior.

What's Worth Building When AI Can Build Anything?

In “What's worth building when AI can build anything?”, the speakers tackled developer identity in an era of abundant code.

As generating code gets cheaper, choosing what to build becomes even more important. My takeaways were:

Taste and Curation: The ability to discern which problems are truly worth solving.
Problem Formulation: Asking the right questions and defining rigorous acceptance criteria.
Domain Empathy: Deep understanding of real-world human user friction.

Creative Coding, Hackable Badges, and Hardware Kits

Finally, “Why creative coding matters more than ever”, with Qianqian Ye and John Maeda, reminded developers that software is also an art form.

The discussion of p5.js, creative experimentation, and learning through making sat naturally alongside the physical hardware projects from San Francisco:

The Hackable Universe Badge: Manufactured by Pimoroni using high-speed surface-mount pick-and-place lines, powered by the Raspberry Pi RP2350 microcontroller.
Custom Mechanical Keyboard Blind Box: A hands-on keyboard assembly kit, with the PCB and mechanical parts becoming something you can build and use.

I joined the Maker activities at Universe and assembled my own GitHub keyboard. I still had a few finishing touches left when I packed up, so I finished it at the airport on my way home.

Catching up with Italian friends

I also got to catch up with some Italian friends in San Francisco. With so many sessions to fit in, seeing familiar faces was one of my favorite parts of the trip.

My fifth GitHub Universe

This was my fifth GitHub Universe, and for me it's still the best tech event in the world. I came home with plenty to try, a keyboard I finished at the airport, and another reason to look forward to the next one.

How I build products with AI: from a brainstorm to a production release

Emanuele Bartolesi — Wed, 04 Nov 2026 12:47:29 +0000

When I start a product, I open ChatGPT before I open a coding agent.

I want to work through the idea before anything starts creating files. Who needs this product? What belongs in the first version? What am I deliberately leaving out? I want to settle those questions while changing my mind still means editing a document.

Then I move between tools: ChatGPT for the requirements, Antigravity for the GitHub backlog, Copilot CLI for implementation, and Claude Code for review. I read the final pull request myself before deciding whether to merge. GitHub Actions carries the work through validation and deployment, with different triggers for previews and production releases.

I also want the same engineering setup when I switch tools or start another product. I use skills for that, and I created dotcraft, my plugin of skills and agents for .NET, Blazor, and MudBlazor. It gives me a reusable starting point instead of another setup to assemble.

My setup:

Work	Tool	Model or setting
Brainstorming and PRD	ChatGPT	GPT-6.1 Sol, high reasoning
Initial application logo	ChatGPT	PRD as context
Everyday work without a model preference	GitHub Copilot	Copilot Fusion
Epics and child issues	Antigravity with GitHub CLI	Gemini 3.8 Flash, high reasoning
Epic implementation	GitHub Copilot CLI with dotcraft	GPT-6.1 Luna (or Copilot Fusion), Max reasoning, YOLO mode
AI review	Claude Code app or CLI	Claude Opus 5.5
UI work	Copilot or Antigravity with the relevant skills	A deliberate choice: GPT-6.1 Sol, GPT-6 Astra, or Gemini Flash
Repeatable browser checks	Playwright	Automated user flows and assertions
Final review	Me	Read the code and check the behavior
Delivery and releases	GitHub Actions	CI, development previews, and production deployment

The model names will change. What I want to keep is the context: a decision made during the brainstorm needs to survive all the way to the code I merge.

Lately, Fusion is my default

I don't choose a model manually for every request. Lately, I use Copilot Fusion for most work where I don't already have a reason to pick a particular model. I give it the task and let it handle model selection.

Copilot Fusion selected at the Standard tier in my model picker.

UI work is an example of when I do have a preference: I might specifically want GPT-6.1 Sol or GPT-6 Astra. That is when I make the choice myself. For the rest, Fusion has been working very well for me, and I have found it helps keep my token costs down. I haven't measured a fixed saving per task.

I switched to Copilot Fusion recently because I was experimenting with it during the Preview (it was called HydraFusion) but I was not enthusiast about the outcomes.

I keep the model and billing details in my GitHub Copilot guide in the Resources section of my website. The named-model handoffs below describe particular parts of my workflow; Fusion is what I increasingly use between those cases.

The PRD carries my decisions between tools

My ChatGPT conversation ends with a product requirements document, or PRD, in the repository. I use GPT-6.1 Sol with high reasoning to work through the scope before asking for that document.

"Users can export their data" is the sort of requirement I want to question here. Which data? Which format? Does it include archived records? If I leave those decisions open, the implementation agent has to make them for me.

I put the PRD somewhere every tool can read it, such as docs/PRD.md. If I change a requirement, I update the file. A decision that exists only in my ChatGPT conversation is missing context for the next session.

The PRD also gives me a starting point for the initial application logo. I use it in ChatGPT to explain the product and audience, ask for a few directions, and choose one before generating the image. At this stage, I care about whether the logo works in an application header and as a small icon.

Sometimes I also use the logo-generator skill by op7418. That is a separate skill I use alongside dotcraft.

Then I open Antigravity and ask Gemini 3.8 Flash with high reasoning to turn the PRD into epics and child issues through the GitHub CLI. In my experience, this step has been accurate and inexpensive. I still check the backlog before implementation starts.

This is a reusable version of the request:

Read docs/PRD.md and the repository instructions.
Check existing issues and the applicable issue templates,
including account defaults.

Use the GitHub CLI to create epics and child issues.
Each epic needs a product outcome and scope.
Each child issue needs acceptance criteria, dependencies,
and a reference to the relevant PRD section.

Use native parent/sub-issue relationships.
Do not invent requirements or create duplicates.
Report unresolved decisions and return the created issue URLs.

I don't need to create and link every issue by hand. I do need to check that the agent has preserved the scope. A backlog full of clear titles can still describe a different product from the one I intended.

I check all the Epics and Issues anyway and I fix something if I see something that I don't really like so much.\
I like also this approach because if something that AI implement and I don't like it, I can always rework on the single task or epic using the same description and prompt.\
It helps to obtain always the same outcome.

dotcraft is how I keep my setup with me

For my .NET products, I want business logic to live in the application services and component tests to follow the same conventions. Switching from Copilot to Claude Code should not mean explaining those choices again.

That is why I created kasuken/dotcraft. It packages skills I have written, adapted, or curated from other projects, together with agents for implementation, review, and cleanup. I can maintain the shared guidance in one place and reuse it across products.

One shared setup for the .NET products I build. The repository also credits the skills' upstream sources.

For example, blazor-saas-stack describes my default architecture. bunit-testing provides guidance for component tests. dotnet-validate defines the verification expected before a change is called done. I don't want to paste all of those instructions into every implementation prompt.

The agents give the work separate roles: csharp-expert implements .NET changes, code-reviewer reads the result and reports findings, and janitor handles cleanup in small steps.

The implementation agent is instructed to validate its changes and hand them to the reviewer. Those instructions still need to be checked against what happened in the session.

In Copilot CLI, I install the plugin with:

copilot plugin marketplace add kasuken/dotcraft
copilot plugin install dotcraft@dotcraft

dotcraft also documents installation for Claude Code and Codex. Each client needs its own setup; installing a plugin in Copilot does not configure Antigravity. For Antigravity, I make the relevant skills available in a supported skill location.

The product's own instructions take precedence over dotcraft's defaults. I keep project decisions in AGENTS.md and the instruction files the client recognizes, then check that the client has found them. In Copilot CLI, /instructions and /skills list help me inspect the setup. A skill appearing in the list establishes availability; I still check that it is loaded when the task needs it.

I also maintain kasuken/.github for shared issue and pull request templates. The feature request form asks for the problem before the proposed solution. The PR checklist asks for testing evidence and includes a check that the app still works with billing disabled.
Using this approach, I don't need to configure common things in all my repos and I increase the bootstrapping of a new project.

The shared PR template gives me specific questions to ask of a change, including what happens when paid features are disabled.

GitHub supplies these supported defaults when a repository has no local equivalent. They are not copied into a clone, so a local agent may need to fetch them. I ask for that explicitly rather than assume a PR created through gh will contain the checklist.

DayPulse gave me a useful example

For DayPulse, one of my private projects, GPT-6 Sol produced the PRD and I gave it to Antigravity to create the backlog. The Today Screen epic had two child issues.

The first covered the localized date and the empty state when there was no check-in for the user's local day, with an action leading to /checkin. The second covered the completed check-in summary, including optional metrics, activities, notes, and navigation to edit or view the entry.

DayPulse's check-in screen with mood and energy selected. Screenshot from my application.

That local-day requirement is a detail I care about. "Show today's check-in" leaves room for an implementation to use the server's date. Specifying the user's local day gives me something concrete to check in the code and tests. The summary issue also explicitly required disabled metrics to stay hidden.

I handed GPT-6 Luna with Max reasoning the whole epic in one request. I then asked Claude Opus 5.5 to review the implementation across the epic; it reported no findings.

The issue completion notes recorded 253 passing tests after the first child issue and 284 in the final Release validation, with no build warnings or errors. Those are reported validation totals, including existing tests. They are not counts of tests the agent wrote for those two issues.

For me, the useful result was being able to compare the implementation with those specific acceptance criteria. A review with no findings doesn't answer whether I asked for the right product behavior.

I hand Copilot an epic with a clear stopping point

For the explicit-model implementation route described here, I open Copilot CLI with dotcraft installed, select GPT-6 Luna with Max reasoning, and enable YOLO mode. Some single-issue runs have used around 10–15 Copilot credits in my experience; that is a rough observation, not a price to budget against.

My request covers the epic and its child issues, with a separate commit for each issue and one pull request at the end:

Implement the epic at <EPIC_URL> and all its child issues.
Read the repository instructions, PRD, and applicable installed skills.
Work on a dedicated feature branch and respect issue dependencies.

Validate each child issue against its acceptance criteria.
Automate repeatable browser flows with Playwright where applicable.
Report automated coverage and anything that still needs a manual check.
Create a coherent commit for each issue and reference its URL.
Record completion and actual validation results on the issues.

Close the epic only when every child issue is implemented and validated.
Leave blocked work open and explain the blocker.

Create a PR using the applicable template, including an issue-to-commit
mapping, validation results, and remaining limitations.
Do not merge the PR.

One commit per issue lets me inspect the parts of the epic separately. In this workflow, closing the epic means implementation is ready for review; it does not mean the feature has shipped.

YOLO mode removes repeated approval prompts through Copilot's allow-all permissions. It does not make the commands safe. I am choosing to give the agent that permission, and I remain responsible for what it does.

After Copilot opens the PR, I ask Claude Code to review the implementation across the whole epic. I usually keep review fixes in that PR and rerun the affected checks if the code changes. I need validation for the version I am considering merging.

Then I read the final code myself and check the behavior against the requirements. That is where I decide whether to accept the work.

UI work gets a different route through the same process

For UI work, I want to choose the model myself when I have a particular result in mind. That might mean GPT-6.1 Sol or GPT-6 Astra in Copilot. I also use Antigravity with Gemini Flash, which has given me good UI results. I choose the tool and model for that piece of work, then return to Fusion when I have no reason to keep a specific model selected.

For the "general" UI and Design System I love the skill frontend-design because it helps AI to create the correct UI based on the context of the application and not the typical slop AI.

I bring in skills such as mudblazor-design-system, better-layout, and better-typography to make the request more specific. I also check keyboard and focus behavior. A screenshot helps me judge the layout, but I still need to use the form and see what happens in the empty state.

The requirements stay in the repository and the result still gets reviewed. Changing the tool for UI work should not mean losing the acceptance criteria I already settled.

I automate the repeatable browser checks with Playwright

I try to automate as much of the application testing as I can with Playwright. I don't want to click through the same screens manually after every change when a browser test can repeat the steps and check the result for me.

For a flow like DayPulse's check-in, I want the test to start from the empty Today screen, create an entry, verify the summary, edit the entry, and check that the updated values appear. Opening each page successfully isn't enough; the assertions need to cover the behavior in the acceptance criteria. This is the kind of repeatable journey I want automated as the product grows.

In Brainy, the CI workflow already has a separate Playwright end-to-end test job. It runs against the application with a real SQL Server database and is configured to upload traces and screenshots when tests fail. That gives me something to inspect when a browser test breaks, alongside the agent's explanation.

I still review whether the interface makes sense and explore behavior the tests don't cover. My aim is to spend that time on things that need my judgment, while Playwright handles the checks I would otherwise repeat by hand. I also review the tests: they need to fail when the expected behavior breaks.

I finish the backlog, then check the application as a whole

I repeat the implementation and review loop for the remaining epics in the release scope. Before calling that scope complete, I go back through the parent epics and their child issues. I want to see which PR contains the implementation, what was validated, and whether anything is still blocked or deliberately deferred.

An agent closing an epic is useful bookkeeping, but I still reconcile it with the merged code. If a child issue is incomplete, I leave it open. If I decide a feature belongs in a later release, I update the scope rather than close the issue as though it had been implemented.

I can ask an agent to help with that final pass:

Review the epics in the current release scope against the PRD,
their child issues, and the merged pull requests.

For each epic, report the implementation PRs, validation evidence,
and any unmet acceptance criteria. Check the child issues themselves;
do not rely only on the parent's checklist or closed status.

Close remaining issues only when the implementation and validation
support doing so. Leave blocked or deferred work open and explain why.
Report any requirements that are missing from the backlog.

Then I check the application across those epic boundaries, using automated browser tests for the repeatable journeys and manual checks for the remaining gaps. In DayPulse, the empty Today screen, the check-in form, and the completed summary need to work as one flow. Reviewing each screen separately would leave that journey unchecked.

The same applies to UI changes made late in the process: a better layout still needs to preserve navigation, validation, and the behavior described in the issues. I make corrections through the same issue and PR loop, so the fix gets reviewed too.

GitHub Actions gives me a development preview

I don't want deployment to depend on an agent remembering a sequence of terminal commands. I keep the build, test, and deployment steps in GitHub Actions so that the repository describes how the application gets published.

DayPulse is a concrete example. Its workflow runs a Release build and the test suite before the deployment job can start. For pull requests from the same repository, it is configured to publish the Blazor WebAssembly application to an Azure Static Web Apps preview environment. That gives me a development preview associated with the PR, before the change reaches production.

This is where I can check the published application in the browser. DayPulse is also a PWA, so I need to check installation, offline reload, and upgrades against a published build. The local development server alone doesn't cover those behaviors.

After I accept and merge the change, the push to main triggers DayPulse's build, test, and deployment workflow for production. Closing the PR also triggers cleanup of its preview environment. The automation handles the repeated publishing steps; I still check the workflow result and the deployed application.

Production releases have an explicit trigger

My server-hosted SaaS applications use a different production path. For Brainy, LearnStack, MoneyBrain, and Needly, I maintain a shared release workflow in kasuken/.github. Each application calls it from a small workflow in its own repository.

For these applications, merging to main runs CI without automatically deploying to production. I choose when to cut a release; GitHub Actions then handles the deployment. The distinction matters to me because several reviewed epics can belong to one release.

The release instructions let me choose a patch, minor, or major bump. For example, this starts a patch release for Brainy:

gh workflow run release.yml -R kasuken/Brainy -f bump=patch
gh run watch -R kasuken/Brainy

For that new-release path, the workflow resolves the next version, waits for passing CI on the commit being released, and builds a versioned application package. It deploys that package to Azure App Service through the GitHub production environment, using OIDC for Azure authentication.

Database changes are part of that delivery path too. Needly's migrations run before deployment; the other applications in this shared setup apply them on startup. I need to account for that difference when reviewing a release, especially if I might need to restore an earlier application version.

The workflow then checks the readiness endpoint, any configured extra pages, and the HTTP-to-HTTPS redirect. On the workflow-dispatched new-release path, it creates the version tag and GitHub release only after deployment and those smoke checks succeed. It uses the matching changelog section for the notes when one exists, or generates notes from the merged PRs.

That is another part of the setup I want to maintain once. An improvement to the shared workflow can serve several products, while the application repositories supply their own project paths and deployment targets.

After deployment, I still have a product to check

A passing readiness check tells me the application responds. I also want evidence that the user flow I intended to release still works. I use automated checks where that behavior is covered and focus my manual review on the remaining gaps. For DayPulse, the Today and check-in journey, including the local-day behavior, remains the reference for what needs checking in the published application.

If I find a problem, it goes back into an issue with reproduction steps and the behavior I expected. I can give that bounded task to an agent, review the correction, and send it through the same delivery process. The backlog remains useful after the initial implementation.

For applications using my shared release workflow, I can redeploy an earlier version tag when I need to roll back. That restores the earlier application code; it does not reverse database migrations. I need to check that the older version still works with the current schema before choosing that route.

This is where the workflow reaches a release: the code has been reviewed, the intended version has been deployed, and I have checked the relevant behavior in the running application. Closing all the epics gets me to that final check; it doesn't replace it.

I like working this way in Omarchy

In Omarchy, I keep the browser full-screen on one workspace and three or four terminals tiled on another. Copilot can be working in one terminal while I inspect tests or Git history in another. Switching workspaces and moving focus with the keyboard lets me keep those layouts in place.

Four-way tiling, shown in the official Omarchy navigation manual. This is the manual's example desktop.

I have tried to reproduce the same behavior on Windows. Getting the tiling, workspace switching, and window focus to feel the way I want has taken more effort there. On Omarchy, I spend less time rearranging the desktop.

The searchable clipboard history is useful when I am carrying an issue URL or prompt between tools. I also like the themes running through the terminal and supported agent clients. I like sitting down at this machine, and that matters when it is where I build my products.

Searching copied text, from the official Omarchy clipboard manual. The example shows how a copied command can be found again.

I still spend attention on the scope, the backlog, and the final review. dotcraft saves me from rebuilding the engineering setup, and GitHub Actions handles the repeated release steps. Neither can decide whether DayPulse should show that metric or whether a feature belongs in the first release. Those decisions are still mine, and I want to see them reflected in the application I publish.

GitHub Universe 2026: My recap from San Francisco

Emanuele Bartolesi — Tue, 03 Nov 2026 10:23:54 +0000

I'll write another post in the coming days covering the announcements. This one focuses on GitHub Universe as an event and on the two keynotes.

My updates from San Francisco
The numbers behind the changes
The Copilot app
Projects across repositories
Session continuity between tools
Copilot Automations
Review and merge
Smaller platform updates
Security
Enterprise access and budgets
Rebuilding Git
Octoverse: how developers use the tools
Closing keynote: developer joy and hardware
Protecting open-source maintainers
DevOps as a prerequisite for agents
Human judgment and speed
Chopin and collaborative planning
Science and the next generation
The closing message
What I’m taking back

I attended GitHub Universe 2026 in person in San Francisco. Between the opening keynote that laid out the architectural overhaul of GitHub and the closing keynote dedicated to the open-source community, maintainers, and developer joy, there was far too much substance to absorb from memory alone. I watched both the Day 1 opening keynote and the Day 2 closing keynote again to take detailed notes.

The second watch helped me connect the announcements across both days. In the Copilot app, Projects coordinates work across repositories while Fusion handles model selection. Automations respond to production signals, code review checks the result, and GitHub is rebuilding the Git infrastructure underneath all of it. But the closing keynote provided the essential counterweight: how open-source maintainers protect their repositories from AI pull-request spam, why DevOps maturity is the real prerequisite for coding agents, and how collaborative multiplayer planning can replace isolated single-player prompts.

My takeaway is that GitHub wants to connect the whole delivery workflow, including the parts that happen before an agent writes code and long after it opens a pull request. That is the angle I care about as a technical lead: how a feature reaches production, who decides whether it is ready, how we protect maintainers, and what the platform needs to support that work.

Two updates I shared from San Francisco

The trip also gave me a chance to share two things I had been working on myself. Alongside the keynote announcements, these were my own small Copilot updates from San Francisco.

The first was Copilot Insights 5.5.0, my VS Code extension. I added a Model Costs explorer and a token-cost estimator so developers can compare model rates and explore how different choices affect estimated AI credit usage. The estimates stay separate from actual account consumption. Hearing so much about model choice at Universe made that question feel especially relevant: what does a particular choice mean for the work in front of me and the credits it uses?

Read my original Copilot Insights update on LinkedIn.

I also shared that I had earned the Microsoft Pro Badge: GitHub Copilot - Proficient. I am not usually a big badge-sharing person, but I was happy about this one. What I like is its focus on deliberate, practical Copilot use: refactoring that preserves behavior, tests that check something useful, and less time spent on repetitive logic. That connects with what I took from both keynotes: the result still needs our attention and judgment.

Read my original badge update on LinkedIn.

The numbers explain why GitHub is changing the stack

Jay Parikh opened with the scale of activity on GitHub. The platform now has more than 225 million developers, and a new developer joined every second over the past year, for the second consecutive year.

The 2026 Octoverse report puts the rest of that activity into perspective:

Metric	Reported activity
Code pushes	17.9 billion, more than 2024 and 2025 combined
Commits across public and private repositories	34.3 billion, more than three times the level two years earlier
Merged pull requests	1.3 billion, averaging around 3.5 million a day
Public and open-source repositories	566 million, up more than 30% year over year
Public contributions	2.5 billion, up from 1.12 billion
GitHub Actions jobs	1,440 a second, or about 124 million a day, more than three times the previous year's volume
Merged Dependabot pull requests	More than 30 million, roughly twice the previous year's pace

The reporting window matters: the Octoverse year runs from October 1, 2025, through September 30, 2026. These are not totals for the full 2026 calendar year, and Actions jobs are different from Actions minutes.

Activity climbed from January and accelerated sharply around June. GitHub connects that timing with better models, stronger agent harnesses, persistent sessions that can continue across days, and more work running in cloud environments.

One comparison deserves attention: among repositories created this year, those with an agent configuration file averaged eight times as many commits as those without one. That measures activity, with some limits: commit counts do not measure useful software, and a repository without an agent file may still use AI.

Jay also called out three projects that give those numbers some purpose: Ersilia's open-source AI tools for drug discovery, OpenQuake's earthquake hazard and risk assessment software, and Matt Pocock's AI Skills for sharing instructions across coding agents. Those examples range from scientific work to improving the tools developers use every day.

From an issue to working software in the Copilot app

Jay described a delivery process where a colleague's request, a code change, or a production signal can start work at any point. Developers set direction and make decisions while agents take on implementation and verification. He organized that vision around velocity, intelligence, and quality: completing work efficiently, carrying context and learning forward, and catching defects before shipping.

Cassidy Williams made it concrete with the GitHub Copilot app and a coffee-shop application.

Her task was a Coffee Passport feature: customers visit different locations, collect stamps, and receive a reward when they complete the passport. Before implementing it, the team needed answers about what counted as a visit and what happened on repeat visits.

That is a useful place to start a demo. An agent cannot implement the right behavior if the team has not agreed on the rules.

The app brings agent sessions, issues, external tools, and project work into one desktop surface. Its canvases include a browser, a terminal, and custom views. Cassidy showed the agent interacting with the running application in a browser canvas to test the passport feature, then opened the changes in VS Code to inspect the code.

The useful part for me is that implementation and inspection remain connected. A working preview helps answer whether the feature behaves correctly; the diff still needs attention.

Connectors bring the missing context into the session

The answers to Cassidy's requirements questions came through connected services. Copilot Connectors use GitHub-managed, verified MCP connections so you can authenticate to a supported service once and use its tools across supported Copilot surfaces.

The keynote and announcement materials included services such as Slack, Work IQ, Sentry, Vercel, Netlify, and Cloudflare. GitHub also emphasized the wider ecosystem, including Datadog and Figma. The point is access to requirements, discussions, deployment information, and production signals where the agent is doing the work.

Connectors are currently in public preview. They work across supported app, CLI, VS Code, mobile, and cloud surfaces, but are not yet supported in sessions running on GitHub Actions, such as assigning an issue to Copilot. That distinction matters when adding them to an existing workflow.

Copilot Fusion chooses how to use the models

Cassidy's next question was which model to use. Copilot Fusion moves that decision into a router and orchestrator that evaluates the task and chooses an execution pattern.

The three patterns explained in the keynote were:

Single: one model handles the task.
Cascade: a model drafts an answer, a judge evaluates it, and the system can escalate to a stronger model.
Critique: other models review a draft, and their feedback informs a revision.

You choose an effort level: Standard, High, or Max. Standard targets everyday work, High adds orchestration for more substantial tasks, and Max prioritizes deeper reasoning. That is more useful to me than manually switching models for every step of a feature.

GitHub reported that Fusion Max scored 60 on the Artificial Analysis Coding Agent Index, within two points of Opus 5.5 Max, at half the cost and 40% less time per task. Those are benchmark results, so I would evaluate the same trade-off on my own repositories before assuming equivalent savings.

The Fusion documentation also clarifies that it respects plan and administrator model policies, bills for the models it uses, and does not itself launch subagents. Projects orchestration and model orchestration are separate capabilities. Users on paid Copilot plans receive a 30% discount on Fusion model costs through November 30, 2026.

Copilot Dreaming addresses instructions that have gone stale

One detail I wanted to keep from the second watch was Copilot Dreaming.

Cassidy explained that the coffee application had moved from Java to SvelteKit, while some instructions still described the old implementation. Dreaming proposed a pull request to update that guidance. She reviewed the diff as she would any other change, and also showed the memories Copilot had learned about her preferences and the team's practices. The Dreaming demo starts around 12:40.

I like this example because custom instructions require maintenance. An instruction file that describes last month's architecture can make an agent consistently do the wrong thing. Proposing an update through a reviewable change is a practical way to handle that maintenance.

Dreaming is in public preview, with plan and model restrictions: it requires GPT-6.1 Sol access, excludes Copilot Pro and data-residency environments, and consumes AI credits when it runs. Instruction-file changes arrive as pull requests; learned memories can update automatically.

Projects coordinates a feature across repositories

Burke Holland continued with Copilot Projects, using the Fourth Coffee repositories to build a feature that lets a customer reorder their usual drink with one tap.

He added the repositories as context, then supplied design mockups, a Slack discussion, and a Teams conversation with legal and compliance. The latter mattered because this was a personalization feature. He could keep adding context while work was underway, without waiting for an individual agent loop to finish.

Projects provides an orchestrator that coordinates agents across one or more repositories while keeping the goal and context together. Sessions can run locally or in the cloud, and resulting pull requests appear in the project overview. The developer can follow progress and redirect the work.

The demo also went beyond code. Burke showed short marketing videos generated with a skill, stored in the library, and described an automation to create them as new features ship. That connects implementation with another piece of delivery work that someone normally has to organize separately.

Projects was announced as available that day, in public preview. For a team with several repositories, the shared view of context, sessions, and resulting pull requests gives the feature a home beyond any individual agent's work.

The same session can follow you between tools

Damian Brady started his demo on a phone. The order-ahead feature stopped accepting orders before a cafe closed, as intended, but failed to explain that to customers.

He started a Copilot session to fix it in a cloud sandbox, then picked up the same session in VS Code. Session continuity also spans the Copilot app, CLI, and web, so changing surfaces does not require restarting the task.

Jay explained that this uses the same Copilot harness, now rolled out across Microsoft, and announced that developers could use the harness to build agents through Microsoft Foundry as well.

Damian's observation about being short on attention and time captured the practical constraint. Once the agent has a clear direction, the developer should be able to focus elsewhere and return when a decision is needed.

Automations connect production signals to repeatable work

The next demo began with a production error. The coffee site's information button returned a 500, and Damian opened the Sentry details in a custom canvas.

He could create an issue or ask Copilot to investigate. Copilot Automations turns that response into reusable work that can run manually, through an API, on a schedule, or in response to an event. Cloud execution means the workflow can continue after the laptop closes.

The controls were a substantial part of the demonstration: choose the available tools, allow an automation to create pull requests without allowing it to merge them, and set an AI credit limit. Shared automations let the team reuse that setup.

Damian also showed a group of specialist automations in a subscriptions repository. One watched for signals and created issues; others triaged them, reproduced the problem with screenshots, implemented a fix, and verified it against the original request.

That separation gives each automation a specific job and an output the next one can use. The announcements also described automations learning from outcomes and proposing improvements for review. The automation documentation confirms support for self-improving groups and configurable tools and spending limits. Changes to those workflows deserve the same review as changes to the application.

For a pilot, I would also account for the current cloud-automation requirements: an eligible paid plan, a private or internal repository, and both AI credit and GitHub Actions usage.

Review and merge have to keep up

GitHub reported that Copilot Code Review has surfaced 200 million findings since its launch. At Universe, it introduced Code Review Max, alongside Lite and Balanced, for changes that need deeper inspection.

According to GitHub, Max achieved the highest F1 score on ReviewBench for high-severity issues. My interest is in the defects a quick review can miss, such as interactions across changed files or a subtle security problem. Testing Max against a team's own review history would help establish where that deeper inspection pays off.

Damian showed Copilot reviewing a coffee-service pull request before the human review. Code Review is also available to organization members without a Copilot subscription when the organization enables paid usage; that route is currently on GitHub.com. Reviews can consume AI credits and GitHub Actions minutes. GitHub's documentation covers the review levels and access requirements.

Stacked pull requests make related changes easier to inspect

The Coffee Passport work was split into a stack: data changes, a service endpoint, and the UI that depended on them. Each part could be reviewed separately, and the stack could be merged together or in contiguous groups, starting from the bottom.

This gives reviewers smaller diffs while keeping the dependency between changes visible. Native support matters when agents can produce a large feature faster than a person can comfortably review it. The stacked pull request docs cover the workflow and the gh stack extension. Octoverse reports that the preview launched on July 30 and had been used by more than 264,000 developers by September. Stacked PRs reached general availability on October 6, before Universe.

Agent Merge helps a pull request reach completion

Damian returned to the fix he had started on his phone and enabled Agent Merge. In the demo, it handled follow-up work such as review feedback, CI failures, and conflicts in the background, with merging enabled once the requirements were met. The Agent Merge demo starts around 28:40.

That closes a gap I see in agent workflows: opening a pull request is only one stage of completing the task. Branches keep changing, checks fail, and reviewers ask for adjustments. Agent Merge takes on those follow-up changes, with repository checks and merge permissions defining when the work can land.

The current GitHub.com watch-and-fix workflow documents failed Actions checks and merge conflicts, excludes fork and stacked pull requests, and treats auto-merge as a separate setting. I would check those boundaries before expecting the whole stack to run unattended.

The smaller platform updates belong in this recap too

The Universe announcement page includes several changes that fit into the same workflow:

GitHub CLI attachments: repeatable --attach flags add local images and videos inline to issues, pull requests, and comments. A reproduction video or architecture diagram can travel with work created from the terminal.
Issue Artifacts: plans, research, links, and other artifacts stay attached to the issue, making the reasoning behind the implementation easier to find.
Repository pull request views: the updated view helps you scan open work, understand its status, and find what needs attention next.

For example, the CLI attachment workflow supports attaching more than one file:

gh pr create \
  --title "Explain when order-ahead is unavailable" \
  --body "Adds a customer-facing explanation before the cafe closes." \
  --attach ./order-ahead-demo.mp4 \
  --attach ./order-flow.png

With the files saved locally, an agent-generated screenshot or recording can become part of the review evidence, especially when it shows whether a fix satisfies the original request.

Security needs to be part of the agent workflow

Damian demonstrated code scanning findings with the location, vulnerability type, and remediation context available to Agentic Autofix. Assigning a finding produced a pull request with a proposed fix.

The broader security announcements cover different stages of the workflow, from local changes to dependency installation and pushing code.

A Security canvas for investigating findings

The Copilot app's security extension brings code scanning alerts into a Security canvas, where you can ask for an explanation, request a fix, and inspect the resulting changes. It can also review local changes before a pull request is opened.

The extension documentation makes two useful distinctions: it is in public preview, and it displays code scanning alerts rather than Dependabot or secret scanning alerts. A requested fix changes the local working copy; the usual review and scanning process still determines whether the alert is resolved.

AI Scan extends coverage beyond CodeQL

GitHub presented whole-repository scanning and assigning a backlog of findings to Copilot, as well as AI Scan coverage for pull requests in languages and frameworks CodeQL does not cover.

For the pull request feature, the docs list examples including PHP, Shell/Bash, Terraform, Dockerfiles, JSP, and Blazor. The findings are advisory and currently cannot enforce a merge requirement through a ruleset. That is a material detail for a team planning its security gates.

Push protection catches unstructured secrets

Damian pushed a local commit containing a secret and showed AI detection blocking it before it reached the repository. This extends protection to unstructured secrets such as passwords that do not match a known provider pattern.

AI-detected secret push protection is in public preview. Both push protection and AI secret detection must be enabled. GitHub documents the security licensing requirements and additional AI credit consumption, which belong in the rollout plan.

Package firewall and reachability analysis address dependency risk

Package firewall blocks malicious or risky npm packages before agents, developer tools, or CI runners install them. The public preview evaluates downloads against policies such as package age and malware advisories.

Reachability analysis helps prioritize existing Dependabot alerts by looking for call paths from application code to vulnerable dependency functions. It currently supports JavaScript and TypeScript repositories and is also in public preview.

The static analysis gives teams a call path to investigate and helps order the remediation queue. Reachability alone establishes neither runtime execution nor exploitability, so severity and other evidence still inform the priority.

Enterprise access changes, but usage still needs a budget

GitHub Enterprise customers can now access Copilot features without purchasing a separate Copilot subscription and pay for the AI credits they use. The announcement includes the app, code review, automations, and the wider Copilot feature set.

The rollout details in the announcement matter: the new route is available through GitHub Sales, self-service is coming later, and existing Copilot Business and Copilot Enterprise customers can keep their plans or move when ready.

Capability	Access or rollout detail to retain
Copilot app and Projects	App access spans Copilot plans; Projects is in public preview
Copilot Fusion	Generally available in supported clients; model and effort access follows plan and policy
Copilot Automations	Eligible paid plans; private/internal repositories for cloud execution; AI credits and Actions usage
Code Review, including Max	Organization policy can enable credit-based review for members without a Copilot subscription
Enterprise consumption route	Available through Sales; self-service forthcoming; existing plans can continue
Security canvas and Connectors	Public preview
AI Scan	Repository visibility, security licensing, settings, and usage billing affect access
AI-detected secret push protection	Public preview; requires the security entitlement and detection settings; consumes AI credits
Package firewall and reachability analysis	Public preview
Stacked PRs and CLI attachments	Stacked PRs reached GA October 6; follow the documented stack and attachment workflows

Simpler access should make adoption easier, while tool permissions and AI credit budgets give enterprise teams a way to control how that usage grows.

Rebuilding Git was one of the most substantial announcements

Jay acknowledged that GitHub had struggled with performance and reliability at points during the year. Growth explained some of the pressure; he explicitly said it was not an excuse.

GitHub reported adding four million CPU cores, 160 PB of high-speed storage, and 50 Tb/s of network capacity so far this year. It also expects to complete the broader migration to a multi-region Azure deployment in early 2027.

April Leonard then explained why adding capacity alone would not solve the Git bottlenecks. Every agent session can create branches, read history, and push changes. In September alone, developers and agents produced more than seven billion commits.

Nearly every repository had already moved to Azure, but for roughly 100 of the busiest repositories, even 25 milliseconds between data centers mattered. An initial improvement changed write coordination from locking a whole repository to locking the branch being updated. That delivered three to four times more write throughput for agents working on different branches.

The next architecture follows three principles: simplify the primitives, separate storage from compute, and minimize coordination. Azure Blob Storage holds the durable source of truth. Ephemeral serving nodes cache data and can scale with demand. A specialized replicated log service handles the small reference transaction that remains on the critical path.

The test results were substantial:

With 5,000 agents targeting one repository, the system sustained 7,200 writes per second, which GitHub described as 180 times current throughput.
GitHub replayed 24 hours of traffic from its busiest open-source repository in one minute against the new architecture.
The read load-testing harness reached its own limit before the new architecture did.

Those are reported test results, rather than a throughput guarantee for every repository. The keynote included an early-user segment with Peter Steinberger of OpenClaw, and GitHub expects everyone to move to the new architecture by early 2027.

The infrastructure work also includes an AI gateway processing trillions of tokens, prompt caching and harness improvements, more Actions capacity and control-plane hardening, additional network edge sites, four times the backhaul between legacy data centers and Azure, and TLS optimizations. The keynote recording covers the infrastructure section, alongside GitHub's written announcement.

This is the dependency behind the earlier demos. Coordinating agents becomes much less useful if they spend their time waiting on Git, CI, or platform availability.

Octoverse shows how developers are using the tools

The rest of the Octoverse report adds context that I did not want to lose in a keynote-only recap.

Agents are increasingly producing the first draft

By September, more than 40% of pull requests started with a detectable agent's first draft, up from 17% in March. That amounted to around 110 million in September alone.

About 87% of agent-started pull requests changed multiple files, compared with 79% of those without detected agent involvement. The share of agent-involved PRs merged within two weeks rose from 83% in February to 90% in September; the comparison group remained around 86%.

Among Copilot's monthly active users, 55% used agentic features, up from 35% a year earlier. Cloud agent usage grew 230% year over year, compared with 85% for agent chat. These figures describe observed workflows, and undetected agent use can still exist in the comparison group.

Review and security activity grew alongside implementation: AI-assisted review and GitHub Advanced Security usage each increased by more than 90%, while push protection ran 5.8 billion scans, nearly four times the previous year's pace.

Model choice is already plural

In September, 61% of Copilot users who explicitly selected models used more than one, up from 50% four months earlier. Developers on paid plans used 47 distinct models, compared with 29 in May, and no model accounted for more than 25% of qualifying requests.

The report groups examples by their intended role:

Model group	Examples in the report
Deep reasoning and planning	Claude Opus 5.5, GPT 5.5
General purpose	Claude Sonnet 5, Grok 4.7, GPT 6.1 Sol
Fast and lightweight	Claude Haiku 5.5, Gemini 3.8 Flash, GPT 6 Luna

Of every 100 developer-selected requests, 38 went to general-purpose models, 37 to reasoning and planning models, and 25 to lightweight models. This analysis excludes automatic selection and several other kinds of traffic; it describes usage rather than model quality.

Separately, 63% of paying Copilot developers used automatic model selection at least once in September. Project HydraFusion, the research preview behind Fusion, routed almost 60,000 sessions. That helps explain why GitHub is investing in choosing models on the developer's behalf while preserving explicit selection.

Growth reaches more countries and industries

The ten largest developer populations in September were:

Country	Developers on GitHub
United States	38.3 million
India	32.0 million
China	12.4 million
Brazil	10.2 million
Japan	7.15 million
United Kingdom	6.47 million
Indonesia	6.34 million
Germany	6.30 million
Russia	5.07 million
France	4.75 million

The United States and India each added more than ten million developers, and Brazil added 3.28 million. Every country included in last year's projections had already closed at least 20% of the distance to its 2030 projection; the US had closed 38.6%, and India 28.3%.

For pushes to public repositories, the top ten were the United States, India, China, Brazil, Germany, the United Kingdom, South Korea, France, Japan, and Canada. That is a different ranking from total developer population.

The new industry analysis uses NAICS classifications of public repositories. Mining, construction, healthcare, and agriculture have grown substantially since 2022. More than 40% of repositories in administrative services, mining, healthcare, and agriculture mentioned AI, but detectable agent-opened pull requests were below 3%. Construction had about 25% mentioning AI and around 9% with agent-opened PRs.

The distinction between AI mentions and agent-opened PRs keeps two different kinds of adoption visible. The report's wider examples include disaster alerts in Nepal, spacecraft software, research tools, and industrial energy analysis. There is useful software here well beyond developer tooling.

Language choices may also reflect agent defaults

TypeScript remained first by contributors, followed by Python and JavaScript. Between September 2025 and September 2026, they added 3.62 million, 3.23 million, and 1.82 million monthly contributors respectively. Rust doubled its contributor base, the fastest percentage growth among the leading languages.

GitHub's forecast puts TypeScript and Python near 13 million monthly contributors each by September 2027.

The report also raises the possibility that agent defaults influence language choice. Among new repositories, TypeScript was the primary language in 35% of those with an observed agent signal, compared with 24% without one. For me, that reinforces the value of specifying language and architectural constraints when starting a project with agents.

Open source supplies both the foundations and the tools

Octoverse separates community and independent projects from single-vendor or product-led repositories. The distinction is strategic control, not whether the project receives community contributions.

These are the complete fastest-growing lists by increase in contributing accounts:

Rank	Community or independent	Single vendor or product-led
1	`farion1231/cc-switch`	`anthropics/claude-code`
2	`punkpeye/awesome-mcp-servers`	`openai/codex`
3	`omacom/omarchy`	`anomalyco/opencode`
4	`firstcontributions/first-contributions`	`microsoft/vscode`
5	`ggml-org/llama.cpp`	`github/copilot-cli`
6	`EclipseFdn/open-vsx.org`	`zed-industries/zed`
7	`sgl-project/sglang`	`google-gemini/gemini-cli`
8	`vllm-project/vllm`	`BerriAI/litellm`
9	`imputnet/helium`	`microsoft/winget-pkgs`
10	`vllm-project/vllm-ascend`	`Kilo-Org/kilocode`

The most-engaged ranking combines stars, forks, and distinct pull request and issue creators:

Rank	Community or independent	Single vendor or product-led
1	`openclaw/openclaw`	`NousResearch/hermes-agent`
2	`vllm-project/vllm`	`anomalyco/opencode`
3	`ggml-org/llama.cpp`	`earendil-works/pi`
4	`omacom/omarchy`	`stablyai/orca`
5	`farion1231/cc-switch`	`pingdotgg/t3code`
6	`sgl-project/sglang`	`microsoft/vscode`
7	`pytorch/pytorch`	`Graphify-Labs/graphify`
8	`rust-lang/rust`	`paperclipai/paperclip`
9	`home-assistant/core`	`BerriAI/litellm`
10	`python/cpython`	`can1357/oh-my-pi`

Inference engines, runtimes, and community platforms sit alongside the agents and editors developers use directly. Both depend on people maintaining code that other projects build on.

The closing keynote: Developer joy, hackable hardware, and the human side of AI

While Day 1 focused on platform architecture, enterprise governance, and Git throughput, the final keynote of Universe 2026 brought the conversation back to where GitHub began: open source, community maintainers, and the joy of building software.

Martin Woodward opened the final session by acknowledging the emotional reality of 2026: with new frontier models shipping every few weeks and telemetry breaking records everywhere, developers are feeling the pace. His answer to feeling constantly out of date is simple: learn by doing.

The hackable badge and culture when no one is looking

The centerpiece of that hands-on ethos was the physical conference badge every attendee wore in San Francisco. Built in partnership with Arm, the 2026 badge is an astonishing piece of hardware: a dual-core Raspberry Pi RP2350 Cortex processor packed with an accelerometer, environmental sensors, Bluetooth radio, and a color screen running MicroPython.

Martin shared an unscripted story behind the badge that stuck with me. During the 2025 conference, a typhoon struck a component supplier and global supply shortages delayed screen deliveries until the night before the event. Rather than canceling the badge giveaway, GitHub engineers, managers, and community members spent the entire night in the San Francisco office hand-assembling boards and soldering screens so attendees could pick them up at 8:00 AM.

As Martin put it: "Culture is what happens when no one is looking." For all the enterprise features and cloud scale discussed this week, that community-first startup spirit is what still makes GitHub distinctive.

From web simulation to MicroPython in the Copilot app

To make sure attendees without hardware or developers watching the livestream could participate, GitHub published a complete web simulator for the badge. It was built by a summer intern, Charlie Nicholson, who used the simulator framework and around $95 in Copilot credits to create an emulator capable of running games like Flappy Mona directly in the browser.

Martin then took the badge project into the GitHub Copilot app. In a live canvas connected to the badge repository, he showed a Breakout game that he said he had created with a single prompt.

The technical detail that matters here is not the prompt; it is the harness. Martin explained that the Copilot app canvas could access the MicroPython debugging environment, letting the agent inspect execution and debug the game. That gave it a verification loop beyond simply generating code.

As Martin noted, that tight verification loop is the difference between an agent producing broken syntax and an agent delivering working software.

Edge ML on stage: Training a decision tree in the browser

Martin followed the Breakout demo with an edge machine learning application: building a pedometer for the badge without prior ML expertise.

He streamed raw accelerometer telemetry from the badge over Bluetooth into a browser canvas. On stage, he gathered live training samples across distinct motion states: standing still, walking normally, and swinging his arms with "big keynote energy" (or as he joked, "the walk of someone who just merged to main on a Friday").

Using a browser-based training loop, he trained a decision-tree classifier on the accelerometer dataset and deployed the resulting model directly back to the badge firmware over Bluetooth. The badge successfully distinguished actual walking from arbitrary gestures in real time.

It was a playful demo, but it demonstrated a practical point: agent tooling can give a developer a way into unfamiliar domains—like embedded edge ML—through experimentation. The learning still comes from collecting data, testing the result, and understanding where it fails.

Open source under AI pressure: Maintainer fatigue, pull request slop, and new defensive controls

The keynote then transitioned into the hardest conversation happening across the industry: what happens to open-source maintainers when coding agents make creating pull requests essentially free?

Octoverse reported that over 40% of all pull requests on GitHub now begin with an agent's first draft, up from 17% in March. While that speed accelerates prototyping, Martin acknowledged the painful downside: "Not all those PRs are diamonds. Just because it's easier to create than ever doesn't mean what you have is ready to commit. Some are just bad ideas. Some are barely ideas at all. You know, slop."

Traditionally, open source functioned because coding had inherent friction. Contributors had to spend time understanding the codebase, learning the project's culture, reading documentation, and following contribution guidelines before submitting code. That friction acted as an organic quality filter.

Coding agents have largely eliminated that barrier. Well-meaning contributors now use agents to generate pull requests and shallow security reports across dozens of repositories without reading the project guidelines or verifying the fix. For open-source maintainers—most of whom volunteer their free time after work—wading through low-effort AI contributions has become an exhausting, unpaid burden.

Maintainer guardrails: WIP limits, contributor exemptions, and PR access

To protect maintainers, Martin highlighted repository controls designed to restore balance. Some predate Universe; the latest update adds more flexibility over who is subject to limits:

Work-in-progress (WIP) limits per repository: Maintainers can cap open pull requests from users without write access, encouraging contributors to finish an existing change before opening another.
Exemptions for established contributors: The October 28 update allows exemptions based on account age or prior merged pull requests. Meeting either configured condition can exempt a contributor. This is separate from temporary interaction limits.
Control over pull request access: Since February, maintainers can restrict PRs to collaborators or disable them. Disabling PRs hides the PR tab, including existing pull requests; re-enabling restores access. It is more than a pause on new submissions.

Martin framed this policy change around a clear boundary:

"Open source is the freedom to inspect, to remix, and to share without asking for permission. But it's not the freedom to impose your will on others."

As a technical lead who manages both internal shared code and public open-source libraries, I see these controls as long overdue. If platforms do not give maintainers tools to protect their time, maintainers will simply walk away.

Why DevOps is the real prerequisite for AI agents

While unguided AI generation strains maintainers, the keynote showed that maintainers with mature operational pipelines are using agents effectively.

Martin recognized Franck Nijhof from Home Assistant in the audience and reported that the project had merged more than 5,000 pull requests. He also described GitHub's support for Copilot agents across the Cloud Native Computing Foundation (CNCF) ecosystem.

Martin recounted a telling example from Jorge Castro around OpenPrinting. The OpenPrinting maintainers possess deep, specialized knowledge of printer drivers and protocols, but their primary pain point was infrastructure: managing container refreshes, keeping dependencies current, and maintaining CI/CD pipelines across multiple architectures. He described the Hive automation framework taking on operational maintenance across four OpenPrinting repositories, freeing the domain experts to focus on the driver code they enjoy.

That example reinforces a foundational truth: teams that do DevOps well are the best equipped to take advantage of AI.

The automated checks, strict linting, integration suites, and branch protections you build to let human developers ship quickly are the exact same safeguards an autonomous agent needs. An agent running in a repository without automated testing or clean CI is just an engine for accumulating unverified changes.

Actions continues to be the backbone of that verification. According to the published Octoverse report, Actions executed 1,440 jobs per second (about 124 million daily) over the reporting year—more than three times the previous year's volume.

The limit of pure speed: "Why they call it work"

Martin addressed the temptation to treat raw coding speed as the sole metric of success:

His point was that shipping faster only helps if we are building the right things. Humans still need to understand the problem, direct the work, and reflect on whether the result makes things better or worse. Defining what good looks like remains part of the job; the agent cannot take that responsibility away.

That judgment also reflects how developers interact with models. The telemetry shows that developers are not relying on a single frontier model. Of every 100 developer-selected requests, 25 went to fast, lightweight models (such as Gemini 3.8 Flash, Claude Haiku 5.5, or GPT-6 Luna), while 37 went to reasoning models and 38 to general-purpose models. These figures exclude automatic selection; they are request shares, not a breakdown of all developer tasks.

Choice also extends to editor surfaces. Copilot usage spans the terminal, CLI, Copilot app, web, mobile, VS Code, Visual Studio, Eclipse, and IntelliJ. Native Copilot integration has also expanded to Apple's Xcode following announcements at WWDC.

GitHub Next and Chopin: Rethinking collaborative planning with agents

One of the most compelling segments of the closing keynote came from Maggie Appleton, designer and engineer at GitHub Next (GitHub's advanced research and prototyping lab).

Maggie tackled a problem every engineer using coding agents has experienced: agent planning today is broken.

Her critique targeted four specific failure modes:

The multiple-choice interrogation: Planning typically happens in a tiny terminal CLI or desktop chat box, subjecting the developer to an endless sequence of multiple-choice questions. By question nine, cognitive fatigue sets in and the developer defaults to clicking "Option A (Recommended)"—what Maggie called vibes-based decision making.
Text walls: Once the questionnaire concludes, the agent spits out pages of dense markdown. Reading walls of technical text is tiring, and subtle architectural errors get buried.
Single-player isolation: Today's agent sessions are private 1-on-1 conversations between an individual engineer and an LLM. Teammates cannot see the plans being generated or the architectural trade-offs being accepted.
The PR is too late for feedback: Because engineers lack collaborative planning tools, they default to letting the agent implement the entire feature and opening a pull request to get feedback from teammates. But a pull request is way too late in the lifecycle to ask: "Should we even build this?" or "Is this the right backend architecture?" Rewriting or discarding code after tokens have already been spent is pure waste.

The Chopin prototype: Multiplayer canvases, proactive research, and decision audit logs

To solve this, GitHub Next built Chopin, an experimental prototype named after the composer Frédéric Chopin.

Chopin re-imagines agent planning as a real-time collaborative workspace where multiple human developers and an intelligent agent work together inside the same document:

Shared context: The planning canvas is connected directly to the repository and open to the entire team. Multiple engineers can chat, write requirements, and refine specifications simultaneously.
Proactive agent research: Rather than waiting passively for instructions, the Chopin agent reads the team's discussion and anticipates needs. When Martin and Maggie discussed using Bluetooth versus Wi-Fi for their multiplayer badge game, Chopin proactively researched Bluetooth LE range limitations, synthesized the technical trade-offs, and generated inline dataflow diagrams explaining how synchronization would work.
Visual prototypes over text walls: When debating user interfaces, Chopin generated interactive, clickable mockups showing different states (such as an animated landscape game view versus a large accessible counter). Engineers can click through states before any production code is written.
Decision cards with attribution: The demo captured choices as decision cards. When Maggie or Martin selected an option, the document recorded who made the decision and when. If a developer asks two months later why a specific approach was chosen, the record gives them someone to ask and the surrounding planning context.
Direct conversion to tasks: Once the team agrees on the plan, Chopin breaks the work into modular implementation tasks and opens corresponding pull requests.

Maggie and Martin then tried the collaborative 10,000-step game on their badges. After moving closer together, the demo reached its shared goal—a suitably hands-on ending to a discussion about planning.

For engineering teams, this approach feels far healthier than isolated agent prompting. It brings software planning back to what it should be: a collaborative team activity where agents assist research and visual prototyping, while humans make and own the decisions.

Software beyond tech: Science, low-level systems, and the next generation

The keynote also explored how open-source practices are transforming disciplines outside traditional commercial software.

Professional, scientific, and technical services have grown fivefold on GitHub, becoming the leading open-source growth sector outside of core tech. Research repositories have quietly become the verifiable paper trail behind published academic literature.

To support researchers, GitHub highlighted native Citation support (enabling standard academic citations directly from repositories) and ORCID ID integration to link software artifacts to verified researcher identities.

The GitHub Campus Program now spans nearly 2,500 academic institutions across 60 countries, supported by more than 100 active Campus Experts and 500 alumni helping students navigate git, AI tools, and open source.

Martin invited Jocelyn Velarde, a visiting undergraduate researcher at the UC Davis Neuroprosthetics Lab and an MLH coach, to share her path through open source.

While still in high school in Monterrey, Mexico, Jocelyn cold-emailed Dr. Miriam Alanis at Tec de Monterrey and built an EEG-controlled brain-computer interface (BCI) robotic hand prosthetic using Linear Discriminant Analysis (LDA) machine learning.

Today at UC Davis, she works on the "Brain to Voice" project, decoding neural signals to restore real-time speech for ALS patients. Her specific technical focus is low-level systems engineering across heterogeneous compute platforms to minimize audio streaming latency—work that requires deep hardware and systems understanding.

Her advice to aspiring engineers was simple and practical: set clear goals, find supportive communities (such as Campus Experts and MLH), and do not hesitate to reach out to mentors directly.

The closing message: You write the story

The final keynote ended with characteristic hacker playfulness. Martin placed his badge inside a plushie "Ship It" squirrel, trained gesture-recognition models on stage to detect throws and drops, and invited the audience into a live airtime contest, tossing Mona, Copilot, and Octocat plushies across the hall while the badges tracked airtime.

Underneath the fun was a serious message for developers:

Martin said AI makes it easier to create applications we previously lacked the time or skills to build. He asked us to broaden the circle of people we learn from, push the boundaries of what we know, and learn by doing. Creativity, judgment, and taste remain ours to bring.

"In this new era, AI doesn't write the story. You write the story."

What I am taking back from Universe

Jay Parikh opened Universe with the claim that all the software written so far might amount to just 1% of what humans and agents build over the next five years. Martin Woodward closed it by reminding us that without human judgment and heart, building faster just means accumulating unverified slop.

Across both keynotes, the real narrative of Universe 2026 was not that agents are replacing developers. It was that GitHub is evolving every layer of the delivery pipeline to make agent-assisted engineering manageable, accountable, and sustainable.

Day 1 provided the technical machinery:

Copilot Projects to coordinate features across repositories.
Copilot Fusion to handle multi-model routing across reasoning, general, and fast tiers.
Rebuilding Git from the ground up, with a reported test sustaining 7,200 writes per second from 5,000 agents targeting one repository.
Automations and Code Review Max to catch regressions and security vulnerabilities before shipping.

Day 2 provided the operational principles:

Protecting maintainers from automated spam with WIP limits and interaction gates.
Recognizing that DevOps and CI/CD maturity are strict prerequisites before deploying agents at scale.
Moving planning out of private terminal questionnaires into multiplayer collaborative canvases like Chopin.
Anchoring delivery in tight verification loops and human accountability.

For my own teams and clients, I am taking back a clear implementation checklist:

Pilot a multi-repo feature with Copilot Projects: Choose a bounded feature spanning two or three services. Set explicit AI credit budgets and tool access, and follow the work from initial issue through review and merge.
Harden the verification gate before scaling agents: If a repository does not have automated linting, appropriate unit and integration tests, and clean CI checks, do not give an agent merge permissions. The OpenPrinting example reinforced why operational maintenance belongs alongside the agent rollout.
Turn on repository guardrails: Configure appropriate limits for outside contributors, with exemptions that fit the community, to encourage focused contributions and prevent maintainer fatigue.
Bring planning into the open: Stop letting engineers plan complex features in private 1-on-1 LLM prompts. Use shared specs, visual mockups, and explicit decision records so the whole team understands what is being built and why.

Tools like Fusion, Automations, and Chopin will continue to evolve. But the fundamental responsibility of an engineering lead remains unchanged: define what good looks like, establish the safety rails, and ensure that every decision that reaches production can be explained by a human.

Thanks for reading this post, I hope you found it interesting!

Feel free to follow me to get notified when new articles are out 🙂

Emanuele BartolesiFollow

🏆 Microsoft MVP (12x) & GitHub Star (4x) ⭐ 👨‍🎓 LinkedIn Technical Instructor 🎓

Seasoned Developer Advice after 25 years in IT

Emanuele Bartolesi — Fri, 09 Oct 2026 10:09:24 +0000

I've now been working in IT for exactly 25 years.

My impostor syndrome is still very much present. Writing an article called "seasoned developer advice" makes me hesitate a little. There is always something I don't know, a technology I haven't used, or someone who understands a subject much better than I do.

But after 25 years, I think I can start sharing a few thoughts.

These are opinions about how to work, build software, and stay in this profession. Take what helps, question the rest, and adapt it to the team and situation you have in front of you.

Ask the question you are embarrassed to ask

If a requirement is unclear, ask about it before you turn it into code.

What does "active customer" mean? Who can approve this operation? What should happen when the external service is unavailable? These questions can feel basic, especially when everyone else in the meeting appears to understand everything.

I would rather admit that I don't understand a business rule than build an entire feature around my interpretation of it. The same applies to an unfamiliar piece of code. Ask someone to walk you through it, then explain it back in your own words.
This step is even easier with AI nowdays, but asking a colleague still an easier thing to understand maybe something that AI doesn't know behind a business choice or something like that.

Experience should make it easier to say "I don't know yet." I still have to remind myself of that.

Give coordination an owner

Developers need time to develop. If the lead developer also has to chase every dependency, negotiate the scope, update stakeholders, and organize the release, account for that work in the plan.

On a larger project, I would want someone explicitly responsible for coordination. That might be a project manager, a delivery lead, or another role that fits the organization. On a small team, it may be a shared responsibility, but the decisions still need an owner.

A date written in a ticket does not resolve a blocked dependency. Someone has to talk to the other team, agree on what happens next, and adjust the plan when the answer changes.

When estimating a feature, include that work. A week full of meetings leaves less time for implementation than a week with clear decisions and uninterrupted time.
Actually we are still doing this mistake to "overmeetings" but I hope it will change soon or later.

Make meetings earn their place

I don't think every team needs the same meeting schedule.

A short conversation with the person who understands the business process can be useful while a feature is taking shape. Showing a working screen may reveal that the approval flow is wrong before you spend another week building it.

A daily meeting where everyone reads out tickets already visible on the board is harder to justify.

For me, a useful meeting resolves a question, exposes a dependency, or produces a decision. If an update can be written down and read when people have time, try that. If a disagreement needs a conversation, have the conversation.

Record the outcome where the work lives. A decision made on a call is easy to miss if the developer implementing it was somewhere else.

Write code for the person who has to change it

Readable code matters most when someone needs to fix it under pressure.

I prefer a method with a clear name and an obvious flow over an abstraction that takes three files to understand. There are good reasons for abstraction, but I want to know which problem it solves before adding another layer.

The same caution applies to shared code. Two methods that look similar may represent business rules that will evolve independently. Putting them in one common library creates a relationship you will have to maintain.

Extract code when the shared behavior is understood. If several applications depend on it, think about compatibility, ownership, and how updates will reach them. Publishing a package creates a responsibility beyond the original project.
Still a valid advice also for we use a lot of AI for writing code.
We need anywayt to review what is written to understand if we can read and understand the code anyway.

Leave the explanation you would want to find later

Code can show what happens without explaining why it must happen that way.

A comment explaining that a file format is required by an external system is useful. A comment saying that the next line increments a counter usually adds little.

I want documentation that helps someone do the work: how to run the application, which configuration is needed, how to execute the tests, and what to check when a deployment fails. Keep those instructions close to the repository and update them when the workflow changes.

There is also value in a short decision note. If the team rejected a queue because the current workload did not justify operating one, record that reasoning and the condition that would make you reconsider.

AI can help draft these explanations. Check them against the code and the actual setup before treating them as documentation. A plausible installation guide that cannot be followed is another problem for the next developer to debug.

Think about the application after it leaves your machine

A feature needs more than a successful local run.

Before shipping, I want to know how we will recognize a failure and what we can do about it. A useful log entry should give enough context to trace an operation without exposing credentials or customer data. An exception with no context can leave you searching through several unrelated requests.

Be deliberate about tests, too. If a feature moves data between customers, test that boundary. If it sends notifications, consider what happens when an operation is repeated. The failure case should influence the test, rather than becoming an afterthought once the happy path passes.

And discuss recovery. Reverting code will not undo every effect of that code. A database change or an email already sent needs its own consideration.

These questions belong in development, while you can still change the design without an incident forcing the decision.

Review the code without making it personal

Having someone question your implementation can be uncomfortable. With impostor syndrome already in the room, a review comment can feel larger than it is.

Try to keep the conversation specific. Explain which behavior concerns you, point to the assumption, and suggest a way to verify it. "What happens if this request is retried?" is a useful opening for a discussion.

As the author, explain your reasoning and be willing to change it. As the reviewer, distinguish a defect from a preference. A naming choice does not deserve the same treatment as a missing authorization check.

I also like reviews small enough that a colleague can understand the change properly. If a bug fix includes a folder reorganization and a new framework, consider separating those decisions.

The goal is a change the team understands well enough to maintain. Being the person who wins the argument contributes very little to that.

Make maintenance part of the plan

Framework upgrades, dependency updates, and refactoring need time on the calendar.

It is easy to postpone them because the application still works. When you do, be explicit about what you are accepting and when you will revisit it. Otherwise, postponement becomes the plan by default.

A refactoring ticket should name the problem it will address. Perhaps adding a validation rule currently requires changing five different places. That gives the team a concrete improvement to assess and a way to tell whether the work helped.

I would apply the same discipline to modernization. Explain what the upgrade enables, which risk it addresses, and how you will validate the change. The age of a framework alone is a weak explanation for rewriting a working application.

Keep learning through things you can use

You cannot study every language, framework, cloud service, and AI tool that appears.

Choose something relevant and spend enough time with it to understand where it helps. Build a small application, add a feature to a side project, or investigate a part of your production system that you usually avoid.

A course can give you structure. Applying the lesson gives you questions the course may never have covered.

I would also leave room to learn from colleagues. Someone with less experience may know a tool or technique you have never used. Twenty-five years in IT should not make that conversation awkward.

Your main language is useful expertise. Stay curious about the parts around it: the database query, the deployment pipeline, or the interface the user has to navigate. A problem does not stop at the boundary of your preferred stack.

Choose tools you can trust and understand

Use an editor that lets you work comfortably. Learn its debugger, navigation, and refactoring tools before assuming a different editor will solve your frustration.

I would take the same approach to AI. Start with work where you can judge the result: exploring unfamiliar code, preparing a first test draft, or checking an implementation for missed cases.

Read the output and run the checks. When the tool proposes a design, ask what assumptions it made. You remain responsible for the change you submit.

Trying another tool or model can be useful when it answers a specific question about your workflow. You don't need a collection of subscriptions just to feel current.

Build a way of working you can keep doing

After 25 years, I want my advice to include what happens away from the keyboard.

Take breaks. Get up, walk around, do sports, and give yourself permission to stop staring at the same problem. If you are stuck, ask for help rather than making another exhausted hour the price of proving that you can solve it alone.

Talk to teammates sometimes without a ticket as the agenda. It is easier to ask someone a difficult question when your only interaction with them has not been a review disagreement.

And keep something outside work. There will always be another release, article, framework, or project. Closing the laptop does not mean you stopped caring about your profession.

I still don't feel that 25 years gives me an answer to everything. It does give me enough reason to share these thoughts, even while the impostor syndrome tells me to wait a little longer.

If you enjoyed this blog post and want to learn more about C# development, you might be interested in subscribing to my bi-weekly newsletter called Dev Dispatch. By subscribing, you will get access to exclusive content, tips, and tricks, as well as updates on the latest news and trends in the development world. You will also be able to interact with me, and share your feedback and suggestions. To subscribe, simply navigate to https://buttondown.email/kasuken?tag=devto, enter your email address and click on the Subscribe button. You can unsubscribe at any time. Thank you for your support!

My Windows 11 Laptop Was Struggling with Claude and Codex. Defender Exclusions Helped.

Emanuele Bartolesi — Tue, 06 Oct 2026 15:01:47 +0000

My Windows 11 laptop sometimes struggled while I was working with Claude and Codex or GitHub Copilot. CPU usage was high, and the fans were running like crazy.
It means also that my battery runs out in 1 hour and 30 minutes 😀

When I checked Task Manager, Antimalware Service Executable stood out. Disk usage was around 90%, with heavy CPU activity as well, while the two tools were running.

That process belongs to Microsoft Defender Antivirus. You can find it as Antimalware Service Executable in Task Manager's Processes tab, or MsMpEng.exe in the Details tab. Microsoft documents both names here.

I suspected Defender's scanning of the tools' local folders was contributing to the slowdown. Adding folder exclusions solved the problem I was seeing on my laptop. This is my experience with one machine, rather than proof that Claude or Codex always causes this behavior.

The folders I excluded

These are the four entries in my Windows Security exclusion list:

C:\Users\barto\.claude
C:\Users\barto\.codex
C:\Users\barto\.copilot
C:\Users\barto\.github-copilot-cli

The last two entries are for my Copilot tooling. Their presence in this list does not establish that they contributed to the Claude and Codex slowdown.

There is a security tradeoff: a folder exclusion removes Defender antivirus scanning coverage for that folder and its contents. Files placed there later are also covered by the exclusion. Trusting the tool does not guarantee that every file it writes or downloads is safe. Microsoft explains the exclusion options and risks.

Treat this list as a record of my setup. For your machine, identify the affected folder first and keep any exclusion as narrow as possible.

How to add a folder exclusion in Windows 11

Open Start, search for Windows Security, and open it.
Select Virus & threat protection.
Under Virus & threat protection settings, select Manage settings.
Scroll to Exclusions and select Add or remove exclusions. Approve the administrator prompt if it appears.
Select Add an exclusion, then Folder.
Browse to the folder you want to exclude, for example C:\Users\YOUR_USERNAME\.claude, and select Select Folder. Replace YOUR_USERNAME with your Windows user folder name.
Confirm that the folder appears in the exclusion list. Repeat for other folders only where needed.

These steps follow Microsoft's Windows Security guidance. On a company-managed laptop, your IT team may control these settings.

Moving to European Digital Services, One Decision at a Time

Emanuele Bartolesi — Thu, 24 Sep 2026 16:13:19 +0000

My move to European digital services includes Proton, Qwant, and DeepL. When it came to Notion, I went further and replaced it with Brainy, the product I built for my own notes, projects, and tasks.

That sounds like a migration, but the word creates the wrong expectation. I did not spend a weekend exporting every account, cancelling every subscription, and declaring myself independent from American technology on Monday morning.

I am changing one decision at a time.

I do not want a US provider to be the automatic answer for every digital need simply because it is the most visible option. Europe has credible products. Some are good enough to compete directly, and some fit my needs better. That does not mean I will replace a working service because a company has the wrong flag beside its logo.

Proton made the change visible

Proton is where the migration became a system rather than a few unrelated experiments.

Proton Mail replaced my previous email setup. Proton VPN replaced NordVPN. Proton Pass replaced NordPass. I also use Lumo for selected private AI conversations rather than treating every chat as suitable for any general-purpose assistant.

The immediate benefit was consolidation. One privacy-focused Swiss ecosystem replaced several separate accounts and subscriptions. I did not need to find a different European company for email, another for passwords, and another for the VPN before making progress.

There is an obvious trade-off: consolidation reduces vendor sprawl while increasing dependence on Proton. Moving three services into one company is not diversification. I still prefer the current setup, but it would be dishonest to describe concentration as independence.

Lumo has a similar boundary. Proton says stored conversations use zero-access encryption, which is why it has a place in my private workflow. I do not pretend that it replaces every AI service or every model. The choice depends on the conversation and the job I need to complete.
For the moment I am using Lumo only for questions related my health and other sensitive information.

The corporate map is more complicated than the logos

Once I started checking where services were based, the simple Europe-versus-USA story stopped working.

NordVPN is not an American service. NordVPN says it is based in and operates under Panama's jurisdiction, while its parent company, Nord Security, is based in the Netherlands. Moving to Proton VPN is a Panama-to-Switzerland change at the service-jurisdiction level, with a European parent company also involved in the old setup.

WeTransfer is European too. WeTransfer B.V. is based in Amsterdam, so my switch to SwissTransfer was not about escaping an American company. It was about the product.

For my file-sharing needs, SwissTransfer has a privacy model I prefer and a much more useful free allowance for large files. Infomaniak says SwissTransfer accepts transfers up to 50 GB, stores the files in Switzerland, supports password protection, and deletes the files after the transfer period. WeTransfer's current free-account documentation describes an allowance of up to ten transfers or 3 GB in total over a rolling 30-day period.

That is a concrete difference. I am not using SwissTransfer because the landing page has a Swiss flag. I am using it because privacy and larger transfers matter in this workflow.

This distinction changed how I evaluate alternatives. I now look separately at the service jurisdiction, parent company, data location, underlying infrastructure, business model, portability, and actual product quality. Those facts do not always point to the same country.

Some changes need almost no migration

Qwant and DeepL were easier decisions.

I use Qwant for search. Qwant is a French company, and its current privacy policy says it does not use targeted advertising or retain search history by default. Search is also easy to test: use it, compare the results, and keep another engine available when it does not find what you need.

I use DeepL for translation. It was founded in Cologne, Germany, and it is a good example of why the word "alternative" can be misleading. I do not need to treat a European translation service as a political compromise. I can use it because it does the work.

Neither choice required a dramatic data migration. There was no archive to restructure and no DNS record that could break a production system. They simply became part of the workflow.

New domains are another low-risk entry point. I now use Infomaniak Domains instead of GoDaddy for new registrations. I am not forcing every existing domain through an immediate transfer. When I need a new domain, the new default is a Swiss, ICANN-accredited registrar. That is progress without creating unnecessary operational risk.

DNS is an even quieter change. I use Quad9 as my resolver. Quad9 is a Swiss nonprofit, and its documentation says the recommended 9.9.9.9 service blocks lookups for malicious domains without logging end-user IP addresses. It also supports encrypted DNS protocols. This is closer to changing an infrastructure setting than migrating an account, but it moves a foundational part of normal browsing away from whichever resolver happened to be the default.

Replacing Notion meant building the alternative

Notion was different because a knowledge system accumulates structure as well as data. Notes connect to projects, tasks carry context, and the way information is captured affects whether it becomes useful work or remains another page in an archive.

I replaced Notion with Brainy, my own product.

Brainy is a practical second brain organized around the PARA method. It captures notes and ideas, connects them to projects and tasks, and focuses on turning stored knowledge into action. The goal was not to reproduce every Notion feature. It was to build a workflow that matches how I move from an idea to a project, from a project to the next task, and from planning to today's work.

Owning the product gives me control over that workflow, the data model, portability, and the roadmap, but it also gives me the maintenance work. I own the deployments, bugs, database changes, security decisions, and migration logic.

This is the clearest reason the entire transition cannot happen in two hours. Replacing a service can mean changing a setting or moving years of habits and information. In this case, it also meant building and operating a product.

For the moment, Brainy is free and you can create your own account here: www.brainy-me.com.

Sometimes the correct migration is no migration

I still use Spotify.

The reason is simple: Spotify is already European and it works for me. Its consumer terms identify Spotify AB in Stockholm, Sweden. Replacing it with another service only to increase the number of changed logos would add work without moving me closer to the actual goal.

A useful migration should leave some rows unchanged. Otherwise the process is driven by ideology rather than requirements.

Here is the current map:

Workflow	Current choice	Decision
Email	Proton Mail	Moved into the Proton ecosystem
VPN	Proton VPN	Replaced NordVPN
Passwords	Proton Pass	Replaced NordPass
Private AI chats	Lumo	Used selectively for private conversations
Large file transfers	SwissTransfer	Chosen for privacy and transfers up to 50 GB
New domain registrations	Infomaniak	Replaced GoDaddy as the default for new domains
DNS	Quad9	Uses a Swiss nonprofit resolver focused on privacy and security
Search	Qwant	In active use
Translation	DeepL	In active use
Knowledge and planning	Brainy	Replaced Notion with my own product
Music	Spotify	Kept because the European service already fits

The process I use before changing a service

The European Alternatives directory is useful for discovery, but inclusion in a directory is the beginning of the evaluation, not the conclusion.

Before changing a service, I work through a small set of questions:

What job does the current product perform?
Which features are genuinely non-negotiable, and which ones are habits?
Where is the service legally based, where is the data processed, and which external platforms does it still depend on?
Can I export the data in a useful format and move again later?
Can I run the old and new services in parallel before cancelling anything?
Is the alternative better, equivalent, or merely acceptable for this specific job?

That last question matters. I am willing to accept a small difference when privacy, control, or supporting a European provider makes the trade worthwhile. I am not willing to ignore a product that fails the workflow simply because it is European.

The safest changes happen at natural decision points. Register the next domain with a different registrar. Test another search engine without removing the old one. Import a copy of a password vault before cancelling the existing subscription. Send the next large file with a service that supports the size you need.

Moving all of them at once would turn a preference into an outage plan.

Change the next decision

I still use services from American companies, and I expect that to continue. Work, collaboration, audience, and network effects do not disappear because a European alternative exists.

The difference is that I no longer want the American option to win by default. When a subscription renews, a new need appears, or a current product creates friction, I check what exists in Europe before repeating the old decision.

The outcomes vary. A European product may be good enough, SwissTransfer may be better for large files, or Spotify may already be the European answer. Brainy sits at the other end of the range because I had to build the alternative around the workflow I wanted.

This process does not need a dramatic finish. The next decision is enough.

Thanks for reading this post, I hope you found it interesting!

Feel free to follow me to get notified when new articles are out 🙂

Emanuele BartolesiFollow

🏆 Microsoft MVP (12x) & GitHub Star (4x) ⭐ 👨‍🎓 LinkedIn Technical Instructor 🎓

Fixing “Your organization has deleted this device” Without Reconnecting Everything

Emanuele Bartolesi — Tue, 19 May 2026 06:49:19 +0000

For two days, my company laptop kept showing this error:

Your organization has deleted this device.

To fix this, contact your system administrator and provide error code 700003.

At first, it looked like the only option was to disconnect and reconnect my work account from Windows.

I really did not want to do that.

Removing and adding the account again can work, but it is annoying. You may need to re-authenticate apps, reconnect services, and deal with device registration again.

Luckily, there is a better option.

The command that fixed it

Open a terminal and run:

dsregcmd /forcerecovery

After running the command, Windows asks you to sign in again with your work account.

That is it.

In my case, after logging in again, everything started working without disconnecting all accounts manually.

It saved me a lot of wasted time.

When this helps

This can help when:

You get error code 700003
Windows says your organization deleted the device
Your device is Microsoft Entra joined
You want to avoid fully disconnecting and reconnecting your work account

A small warning

This is not magic.

If your device was intentionally removed by IT, or your company uses Intune, Autopilot, Conditional Access, or Hybrid Join, talk to your administrator first.

🔖 Stay ahead of the dev curve
I created a Curated RSS Feed Bundle for Web Developers — a hand-picked OPML file of the best dev blogs and websites on the internet.
💡 Just download, import into your favorite RSS reader (like Feedly or NetNewsWire), and enjoy fresh insights every day.

👉 Grab it on Gumroad — stay sharp without the noise.

Stop Coding Through Remote Desktop. Use VS Code Remote Tunnels Instead

Emanuele Bartolesi — Wed, 15 Apr 2026 07:10:40 +0000

There is a pattern I keep seeing with customer environments.

You get access to a VM for development. The code stays there. The dependencies are already there. The network access is there too. On paper, it looks fine.

Then reality starts.

You are expected to work through Remote Desktop, as if software development were the same thing as clicking around a server. It is not. Remote Desktop is tolerable for admin work. For actual coding, it is a bad experience. The editor feels disconnected from your normal workflow. Shortcuts feel wrong. Terminals are awkward. Moving between tools is slower than it should be. You are technically “inside” the environment, but you are not really productive.

In my case, there was another constraint. I could not even sign into VS Code on the customer VM with my own account, which meant no normal setup, no synced configuration, and no easy way to work the way I usually do.

That is where VS Code Remote Tunnels becomes the right solution.

The real-world scenario

Instead of living inside a remote desktop session, you expose the development environment through a secure tunnel and connect to it from your local VS Code. The code stays on the customer VM. The execution stays on the customer VM. But the editor experience comes back to your own machine, where you can actually work properly.

Remote Tunnels is the answer I would pick for that every time.

What VS Code Remote Tunnels actually does

VS Code Remote Tunnels gives you a way to connect to a remote machine from VS Code without setting up SSH access. The official model is simple: you create a secure tunnel from the remote machine, and then connect to it from a VS Code client somewhere else. Microsoft’s documentation describes it as connecting to a remote machine, such as a desktop or VM, through a secure tunnel using Microsoft dev tunnels.

That matters because it changes where the work happens.

The code stays on the remote VM. The terminals run on the remote VM. Debugging happens against the remote VM. VS Code installs its server-side components on that machine, and your local VS Code becomes the client for that remote environment.

Another practical point is that SSH is not required. That is one of the biggest advantages in customer environments, because SSH is often blocked, restricted, or simply not part of the approved setup. Remote Tunnels gives you another path that still keeps the work inside the target machine.

You can then connect in two main ways. You can use local desktop VS Code with the Remote - Tunnels extension, or you can connect through VS Code for the Web in the browser. That browser path is useful when you need access from a locked-down device, although the desktop client is usually the better experience.

There is one important limitation worth stating clearly. The VS Code Server used behind this model is designed for a single user, not as a shared multi-user development service. Microsoft also states that hosting the VS Code Server as a service is not allowed. So this is a personal remote development setup, not a team-hosted IDE platform.

That is why Remote Tunnels fits this customer scenario so well. It gives you remote development, not remote desktop. That is the real difference.

Why it fits this customer use case

This is exactly the kind of setup where Remote Tunnels is the right answer.

The customer wants the work to stay inside their environment. That is reasonable. The code, dependencies, network access, and internal services are already on the VM. Moving everything to a local machine would create more friction, more approvals, and in some cases more risk.

At the same time, working through Remote Desktop is a bad trade.

How to set it up

The setup is surprisingly simple. That is part of why this works so well in customer environments.

First of all, you need to download VS Code Server.
You can download it directly from the official Download page of Visual Studio Code website (https://code.visualstudio.com/Download)

From this page, as you can see in the image above, you can select your OS and your CPU family.
You can also use VS Code with the UI, but it doesn't make sense if you want to install only the server part.

Then you start the tunnel with:

code tunnel

When you run that command, VS Code downloads and starts the VS Code Server on that machine, then creates the tunnel for remote access. The first time, you will also be asked to accept the server license terms, unless you pass the CLI flag to accept them up front.

After that, the CLI gives you a vscode.dev URL tied to that remote machine. When you open that URL the first time from a client, you will be asked to authenticate with GitHub. That authentication is how VS Code checks that both sides are tied to the same account and that you are allowed to access the remote machine.

There are two practical ways to connect.

The first is through the browser using that vscode.dev link. This is the fastest way to prove the setup works.

The second, and usually better option, is from your local desktop VS Code. For that, install the Remote - Tunnels extension, open the Command Palette, and run Remote Tunnels: Connect to Tunnel. You can also see available machines in the Remote Explorer.

So the basic flow looks like this:

On the customer VM, run code tunnel
Authenticate when prompted
Open the generated vscode.dev URL or connect from local VS Code
Start working on the remote codebase from your own editor

There are two practical details worth calling out.

First, the tunnel is only reachable while VS Code is running there, unless you explicitly set it up to keep running. Microsoft documents a service mode for this with code tunnel service install, and there is also a --no-sleep option to help prevent the remote machine from going to sleep.

Second, this does not require VS Code to open inbound listeners on the VM. Microsoft states that hosting and connecting use authenticated outbound connections to the Azure-hosted tunneling service, and that no firewall changes are generally necessary. That is one of the reasons this can fit locked-down environments better than people expect.

Trade-offs and limits

Remote Tunnels is a strong solution for this scenario, but it is not magic. It has constraints, and it is better to say them clearly.

The first limit is the trust model. To create and access a tunnel, you authenticate with GitHub or Microsoft, and the tunnel itself is brokered through Microsoft’s dev tunnel service. That is exactly why setup is easy, but it also means some customer environments may reject it on policy alone, even if the technical setup works.

The second limit is extension support, especially in the browser. The desktop VS Code client is usually the best experience. The browser option is useful, but not every extension behaves the same way there. VS Code’s remote documentation is explicit that extensions may run in different locations, local or remote, depending on the extension type and the client being used.

The third limit is that this is not a shared remote IDE platform. Microsoft states that the VS Code Server is intended for a single user and that hosting it as a service is not allowed. So this is a personal remote development workflow, not something you should pitch as a team-wide hosted development environment for many users.

The fourth limit is operational persistence. A tunnel is easy to start, but if the remote machine sleeps, shuts down, or the tunnel service is not kept running, your session is gone until it comes back. Microsoft documents service mode and sleep-related options for that reason.

👀 GitHub Copilot quota visibility in VS Code

If you use GitHub Copilot and ever wondered:

what plan you’re on
whether you have limits
how much premium quota is left
when it resets

I built a small VS Code extension called Copilot Insights.

It shows Copilot plan and quota status directly inside VS Code.

No usage analytics. No productivity scoring. Just clarity.

👉 VS Code Marketplace:
https://marketplace.visualstudio.com/items?itemName=emanuelebartolesi.vscode-copilot-insights

Using GitHub Copilot CLI with Azure AI Foundry (BYOK Models) – Part 2

Emanuele Bartolesi — Fri, 10 Apr 2026 09:54:00 +0000

In Part 1, you ran GitHub Copilot CLI against a local model using LM Studio.

That setup gives you control. No external calls. No data leaving your machine. But it comes with clear limits. Small models struggle, and output quality drops fast on anything non-trivial.

This is where Azure AI Foundry comes in.

Instead of running models locally, you connect Copilot CLI to a cloud-hosted model you control. You still use the same BYOK (Bring Your Own Model) approach, but now the model runs on Azure.

That changes the trade-offs:

You gain better models and stronger reasoning
You keep control over the endpoint and deployment
You accept cost and network dependency

This is not a replacement for the local setup. It is the next step if you want privacy but at the same time, more power.

Setting Up Azure AI Foundry

This is the only "Azure-heavy" part. Keep it minimal. You just need a working endpoint and a deployed model.

1. Create or Use an Existing Resource

Go to Azure AI Foundry in the Azure portal.

You need:

A resource already created
Access to it (permissions matter)

If you already use Azure OpenAI, you can reuse it.

2. Deploy a Model

This step is mandatory.

In Azure, you cannot call a model directly. You must deploy it first.

Steps:

Open your resource
Go to Model deployments
Select a model (for example GPT-4 class)
Assign a deployment name

Example:

copilot-gpt53codex

This name is what Copilot CLI will use later.

This is how the GPT 5.3 Codex looks like, but you can also deploy models directly from the HuggingFace catalog.

If your AI Foundry is good, you can deploy the models directly with the Deploy button in the model details page.

3. Get Endpoint and API Key

From the resource, retrieve:

Endpoint URL
API key

Typical endpoint:

https://<your-resource>.openai.azure.com/

You will combine this with the deployment in the next step.

4. Build the Final Endpoint

Copilot CLI expects a full path, not just the base URL.

Format:

https://<your-resource>.openai.azure.com/openai/deployments/<your-deployment>/v1

Example:

https://my-ai.openai.azure.com/openai/deployments/copilot-gpt53codex/v1

If this path is wrong, nothing will work.

5. Quick Validation

Before using Copilot CLI, validate:

The deployment exists
The API key is valid
The endpoint is reachable

If you skip this, debugging later becomes painful.

Connecting Copilot CLI to Azure

This is the same pattern as Part 1. Different endpoint. More constraints.

Set the Environment Variables

You must point Copilot CLI to your Azure deployment.

PowerShell example:

$env:COPILOT_PROVIDER_BASE_URL="https://<your-resource>.openai.azure.com/openai/deployments/<your-deployment>/v1"
$env:COPILOT_MODEL="<your-deployment>"
$env:AZURE_OPENAI_API_KEY="<your-api-key>"

What matters:

COPILOT_PROVIDER_BASE_URL → full Azure endpoint
COPILOT_MODEL → deployment name, not model name
AZURE_OPENAI_API_KEY → required for authentication

No COPILOT_OFFLINE here. Requests go to Azure.

Run a Simple Test

Open Copilot CLI with the following command in a project folder you want to test:

copilot --banner

Ask a simple tasks like: "Give me the list of all the files larger than 2MB".

If everything is configured correctly:

The response comes from your Azure AI Foundry Model
The answer is really fast, at least faster than the answers from the Part 1

Reality Check

This is not “Copilot with Azure magic”.

It is:

Copilot CLI acting as a thin client
Azure acting as the model provider

You gain better models, not better tooling.

👀 GitHub Copilot quota visibility in VS Code

If you use GitHub Copilot and ever wondered:

what plan you’re on
whether you have limits
how much premium quota is left
when it resets

I built a small VS Code extension called Copilot Insights.

It shows Copilot plan and quota status directly inside VS Code.

No usage analytics. No productivity scoring. Just clarity.

👉 VS Code Marketplace:
https://marketplace.visualstudio.com/items?itemName=emanuelebartolesi.vscode-copilot-insights

Using GitHub Copilot CLI with Local Models (LM Studio)

Emanuele Bartolesi — Thu, 09 Apr 2026 11:36:59 +0000

Local AI is getting attention for one simple reason: control.

Cloud models are strong and fast, but for many companies and developers, especially when experimenting or working with sensitive code, that is not ideal.

This is where local models come in.

Tools like LM Studio let you run LLMs directly on your machine. No external calls. No data leaving your environment or your network.

Instead of sending prompts to cloud models, you can point Copilot CLI to a local model running in LM Studio.

This setup is not perfect. It is not officially seamless. But it works well enough for learning, experimentation, and some real workflows.

What You Need

Before setting this up, make sure the basics are clear. This is not a plug-and-play setup. There are a few moving parts, and some assumptions.

GitHub Copilot CLI

You need GitHub Copilot CLI installed and working.

You can launch GitHub Copilot CLI with the following command:

copilot

or even better, if you want to see the banner in the terminal:

copilot --banner

By default, the CLI uses GitHub-managed models, but now you can override that.

Note: You must be authenticated with GitHub and have access to Copilot.

LM Studio

LM Studio is the simplest way to run local LLMs without dealing with raw model tooling.

What it gives you:

A UI to download and run models
A local server that exposes an OpenAI-compatible API
No need to manually manage inference engines

Once running, it exposes an endpoint like (OpenAI compatible):

http://localhost:1234/v1

This is the key piece. Copilot CLI will talk to this endpoint instead of the cloud.

A Local Model (Be Realistic)

Not all models are equal. And your hardware matters.

For this guide, a small model like:

qwen/qwen3-coder-30b

is enough to get started.

But be clear on the trade-offs:

Small models → fast, but weaker reasoning
Large models → better output, but slow or unusable on most laptops

If you are on a standard laptop:

1B–3B models → OK
7B+ models → borderline
13B+ → usually not practical without a GPU

On my laptop I am giving a chance to the NVidia model nemotron-3-nano-4b but on my gaming PC (that I use for developing and not gaming) I use bigger models la Qwen3 Code or similar.

Tip: Start small. The goal here is understanding the workflow, not benchmarking models.

Connecting Copilot CLI to LM Studio

This is the part most people get wrong.

Copilot CLI is not designed primarily for local models. You are using a BYOK (Bring Your Own Key/Model) path that is still evolving.

It works, but you need to be precise.

Reference: https://docs.github.com/en/copilot/how-tos/copilot-cli/customize-copilot/use-byok-models

1. Set the Environment Variables

You must override the default Copilot provider.

In PowerShell:

$env:COPILOT_PROVIDER_BASE_URL="http://localhost:1234/v1"
$env:COPILOT_MODEL="google/gemma-3-1b"
$env:COPILOT_OFFLINE="true"

What they do:

COPILOT_PROVIDER_BASE_URL → points to your local LM Studio server
COPILOT_MODEL → defines which model to use
COPILOT_OFFLINE → prevents fallback to cloud models

If COPILOT_OFFLINE is not set, Copilot may silently use cloud models.

2. Run a Simple Test

Open LM Studio, and open the *Developer * tab.
Click on the switch of the Status and the server will start in a second.

Then, click on Load Models and load the models you prefer that you downloaded previously on your machine.

Open Copilot CLI with the following command in a project folder you want to test:

copilot --banner

Ask a simple tasks like: "Give me the list of all the files larger than 2MB".

If everything is configured correctly:

The response comes from your local model
No external API calls are made

Don't expect a result in seconds like a normal cloud model, but it depends on your hardware; it can also take minutes sometimes.

Reality Check

This is not a first-class integration.

No guarantee of full compatibility
No optimization for local inference
No smart routing like in GitHub-hosted Copilot

But for simple CLI workflows, it is good enough.

When This Setup Makes Sense

Do not use this everywhere. Use it where it actually gives you an advantage.

1. Privacy-Sensitive Environments

If code cannot leave your machine, this setup is useful.

Examples:

Internal tools
Proprietary scripts
Regulated environments

You avoid sending prompts and contexts to external services.

This is the strongest reason to use local models.
Especially in some companies like insurances or military, it makes absolutely sense.

2. Offline Workflows

If you work without a stable connection or you don't have a connection at all (like during a flight).

It is slower, but always available.

3. Learning and Understanding AI

This setup forces you to see how LLMs actually behave.

You learn:

Prompt sensitivity
Model limitations
Output variability

This is valuable if you want to go beyond "just using Copilot".

When It Does NOT Make Sense

Avoid this setup if you need:

High accuracy
Large context handling
Production-grade reliability

In those cases, cloud models are still the better option.

👀 GitHub Copilot quota visibility in VS Code

If you use GitHub Copilot and ever wondered:

what plan you’re on
whether you have limits
how much premium quota is left
when it resets

I built a small VS Code extension called Copilot Insights.

It shows Copilot plan and quota status directly inside VS Code.

No usage analytics. No productivity scoring. Just clarity.

👉 VS Code Marketplace:
https://marketplace.visualstudio.com/items?itemName=emanuelebartolesi.vscode-copilot-insights

GitHub Copilot Is Too Nice. Fix It With a Tone of Voice File.

Emanuele Bartolesi — Wed, 01 Apr 2026 12:21:58 +0000

Most GitHub Copilot setups are too polite to be useful.

By default, Copilot tries to agree, avoid criticism, and keep answers "safe".
That sounds good, but in practice it leads to weak suggestions, missed problems, and bad decisions slipping through.

If you want better output, you need to change its behavior.

The simplest way is a tone of voice file.

Create a voice-instructions.md in your repo and force Copilot to be critical:

---
applyTo: '**'
---

Give direct, critical feedback.
Identify mistakes, weak assumptions, unnecessary complexity, unclear naming, hidden risks, and poor trade-offs without softening the message.

Do not add generic praise or filler. Do not agree by default.

When something is wrong, say exactly what is wrong, why it is a problem, and what should be done instead.

Prioritize correctness, clarity, simplicity, maintainability, and practical delivery.

Challenge vague requirements and surface missing constraints, edge cases, and operational risks.

Be blunt but professional. Never be insulting. Always aim to be useful.

You get:

Clear problems called out
Weak assumptions challenged
Simpler and more maintainable alternatives

The result is better code and faster decisions.

There is a trade-off.

It feels harsher.
It is not ideal for beginners.
It removes the "friendly assistant" vibe.

But if you are building real systems, that is the wrong goal anyway.

If you want better output, demand better behavior.

👀 GitHub Copilot quota visibility in VS Code

If you use GitHub Copilot and ever wondered:

what plan you’re on
whether you have limits
how much premium quota is left
when it resets

I built a small VS Code extension called Copilot Insights.

It shows Copilot plan and quota status directly inside VS Code.

No usage analytics. No productivity scoring. Just clarity.

👉 VS Code Marketplace:
https://marketplace.visualstudio.com/items?itemName=emanuelebartolesi.vscode-copilot-insights

DEV Community: Emanuele Bartolesi

I can build the product with AI. Getting the first users is harder.

My network gave me a place to start

Some users found me through search

How I would research one page for Brainy

Reaching outside my LinkedIn circles

The alternative is often something people already do

The first visit needs somewhere useful to go

Trust is part of the first useful experience

Growing MRR asks more than whether someone signed up

I need to know where the attempt stops working

The costs behind the MRR goal

Ambition needs a reason to continue

What I want to do with the next cycle of work

GitHub Universe 2026: Announcements, Sessions, and My Technical Takeaways

Table of contents

1. The Core Platform Overhaul: Git Rebuilt for Agent Scale

Next-Generation Git Architecture

2. Copilot Under the Hood: Model Optimization, Context, and Protocols

How GitHub Optimizes Copilot for Every New Model

Connecting Local Agents to External Tools via MCP

3. Advanced Delivery Workflows: Stacked PRs GA and Cross-Surface Flow

Stacked Pull Requests: Solving the Review Bottleneck

Cross-Surface Continuity: App, IDE, CLI, Mobile, and Slack

4. Hardware Hacking with Copilot CLI: Event-Driven Agent State

Copilot CLI Hook Architecture

5. Enterprise Case Studies: Real Governance at Scale

Trimble: Building a Governance Tool for 436 Repositories in Four Days

Slack: Turning a Personal AI Hack into an Organization-Wide Standard

NVIDIA: Domain-Specific AI Agents for Hardware Reliability

6. Security: AI Scan, Secret Push Protection, and Package Firewalls

7. The Frontier Horizon: Where AI-Assisted Development is Heading

Questions I Am Taking Away from the Panel

Humans Set Direction. Agents Close the Loop.

8. Open Source Governance, Developer Joy, and the Craft of Code

Home Assistant: Building in the Open

Agents in CI/CD: The CNCF & Project Bluefin Experience

What's Worth Building When AI Can Build Anything?

Creative Coding, Hackable Badges, and Hardware Kits

Catching up with Italian friends

My fifth GitHub Universe

How I build products with AI: from a brainstorm to a production release

Lately, Fusion is my default

The PRD carries my decisions between tools

dotcraft is how I keep my setup with me

DayPulse gave me a useful example

I hand Copilot an epic with a clear stopping point

UI work gets a different route through the same process

I automate the repeatable browser checks with Playwright

I finish the backlog, then check the application as a whole

GitHub Actions gives me a development preview

Production releases have an explicit trigger

After deployment, I still have a product to check

I like working this way in Omarchy

GitHub Universe 2026: My recap from San Francisco

Table of contents

Two updates I shared from San Francisco

The numbers explain why GitHub is changing the stack

From an issue to working software in the Copilot app

Connectors bring the missing context into the session

Copilot Fusion chooses how to use the models

Copilot Dreaming addresses instructions that have gone stale

Projects coordinates a feature across repositories

The same session can follow you between tools

Automations connect production signals to repeatable work

Review and merge have to keep up

Stacked pull requests make related changes easier to inspect

Agent Merge helps a pull request reach completion

The smaller platform updates belong in this recap too

Security needs to be part of the agent workflow

A Security canvas for investigating findings

AI Scan extends coverage beyond CodeQL

Push protection catches unstructured secrets

Package firewall and reachability analysis address dependency risk

Enterprise access changes, but usage still needs a budget

Rebuilding Git was one of the most substantial announcements

Octoverse shows how developers are using the tools

Agents are increasingly producing the first draft

Model choice is already plural

Growth reaches more countries and industries