DEV Community: Kay Ashaolu

The junior engineer is not disappearing

Kay Ashaolu — Sun, 26 Jul 2026 01:03:48 +0000

You have probably seen the claim by now: AI is coming for the junior engineer first, so if you are early in your career, or trying to become one, the timing looks bad. If you are a senior who has repeated that line to someone below you, this is worth a second look too.

I wrote a longer essay taking the other side of that argument this week, and I want to give you the short version here.

Look closely at what those predictions actually describe. Not a junior engineer. A person whose entire job is turning a finished spec into working code. That role is real and it is shrinking fast. But it was never the same thing as "junior engineer." We welded the two together for forty years because, until recently, spec-to-code translation was the main thing a junior had the skill to do. AI is eating that task. It does not follow that it eats the title too, unless we insist on keeping them tied together.

So the real question is not whether the junior engineer survives. It is what we train a junior engineer to do now that translation work is cheap.

I think a lot of people land on "they are doomed" for a reason that has nothing to do with whether it is true. It is the easy conclusion. It asks nothing of us. Figuring out how to train a junior into a senior without the years of tickets we used to lean on is genuinely hard. "They are doomed" lets everyone off the hook. "How do we train juniors into seniors now" does not, but it is the question with a future in it.

Here is what is actually disappearing. For as long as I have been in this field, the plan was the same: hire someone who can code, hand them small well specified tickets, and let them grind through years of execution until judgment showed up. Bugs, edge cases, code review, the slow accumulation of pattern recognition. Somewhere around year four or five, if it worked, they started asking "should we build this" instead of just "how do I build this."

That path is closing, and not because anyone designed it to close. The years that used to build judgment were built entirely out of execution work, and execution work is exactly what agentic coding now absorbs. Take away the tickets and there is nothing left for the apprentice to practice on. The casualty is not the junior engineer. It is the apprenticeship.

Somebody still has to build senior judgment. It just cannot happen the old way anymore, which means it has to be built somewhere else, on purpose, before the first job starts. That is school. That is workshops and bootcamps. That is the courses people take on their own time. Each of those has mostly taught something other than judgment: theory in school, syntax and tooling in bootcamps and workshops. That is what has to change. I believe this enough to grade on it: the course I am teaching at UC Berkeley this fall has students build real applications with agentic coding, then grades them on defending the design decisions.

None of this waits on a school's calendar, either. If you are already working, or already past whatever program you paid for, you can start this week on any real project you have open right now: make the agent produce a plan before it writes a line of code, question every decision in that plan, then let what actually happens grade whether you questioned the right things. No enrollment required.

The full essay goes further into the mechanism I think replaces the old apprenticeship. People are calling the discipline of directing an agent well "loop engineering," and most of its value in a company comes from designing the human out of the loop. I think the training version runs the opposite direction: the junior stays in the loop on purpose, pushing back on the agent's plan until an area is genuinely understood, and only then earns the right to step out of it, one area at a time. That part, the graduation mechanism, is the piece worth the full read: https://systemthinkinglab.ai/newsletters/the-junior-engineer-is-not-disappearing/

For now, the short version is this.

You do not train a junior by handing them a shrinking task and hoping judgment shows up on its own. You train them by building the judgment on purpose, before the tickets that used to build it are gone.

P.S. If this is the first thing you have read from me, the free course is where the building blocks lens starts: https://systemthinkinglab.ai/learn

This letter goes out by email every Saturday. Subscribe here or read the full archive at systemthinkinglab.ai/newsletters.

When "saved" does not mean saved

Kay Ashaolu — Sun, 19 Jul 2026 01:03:46 +0000

This week I put AI agents on a real job: rewriting the bios on all eight of my social profiles. They did the work. I reviewed and approved each one from my phone.

I have profiles across LinkedIn, TikTok, Threads, and five others, and over the years they had drifted. Each one described what I teach a little differently. I wanted all eight saying the same thing, so the agents spent an evening rewriting every bio, and I approved each one as it came back.

Simple job. Then one of the agents tried to save a new bio to TikTok, and the app said the save worked when it had not. The character counter read 78 of 80, the app returned a success, and the old bio was still sitting there untouched, exactly as before.

That is the beat I want to write about, because it is not really about TikTok.

When the agents started, they did the obvious thing: they read each platform's own documentation for how long a bio could be and wrote to fit. That was a mistake. Threads documents a 500-character limit; the real field holds 150. We also walked in with our own note that Facebook's bio maxed out around 101 characters; the real field held 255. One number was the platform's error and one was ours. Both failed the same way: nobody had opened the actual field and counted.

Then there was the TikTok save that reported success and changed nothing. If no one had gone back to look, that bio would have stayed wrong for as long as no one looked, and nothing on the page would tell a visitor it had happened. The only thing standing between "the app said it worked" and "it actually worked" was someone opening the profile to check.

That is the whole lesson, and it is smaller and less dramatic than it sounds. Verify the result, not the report.

A few other things happened that night. Halfway through, I decided the bios should lead with a different idea than the one they had been leading with, so I asked the agents to rewrite all nine drafts, and they did, before anything shipped. Then, before a single change went live, a separate verification pass re-checked the whole batch against the live pages, hunting for exactly the kind of silent failure I just described. Ten of the twelve fields were verified against the live page before I looked at one screenshot. The last two waited for my thumbs: edits the platforms only allow from their mobile apps.

Here is the part I think people get backwards about working this way.

The agents did not replace my judgment. They asked more of it.

Every decision that mattered was mine. Which bio was actually the right one. Which of two disagreeing numbers to trust. Whether to scrap the drafts at midnight and start over. What "done" meant, and when I was allowed to stop checking. The agents did the work. I judged the result at every step, against the real profile, not against what the app claimed about it.

