Perplexity Computer, in the company’s words, "unifies every current AI capability into a single system."

Gemini Drops is our regular monthly update on how to get the most out of the Gemini app.

theodp writes: On Tuesday, Microsoft GM of Education and Workforce Policy (and former Code.org Chief Academic Officer) Pat Yongpradit posted an obituary of sorts for coders. "Computer programmers and software developers are codified differently in the BLS [Bureau of Labor Statistics] data," Yongpradit wrote. "The modern AI-infused world needs less computer programmers (coders) and more software developers (more holistic and higher level). So when folks say that there is less hiring of computer programmers, they are right. But there will be more hiring of software developers, especially those who have adopted an AI-forward mindset and skillset. [...] The number of just pure computer programming roles has already been declining due to reasons like outsourcing, AI will just accelerate the decline." On Wednesday, Yongpradit's colleague Allyson Knox, Senior Director of Education and Workforce Policy at Microsoft, put another AI nail in the coder coffin, testifying before the House Committee on Education -- the Workforce Subcommittee on Early Childhood, Elementary, and Secondary Education on Building an AI-ready America: Teaching in the Age of AI. "Thank you to Chairman Tim Walberg, Ranking Member Bobby Scott, Chair Kevin Kiley, Ranking Member Suzanne Bonamici and members of the Subcommittee for the opportunity to share Microsoft perspective and that of the educators and parents we hear from every day across the country," Knox wrote in a LinkedIn post. "Three themes continue to emerge throughout these discussions: 1. Educators want support to build AI literacy and critical thinking skills. 2. Schools need guidance and guardrails to ensure student data is protected and adults remain in control. 3. Teachers want classroom-ready tools, and a voice in shaping them. If we focus on these priorities, we can help ensure AI expands opportunity for every student across the United States." Yongpradit and Knox report up to Microsoft President Brad Smith, who last July told Code.org CEO Hadi Partovi it was time for the tech-backed nonprofit to "switch hats" from coding to AI as Microsoft announced a new $4 billion initiative to advance AI education. Smith's thoughts on the extraordinary promise of AI in education were cited by Knox in her 2026 Congressional testimony. Interestingly, Knox argued for the importance of computer programming literacy in her 2013 Congressional testimony at a hearing on Our Nation of Builders: Training the Builders of the Future. "Congress needs to come up with fresh ideas on how we can continue to train the next generation of builders, programmers, manufacturers, technicians and entrepreneurs," said Rep. Lee Terry said to open the discussion. So, are reports of computer programming's imminent death greatly exaggerated?

Read more of this story at Slashdot.

Welcome to the Cloud Wars Minute — your daily cloud news and commentary show. Each episode provides insights and perspectives around the “reimagination machine” that is the cloud.

In today’s Cloud Wars Minute, I explain why aligning your role with AI may be the key to thriving in the next 18 months.

Highlights

00:05 — There’s a lot of discussion right now about the impact of AI on the job market. Microsoft AI CEO Mustafa Suleyman has weighed in on this debate regarding the pace of AI innovation and its impact on employment.

00:53 — “I think that we’re going to have a human-level performance on most, if not all, professional tasks. So white-collar work, where you’re sitting down at a computer, either being a lawyer or an accountant or a project manager or a marketing person — most of those tasks will be fully automated by an AI within the next 12 to 18 months.”

AI Agent & Copilot Summit is an AI-first event to define opportunities, impact, and outcomes with Microsoft Copilot and agents. Building on its 2025 success, the 2026 event takes place March 17-19 in San Diego. Get more details.

01:18 — “Many software engineers report that they’re now using AI-assisted coding for the vast majority of their code production, which means that their role has shifted now to this meta function of debugging, scrutinizing, or doing strategic stuff like architecting, putting things into production.”

01:36 — And he explains that this is a very different relationship with AI — one that’s evolved a huge amount over the past six months — and things are moving fast. But you don’t need to read this with doom and gloom. Focus on the second statement I read out instead.

01:52 — In that, Suleyman says roles have shifted, and that’s the crux of achieving success in the AI Era — recognizing that things are changing and that, to keep up with these changes, you have to orient yourself alongside AI, to align your role to work with AI — not against it, not instead of it, but with it.

---

The post Microsoft AI CEO Predicts Human-Level Automation of White-Collar Jobs Within 18 Months appeared first on Cloud Wars.

The Verge is heading to Barcelona, Spain, for Mobile World Congress, the biggest phone show of the year.

CES may dominate the headlines when it comes to TVs, computer components, and AI inanity, but for all things mobile, MWC has it beat. Since it’s a global show, that includes all manner of announcements of phones, tablets, and wearables that won’t necessarily release in the US.

Xiaomi has already teased a European launch for its 17 and 17 Ultra flagships, Honor is promising not only its Robot Phone but a full pivot to humanoid robotics, and Nothing is almost certain to drop more details on its Phone 4A ahead of a planned London launch on March 5th.

The likes of Samsung and Google will be there too, but mostly to talk about the already-announced 10A and S26 models, while Apple is launching something during the same week as MWC, but not actually in Barcelona.

We’ll also be looking out for oddities. Last year featured camera phone concepts with detachable lenses, a Lenovo laptop with a folding screen, and an Infinix handset with a solar panel in its back. We’ll be hoping this year gets just as weird.

Keep this page bookmarked for all the news, commentary, and first looks from the show floor.

• Phones are going to get weird next week
• Xiaomi’s magnetic power bank is incredibly thin
• Honor’s new MagicPad 4 is the world’s thinnest Android tablet
• Tecno is doing a modular phone (again).
• Taara Beam provides 25Gbps connectivity over invisible beams of light
• Honor is pivoting to robots.

