Today's Overview
A decade from now, someone will ask: where did the jobs come from when AI automated so much? That question matters now because MIT research published this week shows exactly who has historically filled new tech-created roles-and it's a narrow slice of the workforce.
The employment pattern that repeats
MIT labour economist David Autor and his team analysed 70+ years of US employment data. Their finding: when new types of work emerge from technological change, college graduates under 30 in urban areas capture most of it. In 1950, about 7% of workers held jobs that didn't exist in 1930. By 2020, that number had grown to 18%-roughly one in five jobs now involves work that emerged in the past 50 years. But the pattern is consistent: expertise concentrates first among the young and educated. Wage premiums exist, but they fade over time as the skill becomes common knowledge. Driving a car was scarce expertise once. Using Word was too. Then both became baseline.
What matters for businesses and builders right now: demand drives innovation, not just supply. The research reveals that government-backed investment-like the manufacturing buildout during World War II-created enormous waves of new specialised work. This suggests that how we deploy AI isn't predetermined. We can choose to automate jobs away, or we can create new layers of skilled work around AI systems. One path kills employment. The other creates it.
Infrastructure changes code, again
On the building front, AWS SageMaker now speaks OpenAI's language. You can swap an OpenAI endpoint URL for a SageMaker one-no SDK rewrites, no custom authentication wrappers. This matters because it means teams running inference on their own infrastructure no longer carry the burden of being "different." Your existing LangChain agents, Vercel AI SDK code, and OpenAI client patterns just work. Deploy a model to SageMaker, change the endpoint URL, done. For companies building on open-source models or handling sensitive data that can't leave their infrastructure, this removes friction that previously existed. The bearer token approach (time-limited, cryptographically signed) handles auth without adding complexity.
Elsewhere, a developer built an uptime monitor because existing tools felt bloated. They shipped it using Convex for the backend (reactive queries handle real-time updates without WebSocket management), Clerk for auth, and Resend for alerts. The interesting bit: they're in India, so Stripe wasn't available. They used Lemon Squeezy instead, which handles tax compliance automatically. This matters because it shows the working reality of indie builders in 2026-the tooling exists, the complexity has moved sideways (now you're choosing between payment processors instead of fighting database issues), and someone can ship a production service in weeks that five years ago would've taken months.
For web developers building on GraphQL, a detailed analysis this week compares it to REST using a real problem: the `/api/auth/me` endpoint that returns everything a user might ever need, computed expensively every time, even when the frontend only displays a name and avatar. GraphQL allows clients to request exactly what they need. More importantly, it enables lazy computation-rank calculations, badge aggregations, transaction summaries only get computed when explicitly queried, not on every app load.
The practical question for teams now: these tools exist. Deployment patterns are settling. The labour economics suggest that new tiers of skilled work will emerge around these systems-but only if we build them intentionally. The MIT study offers a roadmap: new work clusters around geographic centres (your developers need to live somewhere), requires fresh skills (hire for potential, not experience), and depends on demand (policy and investment choices matter). If you're building on these platforms, you're positioning your team for that transition.