The FAA says its push to recruit video gamers as air traffic controllers has helped it hire more than 2,000 trainees, reaching 94% of its hiring goal. Another 2,000-plus candidates are in the pipeline. CBS News reports: U.S. Secretary of Transportation Sean Duffy said in a recent social media post that the federal agency's recruitment campaign to recruit gamers as air traffic controllers has been a "game changer" for the Federal Aviation Administration. [...] When Duffy announced the initiative in April, he acknowledged that the Transportation Department needed to extend its reach to recruit prospective air traffic controllers. "A lot of what they do playing games ... is what they do ... controlling traffic in the air," Duffy told CBS News senior transportation correspondent Kris Van Cleave in an interview on Tuesday at New Jersey's Newark Liberty International Airport. Duffy added that many current trainees started out as gamers. Only about 25% of controllers hold a traditional college degree, while former controllers note that gaming requires many of the same skills that air traffic controllers use on the job, such as thinking quickly, staying focused and managing multiple sources of information as they guide more than 80,000 flights to their destinations daily.

Read more of this story at Slashdot.

Check out the latest announcements about Pixel devices at Made by Google 2026.

Opening a new AI tool can feel a little like staring at a blank page. You know you want help with something, but figuring out exactly what to ask can be its own task.

The good news is that you don’t need to write the perfect prompt to get started. A prompt is simply a description of what you want to accomplish. Start with what you know, give Copilot some context, and refine the request as you go.

Let’s walk through what it looks like to start your first task in the GitHub Copilot app.

Start with the right context

Before you can ask Copilot to make a change, it needs something to work on. Agent sessions can be connected to a GitHub repository or a folder on your local machine, giving Copilot access to the code and files it needs for the task.

From the GitHub Copilot app home screen, you can select a project you’ve worked with before or add a new one.

If you’re working on code that’s only on your computer, you can add a local folder instead. Either way, connecting a project gives the session the context it needs to work with your codebase.

Once your project is selected, you’re ready to write your first prompt.

Describe what you want in plain English

You don’t need to learn a special syntax or figure out the perfect way to phrase your request. Start by describing the change you want to make.

For example: Add a most-funded sort option to the games list.

That’s enough to get started. Copilot can examine the project, find the relevant parts of the codebase, and work on the requested change.

If the first attempt isn’t quite what you had in mind, you can provide additional details or ask for changes. Prompting is an iterative process, so you don’t have to anticipate every detail before you begin.

The best prompt is often the one that gets you moving.

Choose the right model when you need it

The GitHub Copilot app also lets you choose which AI model handles your task. Different models have different strengths, and some are better suited to complex reasoning while others can handle simpler tasks more quickly.

If you’re just getting started, the default model is a good place to begin. You don’t need to understand every difference between the available models before you can use the app.

As you work, you can switch models when a task requires more complex reasoning or when the first approach isn’t giving you the results you need. Think of the model selector as another tool you can reach for when the task calls for it, rather than something you need to configure before every session.

Use whatever input feels natural

Typing isn’t the only way to write a prompt. The GitHub Copilot app includes built-in voice input, which can be useful when you’re thinking through a problem out loud or have a longer request to describe.

Your speech is converted into text in the prompt box, where you can review and edit it before sending it. That means you can think out loud without immediately committing to the first version of your request.

Sometimes it’s easier to explain what you want than to type it out. Voice input gives you another way to get that idea into the session.

Customize how the work runs

You can also change how your session handles the work. From the session title, you can select a different agent or enable remote control for the session.

Different agents can be configured for different types of work, so you can choose the one that best fits the task you’re working on.

Remote sessions give you another kind of flexibility. Instead of running the work only on your local machine, you can access the same session from the web. You can start a task, close your laptop, and return to the session later from another device without losing your place.

These options aren’t things you need to configure before your first prompt. They’re there when you need more control over how a task is handled.

Start small and iterate

Your first prompt doesn’t need to be perfect. Start with a small change you’d like to make in a project you already know, describe what you want in plain language, and see what happens.

