DEV Community: Playful Programming

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 🎓

I Open-Sourced My Web Developer Agent. AI Is Supercharging Open Source.

Domenico Tenace — Mon, 02 Nov 2026 16:52:29 +0000

I finally did it: my web developer agent is public on GitHub. I named the repo web-dev-agent, and it lives at github.com/Domenico-Tenace-Open-Labs/web-dev-agent, for the first time since I started building it, people other than me can run it, break it, and tell me what it should do next.

Making that call felt less like a release and more like surrendering control, which is exactly why I made it. Every week I read about agents, benchmarks, and new harnesses, and almost all of it is built in the open now. Keeping mine closed would have meant hiding in exactly the place the ecosystem has decided things get better: public repositories, public issues, public pull requests.

Turns out I picked a decent moment for it. The data from the last twelve months shows something that would have sounded like science fiction in 2023: AI agents are now a structural force in how open source grows, not a nice-to-have at the edge of the dashboard. Here is what I shipped, and here is the evidence that the open source flywheel has a new engine.

What I shipped, and where it sits

A "web developer agent" sounds either trivial or terrifying, and it's neither. Mine is an OpenCode agent configuration: a primary agent, web-developer, that works like a senior frontend developer for Astro, Vue 3 (+ Nuxt), Vite and strict TypeScript, paired with six specialist subagents (code review, SEO, UI/UX, accessibility, documentation, security), nine skills, two slash commands and three rule sets. It scaffolds a project with /scaffold-frontend-project (pnpm only, strict TypeScript), injects clean-code, Astro and Bulma conventions into every session, and can audit the result before it ships.

The point isn't magic, it's leverage. The agent turns the tedious loop of scaffold → implement → check → fix into something a developer supervises instead of performs. You stay on the decisions: what to build, what's good enough, what ships. The agent does the walking, and because every write is approval-gated (effect: ask) and the workspace is sandboxed (external_directory: deny), "supervise" is the operating mode, not a suggestion.

I'm not entering an empty market. The most striking thing about open source in 2026 is that the agents themselves went open source. opencode, the model-agnostic agent from Anomaly, passed 200,000 stars by late 2026 and sits near the top of GitHub's fastest-growing and most-engaged project lists. OpenAI's Codex CLI and Google's Gemini CLI are open too, with six-figure star counts. Aider, Cline, OpenHands, the list goes on. A year and a half ago the category was a handful of tools, most of them closed. Today it's a category where the reference implementations are public, MIT- and Apache-licensed code that anyone can fork. Mine plugs into that same harness, it's an OpenCode configuration, MIT-licensed, and model-agnostic.

Publishing into that ecosystem is the whole point of this article.

Open source is growing faster than ever (and AI is part of the why)

Start with the raw numbers, because they're the least controversial thing I'll say today. According to GitHub's Octoverse report published October 28, 2026, the twelve months ending September 2026 were the biggest in GitHub's history:

Metric (12 months ending Sep 30)	2024	2025	2026
Pushes	5.2B	6.7B	17.9B (more than 2024 + 2025 combined)
Commits	10.0B	12.9B	34.3B
Merged pull requests	402M	538M	1.3B (~3.5M/day)
Actions jobs	8.0B	14.0B	45.4B

Open source holds up its end of that growth: contributions to public repositories reached 2.5 billion in 2026, more than double 2025's 1.12 billion. The developer base keeps expanding too: 225 million+ developers on GitHub today, 36 million of them joining in 2025 alone, more than one new developer every second. March 2025 also set a record: 255,000 first-time contributors in a single month.

AI isn't the whole story behind those numbers, but it's woven into them. GitHub reports that about 80% of new developers start using Copilot within their first week, and more than a million public repositories now use an LLM SDK, up 178% year over year (both Octoverse 2025). The barrier to contributing code has never been lower: the first draft is cheap now, and the bottleneck has moved to review, which is exactly where a human should be.

Agents have become the new contributors

The step change in 2026 is that agents stopped being assistants and started being contributors, with a GitHub identity, a branch, and a pull request.

More than 40% of pull requests on GitHub now start from an agent's first draft (September 2026), up from 17% in March. That's 110 million agent-started PRs in September alone, roughly six times March's volume. GitHub notes its detection is a floor, not a ceiling.
Pull requests started by agents change multiple files more often (87% vs 79%) and, by September, merged within two weeks at a higher rate than the non-agent baseline (90% vs 86%).
GitHub's Copilot coding agent alone contributes ~1.2 million pull requests per month (GitHub, Oct 15, 2025), and paid Copilot subscribers grew 75% year over year to 4.7 million by January 2026.
Independent academic work agrees. The AIDev dataset measured ~930,000 agent-authored PRs across ~116,000 repositories between December 2024 and July 2025, spanning Codex, Devin, Copilot, Cursor, and Claude Code (arXiv:2606.28235).

There's also a striking correlation in this year's report: among repositories created in 2026, the average repo with an agent configuration file logged eight times as many commits as the average new repo without one. Correlation, not causation, but when a nearly-free text file (an AGENTS.md that tells the agent how your project works) coincides with an 8x difference in activity, it's worth treating seriously.

The language data tells the same story from another angle. The three fastest-growing language communities, Rust (+162% year over year), TypeScript (+134%), Python (+118%), are the ones with the highest share of AI-involved merged PRs (40 to 44%). The languages where agents show up the most are the ones where the communities are growing the fastest.

This is the ecosystem I just published into. An open-source agent is no longer a hobby artifact; it's infrastructure that other people's repositories read, run, and learn from.

The open source economy is finally getting some help

For years, the open source conversation has been about a mismatch: more consumers than contributors, and a shrinking pool of volunteer maintainers. The numbers are grim. Tidelift's 2024 survey found 60% of maintainers are unpaid, and roughly 60% have quit or seriously considered quitting. The maintainer base is aging, maintainers aged 46 to 65 have doubled since 2021, while contributors under 26 dropped from 25% to 10% of the total (via GitHub, Aug 2025, citing Tidelift 2024).

AI can't fix funding by itself, but 2026 is the first year the economy around open source has real money moving into it:

Sovereign Tech Fund (Germany): €61.6M commissioned across 2022 to 2026 for critical OSS, funding curl, OpenSSH, the OpenSSF Scorecard, and most recently €1.285M for KDE in May 2026.
GitHub Secure Open Source Fund: $1.25M across 125 projects at launch (November 2024), with partner commitments since.
GitHub Sponsors: $60M+ paid out cumulatively (November 2024 figures).
EU Sovereign Tech Fund pilot: launched in 2026.

Fewer young hands, more code, and new institutional money: the gap between supply and demand of maintainer time is exactly where agents plug in. They won't review as well as a senior maintainer, but they can triage issues, update dependencies (developers merged 30M+ Dependabot PRs in 2026, about double 2025's pace, Octoverse 2026), fix boilerplate, and keep the repository alive while the human does the parts that need judgment. Published under MIT, an agent like mine is a tool any maintainer can run at zero license cost, installation is a single cp -r into your OpenCode config directory. That's the argument for this repo, and it's the argument for open-sourcing agents generally.

The honest counterweight

I'd be lying if I told you the story is only upward momentum. The last couple of years produced some sobering findings.

METR's randomized controlled trial (July 2025): 16 experienced OSS maintainers working on 246 real issues in mature repositories were 19% slower with AI tools, while believing they were 20% faster. Perception and reality are diverging at the exact moment everyone is making tooling decisions.
Stack Overflow's 2025 survey: 84% of developers use or plan to use AI tools, yet 46% distrust the accuracy of the output and only 3% say they highly trust it. The top frustration: results that are "almost right."
Security: broken access control overtook injection as the most common CodeQL alert, 151,000+ repositories, +172% year over year (Octoverse 2025), and GitHub itself ties part of that surge to AI-generated scaffolds that skip critical authorization checks.
Maintainers remain skeptical of AI contributions: 64% of maintainers said they'd be less likely to accept a contribution if they knew it was AI-generated (Tidelift 2024).

This is why the Octoverse line "review is how developers shape what comes back" isn't marketing, it's the actual operating model. Agents generate volume; humans curate quality. Speed without review is how you get slop in, security holes in, and maintainers out.

I built my agent with that tension in mind. Its job isn't to maximize lines generated, it's to reduce the review load per merged change: conventions enforced while writing mean fewer style nits in review, and a specialist subagent for each domain, accessibility, SEO, security, UI/UX, code review, means whole categories of problems get caught before a human ever looks at the diff. If the agent makes my reviews shorter, it's working.

What this means for you

Whether you're a maintainer, a contributor, or someone about to be both, here's a concrete do-list:

Add an agent configuration file to your repo. An AGENTS.md that documents structure, conventions, and commands is nearly free, and it's the file that coincides with the 8x commit difference in this year's data. It also helps every human who joins later.
Treat agent-authored PRs as review-first work. They merge fast (90% within two weeks); you're the gate. Run CI, require tests, and wire up Dependabot and a security scanner (94% of the top 50 projects use OpenSSF Scorecard, Octoverse 2025).
Automate the maintenance backlog, not the architecture. Agents are genuinely good at triage, dependency updates, and boilerplate, the exact work that burns maintainers out. Keep humans on design decisions and interface contracts.
If you build agents, ship them open. Public agents get public benchmarks, public bug reports, and public improvements, and every README and config file doubles as training signal for the next generation.
Measure your own loop. METR showed that beliefs about AI speed are unreliable. Track review time and revert rates; keep what helps, drop what doesn't.

The flywheel

Here's the loop I'm betting on: open source gives AI agents their training data, their benchmark suites, and their adoption channels. The agents, in turn, give open source more contributors, more merged PRs, and more velocity. Each open-sourced agent adds a gear to that machine.

web-dev-agent is mine. It's at github.com/Domenico-Tenace-Open-Labs/web-dev-agent, clone it, drop it into ~/.config/opencode, and try it on a real project. Open an issue when it does something dumb (it will), and fork it if you want to make it yours. And whether or not you touch my repo: if you've been building something useful with an agent, consider doing what I finally did. Build it in the open, and let the ecosystem do the rest.

Hi 👋🏻
My name is Domenico, software developer passionate of Open Source, I write article about it for share my knowledge and experience.
Don't forget to visit my social links to discover my links, check out Domenico Tenace Open Labs for my open source projects and subscribe to my newsletter! 🫰🏻

🌲 Links: https://links.domenicotenace.dev/
🐙 Domenico Tenace Open Labs: https://github.com/Domenico-Tenace-Open-Labs
📰 Newsletter: https://domenicotenace.substack.com/subscribe

If you like my content or want to support my work, you can support me with a small donation. I would be grateful 🥹

☕ Buy me a Coffee: https://buymeacoffee.com/domenicotenace

Sources

Astro Wellness: The First Project Built Start to Finish by My Agent Team 🏋️

Domenico Tenace — Wed, 28 Oct 2026 08:00:00 +0000

Overview

Hey everyone 👋

A few days ago I wrote about the agent team I built for OpenCode: a web-developer primary agent and four subagents for UX/UI, code review, SEO and documentation. The obvious question was, does it actually hold up on a real project?

Meet Astro Wellness, a modern, dark and energetic gym template built with Astro and Bulma. It's the first project the whole team took from empty folder to finished, and it's now listed among the official Astro templates: astro-wellness on the Astro portal. I'm still a bit surprised typing that.

Let's dive in! 🤙

What Is Astro Wellness? 🤔

It's a template for a gym, studio or training brand, ready to adopt and customise. It ships with everything you need to go live:

Pages: home (hero, stats, services, testimonials), about, services with pricing plans, blog, contact and a custom 404
Dark and light mode through Bulma's themes, persisted in localStorage, following the OS preference on the first visit and applied before first paint
SPA style page transitions with Astro's ClientRouter, respecting prefers-reduced-motion
A Markdown blog on content collections with a typed schema and an auto generated RSS feed
SEO ready: per page title and description, canonical URLs, Open Graph, JSON-LD (HealthClub on the home page, BlogPosting on posts), sitemap and robots.txt
Strict TypeScript, typed props on every component, and Bulma imported module by module so nothing unused ships The look is a dark theme with an orange accent plus an adaptive light theme, and every design token lives in two clearly documented places, so re-theming the whole site is a quick job. It's MIT licensed, pnpm only, on Astro 7, with a live demo on Netlify.

How the Team Worked on It 👥

Here's the part I wanted to test. If you missed the previous article, the rule in my setup is simple: nobody edits anything in the first pass. Every agent proposes first, I approve, and only then does it apply changes, with each write still behind an ask gate.

web-developer led the build. It explored the project, proposed the structure (pages, layout, data files, components), and implemented it after my OK, then verified with the type check and the build. The strict TypeScript setup and the clean src/data folder for services, team, pricing and testimonials come from its rules about typed props and keeping pages free of complex logic.

ux-ui-expert handled the design system: the dark and orange palette, the light theme flipping every token automatically, responsive behaviour at Bulma's breakpoints, and the details like focus states and reduced motion support. Its rule of using the framework's primitives before custom CSS is why the project styles stay small and prefixed.

seo-expert audited the head, the structured data, the sitemap, the robots file and the social share image. It's also the reason the README tells you to set your real domain before deploying, since the agent flagged it as something only the template user can decide.

code-reviewer went over the changes with its checklist and reported by severity, with concrete fixes I could approve one by one.

documentation-updater kept the repo honest: README, CHANGELOG, CONTRIBUTING, SECURITY and AGENTS.md. Its rule of never documenting what it can't verify against the code is exactly what you want from docs that will be read by strangers.

What Worked 👍

The approval gate paid off. On a template that other people will copy, I didn't want surprise edits. Proposals first meant I made the design and architecture calls, and the agents did the heavy lifting.

Specialists beat one big prompt. Having the SEO and docs passes happen as separate reviews, by agents with their own skill and checklist, made the final result more complete than anything I'd have remembered to ask for at the end of a long conversation.

Consistency. Same structure rules, same naming, same quality bar across the whole codebase, because the conventions live in the agent files and not in my head.

It's reusable. The same team can now take on the next template without me rebuilding the workflow.

What Was Harder 😬

I won't pretend it was effortless. The approval flow means a lot of reading and clicking, and for small tasks it's slower than just doing it. Delegation costs tokens and time. And the agents don't replace judgment: decisions like the visual direction, the tone of the sample content and which sections a gym site really needs were mine.

The other lesson is that a template has a different bar than a personal site. People will fork it, so documentation, accessibility and clean defaults matter more than usual, and that's where having dedicated agents for those jobs helped the most.

Try It, Fork It, Break It 🚀

Astro Wellness is open source and free to use for your own gym, studio or training brand:

pnpm install
pnpm dev

You'll need Node 22.22 or newer and pnpm 10+. Edit src/data/site.ts for your identity, swap the sample content, set your real domain in astro.config.mjs, and deploy the dist/ folder anywhere static. The live demo is at astro-wellness.netlify.app, and issues and PRs are welcome.

Final Thoughts 🌟

Having a template accepted among the official Astro ones was a great moment, but the bigger win for me is the proof that the agent setup works on a real deliverable, not just on demos. One primary agent, four specialists, a lot of small approvals, and a project I'm proud to put my name on.

If you try the template, or build your own agent team for OpenCode, tell me how it goes.

Happy coding! ✨

🌲 Links: https://links.domenicotenace.dev/
🐙 Domenico Tenace Open Labs: https://github.com/Domenico-Tenace-Open-Labs
📰 Newsletter: https://domenicotenace.substack.com/subscribe

If you like my content or want to support my work, you can support me with a small donation. I would be grateful 🥹

☕ Buy me a Coffee: https://buymeacoffee.com/domenicotenace

One Dev, Four Specialists: My Agent Team for OpenCode 🧑‍💻

Domenico Tenace — Thu, 22 Oct 2026 07:00:00 +0000

Overview

Hey everyone 👋

For a long time my OpenCode workflow was one agent, one giant conversation, and me asking it to code, then review, then fix the SEO, then update the docs. It works, but the context gets messy, and the agent that just wrote the code is the worst one to judge it.

So I rebuilt the setup as a small team: one primary agent that builds, and four subagents it delegates to. Each one has its own role, its own boundaries and its own dedicated skill. Every agent is a single markdown file, so the whole thing is easy to read, tweak and version.

Let's dive in! 🤙

The Team 👥

web-developer is the primary agent, a senior web dev for Astro, Vue, TypeScript, Vite, Bulma and Tailwind. It's the one I talk to, and it owns the implementation.

Then four subagents, all launched by the web-developer:

ux-ui-expert designs and reviews UI, UX and graphics, always respecting the project's design system.

code-reviewer reviews changes, a feature or the whole codebase, and reports issues by severity.

seo-expert audits on-page, technical and content SEO.

documentation-updater keeps README, changelog and guides in sync with the code.

The flow is natural: I describe a feature, the web-developer proposes a plan, builds it after my OK, then calls the right specialists before we call it done.

The Golden Rule: Propose First, Apply After Approval ✋

This is the heart of the setup, and it's the same in every agent. Nobody edits files in the first pass. They present a concrete proposal (files to change, what changes, why) and wait for my explicit approval. Then, when they do apply something, every single write is gated by an ask permission, so I confirm it again.

The relay matters too. When a subagent proposes fixes, the web-developer passes the proposal to me instead of applying it on its own. Two checkpoints, no silent changes, and if something unexpected shows up mid-application, the instruction is to stop and report instead of improvising.

Anatomy of an Agent File 🔧

