Microsoft CTO Kevin Scott has some advice for AI startups waiting for the next breakthrough model: the technology can already do far more than most people are getting out of it, so stop waiting and start building. 

Also: real customer traction still matters more than online buzz.

Speaking at a recent South Park Commons event with the organization’s general partner, former Dropbox CTO and Facebook engineer Aditya Agarwal, Scott said founders are sitting on a “gigantic capability overhang” —  meaning that current AI systems can do far more than most apps built on top of them. 

He cited ChatGPT itself as a past example: the underlying model was “pretty old” when it launched, as he put it, and nobody (including Scott and his peers) predicted at the time it would become a potential trillion-dollar product.

“The cost of doing the experiments has never been cheaper,” Scott said. “So do the damned experiments. Try things.”

The barrier isn’t model capability, he said, but the unglamorous integration work needed to put it to practical use.

“Some of the things that you need to do to squeeze the capability out of these systems is just ugly-looking plumbing stuff, or grungy product building,” he said. “But you’re in a startup, that’s kind of your life. It’s more about the grind.”

Scott also cautioned founders against mistaking online attention for real traction. The current environment, he said, is flooded with “false signal” — from media coverage to investor interest — that doesn’t really correlate with whether you’ve built something useful.

“You’ve got a bunch of people whose business model is getting clicks on articles online or getting people to subscribe to their Substack,” he said. “If you believe the things that particular part of the ecosystem is sending to you in terms of feedback, it could be that you’re steering yourself in exactly the wrong direction.”

The real signal, he said, comes from building something customers actually love.

Other topics included:

• Open-source vs. closed-source models (he effectively framed this as a toolbox, not a battle, and said Microsoft uses both).
• The importance of expert feedback in AI training, which he views as a potential startup advantage. 
• The infrastructure challenge of building memory systems for AI agents, a problem he said won’t be solved by simply training bigger models.

See the full talk above or on the South Park Commons Minus One Podcast.

Whether you’re looking to get a pair yourself or just want to explore what’s available on the market today, we’ve compiled a list of the most compelling pairs available.

Engineers at GitHub have been using GitHub Copilot coding agent for over a year now, studying through experience where it can help save developers real time and energy. Through our work, we have developed a handy acronym: WRAP, which stands for:

• W – Write effective issues
• R – Refine your instructions
• A – Atomic tasks
• P – Pair with the coding agent

WRAP will help you get the most out of coding agent. For example, you likely have a backlog full of issues that have been tough to prioritize. Perhaps you’ve had to push off some tech debt improvements in favor of shipping a new feature. Or perhaps your development time has been split between fixing customer bugs and larger passion projects. WRAP can help you quickly get up to speed, using coding agent to tackle tasks that you may not have had time for in the past.

Write effective issues

The first step of WRAP is to make sure you are writing effective issues to assign to GitHub Copilot coding agent. In essence, you are trying to set coding agent up for success by adding context for the agent, just like you would for a new team member. Here are a set of guidelines you should consider:

• Write an issue as though it’s for someone brand new to the codebase. If you consider what context a newcomer might need, you’re likely to include enough context for the coding agent to complete the task effectively.
• Craft a descriptive title that explains where the work is being done. One of the best things about the coding agent is that you can assign it as many tasks as you want. But assigning many tasks means you might be juggling a lot of pull request reviews! Make sure your issue title clearly describes the nature of your work and where it occurs so you can keep your agent panel easy to navigate.
• Add examples of what you want. If you already know what you’d like the coding agent to implement, such as a specific error-handling pattern, include an example in the issue! This additional context will make it much more likely that you’ll get the output you want.

Here are some example issues to get started:

Instead of: 

> Update the entire repository to use async/await

Do something like:

> Update the authentication middleware to use the newer async/await pattern, as shown in the example below. Add unit tests for verification of this work, ensuring edge cases are considered.

>

async function exampleFunction() {

  let result = await promise;

  console.log(result); //”done!”

}

Refine your instructions

The next step of WRAP is to make sure that you refine the GitHub Copilot custom instructions to improve the results of your coding agent-created pull requests. There are a variety of different custom instructions that you can create, as well as a variety of different cases where it makes sense to use them.

• Repository custom instructions. This is a great place to store any information that might be applicable to your repository as a whole. For example, if you have a Go application and prefer specific ways of writing Go code, that should go in your repository custom instructions. Adding to these instructions over time will improve all the responses from any interactions with GitHub Copilot in that repository. Here’s a guide on how to get started adding these repository custom instructions.
  • Note: This is a great first use case for GitHub Copilot coding agent! Try asking it to generate custom repository instructions for your repository.
