DEV Community: Kay Ashaolu

What a staff engineer benchmark measures

Kay Ashaolu — Wed, 11 Nov 2026 14:00:25 +0000

A new benchmark asks whether coding agents can act like staff engineers. I like the question, because most tests ask about one task and a staff engineer's job is never one task.

It is the whole set of responsibilities: deciding what to build, how the pieces fit, what to leave alone. A benchmark built on real situations can show how close models are to carrying that.

The same list tells you where you stand. Whatever the score says, the responsibilities that remain are yours, and they are worth practicing on purpose.

The score belongs to the model; the responsibilities that remain belong to you.

Kay

P.S. Try the design-with-blocks plugin, which walks you through designing a real application from its building blocks. https://systemthinkinglab.ai/design-with-blocks

This note goes out by email Sunday to Friday. Read more at systemthinkinglab.ai.

If you want to build with AI and still understand what you ship, take your free 5-day course: the plan-first workflow.

Code by hand, even if you never will

Kay Ashaolu — Tue, 10 Nov 2026 14:01:16 +0000

Writing code by hand builds something that survives the day you stop doing it. You learn what a function costs, where state hides, and why a small change breaks something far away.

That understanding turns out to be the most useful thing you can bring to an agent. You ask better questions, because you know what the answers should look like. You notice the plausible output that is quietly wrong.

New engineers who learn to code by hand will likely have an edge, even if their jobs never ask for it. Coding is changing form, and the understanding underneath it does not.

The hands may go idle, but the model you built with them keeps working.

Kay

P.S. Walk through the plan-first loop, a free guide to predicting before you build. https://systemthinkinglab.ai/learn/plan-first-loop/

This note goes out by email Sunday to Friday. Read more at systemthinkinglab.ai.

If you want to build with AI and still understand what you ship, take your free 5-day course: the plan-first workflow.

Ask the agent to keep a ledger

Kay Ashaolu — Mon, 09 Nov 2026 14:01:10 +0000

A rewrite is when a codebase could teach you the most, and it is usually when no one is listening. The old code had thin understanding to begin with, and the new code arrives with none.

So ask the agent for one more thing while it works: a ledger. Every change it makes, and why it made it, in plain text. Plain text scales. A whole team can read it, search it next year, and hand it to whoever joins after the original people have moved on.

The ledger is how the work turns into a lesson.

The best use of an agent leaves behind more understanding than it found.

Kay

P.S. Try the scaffold plugin, which keeps a ledger of what you understood alongside the code your AI writes. https://systemthinkinglab.ai/scaffold

This note goes out by email Sunday to Friday. Read more at systemthinkinglab.ai.

If you want to build with AI and still understand what you ship, take your free 5-day course: the plan-first workflow.

Understand the systems you work on

Kay Ashaolu — Sun, 08 Nov 2026 14:01:11 +0000

Hey,

Most systems are too big to hold in your head. Instagram is. So is the one at your job. But however large a system is, it breaks down into a small set of parts.

Course I teaches those parts: seven building blocks. Once you can see them in Instagram, you can see them in the system you work on every day, and truly understand it.

Here are two of the seven. A Queue is a line that holds work for later; a Worker is a program that takes the next job off the line and does it.

Try this today, free. Pick an app you use daily and find its parts: where it keeps things, where work waits, and what picks the work up.

By the end you can:

Take a design question apart into its parts before you name a single tool.
Move slow work, like sending the welcome email, out of the moment the user is waiting, so a slow mail server never holds up signup.
Choose a database or queue by what it does, then defend the trade-off out loud.
Open a design interview with a method instead of a guess.

It is 12 lessons, including two hands-on Python labs, a Link Shortener case study and an assessment, plus a three-part challenge. Self-paced.

Course I is where the four courses begin. It is $99 on its own, or all four courses are one $299 purchase with Course 0 included, each with a 30-day money-back guarantee.
To buy Course I: https://systemthinkinglab.ai/course-1.html
All four: https://systemthinkinglab.ai/courses-i-iv.html

