Oren Melamed

My mom always told me I'm gonna be a star one day 💫 Thank you @github

I wrote about fusion earlier this month Now out! This is the next era of model router but it is much more - remote model router is not enough and you need a system that operates both on client and server to really help you understand the task in hand And… it is halving prices!

And @GitHubCopilot is in every part of the tool chain From signal to value If you ever adopted AI and your engineers said they work faster but your ROI didn’t move? So it is because u need a platform and not just a coding agent

If you wonder how AI looks like from the system side!!! Let that sink!!!! This is crazy growth

GitHub @Copilot is much more than chat in an IDE. U know how much I like to track @code codebase, but now we can see how features Individually come together to a platform shift. My take 👇

Last year, we were so naive 😅 Instructions were already a thing, MCPs and custom agents were the big craze, and Beast Mode was the agent everyone was talking about. Shoutout @burkeholland 👏 Look how much has changed since. Looking forward to this year’s @githubuniverse to learn, share, and see what’s next. Wheels off ✈️

This is a hidden jam with the @GitHubCopilot orchestration In the desktop app or the @code agents window you can just tell the agent where the work should happen and it opens parallel agent session on top of the repos you need, they communicate back and forth with session tools and you get distributed work done without needing to think about it too much And there are so many insides for working like this Focused tasks for focused agents with focused context windows The remote agent sessions load the specifics of each repos so it there are specific skills or instructions it will load and use them and act as specialized agents It is GitHub and git based so you still retain the full traceability between agents and work done via PRs and logs across the repos In general and this might require some effort, but when the orchestrator gets signals from all working over repos agents that work is done you can ask it to run another agent to do cross repo review by pulling all of it together and comparing not just against code but against original business requirement And not to mention - it scales with GitHub so you don’t need to claim you have one repo with 30000 PRs that requires u to write your own new git

The @github Star swag arrived ⭐️ Next stop: GitHub Universe in San Francisco. Looking forward to seeing what’s next for GitHub and catching up with the people building the future of software development. Who else is going? Let’s connect.

You don’t need to rebuild Git. You’re not merging 30,000 code changes a day like Anthropic(yet). Just ship.

Getting agents to build state machines so they can work as a state machine just got verified by @mattpocockuk But if u r not Matt and have zero clue how to do that you should leverage @GitHubCopilot Dynamic Workflows Bonus points if you use HydraFusion nitter.cf/orenme/status/21059027…

The biggest flaw in how we measure AI ROI? Assuming every token creates value and every minute saved translates into business impact. Neither is true by default. More PRs, faster delivery, growing AI spend. Where’s the corresponding growth in revenue?

HydraFusion is evolving, and there a shiny new v2 that brings a pretty interesting change to the @GitHubCopilot experience. The biggest change isn't just the new Max Mode, although - yes, there is a new Max mode. But it's also how HydraFusion is becoming part of Auto. Instead of having HydraFusion as a separate option in the model picker, which was uber annoying IMHO, HydraFusion and HydraFusion Max now have their own tier in Auto's "Optimize for" UI. You can choose between the regular HydraFusion and the new Max variant, depending on how much you want to push for quality. A quick reminder of what makes HydraFusion interesting in the first place: It's not a model. It's a multi-model orchestrator that chooses how to approach a task. - Single: One model handles the task. - Cascade: Start with a more efficient model and escalate when needed. - Critique: One model solves the task, another reviews it, and the first gets a chance to revise. With v2, this approach is becoming a more integrated part of Auto, with an explicit higher-tier option through Max Mode. My take: we're moving away from choosing which model writes our code to choosing how much effort we want the system to invest in solving the problem. Not every task needs the same level of reasoning, and I like the direction of making that trade-off an explicit part of the experience. Still a research preview, but definitely worth exploring in VS Code Insiders. And look out for your tokens if you throw a too complex task on it - it will solve it, but boy you are gonna spend 😄