This is the same discipline the seven building blocks teach, only at the scale of a profile bio instead of a production system. A Service is not working because it returned a success code. It is working because you followed what actually happened after that response and it matched what you expected. A write that reports success while quietly saving nothing is not a rare bug. It is the ordinary failure mode of anything no one has personally checked.

You cannot judge a system you cannot see. And you cannot see it by trusting what it says about itself.

There are two ways to get this wrong, and I have watched engineers do both.

One is to hand the whole thing to the AI and walk away: trust every "saved," every success code, every green check. That is how a bio stays broken for a month.

The other is to refuse to hand off any of it: touch every field yourself, on every platform, because that feels like the only safe way. That does not scale to eight profiles in one night, and it will not scale to a real system with fifty moving parts either.

The skill is in the middle. Decide what has to be verified, and build something, a person or an agent, that verifies it before you have to ask.

In Course 1 I teach the seven blocks for exactly this: so you can trace what a system actually did, instead of taking its word for it.

You do not trust the response. You verify the result.

P.S. If this is the first thing you have read from me, the free course walks through the same instinct, one building block at a time: https://systemthinkinglab.ai/learn

This letter goes out by email every Saturday. Subscribe here or read the full archive at systemthinkinglab.ai/newsletters.

The Junior Engineer Is Not Disappearing. The Way We Train One Is.

Kay Ashaolu — Sun, 12 Jul 2026 03:00:46 +0000

You have seen the posts. AI is coming for the junior engineer first. Why hire someone to write code a model can write for free? The career ladder's bottom rung is gone, so start saving your pity for anyone about to graduate into this market.

I think the premise is wrong, and it is wrong in a specific, fixable way.

Look closely at what these predictions actually describe. Not a junior engineer. A person whose entire job is turning a finished spec into working code. That role is real, and it is shrinking fast, but it was never the same thing as "junior engineer." We just let the two collapse into one job title for forty years because, until recently, spec-to-code translation was the canonical, critical thing a junior had the skill to do. The task and the title are not the same thing. AI is eating the task. It does not follow that it eats the title too, unless we insist on keeping them welded together.

So the real question is not "does the junior engineer survive." It is "what do we train a junior engineer to do now that the translation work is cheap." And the honest answer is: not much of what we have been doing.

I think we landed on "junior engineers are doomed" for a reason that has nothing to do with whether it is true. It is the easy conclusion. It requires nothing from us. Training a junior into a senior was never straightforward, even in the old world, and figuring out how to do it without the years of tickets we used to lean on is genuinely hard. "They're doomed" lets everyone off the hook. "How do we train juniors into seniors now" does not, but it is the question with a future in it. The first one just has a shrug.

The apprenticeship we built no longer exists

For as long as I have been in this field, the plan was the same. Hire someone who can code. Hand them small, well-specified tickets. Let them grind through years of execution: bugs, edge cases, code review, the slow accumulation of pattern recognition that eventually turns into judgment. Somewhere around year four or five, if it worked, they started asking "should we build this" instead of just "how do I build this." That is the senior question, and it used to take that long to earn the right to ask it, because the only way to earn it was to survive enough tickets.

That path is closing, and not because anyone designed it to close. It is closing because the exact years that used to build judgment were built entirely out of execution work, and execution work is precisely what agentic coding now absorbs. The training ground got automated out from under the training program. An agent now does that same ticket in seconds. Take away the tickets and there is nothing left for the apprentice to practice on.

Here is the part most people miss when they say "junior engineers are doomed." They are looking at the disappearing task and concluding the disappearing person. What is actually disappearing is the on-the-job execution years as the place where judgment gets built. Somebody still has to build senior judgment. It just cannot happen the old way anymore.

Where the training has to move

If the job can no longer teach judgment through years of unsupervised execution, judgment has to be built somewhere else, on purpose, before the first job starts. That means school. That means workshops and bootcamps. That means online courses you can work through on your own schedule. Each of those has mostly been a place to learn something else, not judgment. School has mostly taught the theory underneath the code: algorithms, data structures, the fundamentals of how computers work. Workshops and bootcamps have mostly taught the syntax and tooling that theory doesn't cover. Online courses have split the difference, walking people through that same syntax and tooling at their own pace. That is what has to change, in all three, plus wherever else people go to learn: the judgment-building reps that used to happen on the job now have to happen deliberately, before someone ever opens a ticket queue at a company.

And if you are already out of school, already past the bootcamp you paid for, or never went, you are not waiting on any of them. This loop needs nobody's permission and no enrollment. Run it on any real project you have open tonight: make the agent produce the plan before it writes a line of code, interrogate every decision in it, then let what actually happens grade you. The reps are free, and you can start this week.

This is not a small adjustment to the curriculum. It is a different curriculum, and it needs a repeatable process, not a hope that motivated students figure it out alone. I want to be precise about that word. Judgment is not something you manufacture on a deterministic assembly line, the way a compiler guarantees the same binary from the same source every time. But the process that gives someone real chances to build it, over and over, regardless of which company they land at or which senior happens to mentor them: that can be repeatable. The output is not guaranteed. The opportunity to build it is.

The mechanism: put the junior in the loop

Here is where it gets concrete, because this is the part that actually matters and the part most of these conversations skip.

There is a name, this year, for the discipline of directing an agent well. People are calling it loop engineering. Addy Osmani wrote it up, and the line that stuck came from Peter Steinberger: stop prompting your agents, start designing the loops that prompt them. The idea is that you stop steering an agent turn by turn and instead design the conditions and the iteration around it: what it should attempt, how it checks its own work, when it stops, when it retries, what it remembers between attempts. Set that up well, and the agent loops itself to a finished product with a human barely in the room. That is what the industry means by the term, and the definition is right. Most of the value of loop engineering, in a company shipping software, comes from designing the human OUT of the loop: fewer turns where a person has to look, more of the cycle running on its own.