Not ready yet? The free articles on the blocks are here: https://systemthinkinglab.ai/learn/

This note goes out by email Sunday to Friday. Read more at systemthinkinglab.ai.

If you want to see how products like Instagram and Netflix are designed, take your free 5-day course: the 7 building blocks.

What Cisco's unlimited-tokens rewrite is missing

Kay Ashaolu — Sat, 07 Nov 2026 14:01:11 +0000

Fortune reported last week that Cisco's president, Jeetu Patel, has given a 27-year-old engineer no cap on AI tokens and a goal of refactoring 98% of Cisco's legacy code within 24 months. The engineer says a two-person team can do it. The article is clear that this is a goal, not a result. The engineer has four weeks to show it can be done.

Patel says companies need young people who challenge the status quo. Elsewhere in the piece he describes his team as three groups: experienced operators, "outside-in systems thinkers," and AI-native founders and engineers.

The Hacker News thread under the story was mostly worried, and I think the worry was the right one. Legacy code is code that few people at the company still understand. Hand it to a machine to translate, and you can end up with new code that nobody understands either, just written in a newer language and a lot faster.

I did not want to stop at agreeing, so I left two comments on the thread. Here is the part that matters:

But what if while the code was being refactored the AI was asked in addition to keep a ledger of the changes it made and why.

And then:

That ledger could be the basis of providing understanding to a code base that most likely had minimal corporate understanding in the first place.

I said "most likely" on purpose, because I do not know what Cisco's code looks like inside. A ledger is text. It can be read by the next person, searched, and corrected, which means the understanding does not stay in one team's heads. It can travel.

The line in my comment that I care about most is this one: "I don’t believe it has to be this zero sum game where either you use AI and lose understanding or you don’t use AI and gain understanding." I think there is a way to do both, because "if used properly, AI could be the best teacher we’ve had."

Here is the practice version. You do not need a Cisco-sized project to try it. Take the module you have been meaning to refactor, maybe this Friday. Before the agent touches anything, write down what you expect to find: what the module does, what depends on it, what you think is ugly and why. Then ask the agent to keep a record as it works, what it found and what it changed and why it changed it.

Then read that record. This is the step people skip, and it is where the learning is. Every place where the agent found something you did not predict is a place where your picture of the system was wrong. Every change it explains badly is a change you should not accept yet. The agent does the typing. The judgment lives in the reading.

Kay

P.S. The ledger habit is the same one Course 0 teaches as the plan-first loop: say what you expect, let the agent work, then read what it recorded. Course 0 starts here: https://systemthinkinglab.ai/course-0

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

If you want to build with AI and still understand what you ship, take your free 5-day course: the plan-first workflow.

Can your logic run without the screen?

Kay Ashaolu — Fri, 06 Nov 2026 14:01:14 +0000

Decoupling is the goal, not purity of any pattern. One test tells you whether you got there: can your logic run with no UI loaded at all?

If the model file imports and works in a plain Python REPL, with no windows and no widgets, you are already there. If it does not, something that should be a detail has quietly become a dependency.

The test is also a relief. You can stop picturing a signal on every widget and ask a smaller question: do I need continuous sync, or just a clean read at the moment I act? A single form driving a calculation rarely needs the first.

The less your logic knows about the screen, the more freely the screen can change.

Kay

P.S. Read how services and workers keep your logic separate from everything that waits on a screen or a click. https://systemthinkinglab.ai/learn/building-blocks/services-workers/

This note goes out by email Sunday to Friday. Read more at systemthinkinglab.ai.

If you want to see how products like Instagram and Netflix are designed, take your free 5-day course: the 7 building blocks.

What the interview was really testing

Kay Ashaolu — Thu, 05 Nov 2026 14:01:17 +0000

The heart of a coding interview was never the code. It was to see how someone solves a problem without all of the inputs handed to them, and how they explain their thinking as they go.