From there, you can refine the request, try a different model, or adjust how the session runs. The more you use the app, the more natural these choices become.

The important part is getting started. Pick a project, give Copilot a task, and see where it takes you.

The post Write your first prompt with the GitHub Copilot app appeared first on The GitHub Blog.

Early in my career at Microsoft, I remember complaining to a mentor about how much time interviewing consumed. We were trying to ship software, hit deadlines, recover from bugs, make customers happy, and somehow spend entire days talking to candidates. I viewed interviewing as something important, but fundamentally in competition with the “real work.”

His response was immediate.

“What exactly do you think your job is?”

At the time, I thought he was being sarcastic. Thirty years later, I think he was exactly right.

After decades of building products, leading teams, making hiring decisions, coaching hiring managers, and occasionally cleaning up the consequences of my own mistakes, I’ve come to a simple conclusion:

Excellence in organizations starts and ends with hiring.

Most leaders agree with this statement in principle. Very few behave as though they believe it.

Every company says people are its greatest asset. Leadership teams routinely declare that talent is their highest priority. Then I watch interview loops get rescheduled because something “more important” came up. I watch role definitions get delegated. I watch managers outsource critical hiring decisions to Recruiting. I watch onboarding treated as an administrative exercise that begins after the offer letter is signed.

The behavior tells me what they actually believe.

Hiring is the highest-leverage activity a leader performs. Everything else is downstream of it.

It Is Easier to No-Hire Than Fire

My first hiring principle is brutally simple.

It is far easier to no-hire someone than to fire someone.

A no-hire costs time. A bad hire costs time, management attention, organizational energy, team morale, customer trust, and often the attention of multiple people who would rather be doing something else. Worse, the consequences are rarely isolated to the individual. The impact radiates outward. Teams adapt around weak performers. Standards get lowered. Strong people become frustrated. Decisions slow down. Managers spend months attempting to rescue a situation that should never have existed.

I’ve seen leaders convince themselves they should “take a chance” because a role has been open too long, because the team desperately needs help, or because the project plan depends on adding headcount by a specific date. Those are all understandable pressures. None of them change the underlying reality.

The role being vacant is usually a temporary problem. A bad hire often becomes a permanent one.

This is why my hiring bar is high. If I am on the fence, I keep looking. In One-Way and Two-Way Doors, I argued that hiring a full-time employee is a one-way door, precisely because un-hiring is so expensive. I still believe that.

“A”s Hire “A”s. “B”s Hire “C”s.

One of the oldest observations in management is that strong leaders tend to hire strong people, while weaker leaders often hire defensively.

The shorthand version is:

“A”s hire “A”s. “B”s hire “C”s.

Yes, this is rude. Yes, it’s elitist. Do you want to be excellent or not?

Confident leaders want exceptional people around them. They actively look for individuals who are smarter, more capable, more experienced, or more specialized than they are. They understand that organizational capability compounds over time.

Insecure leaders often do the opposite. Not consciously, usually. They simply become more comfortable with candidates who look familiar, think similarly, and pose less threat.

Organizations do not improve through aspiration. They improve through accumulation. Every hiring decision either raises the average capability of the organization or lowers it. There is rarely a neutral outcome.

Over time, those decisions compound. A company that consistently raises the bar becomes remarkably capable. A company that consistently compromises eventually wonders where all the talent went.

One of the Merit Badges I care about most is “Quickly hire senior talent.” Not “fill the req.” Hire people who raise the bar, repeatedly.

When You’re Hiring, Nothing Is More Important

This belief tends to surprise people.

There is no higher priority than hiring.

When a role is open and actively being filled, I consider hiring the highest-priority work associated with that role. Not just for the hiring manager. For everyone involved. The hiring manager, the interviewers, the peers, the bar raisers, the recruiters, and the leadership chain all have skin in the game.

This sounds extreme until you ask a simple question: what activity has more influence over the future capability of the organization than deciding who joins it?