Here is the move that is ours, and it runs the other direction on purpose. In the training pathway, the junior is not designing the human out of the loop. The junior IS the human in the loop, and that is the entire point. The agent proposes a plan, or code, or both. The junior has to evaluate it: is this actually right, does it fit the system, what did the agent miss, what would break in production. Then the junior goes back to the agent: pushes back, asks it to justify a choice, asks what happens if a dependency fails. That back-and-forth, the friction of interrogating a plan and making the agent defend it, is where judgment gets built. Not watching the agent work. The exchange itself, turn after turn, is the rep, at the exact moment the industry is designing loops that need people less.

And the loop has a graduation built into it. Once a junior genuinely understands an area, once they can predict what the agent will get wrong before it gets there, they earn the right to step out of the loop for that case. That test needs no professor and no title to administer. When you have called the agent's mistake before it made it, three times running in the same area, you have your answer. Their judgment does not vanish when they leave. It gets encoded into the gates the loop already runs on, the checks that catch the mistake they used to have to catch in person, and the loop then runs on its own there, the same way the industry's version does, except this time a person's judgment put those gates there instead of a vendor's default settings. Step out here, stay in the loop over there, one area at a time, as understanding actually earns it.

Compare that to the old apprenticeship: a junior wrote code, a senior reviewed it, weeks later maybe some of the feedback stuck. The loop was slow and the reps were scarce. This loop is faster, it runs on real work from day one, and it can happen before a paycheck is involved, which is the whole point.

The objection: how can a junior judge what it can't out-know

Here is where someone always pushes back, and it is fair. How can a junior judge a proposal from something that already knows more syntax, more APIs, more edge cases than they will ever personally memorize? If the agent is the more knowledgeable party in the room, what is left for the junior to evaluate?

Part of the answer is where the loop starts. It starts with a plan, not code. A plan is a set of decisions stated in plain language: which piece owns this data, what happens when the request fails, why this component and not another. A junior cannot always spot a bug buried in three hundred lines of implementation, but a junior can absolutely ask "why does this need its own database" or "what happens if this call times out," because those questions live in English, not syntax. Code buries the decisions inside the mechanics of expressing them. A plan puts the decisions on the table where they can be questioned, which is the whole reason this loop starts there: it is the layer a junior can actually enter and stay in.

The second part of the answer is that the junior is allowed to ask the agent to explain more plainly, as many times as it takes. The junior can say: meet me where I am, say it again, simpler. Unlike a senior three sprints behind on their own roadmap, the agent will not sigh at the fourth follow-up question. It has the time. That is the difference between a question that dies in someone's head because asking felt costly, and a question that gets answered until it lands. Every follow-up is another turn in the loop, which means another rep at building judgment.

But there is a real objection buried in the fact that the agent answers so willingly. Models are agreeable. Push back on one and it may fold: apologize, rewrite the plan to match your objection whether you were right or wrong. If the agent's agreement were the scoreboard, this loop would build confidence, not judgment. The agent's agreement was never the scoreboard. The plan gets executed. The tests run. The system holds or it breaks. The junior's prediction of what would happen gets scored against what actually happened. In the old apprenticeship, the senior's review was the ground truth. That review was always standing in for the real grader underneath it: production, and the pager. The loop keeps that grader. Reality is the one reviewer that never got automated away.

Now state plainly what all of this asks of the junior: someone still learning how to ask questions must use them to discover what they do not know, in a field they are only beginning to understand. Is that even fair? How is anyone supposed to do that? But this is not a rare skill. Entire careers are built on it. Good CEOs and good VPs lead engineers, doctors, scientists, whoever the domain expert is, and in nearly every case that expert knows more about their own field than the leader ever will in their lifetime. What makes that possible is curiosity, plus the absence of two fears: the fear of being wrong, and the fear of being told they cannot speak. They ask questions, not to perform curiosity but to build a working model of what is true, good enough to decide across a purview that spans far more than any one expert's specialty. The leader does not out-know the expert. The leader out-questions the gap, staying in that loop for as long as the stakes require it, and steps back once the pattern is trusted. Both of those fears are social, and the model eliminates them: a junior questioning an agent pays no status cost for a naive question, and there is nobody in the room to decide they are not senior enough to push back.

That way of leading is, crazily but true, exactly the capability now being asked of a junior engineer. And it stops sounding crazy once you notice what a capable model actually is: a solid expert at nearly everything, available on demand, willing to stay in the loop with you for as many turns as it takes without running out of patience. That combination has not existed before. Taking advantage of it is not a workaround for judgment. It is how judgment gets built now.

What I am actually doing about it

This fall I am teaching a course at UC Berkeley built around exactly this loop. Students learn full stack engineering while using agentic coding to build real applications, and the requirement will not be "ship something that runs." It is that they understand every piece of what they shipped: explain the code, defend the design decisions in it, say why the agent's first attempt was wrong when it was wrong. The agent produces the draft. The judgment is graded, and so is knowing when they have earned the right to stop checking a given kind of decision by hand.

That distinction, between code that runs and code you understand, is the whole course in one sentence. Anyone can now get code that runs. Fewer people can tell you why it should exist the way it exists, what it assumed, and what it will do the day traffic triples or a dependency breaks. That is what used to take years on the job to build. I am not trying to shortcut it. I am trying to build it on purpose, with the loop that actually builds it: the junior in the loop until an area is understood, then out of it, one area at a time, instead of leaving it to whatever a given company's ticket queue happens to expose someone to.