• Organization custom instructions. Much like how you can create a set of GitHub Copilot custom instructions for an entire repository, you can also create a set of GitHub Copilot custom instructions for your entire organization. This is ideal for anything that applies to all repositories in your organization. For example, you may have requirements around tests that should be created for all applications. Here’s a guide on how to get started adding organization custom instructions.
• Coding agent custom agents. Similar to the repository and organization custom instructions, coding agent custom agents can be created with a natural language text file, and are applicable at either the enterprise, organization, or repository level. These are ideal for any repetitive development task that may occur often, but may not be applicable to every single set of changes. For example, you can create an “Integration Agent” for integrating new products with a specific repository. Here’s a guide on how to get started creating custom agents.

Atomic tasks

Coding agent is very good at handling small, atomic, and well-defined tasks. However, it can also be useful for large problems! If you want it to handle a larger problem, the trick is to break that large problem down into multiple, independent, smaller tasks. 

For example, you wouldn’t necessarily want to assign an issue to GitHub Copilot asking it to “Rewrite 3 million lines of code from Java to Golang.” That would probably be too large of a scope for a specific task, and reviewing those changes would likely be pretty painful.

Instead, you could break that larger problem into smaller issues for Copilot to tackle:

• Migrate the authentication module to Golang, ensuring all existing unit tests pass.
• Convert the data validation utilities package to Golang while maintaining the same API interface.
• Rewrite the user management controllers to Golang, preserving existing REST endpoints and responses.

By breaking that large problem into smaller atomic tasks, it will be much easier to test and validate the individual parts of the work and much easier to review the individual pull requests.

Pair with coding agent

When working with coding agent, it’s important to remember its strengths as a coding agent and your strengths as a human. This will lead to less frustrating experiences down the line if coding agent doesn’t perform like you might want or expect it to. 

For example, humans are very good at the following:

• Understanding the “Why:” Humans are great at knowing why a task was created. They can also determine whether the changes to a task will actually solve the underlying problem that caused the issue to be created in the first place.
• Navigating ambiguity: Humans are much better at navigating ambiguity than AI. For example, as a human, you might be able to omit some parts of an issue that you wouldn’t be able to omit for GitHub Copilot to complete it, such as what sorts of tests and telemetry you expect to be done.
• Cross-system thinking: Humans are much better at thinking about the implications of changes made in one system on another system. When coding agent completes a particular task in one repository, it’s unlikely to know about how that task will impact other repositories. Considering cross-system implications is a much better task for humans than for GitHub Copilot.

On the other hand, coding agent is very good at the following:

• Tireless execution: You can assign ten different tasks to coding agent right now and expect it to work on each of them.
• Repetitive tasks: Humans often get bored or miss things when doing repetitive tasks, such as updating naming conventions across many files. GitHub Copilot is great for completing these things, though!
• Exploring possibilities: If you’re considering tackling a problem a couple of different ways, you can assign each one of those different ways to coding agent. This gives you a quick idea of how each of those strategies might play out, without using a lot of development resources.ij

Take this with you

Lingering backlog issues no longer stand a chance when you are equipped with GitHub Copilot and WRAP.

Have a dependency that needs to be updated? Somewhere that you could use more test coverage? New error handling patterns that you’d like to adopt across your codebase? Or perhaps you’d like to get a jumpstart on adding repository instructions and use the GitHub Copilot coding agent to do so? 

Use WRAP to wrap up your backlog!

The post WRAP up your backlog with GitHub Copilot coding agent appeared first on The GitHub Blog.

A tech C.E.O. explains why A.I. probably won’t cure diseases anytime soon. Hint: You still need humans.

Conference session submissions for 2026 are opening all over the place right now. And if your calendar looks anything like most people’s this week, it’s… quiet.

Not vacation quiet.

Just that strange end-of-year limbo where no one is scheduling big meetings, inboxes slow down, and “real work” is mostly on pause.

Which makes this a pretty great chance to work on your conference sessions.

Not frantically. Not at midnight the night before the CFP closes. But thoughtfully — as part of how you want 2026 to look.  And maybe what you’d like to learn next year, and just needed a push. 

Insider secret: speakers do not know the ins and outs of every session they submit for a conference.  Usually it’s something with familiarity, but also a stretch learning goal.  And when a conference decides it’s a good fit, then they have to become the expert.  Shhh, remember it’s a secret.

If writing abstracts always feels harder than delivering the actual session, you’re not imagining it. This is thinking work. Framing work. And it benefits from space — something you probably have more of right now than you will in a few weeks.

I use AI constantly when I’m working through session ideas, but not as a shortcut. More like a thinking partner. I’ll start with a rough idea (ok, so ChaptGPT wrote that part, I start with word vomit of random ideas), a frustration, or an opinion I’m not done forming yet. I’ll push on it. Refine it. Tighten the language. AI helps me do that faster — but the thinking is still mine.

