DEV Community: Abhishek (landed)

The 10 AI system design questions that actually come up, and one way to answer all of them

Abhishek (landed) — Tue, 03 Nov 2026 05:06:59 +0000

If you have an AI engineer onsite coming up, the round to worry about is system design. It runs 45 to 60 minutes, it carries the most weight, and it's where people who breezed through the coding screen lose the offer.

The good news is that the prompts barely change. We went through reported AI system design questions from 2026 interview loops, and the same ten kept coming back. Design ChatGPT. Design a RAG system. Design a support bot. Design a banking chatbot that doesn't hallucinate. A few more.

They look like ten different problems. They get graded as one. The interviewer isn't checking whether you memorised a ChatGPT architecture. They're watching whether you can walk the same seven steps under a clock and put a number on each.

So this post gives you the seven steps first, then the ten prompts with the tradeoff each one is really testing. The full worked answers, with diagrams, latency budgets and cost math, are in a free repo we maintain: https://github.com/landedjobs/awesome-ai-engineer-interview

The seven steps every answer walks

Chip Huyen's book, HelloInterview's rubric and the open templates on GitHub all land on the same spine. What separates candidates is walking it without skipping and saying a number at every step.

1. Frame the problem. Ask about scale, freshness, tenancy, stakes and latency. Then say the numbers you're assuming out loud and get them confirmed. "Ten million requests a day is about 116 a second on average, call it 350 at peak. I'll assume a p99 of 500 ms. Does that match?" That sentence does more for you than any diagram.

2. Design the eval set before the system. LLM apps rarely have clean labels. Say where the quality signal will come from, and propose 50 to 200 hand-written cases (question, expected answer, expected source) that you grow from production traces.

3. Pick a baseline, then the simplest thing that beats it. BM25 for search. One prompt for generation. A router with canned answers for support. Without a baseline you can't say what your complexity buys.

4. Budget latency per stage. "It'll be under 500 ms" loses points. "Embed 15, search 20, rerank 60, first token 300, guardrails 40, the rest is buffer" wins them. For LLMs, split time to first token from time between tokens. The first is compute-bound prefill, the second is memory-bandwidth-bound decode, and they have different fixes.

5. Pair every metric with a counter-metric. Deflection rate with re-opened tickets. Relevance with false refusals. Offline scores are a gate. The A/B test is the verdict.

6. Put a dollar figure on it. Input tokens times input price, plus output tokens times output price, and output usually costs 3 to 5 times more per token. Multiply out to a month.

7. Say what breaks at 10x. The GPU queue, the index RAM, the cold start. Then how you degrade instead of falling over, like serving a cheaper model instead of timing out.

Watch the clock as closely as the content. In a 60 minute round, finish framing and the eval set by minute 18. Completing all seven steps beats a perfect step three. Most people who fail this round fail it in the first ten minutes, by drawing a vector database before anyone has agreed what "good" means.

The 10 prompts, and what each one is really testing

1. Design ChatGPT

This is a serving question wearing a product costume. The graded tradeoff is latency against cost at scale. Talk about continuous batching, PagedAttention (the vLLM paper cut wasted KV-cache memory from 60-80% to under 4%), streaming, where conversation state lives, and prefix caching on the system prompt. The usual miss is giving one latency number instead of two.

2. Design a RAG system

Scope it before you build it. How many documents, how fresh, and who is allowed to see what? Then ingestion, hybrid retrieval (dense plus BM25, fused with reciprocal rank fusion), a reranker, and a cited answer. Do the RAM math on the board. 50 million chunks at 1,536 dimensions and 4 bytes each is about 300 GB before index overhead, so it won't sit on one machine and you'll shard or compress. If you want a strong number, Anthropic's contextual retrieval write-up cut failed retrievals by 49% with contextual embeddings plus BM25, and 67% once a reranker was added.

3. Design LLM inference at scale

