Adrián Mato – Designer at XBOX, leading developer & creator tools

Teaching my agents to work alongside me

2026-08-26T06:06:00-07:00

Most of the conversation around agents is still about making more, faster.

I’m more interested in something slower: teaching my own agents how I work, so I can stay close to more of the work without lowering the bar.

That’s the idea I’m interested in: reach without dilution.

Yesterday I watched a great presentation by @poteto where they compared building a team of agents to running an engineering team. That analogy stuck with me.

A team doesn’t become autonomous because you keep handing people tasks. In my experience leading teams, people gradually absorb what the work is for, what good looks like, and what you refuse to compromise on. They understand not just what you want, but why.

Looking through pstack, what struck me wasn’t really the automation. It was seeing one person’s way of building made explicit enough for an agent to actually use.

This is also why I’m skeptical of blindly downloading someone else’s giant pile of skills, pretending it’ll just work, and calling it a day.

The interesting part of /poteto-mode isn’t the pile of skills. It’s the work behind it: someone gradually making their instincts, standards, and way of building understandable to agents.

Borrowing those skills can help. But using them as a substitute for figuring out my own way of working? Not super inspiring.

That work is slow, but it compounds.

I have a bad habit of thinking I need to do everything myself. Partly because doing the work is satisfying. Partly because the sense of progression is addictive. And partly because every handoff feels like something might get lost.

Most of the time I know pretty clearly what I want to make. The problem is the hundred small obstacles between the idea and the thing. They eat attention. Sometimes I end up making the idea smaller or lowering the bar simply because I can’t hold everything at once.

Maybe the real constraint isn’t output. It’s how much of the work I can stay close enough to care about.

That’s why I don’t want agents to detach me from the work and manufacture more stuff. It’s literally the opposite.

I’m interested in whether they can remove some of that friction without pulling me away from the decisions and details I care about.

I don’t really think of them as minions. More like partners I’m gradually teaching how to work with me.

The funny thing is, teaching them forces me to understand myself better too.

Things that used to live vaguely in my head suddenly need words. I have to explain why something feels wrong, why one choice is better, and where the quality bar actually is. In doing that, I end up questioning and sharpening my own taste.

I have no interest in shipping more slop faster. I’d rather ship less, with more ambition and care, while being able to shape parts of the work I simply couldn’t reach before.

None of this happens overnight. I get things wrong, correct them, and try again. Eventually, hopefully, they start getting more of what I mean without me having to explain every little thing.

Maybe that’s the promise of agents I’m most excited about: more room to be ambitious about the things only I would make, while the work still feels like mine.

Remote work is a blessing and a competitive edge

2025-01-31T01:30:00-08:00

Talent is everywhere. Opportunity is not.

As we welcome our newest Design Engineer to the Copilot Design team, I’ve noticed a trend—the last four hires have all been from Europe. Many of GitHub’s most talented designers are overseas, complementing a widely distributed North American workforce across timezones.

In contrast, many CEOs continue pushing for office returns, insisting that AI and innovation can only thrive in San Francisco. This coordinated narrative makes me question the real motivation behind it. Is it truly about productivity, or is it more about keeping office landlords, VCs, and gatekeepers happy?

Funny enough, DeepSeek caught everyone off guard this week, proving once again that innovation and creativity aren’t exclusive to a limited group of people nor region—and that great things can happen anywhere in the world.

Many startups, including my current employer GitHub, thrived on remote work. Yet, many remote-friendly companies are pulling back—not because remote work failed, but because they have failed to scale effectively. When a startup grows from 100 to thousands, bureaucracy creeps in, and efficiency crumbles. The trust that fueled innovation erodes, and leadership fears losing oversight. In that scenario, remote workers seem less convenient than chair-warmers at the office.

However, most modern work is already remote. Teams sit in offices wearing noise-canceling headphones, joining video calls with peers in the same building. If it was this simple, companies wouldn’t struggle to ship while their offices are full.

Don’t get me wrong, I love in-person collaboration. I love grabbing a piece of paper and a pencil, a marker and a whiteboard, and have deep discussions. My early days at GitHub were filled with camaraderie and valuable spontaneous conversations at the office. Most of this is replicable with async video walkthroughs, iPad sketch sharing, and other remote collaboration tools. In fact, most of us are building those tools to foster collaboration.

