DEV Community: Kay Ashaolu

The most boring service in the stack

Kay Ashaolu — Sun, 16 Aug 2026 01:03:38 +0000

The most reliable part of a stack is rarely the part anyone shows off. It has no clever layer to point at. That is the whole reason it never breaks.

A payment service I want to walk through this week is a clean example of that. One queue sat in front of it, catching every incoming charge. One database sat behind it, recording each charge exactly once. That was the entire system, and it had looked that way for four years.

Engineers rotated onto the team and asked the same question every time. Why is this so primitive? No event mesh. No service constellation. No clever caching layer sitting in front to make it feel faster.

Twice a year, someone pitched a redesign. Twice a year, the answer was no.

Then Black Friday arrived. The recommendation engine buckled under the traffic and stopped returning results. Search slowed to a crawl and started serving stale listings. The mobile app threw errors across half its screens, and the support queue backed up.

The payment service kept working. Every single order that reached it got processed, exactly once, without a single duplicate charge.

Boring was never the absence of ambition. It was the design.

The parts doing the real work here have names. Use them. A Service is the piece that answers you while you are standing there waiting on it, the way a waiter takes your order and comes back with a plate. A Queue is a line for work that does not need to happen the instant it shows up, so a sudden rush of it lands somewhere safe instead of getting dropped. A Relational Database is the record book: the one place that can say, with certainty, this specific charge happened, once, and only once. One Service, one Queue, one Relational Database. Three pieces, not ten.

You can see the same restraint inside Stripe's own payment API. Every charge you send Stripe can carry an idempotency key, a value that means "this is the same request if you see it twice." Your network drops the response, you retry the request, and Stripe uses that key to recognize the retry and hand back the original charge instead of billing your customer again. Stripe did not hand you a new service to run to catch duplicates. It handed you a key, and made one place the last word on whether a charge already happened. Same restraint. Same refusal to add a fourth. You do not need Stripe's traffic to use the same idea. You need one place your data trusts to be the last word on whether something already happened, and the discipline to let it do that job alone.

The way a system like this actually gets worse is rarely neglect. It is ambition wearing a good disguise. An engineer joins the team, wants something to show for the quarter, and pitches the event mesh, or the extra caching layer, or a second message broker sitting in front of the first one. Every one of those pitches sounds like seniority. On a slide, an event mesh reads like foresight. Under real load, it is a new component that has to come up cleanly, hold a connection, and survive Black Friday: a new thing that can time out, drop a message, or disagree with the database about what actually happened, at the exact hour agreement matters most. Saying no twice a year was never stubbornness. It was refusing to add one more way to fail during the one week failure would have cost the most.

In Course 1 I teach these seven building blocks before anyone draws a single box, because the skill this payment service is showing off is not stacking parts well. It is knowing when three of them are enough, and having the discipline to stop there.

You do not protect a system by adding to it. You protect it by refusing what it does not need.

P.S. Knowing when three blocks are enough is a skill you can learn deliberately. The decision framework that teaches it is free here: 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 two opposite ways AI gets your system wrong

Kay Ashaolu — Sun, 09 Aug 2026 01:03:46 +0000

You asked an AI to help you build something, and it put the whole thing inside one service. I have written about this before: a Service is a waiter, it takes the order and comes back with an answer. Ask AI to write the code for your app and it puts everything behind that one order: validate the input, hit the database, send the email, all before the response goes back. It works in the demo. In production the email step is slow, so every user stares at a spinner while your server waits on someone else's mail service.

Ask the same AI to design that system before you write a line of code, and you get the opposite mistake. Same AI. Same app. Opposite failure. You and one other engineer are building an app that lets roommates split rent and bills. Ask AI to design it, and it hands you five services: auth, billing, notifications, an API gateway in front of all of them, and a message broker connecting them.

Five services sounds manageable until you count what is actually inside each one. Auth is not one thing. It is a Service, a Relational Database of user accounts, and a Key-Value Store holding sessions: three building blocks. Billing is a Service plus its own Relational Database of charges: two more. Notifications is a Service, a Queue, and a Worker to send the email: three more. The API gateway is a fourth Service sitting in front of the rest, and the message broker is its own Queue. Ten building blocks, minimum, spread across five separate deployments, for a team of two.

What the app actually needs looks nothing like that. Someone logs in and adds a bill: one Service. The bill has to know which users it belongs to and how it is split: one Relational Database. When someone marks a bill paid, you want to email the other roommates, and that does not need to happen while anyone is watching a spinner, so it goes on a Queue, and a Worker picks it up a few seconds later. One Service, one Relational Database, one Queue and Worker: the whole system. Four blocks, one deployment, against ten blocks spread across five.