The claim, stated plainly

The junior engineer is not disappearing. The junior whose entire value was translating a spec into code is disappearing, and that was never a job description, it was a placeholder for a person who had not yet learned to do anything else. What has to change is not whether we keep training junior engineers. It is how, when, and where we train them. Push the judgment-building work earlier, into school and workshops and bootcamps and the courses people take on their own time, structured around the loop that will define the rest of their career: get in the loop with a real agent on real work, push back until you actually understand, and only then earn your way out.

That is the path I think we need, and it is the one I am actively building at Berkeley right now. If you want to follow where it goes, that is what the newsletter is for.

Originally published at systemthinkinglab.ai. I write a weekly letter on engineering judgment in the AI era: subscribe here.

Own the roadmap, not the backlog

Kay Ashaolu — Sun, 12 Jul 2026 01:03:46 +0000

Nobody tells you the day the work stops arriving pre-decided.

For two years the work arrives pre-decided. "Add a price filter to search." You open the service, find the query, add a line, ship it by lunch. Someone already drew the box. You are extending their decision.

Then one day the ticket is not a ticket anymore. It is two words: "own search." And nobody hands you a query to extend, or a roadmap item that already explains what to do.

Here is what that actually feels like. A shopper lands on your store. On a slow Saturday she is scanning forty items, and your search feels instant. You built it on a single table with a WHERE clause, and at ten thousand products that is exactly the right amount of machine for the job.

Then the catalog grows to two million products. The same shopper now filters by price, brand, size, and color at once. And here is the quiet part: nothing breaks. The WHERE clause still returns an answer. It just takes four seconds to do it, then six, then nine. It fails by getting slow, long before anyone files a bug, because a slow answer still looks like a working system.

Add more filters and it gets worse in a way that is invisible from the code. Ten filters each scanning the same table start locking each other out. The instinct is to reach for a bigger server. But the fix is not more machine. It is a different piece entirely: a dedicated search index, a block built to search, instead of a database table doing a job it was never shaped for.

That is the whole difference between implementing and owning. Implementing a ticket means writing code inside a box someone else drew. Owning a service means deciding which boxes exist. Which one holds the data. Which one does the searching. And then living with what breaks when the assumptions behind those choices stop being true.

Every owned service comes down to three questions. Who is this for: the Saturday browser, or the person filtering two million products? What is it actually built on: which pieces, and can each one carry its job at the size you are heading toward, not the size you have today? What happens when it grows: which piece cracks first, and is the answer a bigger version of the same thing or a different thing entirely?

Those are not senior questions. They are ownership questions. The moment they are yours to answer, you are no longer implementing. You are deciding.

Here is the move I watch juniors miss. They wait. They see the table quietly turning into the wrong tool, and they wait for it to show up on the roadmap. But ownership means you put it on the roadmap yourself, because you are the one who can see the product will not survive its own growth otherwise. Nobody is coming to add that line item for you. The empty space where the redesign should go is not a gap in your instructions. It is the job.

AI sharpens this. It does not soften it. AI will write the WHERE clause. It will write the search index config too, faster than you can type either one. What it will not do is notice that a table has quietly become the wrong tool. That decision is still yours, and it is the one that determines whether the system survives its own growth.

In Course 1 I teach the seven building blocks less as a catalog and more as a vocabulary. Once you can name the pieces, the three ownership questions stop being vague. "What is it built on" becomes "is this a table doing search, or a search index doing search," and that is a question you can actually answer.

You do not get promoted for closing more tickets. You get promoted for deciding what belongs on the roadmap, because you are the one who can see what the product needs to survive.

P.S. This letter has a sibling: why judgment, not output, is the job now that AI writes the code. If you missed it, it is here: systemthinkinglab.ai/newsletters/output-is-cheap-judgment-is-the-job/

This letter goes out by email every Saturday. Subscribe here or read the full archive at systemthinkinglab.ai/newsletters.

The 5 questions junior engineers keep asking about AI

Kay Ashaolu — Sun, 05 Jul 2026 01:03:44 +0000

Lately I keep circling back to the same handful of questions. What AI actually means for junior engineers. How to use it well without hollowing out your own skills in the process. What is still worth learning when a model can produce working code in seconds.

So this week: no story, just a straight FAQ. Five questions, five honest answers.

1. Is AI going to make junior engineers obsolete?

No. What it does is compress the timeline, and it does that fast. The floor work, wiring up boilerplate, writing the obvious version of a function, is exactly what AI is best at right now. What is left standing is the part that was always the hard part: deciding what to build, judging whether a design will hold once real traffic hits it, seeing the failure mode before it ships. That work does not disappear. It just moves onto you sooner than it used to.

2. How do I actually use AI well, day to day?

Decide first, generate second. Work out the architecture yourself: what needs to be a service, what needs a queue behind it, where the data actually lives. Only then hand the implementation to AI, and read every line it gives you back the way you would review a teammate's pull request. Treat it as a fast, confident collaborator who is sometimes wrong in ways that look right. You are not outsourcing the design. You are outsourcing the typing.

3. If AI writes the code, how do I still build real skills?

By taking the reps AI cannot take for you. Watching a model produce a clean solution teaches you nothing, the same way watching someone else debug a production incident teaches you nothing. So design the system before you prompt for it. Write down where you expect it to break. Then compare your prediction to what the code actually does under load. Judgment gets built by deciding and sometimes being wrong, not by reading a tidy output.

4. My team expects more output now that everyone has AI. How do I keep up without burning out?

Stop competing on output. Output is the one thing that just got cheap. Let AI take the implementation grind, the boilerplate, the first draft, and reinvest the time you get back into the work that actually compounds: the design conversations, the tradeoffs, the code review. The engineers burning out right now are racing AI at the one task it is already better at. The ones who thrive are moving up to the scarce thing, which is judgment.