Most developers already do real work in the terminal.

We initialize projects there, run tests there, debug CI failures there, and make fast, mechanical changes there before anything is ready for review. GitHub Copilot CLI fits into that reality by helping you move from intent to reviewable diffs directly in your terminal—and then carry that work into your editor or pull request.

This blog walks through a practical workflow for using Copilot CLI to create and evolve an application, based on a new GitHub Skills exercise. The Skills exercise provides a guided, hands-on walkthrough; this post focuses on why each step works and when to use it in real projects.

What Copilot CLI is (and is not)

Copilot CLI is a GitHub-aware coding agent in your terminal. You can describe what you want in natural language, use /plan to outline the work before touching code, and then review concrete commands or diffs before anything runs. Copilot may reason internally, but it only executes commands or applies changes after you explicitly approve them. 

In practice, Copilot CLI helps you:

• Explore a problem based on your intent
• Propose structured plans using /plan (or you can hit Shift + Tab to enter planning mode), or suggest concrete commands and diffs you can review
• Generate or modify files
• Explain failures where they occur

What it does not do:

• Silently run commands or apply changes without your approval
• Replace careful design work
• Eliminate the need for review

You stay in control of what runs, what changes, and what ships.

Step 1: Start with intent, not scaffolding

Instead of starting by choosing a framework or copying a template, start by stating what you want to build.

From an empty directory, run:

copilot
> Create a small web service with a single JSON endpoint and basic tests

If you want to generate a proposal in a single prompt instead of entering interactive mode, you can also run:

copilot -p "Create a small web service with a single JSON endpoint and basic tests"

In the Skills exercise, this pattern is used repeatedly: describe intent first, then decide which suggested commands you actually want to run.

At this stage, Copilot CLI is exploring the problem space. It may:

• Suggest a stack
• Outline files
• Propose setup commands

Nothing runs automatically. You inspect everything before deciding what to execute. This makes the CLI a good place to experiment before committing to a design.

Step 2: Scaffold only what you’re ready to own

Once you see a direction you’re comfortable with, ask Copilot CLI to help scaffold:

> Scaffold this as a minimal Node.js project with a test runner and README

This is where Copilot CLI is most immediately useful. It can:

• Create directories and config,
• Wire basic project structure,
• Generate boilerplate you would otherwise type or copy by hand.

Copilot CLI does not “own” the project structure. It suggests scaffolding based on common conventions, which you should treat as a starting point, not a prescription.

The important constraint is that you’re always responsible for the result. Treat the output like code from a teammate: review it, edit it, or discard it.

Step 3: Iterate at the point of failure

Run your tests directly inside Copilot CLI:

Run all my tests and make sure they pass

When something fails, ask Copilot about that exact failure in the same session:

> Why are these tests failing?

If you want a concrete proposal instead of an explanation, try:

> Fix this test failure and show the diff

This pattern—run (!command), inspect, ask, review diff—keeps the agent grounded in real output instead of abstract prompts.

💡Pro tip: In practice, explain is useful when you want understanding, while suggest is better when you want a concrete proposal you can review. Learn more about slash commands in Copilot CLI in our guide. 

Step 4: Make mechanical or repo-wide changes

Copilot CLI is also well suited to changes that are easy to describe but tedious to execute:

> Rename all instances of X to Y across the repository and update tests

Because these changes are mechanical and scoped, they’re easy to review and easy to roll back. The CLI gives you a concrete diff instead of a wall of generated text.

Step 5: Move into your editor when you need to start shaping your code

Eventually, speed matters less than precision.

This is the natural handoff point to your editor or IDE, so it can:

• Reason about edge cases
• Refine APIs
• Make design decisions

Copilot works there too, but the key point is why you switch environments. The CLI helps you quickly get to something real. The IDE is where you can shape your code into exactly what you want. 

A good rule of thumb: 

• CLI: use /plan, generate a /diff, and move quickly with low ceremony
• IDE: use /IDE when you need to refine logic and make decisions you’ll defend in review
• GitHub: commit, open a pull request with the command /delegate, and collaborate asynchronously

Step 6: Ship on GitHub

Once the changes look good, commit and open a pull request which you can do through the Copilot CLI in natural language:

Add and commit all files with a applicable descriptive messages, push the changes.

Create a pull request and add Copilot as a reviewer

Now the work becomes durable:

• Reviewable by teammates
• Testable in CI
• Ready for async iteration

This is where Copilot’s value compounds as part of a flow that ends with shipping versus just being a single surface. The Skills exercise intentionally ends here, because this is where Copilot’s value becomes durable: in commits, pull requests, and review (not just suggestions).

One workflow, three moments

A helpful mental model for Copilot looks like this:

• CLI: prove value quickly with low ceremony
• IDE: shape and refine your code
• GitHub: review, collaborate, and ship

Copilot CLI is powerful precisely because it fits into this system instead of trying to replace it.

Take this with you

Copilot CLI is most useful when you treat it like a tool for momentum, not a replacement for judgment.

Used well, it helps you move from intent to concrete changes faster: exploring ideas, scaffolding projects, diagnosing failures, and handling mechanical work directly in the terminal. When precision matters, you move into your editor. When the work is ready to share, it lands on GitHub as a pull request—reviewable, testable, and shippable.

That flow matters more than any single command.

If you take one thing away from this guide, it’s this: Copilot works best when it fits naturally into how developers already build software. Start in the CLI to get unstuck or move quickly, slow down in the IDE to make decisions you can stand behind, and rely on GitHub to make the work durable.

The post From idea to pull request: A practical guide to building with GitHub Copilot CLI appeared first on The GitHub Blog.