Read more of this story at Slashdot.

Deutsche Telekom, Orange, Telefónica, and Vodafone signed a letter of intent saying they're considering a joint bid for spectrum that would support European direct-to-device satellite competition for SpaceX's Starlink. The four telecom companies say they would handle the ground infrastructure while a separate, unannounced satellite partner provides the satellite constellation:

The joint initiative by Deutsche Telekom, Orange, Telefónica and Vodafone has a clear ambition: to meet customer demand for universal coverage in underserved areas, strengthen the resilience of public networks, protect critical communications, and support the develop …

Read the full story at The Verge.

The agent has finished the bulk of your change. Now you want to inspect one implementation detail, adjust a few lines by hand, and run the project locally before you ship it.

But the work is sitting in the GitHub Copilot app… and your editor is where you review diffs, debug code, and make final adjustments. Do you have to choose between staying in the session and starting over in Visual Studio Code?

You don’t. You can open the Copilot app session directly in VS Code and continue with its conversation, code changes, and working context intact. That means Copilot can handle the repetitive or time-consuming work, then hand control back to you for closer review, hands-on editing, and local testing.

In this tutorial, you’ll learn how to:

• Open a Copilot app session in VS Code.
• Review the agent’s changes line by line.
• Continue the same conversation from your editor.
• Modify and test the code locally.
• Push your updates to the pull request associated with the session.

1. Start with a session in the Copilot app

Open the session you want to continue. Before handing it off, take a moment to review the task and the work Copilot completed.

A session contains more than a collection of modified files. It also records the task, the plan, and the conversation that produced those changes. That context is important when you want to understand why Copilot chose a particular implementation or ask it to revise part of the work.

You do not need to summarize that history or copy it into a new chat before moving to VS Code.

2. Open the session in VS Code

From the session, select Open in VS Code. If the app presents more than one supported editor or VS Code installation, choose the one you want to use.

VS Code opens the project using the worktree associated with the session. It also displays the existing session in the Copilot sidebar.

That gives you three connected pieces of the original work:

• The session context: The task, plan, and conversation remain available.
• The diff: The files and lines changed by the agent are ready for review.
• The worktree: VS Code opens the same isolated working tree the session used.

You are continuing the existing session, not reconstructing it in a new editor window.

3. Review the agent’s changes

Before editing, inspect the diff in VS Code. Open the Source Control view to see the changed files, then select a file to review its changes line by line.

Review the implementation as you would any other proposed change. In particular, check that:

• The code solves the requested problem.
• The implementation follows the repository’s conventions.
• Error states and edge cases are handled appropriately.
• Tests cover the behavior that changed.
• No unrelated files or behaviors were modified.

The preserved conversation can help explain how Copilot arrived at the implementation. If something is unclear, continue prompting Copilot in the sidebar. For example:

Explain why you changed this function instead of adding a new helper. Identify any behavior this could affect.

You can also ask Copilot to make another change. Because the session and worktree remain connected, you do not have to describe the task from the beginning.

4. Make a hands-on edit

Once you understand the proposed changes, edit any file directly in VS Code.

This is useful for adjustments that are faster or easier to make by hand, such as:

• Refining a label or error message.
• Renaming a variable for clarity.
• Adjusting layout or styling.
• Adding a missing test case.
• Applying a repository-specific convention.

You are editing the session’s existing worktree, so your manual changes build directly on the agent’s work. You do not need to copy files between directories or manually re-create the branch.

5. Run and verify the project locally

Use the VS Code integrated terminal to run the project’s normal validation workflow. The exact commands depend on the repository, but some web app examples may include:

• npm install
• npm test
• npm run lint
• npm run dev

Treat agent-generated changes the same way you would treat code written by a person: run the relevant tests, inspect failures, and verify the behavior yourself.

If the development server prints a localhost URL, open it to test the change in a browser. When supported by your VS Code setup, you can open the URL in VS Code’s integrated browser and inspect the result without leaving the editor.

For a user-interface change, verify both the requested behavior and nearby states. For example, check the modified component at different viewport sizes and confirm that loading, empty, and error states still work.

6. Continue with Copilot or keep editing yourself

At any point, you can choose the interaction that best fits the next step:

• Prompt Copilot when the change requires repository-wide analysis or repetitive edits.
• Edit directly when you know the exact change you want.
• Use both approaches iteratively as you test and refine the implementation.

For example, after making a manual UI adjustment, you might ask Copilot:

Add a test for the updated label and run the relevant test file. Do not modify unrelated components.

Because you are still in the original session, Copilot retains the context needed to interpret “the updated label.”

7. Commit and push the finished changes

When the implementation is ready, review the final diff one more time. Then commit and push the changes using the Source Control view or the integrated terminal:

• git status
• git add
• git commit -m "Refine session changes"
• git push