GPU economics with a latency mask. Start with memory. A 70B model at FP16 is 140 GB, which doesn't fit on one 80 GB H100. FP8 halves that and int4 quarters it, if a quality check says the output holds up. Then the KV cache, which is the real memory pressure under load. Autoscale on queue depth, not GPU memory, because vLLM preallocates memory and the graph will always look full. The trap answer is "buy bigger GPUs to make tokens stream faster". Decode speed is bound by memory bandwidth, so a bigger card mostly helps prefill and concurrency.

4. Design an agent

Start by arguing for the simplest pattern that works, usually a single loop. Then the math that drives everything else. If each step succeeds 95% of the time, a 10-step task succeeds about 60% of the time and a 20-step task about 36%. So the design is really about catching and recovering from failure. Fewer than 20 tools. Typed errors that say "retry", "try another way" or "ask a human". State saved outside the model. Traces you can replay. Grade it on pass^k (all k attempts succeed), not pass@k, which flatters you.

5. Design an AI tutoring platform

This one has been reported at Oracle. The twist is that a correct answer isn't the goal. The student learning is the goal, so your eval has to measure teaching quality as well as faithfulness. Add safety rules for minors and cost at classroom scale. The tradeoff to name is grounding answers in the curriculum against being a helpful conversation partner.

6. Design a Claude chat service

Same serving spine as ChatGPT, with the weight moved. Spend longer on safety checks for both inputs and outputs, on long context (when to retrieve instead of stuffing 200k tokens into every call), on tool use through MCP, and on keeping tenants isolated. Prepare this variant for frontier labs.

7. Design a customer-support chatbot with RAG

The business metric is deflection with customer satisfaction held steady. Deflecting with wrong answers is worse than escalating. The shape is a router that picks between answering, acting and escalating, RAG over the help centre, and a short list of typed tools like get_order and issue_refund, with a human approving anything that moves money. The baseline is an intent classifier with canned replies for the top 30 intents. Mention that cost grows with every turn, because each turn resends the transcript. The worked answer lands around 3 cents a conversation.

8. Design a real-time chatbot API

A service-level question. Streaming, budgets for first token and per token, rate limits with backoff, hedged requests for tail latency, autoscaling, and a fallback to a smaller model. The senior detail is that the fallback needs its own eval, because users get the degraded answer too.

9. Design a hallucination-free banking chatbot

Push back on the premise first, politely. No LLM is provably hallucination-free. What you can build is grounded-or-refuse. Route transactional and out-of-scope requests away from free-form generation. Never let the model produce a number. It calls a typed balance API and quotes the result. Check every claim against a cited source before the answer goes out. Build three eval slices: questions it must answer, questions it must refuse, and adversarial ones. And track the false-refusal rate, because a bot that refuses everything is broken in a different way.

10. Design candidate sourcing over 750M profiles in under 500 ms

Pure retrieval at scale, and the RAM math decides the design. 750 million profiles at 1,024 dimensions and 4 bytes each is about 3 TB raw. HNSW won't fit comfortably, so you compress with IVF-PQ (roughly 20x, to about 150 GB) and shard. Apply filters like location, seniority, recruiter permissions and data residency before the vector search, because filtering afterwards returns fewer than k results on narrow queries. Use two stages: vector search down to 500, a ranker down to 25. And in hiring, a fairness check on the ranked list is a legal requirement, not a nice-to-have.

What a pass sounds like

Three habits show up in almost every strong answer. The candidate names a baseline by minute 18. They describe quality in business terms, like deflection rate or the cost of one wrong answer, instead of model loss. And they bring up a counter-metric before anyone asks.

The fourth habit is the one people skip. Check in after each step: "Does this match what you're looking for, or should I go deeper here?" In close calls, clear communication beats raw depth.

To practise, pick three of these prompts, set a 45 minute timer, and answer out loud. Record it. Then compare it with the worked design and find the steps where you went quiet.

Get the full set

The repo has the rubric, ten worked designs with latency budgets and monthly cost estimates, 267 interview questions with answers, and breakdowns of the loops at 12 companies including OpenAI, Anthropic and Google DeepMind. It's MIT licensed and free. If it saves you a weekend, a star helps the next person find it.

https://github.com/landedjobs/awesome-ai-engineer-interview

If you had an AI system design round this year, what was the prompt? I'd like to add the ones that aren't on this list yet.