OpenCode has primary agents (the ones you talk to, switched with Tab) and subagents (specialists called by a primary agent, or by you with an @ mention). Agents live in .opencode/agents/ and the file name becomes the agent name. Here's the frontmatter of my code-reviewer, trimmed:

---
description: Expert code reviewer for the current project, proposes fixes and applies them only after approval.
mode: subagent
color: "#f59e0b"
permissions:
  # load and follow the dedicated skill
  - action: skill
    resource: code-review
    effect: allow
  # approval gate: every write asks for confirmation
  - action: edit
    resource: "*"
    effect: ask
  # web access for docs and known issues
  - action: webfetch
    resource: "*"
    effect: allow
  # connected MCP servers, when necessary
  - action: "*_*"
    resource: "*"
    effect: allow
  # sandbox: nothing outside the workspace
  - action: external_directory
    resource: "*"
    effect: deny
---

Two details I like. First, the sandbox rule goes last on purpose: for external_directory the last matching rule wins, so that deny overrides every allow above it, including the MCP one. Agents can't read or write outside the current project, not even through the terminal. Second, web access and MCP servers are always allowed, but the prompt tells the agent not to overuse them and to try project knowledge first.

Below the frontmatter comes the prompt: role, process, operating boundaries and the report format.

One Dedicated Skill Per Subagent 🎯

Each subagent has a global skill it must load first, before doing anything else:

code-reviewer loads code-review
seo-expert loads seo-audit
ux-ui-expert loads web-design
documentation-updater loads update-documentation

The split is simple. The agent file says who the agent is and what it's allowed to do. The skill holds the actual checklist and workflow, loaded on demand so it doesn't clutter the context when it isn't needed. For example, the documentation-updater follows a fixed path: establish repository context, understand the change, inspect the implementation, search for documentation drift, plan, edit, validate, review the diff.

Because the skills are global, I can reuse them across every project and improve them in one place.

How the Delegation Works 🧭

The web-developer prompt has a dedicated section for each specialist, saying exactly when to call it: code reviews, SEO audits and pre-ship checks, UI work and responsive fixes, documentation and changelog updates. It's explicit about what the specialist will bring back, too.

The reports are structured and that's what makes them useful:

code-reviewer returns findings ordered from critical to info, each with path:line, why it matters and a concrete fix. It also notes what is good, because a review that is only a list of problems isn't balanced.

seo-expert returns findings by severity grouped as on-page, technical and content, with before and after snippets, a separate list of quick wins, and the items that need input from me.

ux-ui-expert returns design proposals ranked by impact, the files to edit, asset recommendations and anything it can't decide without brand facts.

documentation-updater returns a plan first: files to modify, files to add, files to leave alone and why. It only documents what it can verify against the implementation.

And one rule I really like, shared by all of them: if a fact only I know (brand info, copy, a release version), flag it and ask, never invent it.

Why This Beats a Single Agent 💡

Fresh eyes. The agent that wrote the code isn't the one reviewing it. That alone catches more than any "now review what you just wrote" prompt.

Cleaner context. Each subagent works in its own child session, so the review reasoning doesn't pollute the building conversation.

Predictable behavior. Same approval gate, same sandbox, same reporting style, across the whole team.

The routine is built in. Review, SEO, design and docs checks are part of the setup, not something I have to remember at the end of every task.

The Downsides 😬

It's not free magic. More agents means more tokens and more waiting, so for a one line fix it's overkill and I simply stay in the web-developer. The approval flow adds clicks, and with two checkpoints it can feel heavy on small tasks, though I prefer that to surprise edits. Subagent descriptions need care too, because similar descriptions make the primary agent pick the wrong one. And a review only helps if you actually read it.

Final Thoughts 🌟

Splitting one do-everything agent into a team looked like a small change, but it changed how I work. I stopped micromanaging prompts at the end of every task, and I got a setup where nothing touches my code without a proposal and a yes from me.

If you use OpenCode, start small: one primary agent plus one reviewer with the approval gate. Once you see the difference, you'll want the rest of the team.

Happy coding! ✨

🌲 Links: https://links.domenicotenace.dev/
🐙 Domenico Tenace Open Labs: https://github.com/Domenico-Tenace-Open-Labs
📰 Newsletter: https://domenicotenace.substack.com/subscribe

If you like my content or want to support my work, you can support me with a small donation. I would be grateful 🥹

☕ Buy me a Coffee: https://buymeacoffee.com/domenicotenace

Closed vs Open Source AI: Who Really Owns Your Data? 🔓

Domenico Tenace — Mon, 12 Oct 2026 08:18:12 +0000

Overview

Hey everyone 👋

When we pick an AI model, we usually look at benchmarks, speed and price. Fair enough. But there's a question most teams skip until it's too late: who owns the data, and who holds the controls?

Right now the AI world is split in two. On one side, proprietary models, the classic "black boxes". On the other, open weights models you can download and run yourself. Let me walk you through why this choice matters more than it looks. Let's dive in! 🤙

Closed vs Open: The Quick Version

Closed models live behind an API. You send text, you get text back, and what happens in between is not your business. They're easy to start with, and that's why so many companies pick them.

Open weights models (think Llama, Mistral, Qwen, DeepSeek) are different. You get the model itself, so you can run it on your own server, in a private cloud, or even on a beefy laptop. One note: "open weights" is not always the same as "open source" in the strict sense, so always read the license before building a product on top of one.

Why Open Source Is Worth a Look

Your Data Stays at Home 🔒

With a self-hosted model, nothing leaves your infrastructure. No customer data, no internal documents, no proprietary code sent to someone else's servers. If you work in healthcare, finance, or you just have a nervous legal team, this alone can settle the discussion.

No Vendor Lock-in 🔓

Prices change. APIs get deprecated. Terms of service get rewritten on a random Tuesday. If your whole product depends on one provider, every one of those changes is your problem, and you get no vote.

With open models you control the infrastructure, so you can move, switch or fork whenever you want.

You Can Look Inside and Make It Yours 🛠️

No black box means you can inspect what you're running. You can also fine-tune a model for your own domain and keep full ownership of the result. Try doing that with a closed API, and you'll quickly find where the rules stop.

The Catch

I'm not here to sell you a dream, so let's be honest about the downsides.

Running models costs real money, in GPUs or cloud instances.
Someone has to maintain it: updates, scaling, monitoring, security. That someone is you.
The very top closed models still tend to lead on the hardest tasks, even if the gap keeps shrinking.
Licenses vary a lot, and some come with restrictions you won't like.

If you're a small team with no infra experience, a managed API might be the smarter call, at least at the start.

So What Should You Do? 🎯

For most teams, the answer isn't "pick a side", it's "keep the exit open".

Start with a closed API if you need to move fast.
Put a thin abstraction layer between your code and the model, so swapping providers is a config change, not a rewrite.
Use open models for the sensitive stuff, or for tasks where a smaller model is good enough and much cheaper.
Test open alternatives regularly. The landscape moves every few weeks.

Open source fits best when privacy is non negotiable, when you have enough volume to justify your own infra, or when you need deep customization. Closed fits best when you want zero ops and the strongest raw performance.

Final Thoughts 🌟

This isn't a philosophical debate, it's a practical one. The more AI becomes the core of your product, the more it matters who controls it. Open source is also what keeps a handful of companies from owning the entire cognitive infrastructure we all rely on.

You don't have to go all in. Just make sure that if the rules change tomorrow, you have somewhere to go.

Happy coding! ✨

🌲 Links: https://links.domenicotenace.dev/
🐙 Domenico Tenace Open Labs: https://github.com/Domenico-Tenace-Open-Labs
📰 Newsletter: https://domenicotenace.substack.com/subscribe

If you like my content or want to support my work, you can support me with a small donation. I would be grateful 🥹

☕ Buy me a Coffee: https://buymeacoffee.com/domenicotenace

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 🎓

INP and Partytown: give the main thread back to your users

Nicolas Frizzarin — Wed, 23 Sep 2026 08:18:37 +0000

Introduction

You click on a button. Nothing happens.
You click again. Still nothing.
Then the menu opens... and closes right away.

We have all lived this. It's a responsiveness problem. And since March 12, 2024, Google measures it with a Core Web Vital: INP.

Very often, the problem is not your code. It's the code you didn't write: analytics, tag managers, pixels, A/B testing tools...

This article explains:

What INP really measures
Why third-party scripts hurt it so much
How Partytown works
How to use it in React and Angular, with real examples
When you should not use it

INP in a few words

INP means Interaction to Next Paint.

It measures the time between a user interaction and the next frame painted by the browser. In other words: how long does the user wait before seeing that something happened?

Only three types of interaction count:

a click with a mouse
a tap on a touchscreen
a key press

Scroll, hover and zoom are not measured.