Companies that are able to see past trends, and find a hybrid model to allow them to identify, attract, and retain talent will outcompete those stuck in the 20th-century. Back in the day job-hopping wasn’t as common, but forcing relocation in a hyper-connected world is backward. People have family, friends, and a community that made them who they are today.

Remote work isn’t for everyone. It demands proactivity, clear communication, and strong independence— qualities that matter anywhere remotely or at the office.

Many of the world’s brightest minds have come to the U.S., made significant contributions, grew, and then left—driven away by visa barriers, personal priorities, or simply a different lifestyle. Meanwhile, hidden talent in small towns worldwide keeps refining their craft, waiting for a chance. I write this from a privileged perspective—as a Spaniard who moved to the U.S., built a career in tech, and helped shape one of the most successful AI-driven products. I know firsthand how hard it is to break in and how many obstacles stand in the way. There’s nothing better than finding someone in the middle of nowhere doing their best work.

Focus on output, not attendance. The best teams aren’t built by location. They’re built by finding the best minds, wherever they are.

Talent wins. Attract it. Build the best team possible. Win.

Podcast interview: designing GitHub Copilot with Software Engineering Daily

2024-03-14T06:00:00-07:00

I’m thrilled to share that I recently made my first-ever podcast appearance, and what a better way to kick things off than on the Software Engineering Daily podcast.

During the episode, I had the pleasure of speaking with Jordi Mon about the challenges and trade-offs involved in designing GitHub Copilot for scale. Looking back on what felt like cutting-edge technology in mid-2023, before GitHub Universe, it now brings both a smile to my face and a touch of embarrassment 😅.

Feel free to listen to the full interview here.

Thanks to Jordi and the team for having me!

Bigger isn’t better: the companies scale dilemma

2023-09-14T10:34:00-07:00

We need more companies doing fewer things, fewer features, and requiring fewer employees. Building high-quality software is fun when you have focus and a tight team.

The current scale of most teams and the absurd financial goals make a large portion of this industry unbearable.

Redistributing the workforce among a broader spectrum of companies will generate more competition and ownership. The ultimate beneficiaries? End-users who enjoy better products and solutions.

The scale pushes us to generate intermediate layers of tech, processes, middle management, and other fat, distracting us from creating better products.

Simply downsizing and flattening organizations isn’t the answer. Companies need to reduce commitments and laser-focus on genuine value delivery.

Most of these problems have been auto-infringed. It’s puzzling to see hyper-growth startups sprinting into the scale issue as soon as they raise some money. Rather than benefiting from focus and competitive advantage, they jump right into the fire with the rest of the companies.

But here’s the truth: introducing more processes and trying to generate order in a bloated, stressful system that’s overly ambitious won’t work; it will burn out most of your team.

These distractions divert our focus from crafting delightful products and building sustainable teams. Let’s recalibrate and aspire to do better.

Speeding up the TypeScript development flow for instant feedback

2021-09-05T14:00:00-07:00

I recently started porting github-pewpew to TypeScript. I enjoy using types, but I struggle with the developer velocity due to compilation times.

I tried enabling a --watch implementation so that my project will compile on the fly. That way, I have it ready to go when running my application. While the experience has improved, it’s still slow when I need instant feedback on my changes. I also tried turning on the --incremental flag decreasing times by 200ms to 300ms.

I’m not alone, the community is discussing about it. The biggest advantage is to transpile skipping types checking, but it’s not supported. This is where the SWC compiler comes in.

Aiming for instant feedback with SWC

SWC is a typescript / javascript compiler written in Rust that’s blazingly fast. They claim to be “20x faster than babel on single thread, and 70x faster on 4 core benchmark”.

Here’s the comparison between tsc and swc transpiling a project with three simple files:

The left side is tsc; the right side is swc. SWC finishes way faster even when I run the command later. It’s almost 1.5 seconds faster compiling just three files.

Setting up SWC it’s pretty straightforward. I installed it as a devDependency, and added some commands in my package.json file:

"scripts": {
  "clean": "rm -rf dist",
  "prebuild": "npm run clean",
  "build": "tsc",
  "start": "npm run build --silent && node dist/index",
  "dev": "node node_modules/@swc/cli/bin/swc src --out-dir dist --delete-dir-on-start --quiet && node dist/index"
}

The dev command calls swc, sets up the output folder, and makes sure previous builds are deleted before starting.

It’s even more noticeable when working in more complex projects. Here’s another comparison running both at the same time using pipes:

What’s the trick?

Rust always gets a lot of praise for its speed, but it’s not just that: it’s skipping the types checking to go even faster. This is not something you want when building your final build to distribute. That’s why I keep a build command using tsc to build the final version of my application.

Does this mean I’m not taking advantage of type checking while developing? Not at all; VSCode TypeScript support will still throw errors and warnings in real-time.

The trade-off here is we need to maintain aligned two configuration files tsconfig.json and .swcrc. They don’t share the same properties, but it’s easy to guess because naming it’s self-explanatory.

Here’s an example of my .swcrc file:

{
  "jsc": {
    "parser": {
      "decorators": true,
      "dynamicImport": true
      "syntax": "typescript",
    },
    "transform": {
      "decoratorMetadata": true
      "legacyDecorator": true,
    },
    "keepClassNames": true,
    "loose": true
    "target": "es2018",
  },
  "module": {
    "lazy": false,
    "noInterop": false
    "strict": true,
    "strictMode": true,
    "type": "commonjs",
  },
  "sourceMaps": "inline"
}

And here’s the tsconfig.json file:

{
  "compilerOptions": {
    "allowJs": true,
    "esModuleInterop": true,
    "incremental": true,
    "module": "commonjs",
    "moduleResolution": "node",
    "outDir": "./dist",
    "resolveJsonModule": true,
    "rootDir": "src",
    "skipLibCheck": true,
    "strict": true,
    "target": "ES2015",
  },
}

Looking forward to a faster cycle

The worst and best part of the JavaScript community is how fast is changing every day. I’ve already seen other folks in the community working on faster alternatives. I can’t wait to see what comes next to ease our developer experience!

Do you have any tips?

I’d love to know if you are using SWC or something else to speed up your developer velocity. Hit me up on Twitter at any time.

Thanks to Lucia, Jorge, and Sergio for the feedback before publishing this article.

github-pewpew: a CLI tool to clean up and remove unnecessary GitHub repositories. 🔫 Pew pew!

2021-08-11T06:56:00-07:00

Why?

Have you ever had too much fun with the GitHub API and ended up creating too many dummy repos? Me too 😅!

I made this little CLI tool to clean up repositories quickly. I’m planning to add some flags and regexp to delete in bulk in the future. Let me know if that sounds interesting to you.

Get the latest version published in npm. It’s open-sourced on GitHub under MIT license.

📦 github-pewpew v1.2.2 on April 5, 2022

A new version 1.2.2 has been published to npm. It’s a minor update, but it’s a special one: we are launching a brand new website and logo.

📦 github-pewpew v1.2.0 on August 24, 2021

I published version github-pewpew v 1.2.0 to npm. A much-needed refactor after v1.1.0 that improves the overall stability of the app. You can now get more than 100 results, as there was no pagination in prior versions.

Many bugs have been fixed, and the authentication process is now more robust when tokens get invalidated in different scenarios. I’ve also added some testing using Mocha to cover the authentication flow.

Next, I’m porting everything to TypeScript. I hope you like it, and thanks for the feedback!

📦 github-pewpew v1.1.3 on August 14, 2021

A new version github-pewpew v 1.1.3 is published in npm. It’s an important update as it’s making it way easier to use than before. It’s also lighter in size.

The auth solution wasn’t too friendly, so I re-implemented it using OAuth, and it’s working like a charm. Plus, it doesn’t need to ask for the username. You automatically get a validation code copied to your clipboard, paste it, and you are good to go! Kudos to @mamuso for suggesting me this mechanism I never used before.

I also added persistent configuration. There’s no more need to sign in every time you run the command. During this implementation, I learned about os.homedir(), the differences between operating systems, and how they store user configuration files.