I'm building landed, which finds jobs that fit you and applies to them early.

I had to let my team go. Then getting every one of them hired became my full-time job.

Abhishek (landed) — Wed, 28 Oct 2026 04:48:37 +0000

At my last startup, Intract, we raised $3 million and grew to about 80 people. I ran product and engineering, so a lot of them reported to me.

They were good at their jobs. I learned from them and they learned from me. I looked forward to going to the office every day, not for the work, but to see them and talk. Somewhere along the way they stopped being my team and became my friends.

Then Intract stopped working. We had to make the decision every founder dreads, and we let most of the team go.

I've had a lot of hard days as a founder. That one was different. These were people who had trusted us with their careers, and we were sending them into a job market that wasn't kind.

Taking on the job search

There were three of us founders. Between us, I took on one job: make sure every single person got placed.

That became my full-time work. I sat with each person and rewrote their resume. We went through job boards together and picked roles. We worked out how to apply so that someone actually replied. I asked everyone I knew for referrals at other companies.

It took a while, and it wasn't always pretty. But in the end everyone got placed, many of them at great companies. It's one of the things I'm proudest of, and nothing to do with any product I've shipped.

What I didn't expect

I went in thinking job hunting was an operational problem. Find the right roles, fix the resume, apply well, follow up. A checklist. And it is that.

But the thing I wasn't ready for was how emotional it is.

Most of the time, nobody replies. You send out applications you spent hours on and get silence. Not a no. Nothing. And you wake up the next day and do it again, and it's silence again. I watched talented, confident people get a little quieter every week. They hadn't got worse. The silence wears you down whether you deserve it or not.

The operational part and the emotional part are tangled. Every application that disappears into nothing makes the next one harder to send. Every reply, even a rejection, gives you a bit of energy back.

What I decided

I knew I couldn't fix the emotional part for millions of people. That's a friend's job, a family's job, a good manager's job.

But I could fix more of the operational part than I'd thought. And if the operational part works, if the right roles show up, if applications go out early and get replies, a lot of the emotional weight lifts on its own. Replies were the best medicine I saw.

Then I saw something bigger

While I was doing this, I noticed the market itself changing under us. The jobs my team was applying for already looked different from the ones they'd been hired into a few years earlier. New titles were appearing. Old ones were quietly asking for skills nobody had trained them on.

I think the next few years bring the biggest change to work that most of us will see, and most people aren't prepared. It's not only that some jobs disappear. The jobs that grow look different, ask for different things, and are found in different places.

So when I started my next company, I wanted to build the thing I wished I'd had back then: a tool that helps people move into better roles, including the new ones AI is creating. It finds the jobs that fit you, applies early so you actually hear back, and helps you get ready for roles you've never done before. It's called landed.

If you're in it right now

If you're job hunting and it's been silence for weeks, here's what I learned from that time:

The silence is not a verdict on you. Most applications are never read by a person. That's a numbers problem, not a you problem.
Apply early. Roles get most of their attention in the first days. A good application on day one beats a perfect one on day ten.
Ask for referrals without shame. People like helping, and most of them remember being where you are.
Track the work, not the replies. You control how many good applications you send. You don't control who answers. Measure yourself on the first.
Don't do it alone. Have someone to talk to every few days. It doesn't need to be a coach. It needs to be someone.

It worked out for my team. It can work out for you too.

Artifacts are the new apps. Whoever manages them best wins.

Abhishek (landed) — Tue, 27 Oct 2026 05:11:34 +0000

Ask an AI to make you something and you get an artifact. A dashboard, a doc, a tracker, a small tool. It's impressive, and then it's gone. The next chat has no idea it exists.

Every morning I open a fresh Claude session and it's a genius with amnesia. It can build a dashboard, refactor a service or write a report in minutes. It has no idea what we built yesterday.

I think that small annoyance is the most important unsolved problem in software right now. Not the models. Not the apps. What happens to the things the models make.

One artifact is a toy

I'm building landed, a job search product, mostly on my own, with a lot of help from Claude. Along the way I ended up with a set of internal tools that nobody else uses:

a content calendar for every channel we post on;
sixteen weekly reviews, one for each part of the company;
a lab that tests and watches the AI agents inside our product;
a tool for making videos;
a sprint board and a weekly checkout.

Every one of them started as an artifact. A page Claude made in one chat. What turned them into software I rely on every day wasn't better UI. It was management: somewhere for the data to live, a way for the agent to update it, a view for me, and a note telling the next session how it works.

Social, our content calendar. Claude drafts, makes the visuals and schedules. I mostly look. Numbers blurred.

Here's the strange part. I almost never type into any of them.

I don't open the calendar to add a post. I say "plan next week around the jobs report", and the calendar fills in. I don't add tasks to the sprint board. I tell Claude what I'm working on and it updates the board through a small command-line tool. In the video tool, the main input isn't a form at all. It's a box that says "Message Claude".

Vids, where we make videos. The main input is a message to Claude.

Chat is the input. The app is just the view.

That's when I realised personal software isn't a new kind of app. It's a collection of artifacts, managed well.

Building is cheap now. That's the point.

For most of the history of software, building was the expensive part. So one company built a project tracker for millions of people, and everyone bent their work to fit its fields, its views and its workflow. SaaS was built for everyone, so everyone got the average.

That constraint is gone. Any good model will write you a working dashboard in minutes, with exactly your fields. When I want a new column, I don't file a feature request. I say "add a column for which repo this touches", and it's there.

If building were still the bottleneck, every person with Claude would already have perfect software. They don't. Most people who've tried this have a folder of beautiful one-offs they never opened twice.

The bottleneck moved. It's now everything that happens after the artifact is made.

Four ways artifacts die

They forget. The artifact lives in one chat. Tomorrow's session starts from zero and spends half its context rediscovering what you built. Count how much of each session goes to re-explaining: where the board is, what we decided about pricing, which dashboard tracks signups, what broke last week. Agents are cheap enough now that the work isn't the expensive part. The context is.

They're alone. The useful things happen between artifacts. My weekly review notices that signups dropped. It raises a task. The task becomes a pull request. Next week the review checks whether signups came back, against the number it predicted. Four artifacts, one chain. That chain only exists because they can see each other. Most artifacts can't.

DNA: each task an AI raises carries its own prediction and links to the PR that shipped it. Numbers blurred.

They can't be trusted. When an agent changes something at 2am, you need to know which session did it and why, and be able to undo it. Without that record, you stop letting agents touch anything that matters, and they go back to being toys.

They don't run. Real tools need schedules. A weekly review that only runs when you remember to open a chat isn't a tool, it's a chore. And when a scheduled run fails, something has to turn red, or you find out a month later.

Fix those four and artifacts compound. Every session builds on the last. Leave them broken and you get a pile of impressive demos.

What good management looks like

From running my own setup for a few months, every artifact that survives has the same five parts:

Data that outlives the session, in a database or plain files, never a chat log.
A way for the agent to write to it, like a small CLI or API, so it isn't editing raw files and guessing.
A view for you, on the web, a desktop app or your phone.
A skill file, so any future session knows what the artifact is and how to use it.
A schedule, so it can run on its own and show red when it fails.

DNA, our metrics dashboard. It started as an artifact. Now an AI reviews it every week. Numbers blurred.

And then two things that no single artifact can do for itself, because no single artifact owns all of your work:

Links between artifacts, so a review can raise a task, a task can point at a pull request, and a pull request can be checked next week.
A record of who did what, so every row knows which session wrote it and why, and anything an agent did can be undone.

A weekly report written by the agent, in plain language, on top of the dashboard. Numbers blurred.

None of this is glamorous. It's filing, labelling, permissions and cron jobs. That's exactly why it's where the value is: the model makes the thing, and the management decides whether the thing is still useful in a month.

The same idea, applied to agents

It isn't only my own tools. Our product has AI agents in it, and I needed the same thing for them: one place where every run, every cost, every failure and every eval lives, so the next change to a prompt can be checked against the last one.

Agent Lab: cost, conversations and failures for our product agents. Numbers blurred.