That distinction matters. Reviewers can tell when an abstract came out of a single prompt. It reads fine, technically, but it doesn’t say much.

One place you should slow down, though, is the title. Titles do the real work. Lots of reviewers — and almost all potential attendees — never read past them unless the title earns it. A strong title tells me what this session is, who it’s for, and why it matters. If the title is vague, overly clever, or loaded with buzzwords, the rest of the submission doesn’t stand a chance.

The abstract itself doesn’t need to be long. In fact, it shouldn’t be. Start with the point. Lead with the problem you’re solving and the audience you’re solving it for. Expand just enough to explain why it matters and what people will walk away with. Reviewers skim. Design for that reality.

And while we’re here: emojis don’t help. They sometimes work on social posts. They don’t work for conference sessions. They add noise, not clarity.  And to me, a clear sign that you used a little too much AI and too little human oversight.

AI is excellent at editing — tightening language, improving flow, helping you say the same thing with fewer words. What it can’t replace is your experience, your judgment, and your point of view. That’s the part reviewers are actually looking for.

I’ve submitted and reviewed a lot of sessions over the years. The ones that get selected aren’t the flashiest. They’re the clearest. They know who they’re for. They respect the reader’s time.  Go learn more about the inverted pyramid, it’s great for session info.

So if your week is a little quieter than usual, use it. Draft your sessions. Shape your 2026 speaking portfolio intentionally. Let AI help — but don’t let it think for you.

Also, don’t be too hard on yourself when you get turned down for an event.  Even after 20 years, I get rejected regularly, more than my sessions are accepted. If imposter syndrome is whispering in your ear, remember this: submitting a session doesn’t mean you’re presenting it. It just means you’re open to the conversation.

Commenter Shawn wondered why we are so worried about memory access semantics. Back in my day, we just used full barriers everywhere, and I didn’t hear nobody complainin’.

Moore’s law says that the number of transistors in an integrated circuit doubles about every two years. For a long time, these resources were employed to make CPUs faster: Accelerating clock speeds, expanding caches, deepening pipelines, performing more prediction and speculation, increasing the number of registers, that sort of thing. All of these improvements sped up single-threaded operations.

The problem is that you can make things only so small before you start running into problems. It’s hard to build things that are smaller than atoms. The speed of light constrains how quickly two components can communicate with each other. You have to look for other ways to get your performance gains.

CPU speeds have largely leveled off at the 4 GHz range. You can’t go faster that way any more. Instead of scaling up, we have to scale out. Rather than making a CPU core faster, we give each CPU more cores.

By analogy, if you have to transport more people per hour by bus, and you can’t make the bus go any faster, then you have to get more buses.¹

More CPU cores means that programs need to use concurrency in order to extract maximum performance. That in turn lead to discoveries like lock convoys, the performance cost of fairness when under heavy load, and (the issue at hand) too many barriers.

Continuing the bus analogy: If you have a fleet of a dozen buses, you need to make sure that nobody tries to use the same ticket to board two different buses. This means that the buses have to somehow communicate with each other to make sure each ticket is used only once. If you have a lot of buses, the ticket validation could end up being the slowest part of loading passengers!

The x86 family of processors have fairly strong memory model semantics. You can dig into the Intel documents to see the precise wording, but it roughly comes down to all memory operations coming with acquire-release semantics by default. Most other processors, however, have a more relaxed memory model by default, allowing them to do more aggressive reordering to improve performance.

In order to ensure any ordering beyond the default, you need to issue explicit fences. And those fences tend to be expensive. (After all, if they were cheap, then the architecture would just do them by default.) Your CPU that has grown to have caches the size of a small country? Yeah, those caches need to be flushed because the memory now has to be made visible to another processor, and they need to be invalidated because they may have been changed by another processor.

Therefore, when writing code that may be used in high-performance scenarios, you want to avoid unnecessary stalls and flushes. And that means choosing the weakest barrier that still achieves the desired result.

In other words, people didn’t complain back then because it wasn’t a problem back then. CPUs were not fast enough and programs not sufficiently multi-threaded that fences showed up in performance traces. But now they do.

Bonus chatter: Commenter Ben noted that the libc++ implementation of shared_ptr is even more aggressive about avoiding barriers and skips the write-release barrier if the reference count is decrementing from 1 to 0, because decrementing to zero means that nobody else has access to the object, so it doesn’t matter that they can’t see what you’re doing with the memory.

Bonus bonus chatter: That article was primarily written as a note to myself for future reference.

¹ You could also make the bug bigger so it carries more passengers. That’s what SIMD tried to do: Let the CPU process more data at once. But it requires workloads that parallelize in a SIMD-friendly way.

The post Why are we worried about memory access semantics? Full barriers should be enough for anybody appeared first on The Old New Thing.