AI changed what missing inputs means, because anyone can paste a puzzle into a chatbot. The skill underneath did not move. Given an open question and a codebase with no context, what does a person do first? How do they shrink the problem when nobody has said where it ends?

That ability is built by reducing messy problems yourself, many times, not by reading about it.

The inputs can be pasted in; deciding which ones matter cannot.

Kay

P.S. Play the building block game, a short design puzzle where you decide with missing information, and it is free. https://systemthinkinglab.ai/building-block-game/

This note goes out by email Sunday to Friday. Read more at systemthinkinglab.ai.

If you want to see how products like Instagram and Netflix are designed, take your free 5-day course: the 7 building blocks.

Guess first, then ask

Kay Ashaolu — Wed, 04 Nov 2026 14:01:15 +0000

When you learn, the thing worth protecting is your ability to build a mental model of why the code works. AI only hurts that when it skips you past the model-building. Once you understand something, letting it write the boilerplate is fine.

So the question is not how much you use it. It is when. If you try the problem yourself first, or at least predict what the answer will be, the AI becomes a check on your model and an explanation of the why. If you ask first, it becomes a replacement for the model.

It was never about using AI less. It is about asking after you have a guess.

Kay

P.S. Try the scaffold plugin, which makes you predict the answer before your AI acts, so your guess comes first. https://systemthinkinglab.ai/scaffold

This note goes out by email Sunday to Friday. Read more at systemthinkinglab.ai.

If you want to build with AI and still understand what you ship, take your free 5-day course: the plan-first workflow.

Bugs live where two parts meet

Kay Ashaolu — Tue, 03 Nov 2026 14:01:24 +0000

When an application is built from components that each have a clear contract for how they are used, something useful happens. You can understand one component without loading the rest. An AI can too: it reads only the relevant modules and still uses them correctly.

The contract also tells you where to look. When something breaks, it is far more likely to break at the edge between two components than inside either one.

Most failures happen where two parts meet, so that is where the design effort belongs.

Kay

P.S. Here are the seven building blocks and what each one promises the others, which is where contracts live. https://systemthinkinglab.ai/learn/building-blocks/7-building-blocks/

This note goes out by email Sunday to Friday. Read more at systemthinkinglab.ai.

If you want to build with AI and still understand what you ship, take your free 5-day course: the plan-first workflow.

Follow one click all the way down

Kay Ashaolu — Mon, 02 Nov 2026 14:01:30 +0000

Understanding a system starts with following one thing all the way through. A user taps a button. Somewhere in the code, something wakes up because of it. Knowing where, and why, is the whole map.

You do not need deep knowledge of every part to see this. You need curiosity, and the habit of switching between the user's seat and the developer's until the two line up.

An agent can draw that map for you in seconds. The drawing is not the point. The walking is, because walking is how the model forms in your head.

A map you were handed shows you where things are; a map you walked shows you what to ask.

Kay

P.S. See one tap on Instagram followed through every building block, so you can walk the path yourself. https://systemthinkinglab.ai/learn/building-blocks/how-instagram-works/

This note goes out by email Sunday to Friday. Read more at systemthinkinglab.ai.

If you want to see how products like Instagram and Netflix are designed, take your free 5-day course: the 7 building blocks.

Can you explain what you shipped?

Kay Ashaolu — Sun, 01 Nov 2026 14:01:06 +0000

Hey there,

Every change an agent writes for you either builds your understanding or spends it. Spending it means you ship something without learning why it works. From the inside, the two feel exactly the same.

The tests pass, the page loads, you move on. Nothing tells you which one just happened, and there is no error message for "shipped three features you cannot explain." You find out later, when something breaks and the code is yours in name only.

There is a study worth knowing about. Anthropic ran a randomized trial with 52 professional developers, most with four or more years of experience, half coding with an AI assistant, half without. The ones using AI scored 17 percentage points lower on a quiz about the code they had just written, roughly two letter grades. The ones who asked the assistant to explain, and asked why, scored higher than the ones who handed the work over.