Same five parts. Data outside the chat, a CLI the agent can use, a view for me, a skill file, a schedule. Once that existed, prompt changes stopped being vibes. They became experiments with a before and after.

The race nobody is talking about

So when people ask whether OpenAI or Anthropic or someone else "wins", I think they're watching the wrong race. Models are converging. They get cheaper and easier to swap every few months.

The interesting race is who manages artifacts best.

There are really three ways it can go.

The model company manages them. Claude is clearly moving this way: skills, artifacts that can keep their own data, scheduled tasks, connectors to your other apps, plugins, projects with shared context. Put those together and it looks less like a chat window and more like an operating system for your work. What it doesn't do well yet is the management itself. Most artifacts still live in one conversation, and the next session can't find them, link them or build on them. If Claude fixes that, it becomes the default home for personal software, and most people will never look further. Convenience usually wins. Most people keep their photos in iCloud, not on a home server.

You manage them, and the agent is a guest. Your artifacts live in your own files and database, on your machine or your domain, organised so any agent can find and use them. Claude today, something else next year. The case for this is also strong. The most valuable thing in the whole system is the history: your tasks, decisions, metrics and the links between them. That's exactly the thing you'd least want locked inside one company's product, and it's the hardest thing to move.

Both, and the artifacts don't care. Artifacts become a format, the way websites did, and run on whichever base you pick. This is the version I'd most like to see, and the least likely to happen without someone pushing for it.

My bet

I think the agent and the base will separate, the way the browser and the operating system did. The agent should feel like a very good employee who works inside your company, not a landlord whose building your company lives in.

But I hold this loosely. If Claude makes artifact management good enough, most people will never think about who owns the base, the same way most people never think about where their email is stored.

So I'm building the version I'd want: a local, agent-agnostic base where artifacts live, link and run, with recipes on top. It's called plinth.

plinth.b100x.ai

Either way, the winner is whoever solves the boring part. Not the model. Not the app. The management.

If you've built tools like these for yourself, I'd love to see them. And I'd love to hear where you land: will your personal software live inside Claude, or will Claude live inside your personal software?

I'm also building landed, which finds jobs that fit you and applies to them early. Most of the tools in this post were built to run it.

I gave my company 16 AI analysts. The bottleneck is now me.

Abhishek (landed) — Tue, 27 Oct 2026 04:40:13 +0000

I run landed mostly on my own. A job search product has a lot of moving parts: the landing page, signup, onboarding, matching, applications, emails, retention, costs. A normal company has an analyst or a PM watching each of those. I have me.

So last week I switched on something I'd wanted for a while. Every part of the company now gets reviewed every week by an AI, and the AI doesn't just write a report. It proposes fixes, opens the pull requests, and next week checks whether the fix moved the number it said it would.

It's the closest thing I've seen to a company that improves itself. Here's how it works, and the thing that surprised me most.

The loop

We call it DNA. It has 16 weekly reviews, one per area: Landing and SEO, Signup and onboarding, First session, Matching, Applications, Retention, Revenue, Cost, and so on. Each one runs the same cycle:

Collect. A plain Python collector pulls that area's numbers from our database, PostHog, Search Console and the rest, and stores them as datasets a dashboard can render.
Review. An agent reads the dashboard and last week's report and writes this week's: what moved, why it thinks it moved, and what's broken.
Raise tasks. Every problem becomes a task with a kind (auto-fix, fix that needs my OK, improvement, or big idea) and, most importantly, a prediction: which metric should move, from what baseline, to what.
Fix. Approved fixes ship as pull requests. Safe ones can merge themselves if I allow it for that area. Everything else waits for me.
Measure. The next week's review scores each shipped task against its own prediction: worked, no effect, hurt, or too early.

On Monday I open one inbox called Needs you, and approve, drop or discuss what the agents raised.

A weekly report the agent wrote for signup and onboarding. Numbers hidden.

What it actually found

The tasks are better than I expected, mostly because they're specific. A few real ones from the first week:

The Matching dashboard's collector was taking half an hour and timing out. The agent proposed a shared daily summary table so every chart reads from one precomputed view. Shipped.
Our email click numbers were inflated by data-centre scanners that open every link to check it for malware. The agent proposed leaving them out before anyone made a decision on fake clicks.
The daily job digest was still being built for a lot of people who never opened it. Small cost, but it added up.
Some remote jobs were tagged "remote, worldwide" when the posting clearly said one country. That breaks matching for everyone outside it.

And then the big ideas, which I didn't expect at all. The First session review proposed sending a user's first ready jobs the moment onboarding ends, instead of the next morning, with a prediction for how much it should lift day-one activity. That one is a PR now.

Every task carries its own prediction and links to its PR. Numbers hidden.

The numbers after one week

In the first week, the agents raised 202 tasks across the 16 reviews. 74 shipped. They opened 51 pull requests and 49 have merged.

And exactly zero have a measured result yet.

That's not a bug in the system, it's the honest state of it. Most fixes shipped in the last few days, and a metric needs a week or two before you can tell a real change from noise. But it showed me something I hadn't understood before I built this.

Shipping got cheap. Knowing what worked didn't.

For most of my career the expensive part was building the fix. You'd argue about which three things to do this sprint because you could only do three.

That constraint is gone. The agents will happily raise 200 tasks a week and write the PRs for most of them. The new constraints are:

My attention. 66 tasks are sitting in "proposed", waiting for me to read them. The agents run every week without fail. I review on Mondays. If I had 16 human analysts, I'd be their bottleneck too, but they'd at least slow down to match me. The agents don't.

Measurement. If you ship 74 changes in a week, you can't tell which one moved your signup rate. Every task having its own prediction is what saves this. Without it, you just have a lot of activity and a feeling of progress.

Taste. The agents are good at finding what's broken. They're worse at knowing what matters. A dashboard can tell you a button gets few clicks. It can't tell you the button shouldn't exist.

What I'd tell anyone building this

Make every task predict something. A fix without a metric, a baseline and an expected value isn't a task, it's an opinion. The prediction is what turns an AI that writes reports into one that learns.
Measure next week, not this week. Scoring a change on the day it ships just measures noise. We score each task in the report the week after it ships.
Separate safe fixes from everything else. Each area has a fix mode: off, PRs only, or auto-merge for safe fixes. Almost everything is "PRs only" today. Trust is earned per area, not globally.
Keep the human step small and regular. One inbox, once a week. If approving things is a chore, you'll stop doing it and the whole loop stalls.
Expect the bottleneck to move to you. That's the point. The work left for humans is choosing, not doing.

Where this goes

The interesting part comes in a few weeks, when the measure step has real data. Then each review knows which kinds of its own suggestions actually worked, and can propose more like those. That's the recursive part: a company where the system that improves things is itself improving.

Right now it's 16 tireless analysts and one founder trying to keep up. Next month I'll know whether they were right.

I'm building landed, which finds jobs that fit you and applies to them early.

AI isn't taking jobs. It's taking the first job.

Abhishek (landed) — Fri, 23 Oct 2026 06:48:20 +0000

In June, the CEO of AWS called replacing junior staff with AI "one of the dumbest things I've ever heard." He said Amazon was hiring 11,000 interns and new grads this year.

He may be right. He is also unusual. SignalFire tracks hiring at the big tech companies and at early-stage startups. In its 2026 report, entry-level hiring was about 65% below 2019 at the tech majors and 76% below at startups.

I run a job search product, so I see this from the applicant side every day. And at my last startup I had to let most of my team go, and then made it my job to get every one of them hired. Here is what I think is actually happening, and what I'd do about it if I were 22.

Nobody is firing juniors. They just stopped hiring them.

The best evidence we have comes from Stanford's Digital Economy Lab, which tracks payroll data from ADP. In its August 2026 update, employment for 22 to 25 year olds in the most AI-exposed jobs is 19% below where it would be if it had kept pace with less-exposed peers. A year earlier the gap was 15%.

Three details in that paper matter more than the headline.

First, the gap comes from fewer hires, not more layoffs. Young people aren't being pushed out. They're not being let in.

Second, experienced workers in the same jobs show no comparable drop. Same occupation, same exposure, different age, different outcome.

