Arguably, the first of many exciting chapters in MCP development this year - the ability to render user interfaces within the chat experience. Finally, we’re going beyond just text.

Starting April 28, 2026, apps and games uploaded to App Store Connect need to meet the following minimum requirements:

• iOS and iPadOS apps must be built with the iOS 26 & iPadOS 26 SDK or later
• tvOS apps must be built with the tvOS 26 SDK or later
• visionOS apps must be built with the visionOS 26 SDK or later
• watchOS apps must be built with the watchOS 26 SDK or later

Learn more about submitting

There’s a new report about two AI coding assistants, used by 1.5 million developers, that are surreptitiously sending a copy of everything they ingest to China.

Maybe avoid using them.

From an Anthropic blog post:

In a recent evaluation of AI models’ cyber capabilities, current Claude models can now succeed at multistage attacks on networks with dozens of hosts using only standard, open-source tools, instead of the custom tools needed by previous generations. This illustrates how barriers to the use of AI in relatively autonomous cyber workflows are rapidly coming down, and highlights the importance of security fundamentals like promptly patching known vulnerabilities.

[…]

A notable development during the testing of Claude Sonnet 4.5 is that the model can now succeed on a minority of the networks without the custom cyber toolkit needed by previous generations. In particular, Sonnet 4.5 can now exfiltrate all of the (simulated) personal information in a high-fidelity simulation of the Equifax data breach—one of the costliest cyber attacks in history­­using only a Bash shell on a widely-available Kali Linux host (standard, open-source tools for penetration testing; not a custom toolkit). Sonnet 4.5 accomplishes this by instantly recognizing a publicized CVE and writing code to exploit it without needing to look it up or iterate on it. Recalling that the original Equifax breach happened by exploiting a publicized CVE that had not yet been patched, the prospect of highly competent and fast AI agents leveraging this approach underscores the pressing need for security best practices like prompt updates and patches.

AI models are getting better at this faster than I expected. This will be a major power shift in cybersecurity.

Editor’s note: A version of this blog was originally published in The GitHub Insider newsletter. Sign up now for more technical content >

If you’ve ever felt like GitHub Copilot could be even stronger with just a little more context, you’re right. Context engineering is quickly becoming one of the most important ways developers shape, guide, and improve AI-assisted development.

What is context engineering?

Context engineering is the evolution of prompt engineering. It’s focused less on clever phrasing and more, as Braintrust CEO Ankur Goyal puts it, on “bringing the right information (in the right format) to the LLM.”

At GitHub Universe this past fall, Harald Kirschner—principal product manager at Microsoft and longtime VS Code and GitHub Copilot expert—outlined three practical ways developers can apply context engineering today:

• Custom instructions
• Reusable prompts
• Custom agents

Each technique gives Copilot more of the information it needs to produce code matching your expectations, your architecture, and your team’s standards.

Let’s explore all three, so you can see how providing better context helps Copilot work the way you do.

1. Custom instructions: Give Copilot the rules it should follow

Custom instruction files help Copilot understand your:

• Coding conventions
• Language preferences
• Naming standards
• Documentation style

You can use:

• Global rules: .github/copilot-instructions.md
• Task-specific rules: .github/instructions/*.instructions.md

For example, you might define how React components should be structured, how errors should be handled in a Node service, or how you want API documentation formatted. Copilot then applies those rules automatically as Copilot works.

Learn how to set up custom instructions 👉 

2. Reusable prompts: Standardize your common workflows

Reusable prompt files let you turn frequent tasks—like code reviews, scaffolding components, generating tests, or initializing projects—into prompts that you can call instantly and consistently.

Use:

• Prompt files: .github/prompts/*.prompts.md
• Slash commands such as /create-react-form to trigger structured tasks

This helps teams enforce consistency, speed up onboarding, and execute repeatable workflows the same way every time.

See examples of reusable prompt files 👉 

3. Custom agents: Create task-specific AI personas

Custom agents allow you to build specialized AI assistants with well-defined responsibilities and scopes. For example:

• An API design agent to review interfaces
• A security agent that performs static analysis tasks
• A documentation agent that rewrites comments or generates examples

Agents can include their own tools, instructions, constraints, and behavior models. And yes, you can even enable handoff between agents for more complex workflows.

Learn how to create and configure custom agents 👉 

Why context engineering matters

The goal isn’t just better outputs, it’s better understanding by Copilot. When you provide Copilot with clearer context:

• You get more accurate and reliable code.
• You reduce back-and-forth prompting.
• You increase consistency across files and repositories.
• You stay in flow longer instead of rewriting or correcting results.

And the more you experiment with context engineering, the more you’ll discover how deeply it can shape your development experience.

More resources

• A practical guide to context engineering for developers 👉 
• How to build reliable AI workflows with agentic primitives 👉 
• What makes a great agents.md file? Lessons from 2,500+ examples 👉 

The post Want better AI outputs? Try context engineering. appeared first on The GitHub Blog.

At GitHub, we hear questions all the time that probably sound familiar to you:

• Does AI really help, or are you just trying to get me to use your product?
• Can I trust AI tools with my codebase?
• Are these tools built for marketing, or for real productivity?
• Does AI improve my flow, or break it?

These questions are real and valid. I did a livestream for our regularly scheduled Rubber Duck Thursdays (which you should check out on GitHub’s YouTube, Twitch, and/or LinkedIn weekly!) with Dalia Abo Sheasha, Senior Product Manager for Visual Studio, to talk about these things and more!

Check it out, or read on for the highlights:

Centering developers, protecting flow

If you ask most software engineers what they most want out of a tool, the answer usually isn’t “more automation.” Most developers are looking for a smoother, less interrupted path toward flow, that state where code and ideas come easily. It’s a fragile state.

We’ve seen again and again that anything causing context-switching (even a well-meaning suggestion) can snap that flow. With that in mind, at GitHub, we design and test our AI features where developers already work best: in their editor, the terminal, or the code review process. And we give developers ways to tune when, where, and how these tools make suggestions.

Your tools should support your workflow, not disrupt it. We want AI to help with the stuff that gets you out of flow and keeps you from building what matters. If a feature doesn’t truly make your coding day better, we want to know, because the only good AI is AI that actually helps you.

Chat has its limits

It’s tempting to believe that everything should be chat-driven. There’s power in asking “Can you scaffold a template for me?” and getting an instant answer. But forcing all interaction into a chatbox is, ironically, a fast path to losing focus.

I’m required to switch my attention off my code to a different place where there’s a chat where I’m talking in natural language. It’s a huge burden on your brain to switch to that.

Dalia Abo Sheasha, Senior Product Manager, Visual Studio

For many developers, chat is better suited to on-demand tasks like code explanations or navigating frameworks. If chat panels get in the way, minimize or background them. Let the chat come to you when you actually have a question, but don’t feel pressured to center your workflow around it.

Empowerment, not automation for its own sake

User data and developer interviews show us that effective AI empowers developers, but doesn’t replace their judgment.

Time and again, developers have told us what they really want is a way to skip repetitive scaffolding, boilerplate, and tedious documentation, while still holding the reins on architectural decisions, tricky bugs, and business logic.

As I explained during the stream: Focus on different behaviors for different audiences. Senior developers already go fast, but you’re trying to change their established behavior to help accelerate them. But for students, you’re training a brand new behavior that hasn’t been fully defined yet.

Use AI-generated explanations to deepen your own understanding. They should never be a replacement for your own analysis.

Cassidy Williams, GitHub Developer Advocate

And we want them to learn because the students—the early-career developers of today—are the senior developers of tomorrow, and everything’s changing.

What stage are you in in the learning process? If you are at the very beginning and you are learning syntax and the fundamentals of programming, use it to explain the fundamentals so you can have that strong foundation.

Dalia Abo Sheasha

AI suggestions that blend in

AI truly shines when it works alongside you rather than in front of you.

Developers tell us the most valuable AI experiences come from suggestions that surface contextually, such as suggesting a better function or variable name when you initiate a rename, or autocompleting boilerplate. In these moments, the AI tool feels like a helper handing you a useful snippet, not an intrusive force demanding attention.

Most AI assistants offer ways to adjust how often they pop up and how aggressive they are. Take a few minutes to find your comfort zone.

The human at the center

AI should be your tool, not your replacement. AI tools should empower you, not take over your workflow. We want AI to remove tedium by suggesting improvements, writing docs or tests, catching issues… not to disrupt your creative flow or autonomy.

The most critical ingredient in software is still the human developer: your insight, judgment, and experience.

Learning from failure

Not every AI feature lands well. Features that interrupt editing, flood the screen with pop-ups, or “help” while you’re adjusting code in real time usually end up disabled by users, and often by us, too.

There is definitely a lot of AI fatigue right now. But there are also such good use cases, and we want those good use cases to float to the top … and figure out how we can solve those developer problems.

Cassidy Williams

If a suggestion pattern or popup is getting in your way, look for customization settings, and don’t hesitate to let us know on social media or in our community discussion. Product teams rely heavily on direct developer feedback and telemetry to adjust what ships next.

Building with you, not just for you

Whether it’s through beta testing, issue feedback, or direct interviews, your frustrations and “aha!” moments drive what we prioritize and refine.

If you have feedback, share it with us! Sharing your experiences in public betas, contributing to feedback threads, or even just commenting on what annoyed you last week helps us build tools you’ll want to use, not just tolerate. Your input shapes the roadmap, even in subtle ways you might not see.

Making the most of AI-driven coding

To get practical benefit from AI tools:

• Understand and review what you accept. Even if an AI-produced suggestion looks convenient, make sure you know exactly what it does, especially for code that might affect security, architecture, or production reliability.
• Use AI’s “explain” features as a learning aid, not a shortcut. These can help you solidify your knowledge, but don’t replace reading the docs or thinking things through.
• Tweak the frequency and style of suggestions until you’re comfortable. Most tools let you control intrusiveness and specificity. Don’t stick with defaults that annoy you.
• Give honest feedback early and often. Your frustrations and requests genuinely help guide teams to build better, more developer-friendly tools.

Take this with you

AI coding tools have enormous potential, but only if they adapt to developers. Your skepticism, high standards, and openness help us (and the entire software industry) make meaningful progress.

We’re committed to creating tools that let you do your best work, in your own flow, right where you are.

Together, let’s shape a future where AI enables, but never overshadows, the craft of great software development.

The post What AI is actually good for, according to developers appeared first on The GitHub Blog.