Use your repository’s normal branch, commit, review, and approval practices. Because VS Code opened the worktree and branch associated with the session, pushing the branch updates the pull request already tracking that work.

There is no need to copy the finished files into another checkout or reconnect the work to the pull request manually.

A continuous workflow from agent to editor

Opening a Copilot app session in VS Code gives you a clean division of labor without splitting the work itself. Copilot can take on a larger or repetitive implementation, while you can move into the editor for detailed review, targeted changes, local testing, and final polish.

The session, diff, and worktree move with you. Start by directing the work in the Copilot app, switch to VS Code whenever you want hands-on control, and push the finished result through the same pull request workflow.

The post How to continue a GitHub Copilot app session in VS Code appeared first on The GitHub Blog.

One of my biggest pet peeves is the Monday morning quarterback, the person who second-guesses every coaching decision after the fact. In The Monday Morning Agent, we’re building one that actually checks the data.

Every other Monday, I’ll take an argument NFL fans can’t stop having and hand it to an AI agent. We’ll use about a quarter-million plays from five complete seasons of public nflverse data, plus the current season as it unfolds. Each of our eight episodes will give the agent another capability. By the finale, it’ll run the desk unattended, and we’ll check what it investigated and what it correctly refused to answer.

We’ll start with “You have to establish the run.” I want the agent to explain what that claim means and what evidence would support it.

Define the claim before querying the data

“Establish the run” can mean that running early pays off late, wearing down the defense, or setting up play action. These are very different claims and they need different data. For this first episode, I focused on whether teams that run more often early in a game win more often.

Before the agent called the tool, I asked it to write one sentence explaining what would have to be true in the data for the claim to hold, including when in the game it applies. “Establish” here means early. A whole-game number doesn’t really test that. Give your agent the same assignment, and check that it’s answering the question you intended.

Give the agent a job you can check

Before any agent touched this, I ran the analysis code myself. The tool did the counting; the agent interpreted the results. Then I wrote the policy in a Markdown file, spelling out its job, the read-only tool it may use, and what its answer needed to include. It has to explain what the plays can’t tell us. It may not say running causes winning.

Try questions outside that job too. When I asked which team I should bet on, the agent refused without calling the tool, because that request is beyond the scope of our agent. But when a viewer asked about running trends, the results got tangled up with the “establish the run” instructions. I had to clarify what I was asking, and still wanted to see the code and validate the answer. As you give an agent more responsibility, check both its results and whether it understood the task.

Make the filters part of the answer

“You have to establish the run” sounds airtight at first. Over the last five seasons, teams with the highest run share, the percentage of their plays that were runs, won 77.7% of their games. Those with the lowest run share won 19.2%. I initially looked at that and thought, “Problem solved, we’re done.” Most of that gap, though, reflects teams that were already ahead running out the clock.

When the agent looked only at first-half running in games within three points at halftime, the result flipped. Teams with the highest first-half run share won 46.3% of the time; those with the lowest won 55.3%. This season through Week 5 points the same way, but each group contained only 11 team games. One game could swing it. That doesn’t mean passing causes winning. We’re measuring association, and the filters change which games we’re comparing.

One filter changed the whole story, which is why the filters have to be on-screen. I wanted to see how many rows remained and which commands produced the results so I could go back and check. Make those details part of your agent’s answer, including when it’s working with a smaller sample.

A few numbers from last week’s games

In Week 5, the team that ran more in the first half won 6 of the 15 games, lost 8, and tied 1 (Giants at Washington). Over the past five seasons that team won 54.3% of the time, so last week came in below the average. That’s not unusual, though. In 27 of the 95 regular-season weeks since 2021, the team that ran more early finished the week with a losing record. One week of games doesn’t say much on its own, which is why the agent reports five seasons alongside the current one.

One more data point: The Monday night game, Buffalo at the Rams, was the first the agent hadn’t seen. Buffalo ran on 60% of its first-half plays to the Rams’ 35%, led by six at halftime, and won by three in overtime. Those 199 plays are in the data now, and the close-at-halftime numbers from the episode didn’t change.

Next up: “Ban the Tush Push”

On October 26, we’ll tackle “Ban the Tush Push.” Not one of the 260,927 play descriptions from 2021 through this season’s October 11 games contains the words “tush push.” After adding Monday night’s game, we have 261,126 descriptions, and “sneak” appears in only two, both from 2021. The data isn’t going to hand us a definition.

Before the agent can judge the play, it has to define it. I’ll challenge it to write that definition into its first permanent document, a shared data dictionary, and cite it in every ruling from then on. Bring your own definition, because the answer depends on which one you pick.

O’Reilly members can sign up on the O’Reilly learning platform to join me live on October 26, 8:00am–8:45am PT / 11:00am–11:45am ET. Everyone can follow along on Radar every other Monday, with a brief pause for the holidays. Watch episode one above, and we’ll build on it in the next session.