Automation or augmentation: the question that decides where AI fits into your team
A Stanford study using payroll data from millions of Americans shows: junior employees in AI-exposed roles are already 19% behind. And the cut isn't layoffs, it's the position that never opens.

Marcelo Sampaio, founder of Hashdex, published in Brazil Journal an account of six weeks at Stanford that matters less for the trip itself and more for a question he brings back from professor Rob Reich: does AI exist for automation or for augmentation? Automating means building the machine that does what the human does (the tradition of John McCarthy, founder of Stanford's AI lab). Augmenting is the line of Douglas Engelbart, who in 1962 wrote Augmenting Human Intellect, proposing to expand human capability instead of removing the human from the equation, which Steve Jobs would later call a "bicycle for the mind."
For anyone who writes code, this isn't stage philosophy. It's the decision you make every time you turn on an agent or a copilot in a workflow: is the tool replacing a person in the equation, or expanding what that person can do? And the article brings real data to show that this choice has measurable consequences.
The number that separates "doing a task" from "having a job"
Reich presented in class two benchmarks that seem to contradict each other, and don't:
| What is measured | Where AI stands | |---|---| | Short tasks (financial analysis, presentation, document) | Ties or beats specialists in 74% of cases | | Complete projects of ~30 hours | Automates about 4% |
Sampaio's reading is direct: "AI is already extraordinary at pieces of the work, but it's still very bad at having a job". For anyone building software, this precisely describes the experience of using Copilot or Claude Code day to day. The model writes the function, fixes the isolated bug, generates the boilerplate. It doesn't hold the architecture of an end-to-end system for 30 hours without getting lost, without hallucinating context, without needing a human reading every step. A job isn't an indivisible unit: it's a set of tasks, and AI eats the short tasks first.
David Autor, of MIT, spent decades showing that technology eliminates tasks, creates others, and redesigns professions, not necessarily destroying work. Agricultural mechanization, the assembly line, the computer: each wave killed functions and created entire economies. The historical mistake, the piece argues, is confusing the automation of a task with the extinction of the need for human work.
The data point that should scare engineering leaders
Here the article moves from theory. Erik Brynjolfsson, director of Stanford's Digital Economy Lab, together with Bharat Chandar and Ruyu Chen, cross-referenced ADP payroll data from millions of Americans looking for the first signs of AI's impact on the labor market. The finding:
Among workers aged 22 to 25 in the occupations most exposed to AI, employment is already 19% lower than that of same-age peers in less exposed areas. Experienced professionals in the same occupations? No comparable effect.
>
-- study by Brynjolfsson, Chandar and Chen, cited by Marcelo Sampaio in Brazil Journal
And, crucially: the adjustment doesn't come from layoffs. Nobody is cutting seniors. The market is simply not hiring juniors. The second finding is what closes Reich's argument with real data: the deterioration concentrates where AI is used to automate. Where it complements human capability, employment is stable or rising.
Translating this into the McCarthy vs. Engelbart fight with payroll numbers: it's not human against machine. It's human with machine against human who hasn't yet learned to use it.
The invisible ladder we might be sawing off
This is the point that should most keep anyone building a technical team in Brazil up at night. Every profession has a ladder. The junior programmer fixes bugs and reviews PRs for years before architecting a system. The problem, as the piece puts it, is that the first rungs are exactly the tasks easiest to hand over to AI.
In other words: you can automate the junior without automating the senior, and discover ten years from now that you've dismantled the factory that produces seniors. A senior doesn't sprout fully formed. They're a junior who went through thousands of bugs, code reviews, and wrong decisions. If the machine absorbs that layer of learning, where does the architect of 2035 come from?
That's why this transition may be harder than previous ones. The tractor hit the field, the assembly line hit the factory, the computer gradually entered the office. Each wave gave a generation time to reinvent itself. AI arrives for the lawyer, the doctor, the designer, and the programmer all at once, and it isn't asking permission.
The honest counterargument
Before wrapping up, the strongest counterargument: perhaps cutting juniors is no different from the computer having killed typing pools. A new tool raises the entry bar, the market resettles, and the "junior" of 2030 already comes in knowing how to pilot agents, becoming productive faster than today's junior ever was. On this reading, the 19% gap is transition pain, not a permanent structure, and Sampaio himself says he's optimistic about the eventual balance.
Maybe. But there's an asymmetry the typing pool analogy doesn't cover: typing was a peripheral task; PR review and bug fixing are the training mechanism for whoever is going to architect. Automating the output of texts is different from automating the rung of learning. And the ADP data doesn't show juniors migrating to a better role. It shows the position not opening.
What I would do with a team in Brazil
Reich's closing point is what matters most to decision-makers: the future with AI isn't a problem of prediction, it's a problem of design. Nothing forces technology to evolve to maximize automation. Companies choose where they put capital and how they implement it.
For an engineering leader in Brazil, where the cost of training a local senior is already high and the junior pipeline is large, this becomes a concrete management decision:
- Treat AI as augmentation, not substitution, at the entry level. Give juniors the copilot as a learning accelerator, not as an argument for not hiring. A junior with AI who understands what the AI generated is worth more in three years than the savings from not having hired them.
- Don't let the machine close the rung of review. If the agent fixes the bug and the junior just approves it, you've automated the task and the learning along with it. Force the reading, the understanding of the diff, the justification for the choice.
- Measure complement, not cuts. The right question isn't "how many positions does AI save me," it's "how much more does each person deliver with it." The part of the study where employment rises is exactly the augmentation part.
The scenario where machines simply replace humans isn't an inevitable consequence of technology. It's a choice, and it's made in the design of your team's workflow, not in a keynote in San Francisco.
Translated from the Brazilian Portuguese original · Read the original
The official Y Combinator SAFE, not the translation, decides the Brazilian founder's cap table
YC's standard document package for SAFE fundraising covers the US, Canada, Cayman, and Singapore, but still has no version for Brazilian companies: the English-language text, tied to one of these jurisdictions, is what actually holds in practice.