VS @code is experimenting with something simple that could make sessions significantly cheaper to run: changing the order of the system prompt. Let me explain - A system prompt contains both stable instructions and information that changes between sessions. If that changing information appears too early, it can prevent the model provider from reusing a large portion of the cached prompt. The new experimental setting in @code , chat.copilot.stabilityOrderedPrompt.enabled, addresses this by grouping the system prompt into global, repository, and session-specific blocks. Stable content comes first. Session-specific information moves to the end. The results from two test sessions with Claude Opus 5.5 were interesting: - Cache reads increased from 14.5K to 23K tokens. - Uncached tokens dropped from 10.7K to 2.3K. - Reported credits dropped from 5.9 to 1.6. That's roughly 73% fewer credits for the measured model call!!!! The change is experimental, and it also changes the order in which the model sees instructions, so cost isn't the only thing to validate. The required runtime support is another dependency. The bigger point is that context engineering isn't just about what you put into the context window. It's also about how you structure it - and it is really great to see the team putting the effort to reduce our overall cost of usage One caveat that we need to bare in mind: these are results from a specific test, not a guarantee of the same savings across models, workloads, or sessions.

This is a big step by @github for @GitHubCopilot cloud code review. The harsh truth is that tokens are tokenomics. They’re metered, budgeted, and tracked across organizations. People are literally afraid to use code review because they don’t want to burn through their own token budget, even when the pricing is fair and the results are good. Now, organizations using @GitHubCopilot can enforce global rules for cloud code review and have it billed at the org level. That takes the cost burden off the individual developer and makes code review a team-level capability. But that doesn’t mean you should review every PR and every push. That can be wasteful too. My preferred trade-off: - Automatically review when a PR is opened. - For subsequent reviews, trigger Copilot manually in the PR comments. This gives you a useful baseline while keeping control over how often you spend tokens on another review. One more thing: reviewing code in isolation only gets you so far. In enterprise applications spanning multiple repos, the real question isn’t just whether the code looks good. It’s whether the implementation matches the original intent. What I do is keep the specs, the intent, in a central repo, and use a CODE-REVIEW.md skill that instructs Copilot code review to use GitHub MCP to fetch the relevant specs and validate the implementation against them. That turns code review from “spot issues in this diff” into something closer to “does this implementation actually deliver what we designed?” Don’t sleep on @GitHubCopilot code review, especially with this new billing option. It’s becoming a standalone capability from a billing perspective, while remaining deeply integrated with the GitHub platform and Copilot’s customization and memory capabilities. Yes, you heard that right. Copilot can learn your preferences and remember them. The interesting part isn’t just getting AI to review more code. It’s making code review an organizational capability, with the right cost controls and the right context. I’ll sum it up: 1. Cost ownership enables policy, not just usage. 2. Review cadence should follow the development lifecycle. 3. The biggest opportunity is reviewing against intent. A review that understands requirements, architecture decisions, and cross-repo dependencies can catch problems that a diff-only review won't.

Agent Bakeoff is coming to @GitHubCopilot . Instead of running the same task manually with different models, you can now run multiple agent attempts and compare the results side by side. You can run 2-10 attempts, use different models, or even run the same model multiple times. Each attempt gets its own isolated worktree, while the workspace, harness, execution mode, permissions and other task configuration stay consistent. Then you can add a Judge to evaluate the attempts and a Synthesizer to combine the results. So: Task → multiple agent runs → Judge → Synthesis There is also telemetry around the comparison, including the comparison ID and the role of each participant. What I find more interesting is how this fits with some of the other things landing in Copilot right now that I recently wrote about. HydraFusion is exploring how Copilot can dynamically choose a workflow and coordinate multiple models within a turn. Dynamic Workflows go in almost the opposite direction: you define the process - the steps, conditions, handoffs, parallelism and checkpoints - and agents execute the parts that need reasoning. And Agent Bakeoff gives you a way to experiment with the execution itself and compare the outcomes. So I don't see these as three competing features at all. I see them as different pieces of the same direction: Define the process. Choose or discover how to execute it. Run multiple approaches. Evaluate the results. That's a much more interesting direction than simply adding another model to the picker. I think this is where @GitHubCopilot really shines vs other harnesses especially lately with all of these features. [Quite a long video, the start is where the initial config is being set, then mostly seeing the 4 agents I chose going at it while some opened the browser and some just worked, and eventually towards the end the judge and the synthesis - which honestly failed for me 😅 )

These dystopian premonitions are very strange to me First all of the examples given are very biased Devs also code alone today, pair programming is a myth, but planning, brainstorming and charting on a board - these are things we do together and also doctors do and I want to believe also mechanics The actual work at the end is done alone maybe and that’s what is being replaced So maybe actually AI will make us work a lot more together in the interesting things I personally really don’t want to work alone So no, I don’t think dev teams are going away, just going somewhere new and exciting