5. What should I actually learn to stay valuable?

Systems thinking. Underneath every application you use, there is a small, repeating set of building-block patterns: services that answer requests, queues that let you say yes now and do the hard work later, databases and stores that hold the data, workers that grind through it in the background. It's the same handful of patterns you can see if you look at how Instagram, Stripe, or Netflix were designed. AI changes the syntax it takes to write them every few months. It does not change the patterns. Learn those, and you can design a real system in any language, with whatever tool happens to be sitting in front of you.

The thread running under all five: AI brings the implementation. You bring the judgment. Learn the patterns, and the rest really is just syntax.

P.S. If you know a junior engineer chewing on any of these, forward this their way. And if this landed in your inbox because someone forwarded it, you can get the Saturday letter yourself at systemthinkinglab.ai.

This letter goes out by email every Saturday. Subscribe here or read the full archive at systemthinkinglab.ai/newsletters.

The one rep you can't outsource

Kay Ashaolu — Tue, 30 Jun 2026 01:15:19 +0000

Last week I said judgment is the job now that output is cheap. Which leaves the obvious next question: fine, but how do you actually build judgment?

Here is the uncomfortable part. You build it the same way you always did. By doing the reps. The trouble is that AI just quietly removed most of them.

Think about how you used to learn that a database needs an index. You wrote the slow query. You shipped it. Then one night traffic climbed and you watched the dashboard go red, and you sat there at 1 AM reading an EXPLAIN plan you did not understand yet, and by 3 AM you understood it for the rest of your life. That night was not the bug. That night was the curriculum.

Now you ask AI to write the query and it hands you one with the index already there. Clean. Correct. And the lesson never arrives. You skipped the night that would have taught you what a slow query feels like under load, so the next time you will not see it coming either.

That is the trap of this era. AI is fastest at exactly the reps that used to teach you the most.

You cannot read your way out of this. I cannot write a letter good enough to give you the instinct for when a system needs a queue. Nobody can. Judgment is not information you absorb. It is the residue of decisions you made and then had to live with. You decided the design did not need a cache, and either it held or it fell over, and either way you learned something a paragraph could never tell you. The deciding is the rep. The living-with-it is the lesson.

So the practical move is not to refuse the tools. It is to choose which reps you keep.

Let AI write the boilerplate. Genuinely, let it. The CRUD endpoint, the config, the test scaffolding, the slow query with the index already in place. None of that builds your eye. Hand it over and move faster.

But the design decisions are yours. Should this be a Service or a Worker behind a Queue? Does this read-heavy path need a cache or are you adding a moving part you will regret? When the user hits Submit, who is waiting, and what happens if the thing they are waiting on is slow? Those are the reps that build the eye, and they are exactly the ones worth slowing down for.

And when you are handed a block of AI code, do not just accept it. Interrogate it. Ask the one question a senior asks on instinct: where does this fall over? At a thousand users? At a million? When the external service it calls times out? That question, asked on purpose, again and again, is the rep. You are training the exact muscle the AI cannot train for you, because the AI is not the one who will be paged when it breaks.

Here is why this compounds. Two juniors start today. Both use AI for everything. One also keeps the design decisions, owns them, sits with the ones that went wrong. The other ships fast and never looks back. For a year they look identical. Same velocity, same clean PRs. The difference is invisible right up until 2 AM when something breaks in a way the AI did not predict, and one of them can reason about why and the other can only paste the error back into the chatbot and hope.

One of those juniors is becoming a senior. The other is staying fast and blind.

You do not build judgment by watching the rep. You build it by being the one who decides.

So keep the design decisions. Hand off the rest.

P.S. The free hub is where the reps live: walk the seven building blocks, then assemble real systems yourself in the capstone game. That last part is the rep, on purpose. systemthinkinglab.ai/learn

This letter goes out by email every Saturday. Subscribe here or read the full archive at systemthinkinglab.ai/newsletters.

The role AI actually eliminates

Kay Ashaolu — Sun, 21 Jun 2026 16:00:00 +0000

Everyone keeps predicting that AI eliminates the junior engineer first.

I think that prediction aims at the wrong rung of the ladder.

Maya is the best mid-level engineer on her team. Give her a ticket and she ships it: clean code, good tests, on time, every time. For six years that reliability made her indispensable. Then the two juniors on her team got Claude Code, and within a month they were closing tickets at her pace.

The thing Maya was great at became the thing everyone is great at. Overnight.

To see why this lands on the middle rung specifically, ignore the years attached to each title and look at what each rung is for.

A junior engineer is paid to learn. That growth path is human, and AI does not remove it.

The pinnacle of mid-level development is successful execution. Hand over a clear spec, get back working, production-grade code. Reliable translation of a defined problem into a working solution: that is the rung's entire identity.

A senior is paid for judgment within ambiguity. Not judgment in general: judgment where the spec does not exist. What to build. What to cut. What breaks at 2 AM, and whether it is worth preventing.

Now line those up against what AI actually does. Give a coding agent a clear spec, a well-organized codebase, and context about your team's practices, and it produces the implementation. Execution is the part AI is best at. The middle of the ladder got automated. The rungs on either side did not.

And the consequence is bigger than one rung folding. If AI gets a junior close to mid-level execution quality, the distance between junior and senior is not as wide as it has been. The traverse that used to take years of grinding through tickets now runs more directly: from learning what to build, toward deciding whether to build it.

Here is the cruel twist. The tool feels slow when you are fast. A proficient engineer who can type the solution in twenty minutes experiences the AI loop as friction, so they wait. A junior has no speed to defend, so they adopt on day one. The engineers whose role depends most on execution are the slowest to pick up the tool that resets it.

