What an "AI Developer" Actually Is, and How to Hire One

Sebastian Alvarez shares what analyzing the public GitHub firehose taught him about who is actually good at building software.

The "AI Developer" Nobody Can Define

Ask a hiring manager what an AI developer is and you will get a confident answer that falls apart under one follow-up question. We get the request constantly at Human Cloud. We ask what it means. The room goes quiet.

Sebastian Alvarez gets the same request at Remotely, and because his team has to actually fill the role, he was forced to break it into something usable. There are three of them, and they are not variations on a theme. They are different jobs, different people, and wildly different price points.

The first is the engineer who uses AI to write code faster. Claude Code, Codex, whatever the tool. Same output as before, compressed. The second builds products on top of AI: integrating models, wiring up voice or vision, making the product itself smarter. The third is the machine learning engineer modifying models for a specific use case. Rare, expensive, and almost never what the person asking actually needs.

Ask for the wrong one and you pay research prices for work a strong full stack engineer would have shipped in a week.

Why the Technical Interview Stopped Working

Here is the part that should make every engineering leader uncomfortable, coming from someone whose company screens engineers for a living.

"I would stop doing the technical test. I don't think that the technical test has any value anymore, in the sense that writing code by hand is not a feature anymore." - Sebastian Alvarez

The logic is hard to argue with. The technical test measures how well someone writes code by hand under artificial conditions. That skill stopped being scarce. So you are spending your most expensive interview hours grading the one thing AI made abundant.

What he does instead is almost old fashioned. Talk to them. Ask them to record a short video, then have a real conversation. Ask a lot of questions about what they built and why they built it that way. Screen for whether they fit how your team actually works, because with AI, in his words, any good engineer should be able to work on any platform.

That has a consequence most CTOs have not thought through. If culture is the primary screen, your CTO is no longer the right person to run it. Your talent and people leaders are. This is the strongest argument I have heard for pulling them deeper into engineering hiring rather than further out.

Hiring Software Engineers When Code Is No Longer the Bottleneck

Underneath all of this sits a claim that reframes the entire AI headcount debate.

"The main problem now, even now with AI, is that we're writing too much code that nobody cares about." - Sebastian Alvarez

Code was never the constraint. Deciding what deserved to be built was. AI made the first one nearly free and did nothing at all to the second. So the honest outcome for many teams is not ten times the output. It is ten times the volume of software nobody asked for, shipped faster, and now permanently in the codebase for somebody to maintain.

His answer to "why not just fire everyone and run Claude" starts there and gets more practical. You cannot fire everyone because someone still has to run what you already built, and not every piece of code can be handed to AI. Whether your product can be developed with AI at all is, as he put it, a big thing to say out loud. It depends entirely on how your infrastructure runs and how your code is structured.

What he would do with a real budget is not hire a big team. It is build pods of three, a talker, a builder, and a designer, hand each pod a single business KPI, and get out of the way.

Cultural Fit Screening at Scale: 200,000 Engineers, 8,000 Accepted

None of this would land without the machinery underneath it. When Sebastian started Remotely, he knew the engineers in his own city and nobody else. So his team went and analyzed the public GitHub firehose, mapping engineers worldwide by what they actually commit: which technologies, how much review they do versus how much they write, how many pull requests they open, how often other people accept their work.

Then they layered the human screen on top, run by a team that included a psychologist and an English teacher, asking candidates what kind of company they wanted to work at and tagging the answers. Someone burned out by a startup is not a bad engineer. They are a great engineer for a scale-up.

The result is roughly 8,000 accepted engineers out of more than 200,000 evaluated. Technical signal from public behavior, cultural signal from real conversations, matched against a profile of the customer built the same way.

Why This Is an Argument for Partners, Not Job Descriptions

Now put yourself in the hiring manager's seat. If everything above is right, you need to redesign engineering hiring from the ground up: cut the technical test, screen for culture, restructure into pods that own business outcomes. And you are doing it maybe once a quarter, from scratch, with no reps.

Remotely does it every day. That gap is the whole argument.

What matters here is that a traditional staffing firm cannot do what Sebastian's team does. Not through any failure on their part. They optimized for a different decade, investing in account management, a sales layer, and manual recruiters, which was exactly the right investment ten years ago. Remotely invested in reading every public commit on GitHub and building a cultural screen on top of it.

Same category on a vendor list. Completely different machine underneath. And a buyer comparing websites has no way to see the difference, which is precisely why we built Human Cloud: to make the machinery visible, so companies can find the right partner in minutes instead of months rather than defaulting to whoever writes the best proposal.

The Bottom Line

If you are hiring an AI developer, the first task is not writing the job description. It is deciding which of the three roles you actually mean, then accepting that the interview loop you inherited tests for a skill that stopped being scarce.

Sebastian's own summary of what to screen for is disarmingly simple: the engineers who last are the ones who can sit with a user, hear the real problem, choose a solution, and then come back and explain why. Everything on the other side of that line is increasingly automatable.

Code is no longer king. Context is. And the fastest way to get context you do not have is to partner with someone who does this every day instead of once a quarter.

---

About Sebastian Alvarez

Sebastian Alvarez is co-founder and CTO of Remotely, where he built the GitHub commit-analysis engine that maps engineers worldwide. He was previously the first engineer at Olapic, scaling its Argentina engineering org to nearly 100 people before the company was acquired.

Listen to the full episode: Human Cloud Podcast on Spotify

---

This article was adapted from the Human Cloud Podcast. Subscribe wherever you get your podcasts.