Third, it depends on how AI is used. Where AI does the task instead of the person, young employment falls. Where AI helps the person do the task, it doesn't, and for older workers it's slightly positive.

So the pattern isn't "AI takes jobs." It's "AI takes the part of the job that used to be given to beginners."

The junior job was never really about the work

Think about what a first job actually was. First drafts. Support tickets. Boilerplate code. Research nobody else wanted to do. The output was rarely worth much. The company paid you anyway, because doing that work for two years is how you became someone worth paying properly.

The junior job was a paid apprenticeship wearing a job title.

That is exactly the work AI now does first. Klarna said in 2024 that its assistant was handling two-thirds of customer service chats. Salesforce's CEO said last year that support headcount had dropped by about 4,000. Shopify's CEO told teams to explain why AI can't do a job before asking to hire for it. None of these are "we fired the juniors." They're "we stopped needing to give the juniors that work."

And when the training tasks disappear, the job that's left gets quietly harder. PwC looked at over a billion job ads this year. Entry-level roles that are highly exposed to AI were seven times more likely to ask for traditionally senior skills, like leadership and strategic thinking. Indeed classifies software postings by what the job actually involves, and in early 2026, 69% of them were senior-level.

The first job now asks you to have already done the first job.

The math stops working in about ten years

Every senior engineer, analyst and account lead was once a junior who got paid to be slow. If companies stop hiring beginners, they don't save money. They borrow it from a future where there's nobody to promote.

That's the real point behind the AWS quote, and a few companies are acting on it. IBM said in March that it would triple US entry-level hiring this year, and that those roles were shifting from task work to analysis, problem solving and using AI well. I think the companies that keep training juniors through this will have the best people in 2035, and they'll get them cheap.

But most companies optimise for this quarter, not 2035. So I wouldn't plan your career around them coming to their senses.

Where is the new rung?

The comfortable version of this story says new AI jobs will replace the old ones. Forward-deployed engineers, GTM engineers, AI product managers, evals engineers.

Those roles are real. They show up in our job lists every day. But I went looking for the evidence that they replace the lost entry-level volume, and it isn't there yet. There's no reliable public data on how fast they're growing, or how many of the people in them came from the junior roles being squeezed. Pave's compensation data even puts forward-deployed engineers below generalist software engineers on pay. And the OECD estimates fewer than 1% of workers will need advanced AI skills like building models.

What is clearly measurable is a premium for AI skills inside ordinary jobs. PwC's 2026 data shows job ads asking for AI skills offer about 62% more pay on average. Lightcast found 28%, about $18,000. Different methods, same direction.

So the new rung isn't a new job title. It's the old job, done by someone who already knows how to make AI do half of it and check the other half.

And it got harder to even be seen

Greenhouse runs hiring for thousands of companies. Between 2022 and 2025, average applications per job went from 116 to 244. The number of recruiters per company fell by more than half. Each recruiter went from handling about 1,600 applications a year to about 4,900. Time to fill a role went up by more than two weeks.

In Greenhouse's latest survey, 86% of US recruiters said at least half the applications they get are written by AI. Robert Half found 65% of hiring managers say AI-polished applications make skills harder to verify.

Put those together. Fewer entry-level roles, each one asking for more, buried under twice the applications, read by half the recruiters, who don't trust what they're reading.

To be fair to the other side

I want to be honest about what this evidence doesn't show.

Yale's Budget Lab finds no broad AI footprint in the labor market yet. Unemployment overall isn't tracking AI use. The Stanford authors call their own results descriptive, not causal, and some of the divergence started before ChatGPT. And tech overhired massively in the pandemic. SignalFire's tech majors were hiring 63% above 2019 levels in 2022, so some of the fall since is just the hangover.

All of that is true. My read is that it doesn't change the advice. Whether the door narrowed because of AI, interest rates or a hiring hangover, AI makes it very unlikely to reopen the old way. The tasks that used to train beginners are not coming back to beginners.

There's a useful history lesson here too. When ATMs arrived, the number of tellers per bank branch fell from about 20 to 13. Teller jobs didn't vanish, because cheaper branches meant banks opened more of them, and tellers moved to sales and service. Technology can create more work than it removes. But that happened because the job changed, and the people who did well were the ones who changed with it.