Here’s how it works:

function getConfigDir(homeDir) {
  const configDir = path.join(
    homeDir,
    process.platform === 'win32'
      ? path.join('AppData', 'Roaming', PACKAGE_AUTHOR, PACKAGE.name)
      : path.join('Library', `com.${PACKAGE_AUTHOR}.${PACKAGE.name}`)
  );

  return configDir;
}

// Windows: adrianmg\AppData\Roaming\adrianmg\github-pewpew
// macOS/UNIX: /Users/adrianmg/Library/com.adrianmg.github-pewpew

The win32 solution won’t work for systems older than Windows Vista. I guess that’s OK in 2021? Some npm packages provide a robust solution covering all the different platforms, but it felt like a waste of weight for such a small tool. Plus, I’m learning a few things along the way.

📦 github-pewpew v1.0.0 on August 11, 2021

The first public version, github-pewpew v 1.0.0 released on npm. The authentification is relying on both e-mail and PAT (Personal Acess Token) with a repo_delete scope. Although it works, it’s adding too much friction as the user must constantly copy and paste the value to get permissions to delete repositories.

I’m planning to reduce friction via a refactor that will use OAuth as the mechanism to get permissions.

Questions? Ideas? Bugs?

If you run into any issues or you’d like to share your thoughts, feel free to open an issue in this repository or hit me up on Twitter.

Improving the experience of GitHub Actions Logs

2020-12-03T10:00:00-08:00

It’s now even easier to review logs from your GitHub Actions workflow runs. We’ve introduced several improvements to make the experience more performant, precise, and pleasing to use.

Why these changes matter

When we think about successful automation, we aim to spend the least amount of time looking at what’s automated, so we can focus our attention on what’s relevant. But sometimes things don’t go as planned, and we are required to review what happened. That debugging process can be frustrating; that’s why we’re introducing a series of changes that will improve both performance and user experience:

Simplified the layout structure
Introduced a single and faster virtualized scrolling
The search is now more responsive
Better ANSI, 8-bit, and 24-bit color support
URLs are now interactive
A new full-screen view mode
A refreshed UI that improves readability and overall interactions

Because a picture is worth a thousand words, here’s an overview of the changes:

Super-charging the debugging process

The performance gains will make your logs load faster and smoother when scrolling. It’s more apparent in logs with thousands of lines. We also felt it was an excellent time to improve the overall experience, putting a particular emphasis on readability and the interactions to make the UI more responsive and precise.

Let’s dive into these changes.

Layout structure and a single scroll

We have established a clear layout structure that enables a quick way to navigate between the jobs while keeping the context of the currently debugging step.

This is especially relevant when logs are dense. We want users to still be able to easily navigate between the different search results while keeping track of the step they are currently focused on.

Improving readability and interactions

All of the elements in the logs now have improved contrast, alignment, accessibility, and overall desktop and mobile interactions.

These additions result in a better reading experience, letting users scan through the logs’ content quickly and find what they are looking for.

The search also received minor visual updates and interaction design updates. Additionally, we’ve improved the performance by defining a threshold that will prevent the system from querying unintentional matches. These gains are especially apparent in content-heavy logs.

Color is a powerful visual resource, and we wanted to be more mindful of using it to guide you to the right place, so we have redesigned how we use color in our log output. If things go as expected, your logs will look largely the same. If items are in progress, waiting for your input, or even failing, you’ll now be able to quickly locate the item that needs attention and start taking action on your next task.

Opening the door to a more colorful experience

We want to be more mindful about color usage, which means we also need to acknowledge that people build their own scripts, commands, and tools to output useful information.

That’s why we are increasing the color support, including:

ANSI colors
8-bit colors
24-bit colors

This enables richer content and better integration when rendering information coming from third-party sources. Here’s a sneak preview of how some of them will look like:

Id’d love to hear your thoughts!

I enjoy a conversation about design. I would love to hear any feedback you have—share your questions and comments, find me on Twitter.

Thanks!

Worklog: Sharing your process and work in progress

2019-12-12T14:30:00-08:00

December 16, 2019 at 22:30