Every future decision that person makes, every future customer interaction, every future line of code, every future design review, every future management conversation, and every future hire they make is downstream of this decision. The people who join your organization become your culture. They become your execution capability. They become your future leaders. They become the people who will eventually hire the next generation.

And yet I routinely see interview loops delayed because something “more important” came up. I have never understood that logic.

If someone is participating in a hiring loop, that hiring loop is the important thing. Not because interviewing itself is inherently valuable, but because the consequences of the decision are so large and so durable.

Hiring is not an interruption from the work. Hiring is the work. If you are not starving other things to hire and develop the best, you do not understand what it means to prioritize.

I said the same thing more bluntly in People Management Is Not a Hobby: if you are on the Steward track, hiring is not a side quest. It is the job.

Recruiting Does Not Own Hiring

This leads directly to another belief that occasionally gets me into trouble.

Recruiting does not own hiring. Hiring managers own hiring.

Recruiters are incredibly important. Great recruiters amplify organizational capability in remarkable ways. They find candidates, improve processes, manage logistics, build pipelines, strengthen employer branding, and keep entire systems operating smoothly.

But they do not own the outcome.

The hiring manager owns the outcome. The hiring manager defines what success looks like. The hiring manager establishes the bar. The hiring manager evaluates signal. The hiring manager decides whether the candidate should join the team. The hiring manager is accountable when the decision turns out to be wrong.

Recruiting exists to assist, amplify, coach, enable, and improve the process. It does not exist to replace leadership accountability.

Too many managers behave as if Recruiting is a service organization responsible for finding them a candidate while they continue doing the “important work.”

The search for great talent is the important work.

Hiring Is a Lifecycle, Not an Event

A common mistake I see is treating hiring as synonymous with interviewing. Interviewing is merely one stage of the lifecycle.

Hiring begins much earlier and ends much later. In my mind, the lifecycle starts when someone first says, “We need a role.” It continues through role definition, sourcing, recruiting, screening, interviewing, debriefing, offer negotiation, the 30-60-90 day plan, coaching, and integration into the team.

And it does not end when the candidate signs the offer letter. It ends when the person filling the role is consistently kicking ass.

That distinction matters. A manager who views hiring as an interview process stops caring after the offer is signed. A manager who views hiring as a lifecycle becomes deeply invested in onboarding, role clarity, expectations, coaching, and early success.

Everything Else Is Implementation

Only after all of this do we get to interview design, behavioral questions, written feedback, bar raisers, bias reduction, scorecards, and hiring committees. Those things matter. I care deeply about them. But they are implementation details.

The philosophy comes first.

If you genuinely believe that excellence in organizations starts and ends with hiring, a remarkable number of decisions become obvious. You raise the bar. You prioritize interviewing. You invest in recruiting. You define roles carefully. You take onboarding seriously. You treat every hiring decision as consequential.

Then you build Mechanisms so the organization behaves that way even when you are not in the room. Good intentions are never enough. A hiring philosophy without operating mechanisms is just a slide.

The rest is mechanics. I will write more about those later.

The future of an organization is largely the cumulative result of its hiring decisions. Culture, execution quality, leadership quality, and innovation all emerge from who you let through the door.

Most leaders claim to believe that. I am not sure all of them schedule their calendars as though they do.

As usual, I’d be interested in hearing where people disagree. Time will tell.

The post Hiring First. Everything Else Second. first appeared on tig.log.

The same question keeps coming up in maintainer conversations: what do you do when the pull request queue fills with work written by agents?

It’s something Nicholas Tindle, founding AI engineer at AutoGPT, also deals with every day. I spoke with him in May for Maintainer Month. At the time of the interview, AutoGPT had over 180,000 stars and around 150 open pull requests. A big chunk of those pull requests were written by agents, including Copilot, OpenClaw, and AutoGPT’s own internal tooling, among others. Most maintainers I talk to have the same reaction: close the door. Turn off pull requests. Don’t tax the team with reviewing slop.

