DEV Community: Kay Ashaolu

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!