(The paper is Shen & Tamkin, "How AI Impacts Skill Formation," 2026.)

The tool was the same. What differed was what each developer did with the answers. So the fix is not to use agents less. The fix is to ask why before you accept, so that what you ship is something you could defend if a teammate questioned it.

Here is the practice version. Pick something you built recently, at work or in a class, and explain out loud why it is built that way, not just what it does, as if to a teammate.

Wherever you stall is where the gap is.

If you want help closing it, Course 0 is where I would start. It is a self-paced online course you take on your own schedule: eight lessons, two hands-on labs, a ten-question written assessment with feedback, and three challenges on a chat app running on your own computer. It teaches one workflow end to end: before you accept a plan from your AI agent, ask for its reasons, make it show a test that backs them, then decide.

I built it, and I lecture at UC Berkeley. It is for people who build with agents every day and want to defend what they ship. You keep the speed and you keep your understanding. It is $99 once, with a 30-day money-back guarantee.

Two ways in, whichever suits you. The course:

https://systemthinkinglab.ai/course-0

Or, if you would rather start free, the five-day email course:

https://systemthinkinglab.ai/five-day/

This note goes out by email Sunday to Friday. Read more at systemthinkinglab.ai.

What an Anthropic hiring manager stopped asking candidates to do

Kay Ashaolu — Sat, 31 Oct 2026 13:01:35 +0000

Felix Rieseberg is an engineering manager at Anthropic. This month he wrote that he has stopped giving candidates the coding interview. His reason is short: AI can now handle the small coding challenges the interview was built from, so those challenges no longer tell him who will do well on his team.

His post, "Hunger beats tenure", is advice for junior engineers. The line from it I keep coming back to is this one: "I'm seeing engineers who are comparatively new fly past people who are probably better coders and have been around much longer." It is one manager's observation, and he offers it as hopeful news. I read it as that, not as a rule. Then comes the part I find most honest. He says he has not yet found the replacement for the interview. For now he looks through resumes and portfolios for small prototypes that show taste, empathy and principled thinking.

I commented on the Hacker News thread, because I think the interview was measuring something specific, and that something did not go away. Here is what I wrote, lightly tidied:

The heart of the coding interview is to get signal on a candidate's ability to solve a problem without all of the inputs given to them, and see how they explain their thought process as they do it.

Because of AI, what it means to "not have all of the inputs" has changed as anyone can cut and paste a Leetcode problem to a chatbot and solve it.

I think we are going to iterate a bit to figure out a better signal than the typical coding interview. For junior engineers, I think coding questions will move towards MBA style problems when someone is given more of an open ended question with a codebase and you see what the candidate does without context to reduce the problem.

The word that matters there is reduce. A LeetCode problem arrives already reduced: the inputs are named, the goal is stated, and only the code is left. A real ticket arrives as a sentence from a person, sitting on top of a codebase you did not write. Somebody has to decide what the problem actually is, what can be ignored, and what has to be true when it is done. Then they have to explain those choices to someone else. An agent cannot do that part for you, because it does not know which parts of your situation matter.

That is a judgment test, and you do not need an interviewer to practice it. Take any ticket you have this week, or any feature in a side project, and do two things before the agent writes a line.

First, write the plan. A few sentences: what is being asked, what you are leaving out, and how you will know it works. Hand the plan to the agent, and build from that.

Second, name the blocks before you name a technology. The seven building blocks are the small set of parts that almost every software system is made from: a service that answers requests, a worker that does jobs in the background, a queue that holds work waiting its turn, and four other places to keep data. Ask which of those your ticket touches and what moves between them. Only then ask whether the answer is Postgres or Redis or something else. Doing it in that order shows you whether you understood the problem, and it gives you words to explain the reduction to a teammate.

Here is the practice version. The free five-day course walks through the first habit, writing the plan before the agent builds, one email a day.

https://systemthinkinglab.ai/five-day/

Reducing the problem was what the interview was always trying to see. So is the next thing you build.

Kay

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