What I'd do if I were 22

The apprenticeship moved. It used to happen inside the company, paid. Now it happens before the company, unpaid, and mostly with AI as your teacher. That sounds bleak. It's also the first time in history a 22 year old can get a decent tutor in any field, for free, at 2am.

So here's what I'd do.

Do the first job yourself. Pick a real problem in the field you want, and do the work a junior would have done. Use AI for it. Then do the part AI can't: check it, test it, and write down what was wrong.
Show your verification, not your output. Anyone can generate a working demo. Very few people can show how they knew it worked. A short "what I tried that failed" section is worth more than another feature.
Go where the feedback is. Customer-facing roles, deployment work, internships, apprenticeships. Anything where a real person tells you you're wrong, fast.
Read "entry level" carefully. Look at the actual responsibilities. Many junior roles are now senior roles with a junior salary. Some are genuinely built to train you. Find those.
Be checkable. Recruiters assume your application was written by AI. Make every claim something you could explain on a whiteboard in five minutes.

Underneath all five is one trait, and it isn't intelligence. It's the willingness to go learn the thing nobody assigned you, including the things you don't enjoy. I think that's becoming the most valuable skill there is, and I'll write about it next.

The first job used to be where you learned. Now you learn before you get it.

I'm building landed, which finds jobs that fit you and applies to them early. We also keep free, auto-updated job lists and interview prep for AI roles on GitHub.

Sources

Stanford Digital Economy Lab, Canaries in the Coal Mine?, August 2026 update: https://digitaleconomy.stanford.edu/app/uploads/2026/08/Canaries_August2026.pdf
SignalFire, State of Tech Talent 2026: https://www.signalfire.com/blog/signalfire-state-of-talent-report-2026
AWS CEO Matt Garman interview, Platformer, June 2026: https://www.platformer.news/matt-garman-aws-ceo-interview-ai-jobs/
PwC, 2026 Global AI Jobs Barometer: https://www.pwc.com/gx/en/services/ai/ai-jobs-barometer.html
Indeed Hiring Lab, "The Labor Market Is Tilting Toward Seniority", July 2026: https://hiringlab.indeed.com/2026/07/23/the-labor-market-is-tilting-toward-seniority
IBM, "The bottom rung returns", March 2026: https://www.ibm.com/think/news/entry-level-roles-get-reset-ai
Klarna AI assistant, February 2024: https://openai.com/index/klarna
Salesforce support headcount, Fortune, September 2025: https://fortune.com/2025/09/02/salesforce-ceo-billionaire-marc-benioff-ai-agents-jobs-layoffs-customer-service-sales
Shopify memo, CNBC, April 2025: https://www.cnbc.com/2025/04/07/shopify-ceo-prove-ai-cant-do-jobs-before-asking-for-more-headcount.html
Pave, Forward Deployed Engineering benchmarks, August 2026: https://www.pave.com/blog-posts/august-market-data-release-forward-deployed-engineering
OECD, AI and Skills, June 2026: https://www.oecd.org/en/publications/ai-and-skills_f843b352-en/full-report.html
Lightcast, AI skills salary premium, 2025: https://lightcast.io/resources/blog/beyond-the-buzz-press-release-2025-07-23
Greenhouse hiring benchmarks 2026: https://www.greenhouse.com/recruiting-benchmarks
Greenhouse AI hiring research, October 2026: https://www.greenhouse.com/de/newsroom/greenhouse-launches-the-orchestrated-hiring-ecosystem-to-break-ais-hiring-doom-loop
Robert Half survey, March 2026: https://press.roberthalf.com/2026-03-10-Robert-Half-survey-67-of-HR-leaders-report-AI-generated-applications-are-slowing-hiring
Yale Budget Lab, October 2026: https://budgetlab.yale.edu/research/tracking-impact-ai-labor-market
James Bessen, "Toil and Technology", IMF, 2015: https://www.imf.org/external/pubs/ft/fandd/2015/03/pdf/bessen.pdf