Nicholas saw an upside:

It’s basically somebody else paying for your compute.

Nicholas Tindle, founding AI engineer at AutoGPT

The way he sees it, if a contributor wants to spend their tokens improving your project, let them. Just make it so the only way through the door is the way that works for you.

Your docs aren’t the problem. Discovery is.

AutoGPT tried the obvious thing first. Better contributor guidelines. Better docs. A whole wiki dedicated to working with the repo.

None of it moved the needle. It turns out the tools aren’t going to go read your docs unless they’re told to. That’s the part a lot of us get wrong. We treat documentation like the agent will go find it. It won’t. Agents read what’s in front of them, at the level of the directory they’re working in.

So AutoGPT started putting instructions where agents look. First CLAUDE.md files, because Claude was generating pull requests without enough repository-specific context. The commit trailer made each one easy to spot, because they announced themselves in the commit trailer. Then they hit the next wall: Copilot and Codex ignore Claude files, because they’re not Claude. So they centralized the standard AGENTS.md and pointed Claude files at it.

Here’s the nuance I found most useful. AGENTS.md is scoped to a directory. A skill can be discovered outside that directory. (If you haven’t shipped one: a skill is an instruction file with a description that tells the agent when to load it. The agent scans descriptions up front and pulls in the full instructions when the task matches.)

AutoGPT’s AGENTS.md sits beside the code it governs. That placement matters as much as the instructions themselves.

If you’re writing backend tests and you think about doing front-end stuff, a skill may load dynamically. It’s not going to know what directory to go look in for an AGENTS.md file, but the skill can tell it that.

Their front-end engineer got tired of the same class of broken pull request, so they wrote a guide, and shipped it as a skill in the repo. The description contained trigger phrasing: write a Storybook test if your component lives in these folders. Now every harness that touches the repo discovers it automatically. The backend enforces its own version of the rule the same way: hit 80% coverage or don’t open the pull request.

Gates that actually work

These are the gates you can adapt for your project.

Enforce the pull request template, loudly. AutoGPT tells agents that pull requests not matching the template get closed automatically with zero hesitation. They built the tooling to actually do it, then found they didn’t need to run it. At AutoGPT, the rule changed agent behavior before the automation ever ran. The agents followed the template. Human contributors sometimes needed more room, which Nicholas treats as a feature:

If you don’t follow the template, I know you’re probably a person, and I’m going to be kinder.

The test plan trick. The template requires a test plan, and its wording casually mentions testing the pull request. That phrase triggers a skill called test PR, which installs agent browser (with permission), spins up the app, and executes the change. The agent set out to fill in a checkbox and ended up running the code.

They almost never get pull requests that don’t work anymore. What they get now is pull requests that work but don’t fit the roadmap, which is a much better problem to have.

Make CI a wall, not a suggestion. Codecov coverage thresholds are required checks. The agent opens the pull request, checks back a few minutes later, sees it can’t merge, loads the testing skill, and writes the tests. Nobody had to ask.

Use the CLA as a human detector. AutoGPT is dual licensed, but Nicholas argues every project should do this, MIT included. Signing requires a browser and a GitHub OAuth flow on a separate domain. Agents are bad at that today, and for good reason: most maintainers do not want an agent logged into GitHub in a browser with broad account access.

If your CLA is not signed after a week, we close the pull request with a comment that says sign the CLA, reopen when you’re done.

That gate works because it puts a human back in the loop. A CLA is one option. A code-of-conduct checkbox can do the same job.

Require a commit SHA before resolving a review thread. Some agents mark every review thread as resolved without touching the code. AutoGPT’s fix is a pr-address skill in the repo that declares the only valid sequence: fix, commit, push, reply, then resolve. The reply has to link the fixing commit, with the full SHA pulled from git rev-parse HEAD after committing, so the agent can’t recycle an old one. The skill even names the anti-patterns: “Acknowledged” is not a fix, and neither is citing a commit that doesn’t touch the flagged line.

The gate they turned off