But the trap and the door are the same tool. The mid-level engineer who fully embraces AI keeps solid execution, now with the tool doing the typing, and frees bandwidth for the hardest habit separating the middle of the ladder from the top: the pause. Stopping to ask why this is being built. Challenging whether it should be built at all. That used to be hard to practice. You cannot challenge your colleagues all day. You can challenge the AI all day long.

That is what Maya did. She stopped racing the tool, started writing the specs the juniors' AI built from, cut a feature that looked urgent and was not, and learned what breaks at 2 AM. Six months later her name was on fewer commits than anyone on the team, and nothing shipped without her. Then the title caught up.

In Course 1 I teach the seven building blocks because they are the vocabulary of exactly this: owning problems instead of tickets. The rung was never the job. The judgment was.

You do not climb by writing more code. You climb by owning the problem the code is for.

One more thing, because it is the practical version of this whole letter.

The argument above says you grow by challenging the AI, not by accepting its code. So I built a tool that makes the AI challenge back. It is called Scaffold, it is free and open source, and here is what it actually does:

Before it writes a line of code, it asks what you think should change, and why. Then it shows its own plan as a diff against yours: what you got right, what it would do differently, and the concept behind each gap. When you genuinely disagree, it will not move until you have argued it out. It keeps a running wiki of what you have actually proven you understand, kept separate from what it merely knows, and every commit ends with a short report on the code and on you. The record of your growth lives on your machine and nowhere else.

It has been tested into the ground by simulated engineers. Now I want ten real ones to break it.

If you have Claude Code and a codebase you actually work in, run Scaffold on real work for two weeks and tell me the one moment it annoyed you most. Make it to the end and Course 1 is on me.

Want in? Reply with "I'm in." That is the whole application.

P.S. The objections I could not fit here (where will seniors come from, what about code quality, and the one defense of the mid-level role that almost works) are in the extended version: https://systemthinkinglab.ai/newsletters/ai-will-eliminate-an-engineering-role-it-is-not-the-junior-one/

This letter goes out by email every Saturday. Subscribe here or read the full archive at systemthinkinglab.ai/newsletters.

Output is cheap. Judgment is the job.

Kay Ashaolu — Sun, 21 Jun 2026 01:03:39 +0000

AI writes the code. You make the call.

I rebuilt the entire site this month around that one sentence. Here is why, and what changed.

For two years the pitch was "understand the systems you build." True, but soft. It did not answer the question every engineer is actually asking in 2026: if AI can write the code, what exactly is left for me to be good at?

The answer is judgment. Output is cheap now. Anyone can generate a working function in thirty seconds. What nobody can generate for you is the call: does this system need a queue, or are you adding a moving part you will regret? Is this the design that survives traffic at 3 AM, or the one that looks clean in the demo and falls over in production?

Knowing what a queue is will not tell you whether this system needs one. That instinct is the whole game. And it is the one thing AI cannot hand you.

So the site now has two doors, and they say what they are.

Learn is free. The seven building blocks, every one of them, as articles and videos in one place, capped by a game where you assemble systems from the pieces. That is the knowledge. It is further than most engineers ever get, and it costs nothing.

Master is the courses. Not more to read. Reps. You study how real systems were solved, then design your own under real constraints, and you get told where your reasoning held and where it broke. That feedback is the part you cannot get from a video or a chatbot that agrees with everything you say.

Here is the line that holds the two together: free gets you the knowledge, the courses build the judgment.

And judgment does not come from consuming. It comes from doing. That is the part I want to be loud about, because everyone else in this space sells content you watch once and forget. Doing has more than one form. You study how a real system was solved and trace why each call was made. You run the framework on an app you use with Build with Blocks. You design under constraints and get graded on your thinking. You cannot read your way to judgment. You have to build.

There is one more new thing. Teams.

Good engineering judgment is not only an individual skill, it is a shared language. When a whole team can name the same seven blocks, design reviews stop being about taste and start being about tradeoffs. So there is now a free Team Workshop Kit: a facilitator guide to run a 60 to 90 minute session with your team on the free material, no purchase required. One person can bring the framework to everyone they work with.

None of this is a paywall trick. The framework is genuinely free, and it always will be. What you pay for is not access to information. It is the deliberate practice that turns information into instinct, the way it is taught at UC Berkeley.

In Course 1, the seven building blocks are the vocabulary. The labs and challenges are where that vocabulary becomes judgment you own.

You do not become the engineer who can build anything. You become the engineer who knows whether what got built is right.

P.S. The new front door is live. Walk through the framework, free, and play the capstone game at the end: systemthinkinglab.ai/learn/

This letter goes out by email every Saturday. Subscribe here or read the full archive at systemthinkinglab.ai/newsletters.

The block AI always forgets

Kay Ashaolu — Sat, 20 Jun 2026 16:00:00 +0000

Ask an AI to build a feature. It will forget one block. Every time.

Try it. Tell Claude to build video upload for your app. You will get a clean service: it receives the file, transcodes it, writes it to storage, and returns a response. It works. You demo it. Everyone nods.

Then you ship it, and the real world arrives.

A thousand users upload at once. Each request holds a connection open while the server grinds through transcoding. The server runs out of workers. New uploads time out. The feature that worked perfectly in the demo is now the reason your app is down.

The AI did not make a mistake. It answered exactly what you asked: upload a video. It just answered for one user, in a quiet moment, on a good day. That is the only world a demo lives in.

The block it forgot is the Queue. And the queue is strange, because it does almost nothing. It does not transcode. It does not store. It just holds messages. One part of your system drops a job in. Another part picks it up later. The two never talk to each other directly.