Ask AI to write code and it defaults to the plainest possible shape: one function, one service, request in, response out. It never reaches for a queue, because a queue is a decision about what can wait, not the plain shape of code. Ask AI to design a system on its own and it defaults to the most-discussed shape it has read about, which is how large companies solve problems you do not have. Same root cause both times: it is matching the genre of your prompt, not your actual constraints.

This is why the blocks matter more than the word "service." A microservice is not a building block. It is a whole deployment that can contain two or three of them. Count in services and "five" sounds like five things to build. Count in blocks and it is ten pieces you have to build, wire together, and keep alive, spread across five deployments you run separately. Against four pieces in one.

Microservices earn their cost when separate teams need to ship without waiting on each other, when one part needs different hardware, or when one failure cannot be allowed to take down everything else. Two people building one app have none of that pressure. What you need is one place to change things, one deploy, one thing to reason about at 11pm: a monolith. Not the beginner version of something you graduate out of. At your stage, it is the correct design.

Run every piece of the AI's answer, whether it built too little or too much, through one question: does the pressure that justifies this exist on my team, right now? Multiple teams stepping on each other's deploys. A component that needs different hardware. Traffic you can already measure, not traffic you are imagining for next year. If that pressure is not real, the piece comes out, whether it is a missing queue or an extra service.

That is why I teach the seven building blocks in Course 1 before anyone draws a single box. Know what each one is for, and you can look at any answer, AI's or your own, and ask what it is actually built to survive.

You do not fix the answer the AI gave you. You check the pressure behind every piece of it.

P.S. If you want the repeatable version of that question, I wrote up the full decision framework: one question per building block, so you can point at any requirement and know exactly what it needs. https://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.

What an AI Engineer job actually tests

Kay Ashaolu — Sun, 02 Aug 2026 01:03:38 +0000

An AI Engineer job posting almost never asks you to train a model. It asks for Python. Backend services. APIs. Deployment.

Say you are two years into your career. You want the AI Engineer title, because that is where the hiring is right now. You open a listing. Under requirements you find things you already know: REST APIs, Postgres, a message queue. Then one line stops you: experience with LLM-based retrieval systems. You have never trained a model, so you assume the role is out of reach. You close the tab and go back to applying for titles that do not say AI.

Open ten AI Engineer job listings yourself. Count how many ask you to design a training pipeline. Count how many ask you to call a model through an API, store some vectors, and ship a working service. The ratio is not close. And unlike most claims you will read this week, that is one you can check in ten minutes on any job board.

That gap between the title and the requirements is not a trick played on the applicant. It is a plain description of what the job actually is. Model training is real machine learning work, PhD-deep, and it happens at a small number of companies with the budget and the data to do it. Everyone else shipping something called an AI feature is doing something else entirely.

Most AI Engineer work is product engineering with a model in the stack. A Service takes the request from the user. The model sits behind an API call, an External Service in exactly the slot Stripe or Twilio occupies on any other project you have built. A Vector Database holds what gets retrieved before the model is asked anything, so the answer is grounded in real documents instead of a guess. The same relational databases and queues every other feature already needs round out the design. Perplexity answering a question with sources, the AI notes assistant, the AI coding sidebar: strip away the branding and each one is this same handful of parts, wired together with care.

The model is one component. The composition is the job.

And composition is learnable. It is the same skill that ships any production system you have already worked on, a checkout flow, a notification pipeline, a search page, pointed at one new primitive instead of a familiar one.

Here is the wrong move I see most often, and it is the expensive one. An engineer decides the gap is technical: they need to learn embeddings math, or enroll in a machine learning certificate, before they can call themselves qualified for the title. That is solving the wrong problem. The company hiring for that AI Engineer role is not testing whether you can derive backpropagation. It is testing whether you can take a Service, an External Service, a Vector Database, and a queue, and compose them into something that survives real traffic on a Tuesday afternoon. Come back to the same listings six months later and the requirements have not moved: still a Service, still an External Service, still a Vector Database. Only now half a year has gone to the wrong half of the job. 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.

Composition, choosing the right primitive for the job and wiring it correctly, is the entire subject of the seven building blocks and three external entities I teach. A Service, an External Service, a Vector Database, and the storage and queues around them are not background theory here. They are the actual vocabulary behind the job title on that listing, named and taught, in the order you would actually build them.

You do not need to master gradient descent. You need to build the composition around the model: what takes the request, what talks to the model, what remembers enough to make the answer good, and what quietly keeps the whole thing running when the model call is slow.

P.S. The Vector Database is the one piece of that composition the AI era genuinely made essential. I wrote up how it actually works and why it is the retrieval half of almost every AI feature you have used: https://systemthinkinglab.ai/learn/building-blocks/vector-database/

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

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.