INP looks at all the interactions during the visit, and reports the worst one. If there are a lot of interactions, the browser ignores the highest one for every 50 interactions. That way, one random hiccup does not ruin your score.

The thresholds, at the 75th percentile of your real users:

INP	Result
≤ 200 ms	🟢 Good
200 ms to 500 ms	🟠 Needs improvement
> 500 ms	🔴 Poor

Just a reminder: INP replaced FID (First Input Delay). FID only measured the waiting time of the first interaction. INP measures every interaction, from start to paint. Much stricter.

What's inside an interaction?

An interaction has three phases:

 user clicks                                              next frame
     │                                                        │
     ▼                                                        ▼
     ├────────────────┬──────────────────────┬────────────────┤
     │  Input delay   │ Processing duration  │ Presentation   │
     │                │                      │ delay          │
     └────────────────┴──────────────────────┴────────────────┘
     │◄───────────────── interaction latency ───────────────►│

Input delay: the time before your event handlers start. The browser is busy with something else.
Processing duration: the time to run all your event handlers.
Presentation delay: the time to compute style, layout and paint the next frame.

Keep the first one in mind. This is where third-party scripts hurt the most.

The main thread: a one lane road

The browser has one main thread. It does everything:

runs JavaScript
handles events
computes style and layout
paints

And it does one thing at a time.

A task longer than 50 ms is a long task. During a long task, the browser can't respond to the user.

Now imagine your page with Google Tag Manager, a marketing pixel and an analytics script. The user clicks at the wrong moment:

Main thread, without Partytown

──[ your app ]──[ tag manager 180ms ]──[ pixel 120ms ]──[ click handler ]──[ paint ]──
                      ▲
                user clicks here
                      │◄──────── input delay ────────►│

Your click handler is fast. Your code is clean. And your INP is still bad.

This is the key point: you can write perfect code and still fail INP, because you share the road with scripts you don't control.

Partytown: move the party somewhere else

Partytown is a small library, lazy-loaded, maintained by the QwikDev team. Its goal is simple: move third-party scripts from the main thread into a web worker.

The philosophy: the main thread is for your code. Everything that is not in the critical path can go elsewhere.

flowchart LR
  subgraph Before["Without Partytown"]
    MT1["Main thread<br/>your app + GTM + pixel + analytics"]
  end
  subgraph After["With Partytown"]
    MT2["Main thread<br/>your app"]
    WW["Web worker<br/>GTM + pixel + analytics"]
    WW -. "DOM calls through a proxy" .-> MT2
  end

And the same timeline as before:

Main thread, with Partytown

──[ your app ]──[ click handler ]──[ paint ]──
                ▲
          user clicks here: almost no input delay

Web worker

──[ tag manager 180ms ]──[ pixel 120ms ]──   ← nobody waits for this

The long tasks still exist. They just don't block the user anymore.

⚠️ Partytown is still in beta. It's not guaranteed to work for every script. Test before you ship.

How does it work?

Here comes the tricky part.

A web worker has no DOM. No document, no real window. But third-party scripts expect them. They call document.cookie, getBoundingClientRect(), addEventListener...

On top of that, communication between a worker and the main thread is asynchronous. Third-party scripts are written in a synchronous way. No await, no callback.

So Partytown does two things:

In the worker, it creates JavaScript Proxies that look like window and document.
Each call to these proxies is sent to the main thread through a synchronous channel, and the worker waits for the answer.

From the script's point of view, nothing changed. This code works as is inside the worker:

const rect = element.getBoundingClientRect(); // blocking call, like on the main thread
console.log(rect.x, rect.y);

There are two ways to get this synchronous channel.

Option 1: Service Worker (the fallback)

The worker sends a synchronous XHR. A service worker intercepts it, asks the main thread, and answers.

sequenceDiagram
  participant W as Web worker (3rd-party script)
  participant SW as Service worker
  participant M as Main thread (DOM)
  W->>SW: sync XHR "getBoundingClientRect()"
  SW->>M: postMessage
  M-->>SW: result
  SW-->>W: response { x, y }
  Note over W: for the script, it was a normal blocking call

That's why you'll see a lot of proxytown requests in the network tab. They are not real HTTP requests. They're handled locally. You can hide them with the -url:proxytown filter in Chrome DevTools.

Option 2: Atomics (the fast one)

With Atomics and SharedArrayBuffer, the worker writes the request, calls Atomics.wait(), and reads the result when the main thread answers. No service worker needed.

It's about 10x faster to transfer data between threads.

But there's a condition: the page must be cross-origin isolated. You need these response headers on your document:

Cross-Origin-Embedder-Policy: credentialless
Cross-Origin-Opener-Policy: same-origin

Two things to know:

Safari doesn't support credentialless. So Safari falls back to the service worker.
You can use require-corp instead, which works in Safari. But it blocks every cross-origin image, script or video that doesn't have a crossorigin attribute. Be careful with your CDN.

If the headers are not there, no problem: Partytown falls back to the service worker automatically.

The two rules to remember

Before the code, two rules. They are the same for every framework.

Rule 1: type="text/partytown"

The browser doesn't know this type, so it doesn't run the script. Partytown finds it with a selector and runs it in the worker.

- <script src="https://third-party.com/script.js"></script>
+ <script type="text/partytown" src="https://third-party.com/script.js"></script>

Partytown is opt-in. Only the scripts with this type move. All the others stay where they are. You choose.

Rule 2: forward

Your own code still calls dataLayer.push(...) on the main thread. For example, when a user adds a product to the cart.

But GTM now lives in the worker. So Partytown needs to know which window functions to patch and send to the worker. That's the role of forward. It even queues the calls made before Partytown is ready.

flowchart LR
  A["Your code<br/>dataLayer.push(...)"] -->|"patched by forward"| B["Partytown<br/>(main thread side)"]
  B -->|"serialized message"| C["GTM<br/>in the web worker"]
  C -->|"network"| D["Google servers"]

By default, a forwarded call only runs in the worker. If you need the original function to also run on the main thread, use preserveBehavior:

partytown = {
  forward: [
    ['dataLayer.push', { preserveBehavior: true }], // runs on both sides
    'fbq'                                           // worker only (default)
  ]
};

Now let's have some code.

Angular

Our goal: run Google Tag Manager in the worker, and track page views and a click from our Angular app.

Step 1: install

npm install @qwik.dev/partytown

Step 2: serve the Partytown files

The worker and the service worker are real files. They must be served by your app. In angular.json, add them to the assets:

"build": {
  "options": {
    "assets": [
      {
        "glob": "**/*",
        "input": "node_modules/@qwik.dev/partytown/lib",
        "output": "/~partytown"
      }
    ]
  }
}

After a build, you should see a ~partytown/ folder in your output, with partytown.js, partytown-sw.js, partytown-atomics.js...

Step 3: `index.html`

Third-party scripts must be there early, before Angular starts. So we put everything in src/index.html:

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>My Shop</title>
  <base href="/">

  <!-- 1. Partytown configuration: BEFORE partytown.js -->
  <script>
    partytown = {
      forward: ['dataLayer.push']
    };
  </script>

  <!-- 2. Partytown itself: no async, no defer -->
  <script src="/~partytown/partytown.js"></script>

  <!-- 3. Google Tag Manager, moved to the worker -->
  <script type="text/partytown">
    (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
    new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
    j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
    'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
    })(window,document,'script','dataLayer','GTM-XXXXXXX');
  </script>
</head>
<body>
  <app-root></app-root>
</body>
</html>

💡 While you set things up, use /~partytown/debug/partytown.js and add debug: true to the config. You get logs in the console. Don't ship the debug build to production.

Step 4: an analytics service

Now, our Angular code must talk to GTM. We only push to dataLayer. Thanks to forward, Partytown sends it to the worker.

// analytics.service.ts
import { DOCUMENT, Injectable, inject } from '@angular/core';
import { NavigationEnd, Router } from '@angular/router';
import { takeUntilDestroyed } from '@angular/core/rxjs-interop';
import { filter } from 'rxjs';

declare global {
  interface Window {
    dataLayer: unknown[];
  }
}

@Injectable({ providedIn: 'root' })
export class AnalyticsService {
  private readonly router = inject(Router);
  private readonly window = inject(DOCUMENT).defaultView; // null on the server (SSR)

  constructor() {
    // An SPA has no real page load after the first one.
    // So we send a page view on each navigation.
    this.router.events
      .pipe(
        filter((event): event is NavigationEnd => event instanceof NavigationEnd),
        takeUntilDestroyed()
      )
      .subscribe((event) => this.track('page_view', { page_path: event.urlAfterRedirects }));
  }

  track(event: string, params: Record<string, unknown> = {}): void {
    if (!this.window) return; // nothing to do on the server

    this.window.dataLayer = this.window.dataLayer || [];
    // This call is patched by Partytown: it's serialized and sent to the worker.
    // GTM does its heavy work there, not on the main thread.
    this.window.dataLayer.push({ event, ...params });
  }
}