That word "later" is the whole point. A queue forces one uncomfortable question onto every task: can this be done later?

For a video upload, the honest answer is yes. The user needs to know the file arrived. They do not need to wait for it to be encoded into nine resolutions. So you split the work. The upload becomes a quick service that says "got it." The encoding goes into a queue, and workers chew through it at their own pace.

This is exactly how Instagram handles your post. When you tap Share, the upload is the quick service. Everything after it, the thumbnails, the feed fan-out, the notifications, the content moderation, rides a queue. That is why the post appears to publish instantly even though the work behind it keeps running for seconds after.

Now watch what the queue absorbs. A thousand uploads at once? They wait in line instead of crashing the server. An encoding service that dies at 2 AM? The jobs sit in the queue until it comes back, instead of vanishing. A viral post that triples your traffic? The line gets longer. Nothing falls over.

The queue did not speed anything up. It made the system survive being overwhelmed. Speed was never the point. Survival was.

Here is the trap, and it is the opposite of what you would expect. Once people learn about queues, they want to make everything async. The user clicks Purchase. The system queues it, flashes a success screen, and processes the payment in the background. Then the payment fails. Silently. The user walks away believing they bought something they did not.

That is the queue used in exactly the wrong place. The rule that prevents both mistakes is the same question, asked honestly: does the user need the result right now? If yes, it is a synchronous service, and a queue would lie to them. If no, it is background work, and a queue is what keeps it from taking down everything else.

AI will almost always reach for the service. The service is the happy-path answer, and the happy path is the only path a model sees unless you tell it otherwise.

In Course 1, the Queue is one of seven building blocks I teach, and it is the one that most often separates a demo from a system. Not because it is complicated. Because it is the block you do not miss until the night it would have saved you.

So before you ship the next thing AI built for you, ask its forgotten question yourself. Can this be done later? If it can, do it later. Your 2 AM self will thank you.

P.S. The queue is easiest to understand once you see it next to the worker that drains it. Full walkthrough, with the upload trace, is here: systemthinkinglab.ai/learn/building-blocks/queues/

This letter goes out by email every Saturday. Subscribe here or read the full archive at systemthinkinglab.ai/newsletters.

Should you build it?

Kay Ashaolu — Fri, 19 Jun 2026 16:00:00 +0000

Here is a story that is playing out on teams everywhere right now. A junior engineer ships a payment system in one afternoon. Stripe, Postgres, Redis, a job queue, a webhook handler. The whole thing, before the day is out.

In 2019 that was a quarter of work. Three engineers. A vendor bake-off. A wiki page arguing about whether you really needed Kafka.

The afternoon version worked in the demo. Two weeks later it was paging someone at 2 AM.

Here is what happened. The junior engineer opened Claude Code and described the app. Claude wired up Stripe for payments, Postgres for orders, Redis for sessions, BullMQ for background jobs, and an SQS queue to fan out webhooks. Every piece connected. The checkout button worked. The receipt arrived. The demo was clean.

Then real traffic arrived. The receipt email went out on the same synchronous path as the payment, so when the email provider had a slow afternoon, checkout requests hung waiting on it and timed out. Users saw a spinner, gave up, and hit Buy again. Some of them were charged twice. None of this showed up in the demo. All of it showed up in production.

The code was not the problem. The code was excellent. Claude does not write sloppy code. The problem was that nobody asked whether each tool was the right primitive for the job it was doing, or whether five tools were even needed.

Here is the shift, and it is the whole point. In 2019 the bottleneck was building. Could you wire up the payment processor at all? Could you get the queue running? The work was in the assembly.

In 2026 the assembly is free. Claude does it in one session. The bottleneck moved upstream, to a question that has no technical answer: should this exist at all, and if it should, what is it actually made of?

Tools are not the unit of design. There are seven primitives underneath every system you have ever used. Stripe is an External Service. Redis is a Key-Value Store. SQS is a Queue. The job runner is a Worker. When you name the tool, you have named a brand. When you name the primitive, you have named a decision: who waits, what fails, when it runs.

This is also why the AI-native patterns are less new than they look. An LLM shows up in your architecture as an External Service, the same slot Stripe occupies. RAG, the thing every team is rushing to build, is a Vector Database holding embeddings, a File Store holding the source documents, and a Service tying them to the model. Three primitives you already know, in a configuration that was uncommon two years ago. The names are new. The shapes are not.

Pick the wrong primitive for the access pattern and adding more tools does not save you. It buries the mistake under more wiring.

The most common wrong move in 2026 is the easy one. When building costs nothing, every instinct says reach for a new thing. Need a cache? Add Redis. Need search? Add a vector database. Need a queue? Add SQS. Each addition feels like progress because it compiles and it demos.

The senior engineer's move is the opposite. Before adding anything, the senior engineer asks one question: which of the seven am I already using, and does one of them already cover this? Most of the time one does. The junior engineer ends up with five tools. The senior engineer ends up with the same job done by two primitives they already had, and a system with half the moving parts to fail.

Restraint became the scarce skill. Not because building is hard. Because building is now so easy that the only thing standing between you and a sprawling, fragile system is the discipline to not add the next thing.

In Course 1 I teach exactly seven primitives, and the fixed count is not a limitation I apologize for. It is the entire point. When the menu is short, you are forced to choose carefully every single time. You cannot hide a bad decision behind a new tool, because there is no new tool to reach for. There are seven. You compose them.

AI did not make engineers obsolete. It made the assembly free and moved all the value to the judgment. You do not win by wiring up more. You win by knowing what you are already holding.

P.S. The hardest part is no longer wiring the tools together. It is choosing which primitive each job actually needs. I wrote up the decision framework I use for exactly that: systemthinkinglab.ai/learn/building-blocks/decision-framework/