I just arrived in my hometown with a terrible jet lag, so I managed to put together a first working version of the new login system using passport-twitter. I spent a decent amount of time debugging a token session error while using cookie-session. It turns out using sameSite: strict won’t work and it will throw some token errors when running the app in a local environment.

The next steps are figuring out the data retrieved from Twitter and hook it up properly with the data model in the database.

December 12, 2019 at 22:30

After eight years working together, mamuso and I thought it was time to build something together out of work, so here we are. We have a specific goal: to improve the sharing of process, work in progress, and feedback for creators. We are trying to limit the technical complexity by relying on a JavaScript boilerplate that Max and Brian have put together.

We got login sessions working via Google Auth, but I’m currently working on a Passport Twitter Strategy.

Saying goodbye to a great 2018!

2019-01-01T08:00:00-08:00

The past year has been an amazing one, but before getting into the details, I’d love to share some thoughts on 2017 as I have been struggling to talk about it for quite a while.

Coming from a tough 2017

On February 2017, we moved to San Francisco as it seemed to be a great professional opportunity for both me and Lucia. It turned out to be one of the most challenging years:

Lucia gave up her job in London and couldn’t find anything good
Our dog Coco passed away (we miss him so much)
Timezones and distance with family and friends
I wasn’t as happy as before at my job

The transition between Madrid and London was so smooth that I think we overestimated how difficult it would be to move to a different continent, country, and city.

We almost gave up, every week we would sit down and discuss moving back. We were so contaminated that we couldn’t enjoy anything, even the good news. I still feel guilty for asking Lucia to move with me giving up her job.

When things couldn’t get worse, we did a hard reset. We forced ourselves to be more positive, to give it a try, and things started (slowly) to feel better. I know it sounds like bullshit, but sometimes looking at the same problems with different eyes is a good first step towards a better situation.

It’s been an amazing 2018!

The past 2018 was arguably one of the best years of my life. It was the first time I’ve managed not just to accomplish my own goals, but also helped others to achieve theirs. After all we have gone through, I feel we deserved it.

Helped Lucia with a career change into Front-End Development.
Changed jobs and joined Microsoft Azure DevOps
Run my first marathon and a total of 670 Km
Traveled more: Yosemite, Death Valley, Joshua Tree, Vegas, Mexico, Seattle, Raleigh…
Shot a lot of photos
Build and launched my website
Got promoted at Microsoft (finally?)
Sold my first company, Erasmusu (excellent job, Javi, Emilio, and Ivan!)
Modeled more 3D stuff
Failed at reading more books

The best thing happened at the end of the year, after an entire year studying on her own on a full-time basis, Lucia landed her first job as a Front-End Developer. There are no words to describe how happy and accomplished we both felt after this entire year of tireless effort. Being able to share and enjoy some common goals with other people has been the most significant learning from this year. I’d love to do more of that during 2019.

Because one picture is worth a thousand words… here are a few summarizing my year 🙂.

Thanks to everyone that helped to make a fantastic year. I’m planning to share my goals for 2019 in an upcoming post. Until then, Happy New Year to everyone! 🙂

Worklog: Small tool for servers to be figured out yet

2018-11-24T13:40:00-08:00

March 29, 2019 at 7:51

Some news, Iván has paired up with me helping to improve the business logic, and making the code a bit more robust for future steps. I’m trying to put together a template to generate the first version of the front-end. Basically we will be able to serve all the data we’re collecting.

November 25, 2018 at 16:05

I’ve refactored and added long polling to the nodejs application so now I can control how often the date is going to be retrieved. I also set up a simple docker container that allows me to deploy the app to now/zeit continuously.

Here’s a preview of the app running while updating the real-time database from firebase:

I’m going to leave this up and running for a few days as I keep making progress on the client side. Hopefully, it doesn’t crash 😅.

November 24, 2018 at 21:45

I’m still not sure where this is going to, but I’ve managed to put some hours to code the first part of it. I’ve started with a nodejs client that pulls information from a list of endpoints and write all that data into a Firebase real-time database.

Stay tuned, I think it’s going to be useful. I’m going to invest the next few days working on a React client that would read all this information and give it some structure to make this more useful.