Start it with the application:

// app.config.ts
import { ApplicationConfig, inject, provideAppInitializer } from '@angular/core';
import { provideRouter } from '@angular/router';
import { routes } from './app.routes';
import { AnalyticsService } from './analytics.service';

export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(routes),
    provideAppInitializer(() => {
      inject(AnalyticsService); // create the service, so it listens to the router
    }),
  ],
};

Step 5: track a click

// product-card.ts
import { Component, inject, input } from '@angular/core';
import { AnalyticsService } from './analytics.service';
import { CartStore } from './cart.store';

interface Product {
  id: string;
  name: string;
  price: number;
}

@Component({
  selector: 'app-product-card',
  template: `
    <h3>{{ product().name }}</h3>
    <button (click)="addToCart()">Add to cart</button>
  `,
})
export class ProductCard {
  private readonly analytics = inject(AnalyticsService);
  private readonly cart = inject(CartStore);

  readonly product = input.required<Product>();

  addToCart(): void {
    // 1. What the user wants to see: update the UI first
    this.cart.add(this.product());

    // 2. Tracking: cheap on the main thread, GTM works in the worker
    this.analytics.track('add_to_cart', {
      item_id: this.product().id,
      value: this.product().price,
    });
  }
}

Look at the click handler. Without Partytown, dataLayer.push wakes up GTM on the main thread, in the same frame as your click. With Partytown, the push is sent to the worker, and GTM runs its tags there. Your handler stays small. Your processing duration stays small.

React

Same goal, same app: GTM in the worker, page views and a click.

There are two ways to do it in React:

Option A: index.html, for a client-side app (Vite, Create React App...). The simplest.
Option B: the <Partytown /> component, for apps rendered on the server (React Router framework mode, Remix, Gatsby...).

Step 1: install and copy the files

npm install @qwik.dev/partytown

Partytown comes with a small CLI to copy its files into your public folder. Run it before dev and build:

"scripts": {
  "partytown": "partytown copylib public/~partytown",
  "dev": "npm run partytown && vite",
  "build": "npm run partytown && vite build"
}

Add public/~partytown to your .gitignore. It's generated.

Option A: client-side app (Vite)

Everything goes in index.html, like in Angular:

<!doctype html>
<html lang="en">
<head>
  <meta charset="UTF-8" />
  <title>My Shop</title>

  <script>
    partytown = {
      forward: ['dataLayer.push']
    };
  </script>
  <script src="/~partytown/partytown.js"></script>

  <script type="text/partytown">
    (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
    new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
    j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
    'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
    })(window,document,'script','dataLayer','GTM-XXXXXXX');
  </script>
</head>
<body>
  <div id="root"></div>
  <script type="module" src="/src/main.tsx"></script>
</body>
</html>

Why not in a component? Because a client-side app renders late. The third-party scripts would wait for React to boot. In index.html, they're found as soon as Partytown starts.

Option B: server-rendered app (the `<Partytown />` component)

The package ships a React component: @qwik.dev/partytown/react. It's a thin wrapper around the Partytown snippet. The config becomes JSX props. And the snippet is inlined in the HTML, so there's no extra request for partytown.js.

Example with a root layout (React Router framework mode / Remix style):

// app/root.tsx
import { Partytown } from '@qwik.dev/partytown/react';
import { Links, Meta, Outlet, Scripts } from 'react-router';

const GTM_ID = 'GTM-XXXXXXX';

const gtmSnippet = `
(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','${GTM_ID}');
`;

export default function App() {
  return (
    <html lang="en">
      <head>
        <Meta />
        <Links />

        {/* 1. Partytown: config as props */}
        <Partytown forward={['dataLayer.push']} />

        {/* 2. GTM in the worker */}
        <script
          type="text/partytown"
          dangerouslySetInnerHTML={{ __html: gtmSnippet }}
        />
      </head>
      <body>
        <Outlet />
        <Scripts />
      </body>
    </html>
  );
}

💡 Add debug={true} on <Partytown /> while you set things up.

Scripts added later

If a text/partytown script is added to the page after Partytown started (lazy loading, route change...), recent versions of Partytown (0.14.3 and later) find it automatically. On older versions, you have to tell Partytown:

const script = document.createElement('script');
script.type = 'text/partytown'; // set the type BEFORE adding it to the DOM
script.src = 'https://third-party.com/widget.js';
document.head.appendChild(script);

window.dispatchEvent(new CustomEvent('ptupdate')); // only needed before 0.14.3

Track page views and clicks

A small module, no library needed:

// analytics.ts
declare global {
  interface Window {
    dataLayer: unknown[];
  }
}

export function track(event: string, params: Record<string, unknown> = {}): void {
  if (typeof window === 'undefined') return; // nothing to do on the server

  window.dataLayer = window.dataLayer || [];
  // Patched by Partytown: serialized and sent to the worker
  window.dataLayer.push({ event, ...params });
}

A hook for page views:

// usePageView.ts
import { useEffect } from 'react';
import { useLocation } from 'react-router';
import { track } from './analytics';

export function usePageView(): void {
  const location = useLocation();

  useEffect(() => {
    track('page_view', { page_path: location.pathname + location.search });
  }, [location.pathname, location.search]);
}

Call it once, in your layout:

// Layout.tsx
import { Outlet } from 'react-router';
import { usePageView } from './usePageView';

export function Layout() {
  usePageView();
  return <Outlet />;
}

And the click:

// ProductCard.tsx
import { track } from './analytics';
import { useCart } from './useCart';

interface Product {
  id: string;
  name: string;
  price: number;
}

export function ProductCard({ product }: { product: Product }) {
  const { add } = useCart();

  function handleAddToCart() {
    // 1. UI first: this is what the user is waiting for
    add(product);

    // 2. Tracking: GTM does the heavy work in the worker
    track('add_to_cart', { item_id: product.id, value: product.price });
  }

  return (
    <article>
      <h3>{product.name}</h3>
      <button onClick={handleAddToCart}>Add to cart</button>
    </article>
  );
}

Using Next.js? Partytown has its own Next.js integration page. Check it, the setup is a bit different.

Check that it works

Don't trust, verify. Three quick checks in Chrome DevTools:

Console: with the debug build, Partytown logs what runs in the worker.
Sources panel: look at the threads. GTM should run in the Partytown web worker, not in the main one.
Performance panel: record a page load and a few clicks. The long tasks from googletagmanager.com should be gone from the main thread track.

Then check in GTM Preview mode that your page_view and add_to_cart events arrive. If nothing arrives, check your forward config first. It's the most common mistake.

Where INP really wins

Let's go back to our three phases.

               Input delay     Processing      Presentation
               ───────────     ──────────      ────────────
Partytown:     big impact      some impact     small impact

Input delay: the big win. Third-party long tasks no longer block the main thread, so the click is handled right away.
Processing duration: the work done by third-party scripts when you push an event (like in addToCart) happens in the worker, not in your handler's frame.
Presentation delay: Partytown batches DOM reads and writes into group updates. Less layout thrashing from third-party code.

Trade-offs: no magic here

Partytown is a great tool. It's not a silver bullet. Here is what you need to know before using it.

preventDefault() has no effect. When the worker receives the event, it's already too late. A script that needs to block a link or a form submit won't work.
DOM operations are throttled. Each call crosses threads. That's fine for analytics, not for scripts that build UI.
UI-heavy scripts are a bad fit. A chat widget, a cookie banner with a dialog, anything that injects a lot of DOM nodes: keep them on the main thread.
CORS. Some third-party scripts don't send the right CORS headers. You'll need to proxy them.
Cross-origin iframes created from a Partytown script can't persist cookies or storage.
Bad scripts stay bad. A script that reads the whole document every X milliseconds with setInterval will overload Partytown.

A quick rule:

Good fit ✅	Bad fit ❌
Google Tag Manager	Chat widgets
Google Analytics 4	Cookie consent dialogs
Facebook Pixel	Scripts that call `preventDefault()`
Mixpanel, Segment, Amplitude	Scripts that inject a lot of DOM

Measure, don't guess

Never move a script "because it should be better". Measure before, measure after.

INP is a field metric. Your real users on real devices are the source of truth. Use the web-vitals library with the attribution build to see which phase is slow. It works the same in React and Angular:

import { onINP } from 'web-vitals/attribution';

onINP(({ value, attribution }) => {
  console.log('INP:', value);
  console.log('Element:', attribution.interactionTarget);
  console.log('Input delay:', attribution.inputDelay);
  console.log('Processing:', attribution.processingDuration);
  console.log('Presentation:', attribution.presentationDelay);
  // send it to your analytics
});

Put it in main.ts (Angular) or main.tsx (React).

Here's how to read the result:

High input delay? Look at what runs before the click. Third-party scripts are the usual suspects. This is where Partytown shines.
High processing duration? It's probably your handler. Partytown won't help.
High presentation delay? Look at your DOM size and your layout.

In the lab, INP depends on what you click. Two tips:

Interact with the page while it loads. That's when the main thread is the busiest.
Use Total Blocking Time (TBT) as a proxy. It's not INP, but it tells you if the main thread is crowded.

Partytown won't fix your own code

If your click handler takes 400 ms, moving GTM to a worker changes nothing.

For your own code, the classic tools still apply:

Break long tasks into smaller ones.
Yield to the main thread (setTimeout, or scheduler.yield() where it's supported).
Show visual feedback first, do the heavy work after.
Move heavy computation to your own web worker.

Partytown handles the code you don't own. You handle the code you own.

Conclusion

INP measures what users feel: "I clicked, did something happen?"

Third-party scripts are often the hidden reason for a bad INP. They take the main thread, and your users wait.

Partytown moves them into a web worker, and keeps them working thanks to a clever synchronous bridge (Atomics or a service worker).

In Angular and React, the setup is small:

serve the Partytown files
add the config and type="text/partytown"
forward the functions your code calls
keep your tracking code as simple as a dataLayer.push

It's not magic. It's in beta, it has trade-offs, and it's not made for UI scripts. But for analytics, tag managers and pixels, it can give the main thread back to the only code that should be there: yours.

Measure first. Move the right scripts. Measure again. 🎉

The Grand Unifying Architecture of Frontend

Ryan Carniato — Tue, 22 Sep 2026 16:43:06 +0000

I used to joke that the history of frontend development could be retraced by following the argument of who owned the state. And the truth is both sides have gone back and forth on this over the years. We started on the document web where state was on the server. Then we added JavaScript and Applets where we could have stateful things in the client. But developers at the time didn't like either much and tried to wire state across both sides in their server languages and we got ASP.NET and the like.

I sit here over 30 years later and it is still going on. Going to replace your React app with HTMX? Maybe. Maybe it isn't that simple. Although this seems like an endless spiral, I don't think this is unsolvable. Even though it has been going on so long, I actually think the answer is in front of us.

The unified model comes down to understanding responsibilities. And they are as old as the web itself. Every time we misalign complexity soars. Every time we ignore part of the puzzle it goes on to bite us. Every solution straddles part of this solution space but we've struggled to cover the whole range.

Core Responsibilities

My observation is that all frontend architectures come down to layering of three responsibilities. Some are more present than others but they all exist in some form.

1. Navigation (client)

The URL is the basis of the web experience and it belongs to the browser. Orchestration is a client responsibility and every solution from SPA to HTML partial agrees with this. JavaScript in the browser is the root of our application.

2. Content (server)

Conversely, content belongs to the server whether it is markup or JSON. The server is the authoritative source. It hangs off of our navigation.

3. Affordances (client)

Affordances find us back in the browser. Local UI state, in progress work, optimistic updates. We need to provide our user feedback faster than a round-trip to the server.

Following the Shape

All web application architectures follow this client -> server -> client layering. A user navigates or performs an action, content comes back from the server, and the client settles it. That's the Single Page Application(SPA) architecture after load, but it's also HTMX. And also LiveView, if the server -> client protocol is powerful enough.

It feels like I'm stating the obvious here. But the web generally maps writes to navigation, and the server only pushes reads. Mutations travel through layer 1 with forms, actions, invalidation, and requests for the content. Layer 2, content, never writes and only publishes.

This asymmetry is what makes it composable. Breaking that leads to two stateful systems fighting against themselves. Which is why affordances like optimism(layer 3) fit cleanly on top if viewed as an overlay. The client never writes server content directly as it doesn't own it.

Revisiting the Spectrum

I've tried many times to map the solution space to a 4 quadrant grid but I never found the right axis. But I'm now seeing how all solutions can sit in the same diagram.

Obviously this is a rough placement, solutions fit spaces not points, and something like React can be used as a frontend in a sync engine like Zero. Here React represents classic SPAs + JSON API. But most frameworks fix both transport and affordance weight so they don't move much.

But if you put it under our lens of responsibility:

HTMX: Minimal layer 1, HTML carries the majority of the work under layer 2, and layer 3 is almost nothing.
LiveView: Layer 2 expands its capability, while layer 3 remains nearly non-existent. Same dance with the read window stretched to the length of the session.
DataStar: More machinery in layer 2 with the addition of server populated Signals allowing for some closer interaction with the client.
Astro(+ View Transitions): navigation(view transition) -> server(markup) -> client(islands). All 3 parts laid out explicitly.
Server Components(Next.js): Like Astro except shared client state is preserved.
SPA + JSON(React): Layer 3 grows until it merges with layer 1. And layer 2 is delegated to JSON APIs.
Sync Engine(Zero): Layer 2 becomes a persistent read of a replicated store, and layer 3 grows to hold a full local copy of it. Optimism over the whole dataset.

Every solution, with a bit of coaxing, is capable of expressing all of these. They differ in transport, window length, and how much affordance code you ship. So it comes down to efficiency and authoring. Which means one framework could cover it all, if each responsibility is adjustable.

A Modern Take

Nothing I've laid out is any different than how the base platform has always worked, but can we mirror this in a way that encompasses the full spectrum of the past 30 years?

I'm going to paint a picture using our 3 responsibilities with Solid 2.0.

Navigation: Delegation and progressive enhancement

Solid's router owns nothing in the render tree. There is no <Link>(or <A>) component. Instead our JSX compiler registers a claim on every a[href] and form[action] element it creates, and server-streamed content gets the same claims swept over any subtree the runtime renders.

// lib/users.ts
export const renameUser = action(
  async (id: string, formData: FormData) => {
    "use server";
    updateUser(id, { name: String(formData.get("name")) });
  }
);

// routes/users/[id].tsx — plain HTML. The compiler claims the
// anchor and the form. The router intercepts both. Works before 
// hydration and after.
<a href={`/users/${id}`}>{user().name}</a>
<form action={renameUser.with(id)} method="post">
  <input name="name" value={user().name} />
  <button>Rename</button>
</form>

Note: There are no components in this markup.

A SolidJS router consumes those claims to manage aria-current, active classes, and interception. This means server-rendered markup with zero client components participates fully in client-side navigation. So it works not only with "No JS" but with JavaScript with no interactive components.

Forms and buttons delegate to server function actions the same way. You hoist your preloads and invalidation correctly and single-flight mutations mean one round trip settles every piece of UI the mutation invalidated whether that UI is JSON-fed client components or server-owned markup.

Content: Reactive reads over the wire

Solid's powerful protocol for layer 2 stands on our "use server" functions. Solid serializes across the boundary with Seroval, which handles not just plain data but async structures, like Promises and async iterators. The communication between server and client is about the data, including data that hasn't settled yet.

export async function report(id: string) {
  "use server";
  return {
    title: await getTitle(id),
    // AsyncIterable<string> — crosses the wire as-is
    progress: watchProgress(id), 
  };
}

// client: the iterable's latest yield is just a reactive read
const r = createMemo(() => report(props.id));
const progress = createMemo(() => r().progress);
<h1>{r().title}</h1>
<p>{progress()}</p>

More than that, the reactive graph propagates over the wire. On the server, every expression feeding the client is an open binding for the life of the response. When a promise settles or iterator yields the server re-runs the expression and sends the new value to the client to be replaced or morphed.

So far I've showcased this in examples around the original response, ie what happens during hydration. Even if the content chunks stream in as they initially are ready, we can continue to update the stream in place as long as the request stays open.

But the same can be true of server function requests after the fact. We can send back would-be static markup, "Server Components", and have their reactive graph never ship to the client while still doing these streamed pinpoint updates. We will be announcing the preview for our Server Component feature soon (but if you look you can already see fully working examples in our repo).

export async function countdown(n: number) {
  "use server";
  const ticks = tick(n); // AsyncIterable<number>, one per second

  // returning a function returns a Server Component
  return () => {
    const count = createMemo(() => ticks);
    return <p>Counted to {count()} of {n}</p>;
  };
}

// client — zero component code ships for this
const Counter = dynamic(() => countdown(10));
<Counter />

Because the communication is one-way with a single authoring model, the transport is pluggable. Today we use Request/Response, so it lives as long as the request is open and you reconnect as needed. Swap in something persistent like SSE or a socket and the same server component becomes a non-terminating live component.

// request/response — left side of the grid
export const getAuction = GET(async () => {
  "use server";
  return read();
});

// persistent — right side of the grid
export const liveAuction = live(async function* () {
  "use server";
  while (true) { yield read(); await changed(); }
});

// the consumer doesn't care which one it got
const [auction] = createOptimisticStore(() => liveAuction(), {});

What makes this safe is what LiveView's failure mode teaches us: The server's live graph must be a re-derivable projection of durable state. It is never the source of truth. Reconnection doesn't depend on sessions, event replay, or anything that dies with a process.

Affordances: An async-aware graph that hydrates once

This is an area SolidJS has excelled in. But in 2.0, async became native to the graph. A value arriving from the server content channel and a value computed locally are indistinguishable to the consumer.

Optimism is a first-class primitive. It isn't just something bundled with the server functions or query caching library. Optimism represents any uncommitted state predicted over async, whatever the async source. It's a general concept. It doesn't just represent what some might consider "lying to the user", it doesn't have to masquerade as an invisible success. It represents any predictive ephemeral affordance. It either settles eventually as truth or it is reverted, but it never outlives its transaction. It prevents getting out of sync.

const [auction, setAuction] = createOptimisticStore(() => liveAuction(), {});

const placeBid = action(function* (amount: number) {
  // overlay — reverts on settle
  setAuction(a => { a.highBid = amount });
  // mutation - the write goes up
  yield bid(amount);
  // hold until truth comes back down             
  yield until(() => auction.highBid >= amount);
});

This all works because we never hydrate more than once. After startup, the server should never render a client component as client state has diverged from anything the server could know. This is a critical naive breaking point in HTML Partial and Islands solutions that share client state. Hydrating after state has updated is a recipe for hydration mismatches. While we can safeguard during the initial streaming progression, that isn't a realistic proposition over the life of an application.

A rule like that only holds if the system enforces it. Every piece of server content is keyed by the call that produced it, the function and its arguments, the same key a query cache would use. Content arriving on any transport only ever writes to that address's store, and mounted UI pulls from the address it's bound to. There is no direct connection from the network to the DOM. So a hover preload can't clobber the page you're looking at, a refetch morphs in place while the client-owned ranges inside it survive, and a stale response doesn't pass a version check.

Under this unified model, initial load gets the same treatment without paying serialization twice. Client components claim their server-rendered nodes and boot makes zero requests. The only serialized records are values the client requires. Server-only content ships as HTML or as data, never both. The page markup is the payload. For server components, that means always one copy. View-source and search for any piece of content and you'll find it exactly once.

I once positioned this as "Facing Frontend's Existential Crisis", but now it is a solved problem.

Traversing the Spectrum

What makes this exciting is with the pieces above you are completely free to move the whole solution space and every point in between.

If you start in the lower left corner, that would be like a SolidJS app with no client components that just swaps server component chunks on server "use server" actions bound to <form action>. Server markup streams and morphs, and navigation is handled without any client components.

The top left-hand side is when we extend layer 3 until it dominates and you have the SPA and there are no server components or server rendering at all. Just JSON APIs.

And we can continue to traverse over the top to the right-hand side by the way of persistent "use server" functions and our granular optimistic layer. Solid's live and until operators help close the gap when the client state is streamed in as available. I'd still use a dedicated sync engine, but the base primitives alone do a good impression.

Finally, the lower right corner, is closer to where we started. Except this time our server components have reactive bindings and their connection is persistent. No client components, just our same "use server" action protocol to write back, while our reads stream fine-grained markup partials over the wire. In this world, even the server components could be optimistic depending on how you write your actions, and until again gives us a mechanism for completion acknowledgements.

The incredible part is that this required nothing that users of Solid 2.0 aren't already familiar with. Async Signals and use server. With that, all these experiences are authorable using basically the same patterns, in the same framework, even in the same application.

Conclusion

It goes back to where we started. A few pieces that have been sitting in front of us this whole time.

The browser owns navigation and affordances. The server owns content. Communication is a loop with writes travelling as navigation and content travelling as one-way reads. And the transport and the response window should be configurable without changing the shape of authoring.

Everything from HTMX to LiveView to islands to the SPA is a coordinate on this grid. The differences between them are efficiency and ergonomics rather than expressiveness.

What makes this more than an exercise in categorization is that all the hard pieces are built. We serialize and hydrate once. The reactive graph serializes its own updates. Content is stored by address, so stale hydration can't be represented.

It comes as little surprise to me that Signals can act as that common representation on all sides. Sync and async. Server and client. Stateful and stateless.

This is stupidly ambitious. RSCs only aimed to provide the left half of the grid and many felt they still fell short. The HTML-over-the-wire camp has aimed to provide the bottom half, but ignoring the client is ignoring an entire responsibility.

And yet, this is a future that I want to live in. One where choosing a framework doesn't require you to choose a religion. And one, from my perspective, that is already here.

SpellBook of Skill: The Twin Project Nobody Asked For, But I Built Anyway 🧙🏻‍♂️

Domenico Tenace — Mon, 21 Sep 2026 07:00:00 +0000

Overview

Hey everyone 👋

A while back I launched Spellbook of Prompt, my curated collection of prompts organized by use case. It's been out there growing steadily, and at some point while adding new entries I kept thinking: prompts are only half the story. Knowing how to build something matters just as much as knowing what to ask an AI to do.

So I built the twin project. Meet Spellbook of Skill, a curated collection of development skills, tutorials, and guides to help you level up your craft from fundamentals to advanced techniques.

Let's dive in! 🤙

What It Actually Is 🤔

Where Spellbook of Prompt gives you the incantation, Spellbook of Skill teaches you the magic behind it. It's structured, practical guides organized by category and difficulty, each one built to save time and actually get you somewhere, not just another wall of theory.

Every guide follows the same shape: a clear learning objective, a working code example, prerequisites listed upfront, and a troubleshooting section for when things inevitably don't work on the first try. The concepts are language and framework agnostic where possible, so what you learn actually transfers instead of being locked to one stack.

The whole thing runs on Astro with Starlight, same setup as Spellbook of Prompt, so browsing is fast and the docs feel consistent across both projects. It's a genuine sibling project, same philosophy, different content.

Built Entirely with OpenCode + OpenRouter + DeepSeek V4 Pro 🛠️

Here's the part that ties back to everything I've been writing about lately. I built Spellbook of Skill end to end using OpenCode wired through OpenRouter, running on DeepSeek V4 Pro 0813.

No manual scaffolding, no switching to a pricier model halfway through. The project structure, the Astro and Starlight configuration, the content schema, the initial category setup, all of it came out of that same combo I've been using as my daily driver. If you've read my previous pieces on DeepSeek's cost-to-quality ratio or on wiring OpenRouter into OpenCode, this is that setup doing real, shippable work again.

It's honestly become my proof of concept for "can a budget model stack actually ship a complete open source project." So far the answer keeps being yes.

What's In There Right Now 📚

The structure is organized by category, starting with:

Content Creation, structured prompts and guides for writing clear technical articles, the same kind of workflow I use for these posts.

More categories are marked as coming soon: coding and development workflows, DevOps and deployment, system design and architecture, design and creative development, career and professional growth.

It's early. I'd rather be upfront about that than oversell it. The foundation, the docs site, the contribution flow, the conventions, is all solid and ready. The content library is what needs to grow now, and that's exactly where the community comes in.

This Is Where You Come In 🤝

Spellbook of Skill is MIT licensed and genuinely open to contributions. Whether you want to add a new guide, improve an existing one, or just fix something that's broken, there's a clear path to do it.

The process is simple: search existing guides first to avoid duplicates, add or update a guide in the right category folder, include a clear title, description, and at least one complete working example, then open a pull request with a short summary. Guides should stay concise and actionable, list prerequisites and learning objectives, include a troubleshooting section, and obviously never contain real secrets or sensitive data.

Full details are in the CONTRIBUTING.md file if you want the complete picture before jumping in.

If you've got a skill you wish someone had written down clearly when you were learning it, that's exactly the kind of guide this project needs. Beginner content is just as valuable as advanced content here.

Try It Out 🚀

The live docs are up at spellbook-of-skill.netlify.app, or clone it and run it locally:

git clone https://github.com/Domenico-Tenace-Open-Labs/spellbook-of-skill.git
cd spellbook-of-skill
pnpm install
pnpm dev

Then open localhost:4321 and start browsing.

Final Thoughts 🌟

Spellbook of Prompt and Spellbook of Skill now sit side by side under Domenico Tenace Open Labs, one teaching you what to ask, the other teaching you how to actually do it. Together they cover more ground than either could alone.

If you're curious about the project, go star it, and if you've got something worth teaching, open a PR. This is exactly the kind of thing that gets better the more people show up.

The spellbook grows. 🔥

Happy coding! ✨

🌲 Links: https://links.domenicotenace.dev/
🐙 Domenico Tenace Open Labs: https://github.com/Domenico-Tenace-Open-Labs
📰 Newsletter: https://domenicotenace.substack.com/subscribe

If you like my content or want to support my work, you can support me with a small donation. I would be grateful 🥹

☕ Buy me a Coffee: https://buymeacoffee.com/domenicotenace

OpenCode + DeepSeek V4: The Budget Combo That Doesn't Feel Like a Budget Combo 🐋

Domenico Tenace — Tue, 01 Sep 2026 07:00:00 +0000

Overview

Hey everyone 👋

I've spent the last few weeks running most of my daily coding work through OpenCode wired to DeepSeek V4, both Pro and Flash. Not as an experiment, as my actual default setup. And the thing that keeps surprising me is how rarely I miss Claude or GPT for everyday tasks, while paying a fraction of the price.

I also used DeepSeek exclusively to generate an entire Astro template from scratch, Studio Pulse, which turned out to be a genuinely good test of what these models can actually do unattended.

Let me walk you through what I found. Let's dive in! 🤙

Quick Context on DeepSeek V4 🤔

DeepSeek V4 is an open weight, MIT licensed model family that went GA in two waves this year, V4-Flash on July 31 and V4-Pro on August 13. Both are mixture of experts models with a 1M token context window.

V4-Pro runs 1.6T total parameters with 49B active per token. V4-Flash is leaner, 284B total with 13B active. Both support tool use, function calling, and a thinking mode that effectively replaces the old R1 reasoning line.

The current API pricing sits at $0.435/$0.87 per million input/output tokens for Pro, and $0.14/$0.28 for Flash. Cache hit input drops even further, down to $0.0036 for Pro and $0.0028 for Flash. For context, Claude Opus output alone costs $25 per million tokens. A dollar buys you roughly 500K off-peak output tokens from V4-Pro, versus 40K from Opus.

That's not a small gap. That's an order of magnitude.

Setting It Up with OpenCode 🔧

Since OpenCode is model agnostic, plugging in DeepSeek is just a matter of pointing it at DeepSeek's API endpoint (or routing through OpenRouter, which I also do for some workflows). No special configuration, no compatibility layer, it speaks both OpenAI ChatCompletions and Anthropic API formats natively.

I keep both models available and switch depending on the task:

DeepSeek V4 Flash for quick iterations, small fixes, boilerplate, and anything where speed matters more than depth.

DeepSeek V4 Pro for anything that needs real reasoning, architecture decisions, or larger refactors.

Switching between them mid-session in OpenCode takes one command. No restart, no reconfiguration.

What Actually Impressed Me 👍

The cost is almost absurd. Running a full day of development work, dozens of file edits, multiple refactoring sessions, test generation, through V4-Pro costs me less than a coffee. Through V4-Flash it's closer to pocket change. I stopped thinking about token budgets entirely, which changes how you work. You stop being conservative with your prompts.

Coding quality holds up. On Artificial Analysis benchmarks, V4-Flash scores 69.1 on the coding index, ranking 29th out of nearly 200 models tracked. That's genuinely competitive, not "good for the price," just good. For everyday tasks, boilerplate, CRUD logic, component generation, API routes, I couldn't tell the difference from more expensive models in blind use.

The 1M token context window is a real advantage. Both models default to a million tokens of context. For large codebases or long refactoring sessions where you want the model to see everything at once, this matters more than raw intelligence scores.

Tool use and function calling are solid. Agentic workflows in OpenCode, file edits, shell commands, multi-step tasks, worked reliably. I didn't run into the kind of tool-call confusion I've seen with smaller open models in the past.

Cache hit pricing rewards good habits. If you structure your prompts with static content first and variable content last, DeepSeek's caching drops input costs by roughly 88%. That's a meaningful incentive to write better prompts, and OpenCode's session handling makes this easy to leverage naturally.

Where It Falls Short 👎

Agentic capability trails coding capability. DeepSeek themselves and independent reviews are honest about this: the model handles individual coding tasks well, but complex autonomous multi-step processes need tighter task boundaries and more validation than you'd need with Claude Opus or GPT-5.5. Long, loosely defined agent runs are where it's more likely to drift.

No image or video input. V4 is text and code only. If your workflow involves reviewing screenshots or mockups, you're switching models anyway.

Pricing isn't fully stable. DeepSeek has already signaled a broader price increase without publishing new rates yet, and peak/off-peak tiers were introduced in mid-August. The eye-popping pricing I quoted above could shift. Budget for it, but don't assume it's permanent.

Less polished on ambiguous instructions. When a prompt is vague, DeepSeek tends to make more assumptions than Claude does. Being explicit about what you want pays off more here than with pricier models that are better at inferring intent.

Reasoning depth on genuinely hard problems. For architecture decisions with lots of competing trade-offs, V4-Pro is good but not at the level of the very top tier models. I still occasionally reach for something stronger when the stakes are high enough to justify the cost difference.

The Real Test: Studio Pulse 🚀

To really push this setup, I built Studio Pulse entirely through DeepSeek, no manual coding, no assist from another model.

It's a template for a full-service communication agency marketing site: multi-page structure with home, about, blog, and contact, dark and light mode with OS preference detection and persistence, SPA-style page transitions via Astro's ClientRouter, a blog powered by content collections with typed frontmatter, and accessibility handled properly, skip links, semantic landmarks, focus-visible outlines, reduced-motion support.

Stack is Astro 7 with Bulma 1.0.4, statically generated, dependency-light, pnpm as the package manager. Clean project structure, typed content schema, CSS custom properties for theming.

What stood out building it: DeepSeek handled the Astro-specific patterns (content collections, the loaders API, client router transitions) correctly on the first or second pass most of the time. The accessibility details weren't an afterthought either, I asked for them once early in the process and the model kept applying them consistently across new pages without being reminded.

It's live at studio-pulse-demo.netlify.app, MIT licensed, and available as a GitHub template if you want to spin up something similar.

Who Should Try This Combo 🎯

If you're cost-conscious and building things where "good enough" coding quality is genuinely enough, which is most day-to-day development, this setup is hard to beat. Side projects, templates, internal tools, prototypes, all of it fits well within DeepSeek's strengths.

If you're running agent pipelines at scale where token costs actually matter to your bottom line, the math here is compelling enough to at least test against your current model.

Where I'd still reach for something else: safety-critical code, deeply ambiguous architecture decisions, or long autonomous agent runs with minimal supervision. That's where the extra cost of a stronger model still earns its keep.

Final Thoughts 🌟

I didn't expect to make DeepSeek V4 my daily driver, but that's what's happened. Between OpenCode's flexibility and DeepSeek's pricing, the barrier to just trying things dropped to nearly zero, and that changed how much I experiment.

Studio Pulse is proof that a fully model-generated project doesn't have to feel like a rough draft. It's not a toy, it's an actual usable template with real attention to detail.

Is DeepSeek the best model on the market right now? No. Is it the best model per dollar? By a wide margin, yes. And for most of what I build day to day, that's the metric that actually matters.

Happy coding! ✨

🌲 Links: https://links.domenicotenace.dev/
🐙 Domenico Tenace Open Labs: https://github.com/Domenico-Tenace-Open-Labs
📰 Newsletter: https://domenicotenace.substack.com/subscribe

If you like my content or want to support my work, you can support me with a small donation. I would be grateful 🥹

☕ Buy me a Coffee: https://buymeacoffee.com/domenicotenace

DEV Community: Playful Programming

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

Language choices may also reflect agent defaults

Open source supplies both the foundations and the tools

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

The hackable badge and culture when no one is looking

From web simulation to MicroPython in the Copilot app

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

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

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

Why DevOps is the real prerequisite for AI agents

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

GitHub Next and Chopin: Rethinking collaborative planning with agents

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

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

The closing message: You write the story

What I am taking back from Universe

Emanuele BartolesiFollow

I Open-Sourced My Web Developer Agent. AI Is Supercharging Open Source.

What I shipped, and where it sits

Open source is growing faster than ever (and AI is part of the why)

Agents have become the new contributors

The open source economy is finally getting some help

The honest counterweight

What this means for you

The flywheel

Sources

Astro Wellness: The First Project Built Start to Finish by My Agent Team 🏋️

Overview

What Is Astro Wellness? 🤔

How the Team Worked on It 👥

What Worked 👍

What Was Harder 😬

Try It, Fork It, Break It 🚀

Final Thoughts 🌟

One Dev, Four Specialists: My Agent Team for OpenCode 🧑‍💻

Overview

The Team 👥

The Golden Rule: Propose First, Apply After Approval ✋

Anatomy of an Agent File 🔧

One Dedicated Skill Per Subagent 🎯

How the Delegation Works 🧭

Why This Beats a Single Agent 💡

The Downsides 😬

Final Thoughts 🌟

Closed vs Open Source AI: Who Really Owns Your Data? 🔓

Overview

Closed vs Open: The Quick Version

Why Open Source Is Worth a Look

Your Data Stays at Home 🔒

No Vendor Lock-in 🔓

You Can Look Inside and Make It Yours 🛠️

The Catch

So What Should You Do? 🎯

Final Thoughts 🌟

Step 3: `index.html`

Option B: server-rendered app (the `<Partytown />` component)