When a check fails, AutoGPT had an agent read the run and comment on what broke. Their first version wired Claude Code into GitHub Actions and authenticated it inside the workflow, which meant one more broad credential living in CI. Running Copilot in the workflow gets the same result without that. Nicholas is a fan:

It’s unbelievable. I’m so happy I never had to bother with YAML ever again. I’m never writing a workflow for an action ever.

Then they turned the commenting off anyway. Their CI fails a lot, and a bot narrating every failure all day is not much better than the failure itself. The lesson is the restraint: keep what lowers the maintainer burden, shut off what becomes noise.

Four gotchas worth writing down

A bad AGENTS.md file is worse than no AGENTS.md. AutoGPT littered them everywhere at first and ended up polluting context, pulling the agent’s attention toward files that didn’t matter. If behavior gets worse, go read what you wrote.

The GraphQL API will rate limit you. When every tool on your team hits the CLI as an individual user, you hit the ceiling fast. Create a GitHub App and authenticate the CLI through it.

The heavy review tooling costs real money. Their pull request test rig clones the branch, spawns eight agents with different jobs, runs the whole stack, and uploads screenshots. It’s great. It’s also expensive enough that they now run it only on very small or very large pull requests.

Go audit your authorized apps. AutoGPT is part of the Secure Open Source Fund, and this was one of Nicholas’s takeaways from that work. Every tool they trialed and dropped left an authorization behind.

If you stop using a GitHub app, remove it from the authorized apps. Do a little audit right now after this stream and go see what you have. You’ll be surprised.

Logging in with GitHub is so automatic at this point that most of us have never gone back to look. I opened my settings during the stream. He was right.

Not everything is a gate

Two takeaways from Nicholas had almost nothing to do with tooling.

First: you don’t have to accept every pull request. Merging someone else’s LLM output is asymmetric. You do the upkeep, forever. Closing the pull request and building the fix yourself is a legitimate choice.

You can disable pull requests entirely. You can restrict issue creation to collaborators. Nicholas tied those controls back to the thing he kept coming back to in the interview: maintainers need knobs. Sometimes the right answer is fewer drive-by pull requests. Sometimes it’s issues only. Sometimes it’s “talk to us first.”

SQLite doesn’t take external code contributions. They take bug reports. That’s a valid open source boundary. Your project can have one too.

Second: when you close a pull request you’re going to rebuild yourself, add the contributor as a co-author if it makes sense. AutoGPT has around 800 contributors, so one more costs them nothing. For most people, the thing that matters is that their problem got fixed and somebody noticed they showed up.

What I’m taking back

Open source has always evolved by making collaboration explicit. Licenses made permissions explicit. Issues made work visible. Pull requests made review a shared practice. Instructions in the repo look like another step in that direction, though I’d hold that loosely. Nobody’s landed on the right shape yet. AutoGPT is on its third version, and it got there by shipping bad versions first and watching what agents did with them.

You still decide what belongs. You still set the bar. The difference is that more of that judgment can live next to the code, where your contributors and their agents already are.

Go look at the AutoGPT repo and read how they structured their agent files.

Then go join maintainers.github.com. I’d tell you that anyway because I work here, so take it from Nicholas instead:

You’ve got to go there. You’ve got to sign up. It gets you all the connections you want at GitHub. That’s where I learned about all this stuff, and where I share it.

It’s also where Tiny Wins gets prioritized, the weekly drip of small maintainer-requested improvements. Some of those asks have already shown up in the controls GitHub highlighted during Maintainer Month. It’s also where our product managers and engineers read feedback before anything ships. If you want a say in what the platform does for maintainers next, that’s the room. Your contributors are already AI-first. Put the rules next to the code before the next pull request lands.

The post Your contributors are AI-first now. Is your project? appeared first on The GitHub Blog.

Ask an architect almost any question and you’ll get the same answer: It depends. For years this answer has been the punchline of jokes about architects, but in an era when AI can generate a working service faster than you can describe it, “it depends” is one of the most important phrases in software. It marks the exact boundary of what these tools can and cannot do.