This letter goes out by email every Saturday. Subscribe here or read the full archive at systemthinkinglab.ai/newsletters.

The lens behind every block

Kay Ashaolu — Thu, 18 Jun 2026 16:00:00 +0000

Quick site update before this week's letter: Courses 2, 3, and 4 now have their full written content live. Slide decks, labs, reading material, assessments, and challenges, all in place. The video lectures are still being recorded and will roll out as they finish. If you own any of those courses, log in and the new material is waiting for you.

You can know the seven blocks cold and still design the wrong system. The blocks tell you what to build. They do not tell you why.

The why comes from outside.

Picture a design review. An engineer at the whiteboard has sketched a Service, a Database, a Worker, and a Queue. Each block is correct in isolation. The diagram is clean. The arrows make sense. The review still goes badly.

The senior in the room asks a question the engineer cannot answer. "Who is waiting for this?" The engineer points at the Service. "What if it fails?" The engineer points at the Database. "When does this run?" Long pause.

The blocks were right. The forces behind them were never named. Without the forces, the design is a drawing. A drawing of correct shapes that does not survive contact with the real world.

There are three forces. Every architectural decision you will ever make comes from one of them.

The first is the User. Someone has tapped a button, made a request, opened a page. They are waiting. They do not care that your downstream service is slow or that your database is sharded. They care about three things: the response is fast, it is correct, and it shows up reliably. Every synchronous path in your system exists because of them. The User is why Services exist.

The second is the External Service. Something outside your control that your system depends on. Stripe. SendGrid. OpenAI. Twilio. You did not write their code. You do not own their uptime. Their pager is not your pager. Sooner or later they will fail, time out, throttle you, deprecate the endpoint you depend on, or change the response shape. Your design has to assume this happens. Workers absorb the unreliability. Queues buffer the traffic. Idempotency keys make retries safe. The External Service is why your system has shock absorbers.

The third is Time. The clock. Cron jobs. TTL expirations. Scheduled invoices. The midnight backup. Time does not initiate a request. It fires when it fires. It does not care that the engineering team is in a meeting. It is not waiting for a response. It is simply the heartbeat that triggers work. Time is why Workers run when no User is in sight.

When you look at a system through these three forces, the block selection stops being a debate.

User is waiting? You need a Service. The path must complete in milliseconds and return.

Work has to happen but the User has moved on? You need a Worker, and a Queue feeding it. The User does not stay on the page for the receipt email to send. The receipt email runs in the background.

External Service is unreliable? You need a Worker with retries and a Queue as a buffer. When SendGrid is down at 3 AM, the email is not lost. It sits in your Queue.

Clock fires at midnight? Time pulls a Worker. The Worker rolls invoices, expires sessions, regenerates feeds, takes the backup. No User involved.

The blocks are the answer. The forces are the question.

This is the lens most engineers never get. They learn the technologies. Postgres, Redis, SQS, Kafka. They learn the patterns. Services, queues, workers. They miss that the patterns are responses to something. The system is not a pile of components arranged for elegance. It is a set of decisions about what to do when the three forces show up.

The most common failure mode is to design only for the User. The happy path. The one force you can see. The screenshot in the spec. So the engineer builds a Service and a Database and ships it. Then a third-party API rate-limits them on launch day, and the Service crashes because there is no Worker to absorb the failure. Then the midnight backup fires and there is no Time + Worker arrangement, so it runs inside the same Service as the User requests and slows everything down. Then the engineer rebuilds half the system in production. They blame complexity. The real cause is that they only saw one force.

In Course 1 I teach the three external forces alongside the seven blocks, because the blocks do not mean anything without them. The first thing we do in every design challenge is name the forces. Then we pick blocks. Always in that order. The framework collapses if you skip it.

You do not start a system design with the database. You start with the force asking something of your system.

P.S. There is a full walkthrough of the external forces and how each one pulls different blocks at systemthinkinglab.ai/learn/building-blocks/external-entities/

This letter goes out by email every Saturday. Subscribe here or read the full archive at systemthinkinglab.ai/newsletters.

System Design at Kekoexchange

Kay Ashaolu — Fri, 13 Sep 2024 12:58:25 +0000

"What's the most important thing for early software engineers to learn in the next five years?"

My answer has recently changed due to the advancements in AI and what seems to be achievable in the near future. With the emergence of tools like GitHub Copilot and Claude, it is very likely that AI will make engineers an order of magnitude . Given this, how can a software engineer maximize their output knowing this trend is on the horizon?

At Kekoexchange, we emphasize the importance of understanding sound system design and having knowledge of the end-to-end system, including how components connect, interact, and operate to create a scalable system. That's why we're excited to announce a collaborative project. This month, the entire community will be working together to describe the design of a fully featured blog application from scratch.

The community has been asked to respond to the following prompt:

Design a scalable and robust blog application that allows users to create, publish, and manage blog posts. The application should support features like user authentication, content management, commenting, and content discovery (e.g., tags, categories, search). The system should be able to handle high traffic and large volumes of content.

Community members, your input is crucial to this project. Each week, you will share your thoughts, and by the week's end, we will consolidate everyone's input using AI into a single system design. This design will then be evaluated by our System Design Evaluator with your contributions playing a significant role in the final analysis.

Provide a score ranging from 200 to 800 points
Provide an overall summary of the application and its performance
Identify the design's strengths and areas for improvement for the user

Stay tuned every Monday in this newsletter to see what the community comes up with and how we do against the System Design Evaluator. Participating in the process will not only contribute to the project but also significantly enhance your system design skills.

If you want to join the conversation and contribute to our community project, check out our website and sign up to join our community! We look forward to seeing you there!