The First Law still holds

We’ve said for a long time that the First Law of Software Architecture is: Everything is a trade-off. Nothing about generative AI repeals that law. If anything, it enforces it more brutally than ever.

AI coding tools are extraordinary at answering “how” questions. How do I implement a saga pattern? How do I set up circuit breakers between these services? How do I paginate this API? These questions have answers that exist in the world in documentation, in open source code, in a decade of blog posts, and large language models have read all of it. Asking an LLM a “how” question is like asking a very fast librarian who has memorized the library.

Architecture questions are not “how” questions. They’re “should” questions, and “should” questions have a different shape entirely. The honest answers require knowing things that appear in no training: that your ops team is three people, that the CFO just froze cloud spend, that the last reorg left the payments team demoralized. An AI can enumerate the generic trade-offs of distributed architectures beautifully. What it cannot do is weigh them, because the weights live in your organization, not on the internet.

That’s the Second Law, incidentally: “Why is more important than how.” LLMs are “how” machines. Architects are “why” people.

Cheap code makes decisions expensive

There’s a tempting inference floating around: If AI makes building software easier, surely it makes architecture matter less. Our experience so far suggests the opposite. When code was expensive to produce, the cost of construction acted as a natural brake on bad decisions. A questionable design took months to build, and somewhere in month two, someone usually noticed. Now a team can stand up a fleet of services in a week. The brake is gone. It has never been easier to build the wrong thing quickly, at scale, with tests.

Think of AI as an amplifier. Point it at a sound structure and it accelerates you. Point it at a flawed one and it pours concrete over the flaw before anyone has time to object. The half-life of a bad architectural decision used to be measured in the time it took to implement; now the implementation arrives almost instantly, and you get to live with the decision for years.

This shifts where the leverage sits. When implementation is abundant, judgment is the scarce resource. Someone still has to decide where the service boundaries go, what “good enough” availability means for this system, and which architectural characteristics actually matter.

Judgment doesn’t come from reading

Here’s the uncomfortable part, and it applies to humans as much as machines: You cannot learn trade-off analysis by consuming content about it. We’ve written a fair amount of that content ourselves, so we say this with some authority. Books and talks give you the vocabulary. They don’t give you the judgment.

Judgment comes from making decisions and living with the consequences or at least watching someone experienced make them, asking why, and arguing about the alternatives. Every working architect we know learned the craft this way: apprenticed to messy, real problems, with feedback loops. The pattern catalog was the easy part. Knowing which pattern not to use, and why, and being able to explain that to a skeptical VP that took years of reps.

This is also, not coincidentally, exactly what today’s AI lacks. A model trained on the world’s code has seen millions of decisions but almost none of the consequences. The post mortem that traces an outage back to a boundary drawn wrong in 2019 rarely makes it into the training data, and even when it does, it isn’t connected to the pull request that caused it. Architecture’s feedback loops are measured in years. That’s precisely the kind of learning that can’t be scraped.

Where this leaves engineers

If you’re a developer watching AI absorb more of the implementation work, the strategic question isn’t whether your current tasks will change but where to move on the value chain. Our answer is to move toward the decisions. Toward the trade-offs, the constraints, the “it depends.” That territory isn’t shrinking; it’s growing, because every AI-accelerated team needs someone who can tell the amplifier where to point.

The good news is that this is learnable. Not from a book alone, and certainly not from an LLM, but the way it’s always been learned: by practicing architectural thinking on real problems, with experienced people looking over your shoulder and asking why. We’ve spent the last several years teaching it that way, most recently in a six-week cohort format that works less like a course and more like a short apprenticeship in making and defending architectural decisions. (Details are on the O’Reilly live events page, if you’re curious.)

However you pursue it, pursue it. The machines have gotten very good at “how.” The career-defining skill of the next decade is being the person in the room who can answer “should,” who knows that the real answer starts with “It depends,” and can finish the sentence using their brain alone.