DEV Community: Robert Stowe

How I think engineers grow when AI writes the first draft

Robert Stowe — Wed, 04 Nov 2026 14:03:39 +0000

For most of my career an engineer learned the craft by doing the small things first. Fix the typo in the error message, then the off-by-one, then the feature behind a flag, and somewhere in the second year the design of a whole module. AI coding tools now write a decent first draft of most of those small things, and I think that quietly removes the ladder a lot of us climbed.

I do not think the answer is to keep people away from the tools. It is to be deliberate about where the learning now happens.

What the small tasks were teaching

The typo fix was never about the typo. It taught how the code is organized, how a change gets reviewed, what the tests look like, and how it feels to ship. When a tool does the typing, the person still needs those lessons, and they are no longer free. A manager who wants a junior engineer to learn the codebase has to arrange it on purpose, with a walk through the system, a review that explains instead of approves, and a first change small enough to understand completely.

The skill that is left

What the tools do not supply is judgment, such as knowing that the generated code is correct for the wrong reading of the ticket, that it duplicates something two folders away, or that it will be slow at real data volumes. I think judgment grows from reading more code than you write, and from being wrong in public and finding out why. So the growth path I would design now has more reading, more review, and more explaining to others, and less emphasis on lines produced.

The strongest objection

Some people say juniors should simply learn the way everyone will work from now on, directing the tools, and that the old ladder is nostalgia. There is something to it. But directing a tool well requires knowing what good looks like, and I have not seen a way to know that without having built things by hand at least a few times. I would keep some work tool-free early on, the way a pilot still learns to fly without the autopilot.

Where I am unsure

I do not know yet how long the by-hand period should be, or whether it is a period at all rather than a proportion. I also do not know whether the people who start now will end up with a different kind of judgment that is as good as the old kind. Hiring conversations I hear now weigh autonomy and judgment above domain knowledge, and I think that is the right instinct even if nobody can measure it yet.

What I am sure of is that the ladder does not rebuild itself. If a team wants seniors in five years, someone has to decide how juniors learn now.

Photo source: https://photos.robertstowe.com/bengaluru

Career day with Flappy Eagle at Drew Charter School

Robert Stowe — Fri, 30 Oct 2026 13:26:14 +0000

Earlier this month I spent a morning at Drew Charter School in Atlanta for career day, talking with third grade and sixth grade classes about what a software developer does. I have worked with kids and code before, and I knew a talk about my job in financial technology would not hold a room of young minds for long, so I brought a game.

Flappy Eagle

The game was a clone of Flappy Bird running on my laptop, renamed Flappy Eagle for the school's mascot and mirrored to the classroom screen. I walked the classes through how it is put together. One part draws the screen, one part moves the eagle and decides whether it hit something, and one part keeps score, and they stay separate so a change to one does not break the others. Then I showed them where the code lives and how git keeps every version of it, so a bad change is never lost work.

Changing the game while they played it

The part I was least sure about was AI, because most of what kids hear about it is either magic or doom, and I wanted them to see the real thing. So I asked each class for ideas to change the theme of the game, handed a controller to the first student, and let Claude Code make the changes while the controller went around the room.

The ideas were better than anything I would have planned. A McDonald's theme. An anime theme. A Spider-Man theme. A pink rainbow unicorn theme. Each one rebuilt the game on the fly, and the theme just changed under whoever was holding the controller at the time. Nobody had to stop playing.

The question everyone asked

Teachers and students asked the same thing in different words. Is this real, and what does it mean for them? I told them what I believe. AI in the development process is growing fast, I use these tools myself, and I do not know exactly what the job will look like when they are old enough to do it, ten or more years from now.

What I could show them is that every idea came from the room, and so did the judgment about whether the new version was any good. The tool did the typing. The people decided what to build and whether it was right.

So I told them where to put their effort. Writing code is cheap now, and it will get cheaper. What does not change is the rest of the work. The skills and structures for managing people and projects, and the principles of software architecture, are the same whether a person or a tool writes the code, and they can focus on learning those. That means breaking a big problem into parts, keeping the parts separate so one can change without breaking the others, deciding what to build first, and working with other people to get it done. A third grader can start on all of that now, and that is what I hope they took home.

The questions I would ask before splitting a front end

Robert Stowe — Wed, 28 Oct 2026 14:28:48 +0000

Splitting a large front end into separately built and deployed pieces, whether you call them micro frontends or something plainer, is a decision teams tend to make for the wrong reason. The reason is usually that the build is slow and the repository feels crowded. Those are real, but they are build problems, and splitting the application is an organizational change dressed as a technical one.

I think the decision goes better when a team asks a few questions first.

Do the pieces have different owners?

This is the one that matters most. A split pays off when each piece has a team that owns it end to end and rarely needs to change another piece to ship. If the same people will work across all of them, the split adds a seam without removing any coordination, and the seam has a cost every day.

What will be shared, and who owns that?

Every split front end still has a shell, a design system, routing, sign-in, and some way to pass state between pieces. Those become a platform, and a platform needs an owner. I think a lot of the pain stories come from a team that split the product and left the shared parts to whoever touched them last.

How will a user notice?

Two pieces loading two copies of a framework, or two versions of the component library, show up as a slower page and a flicker at the seam. A good answer is specific, such as one shared runtime, one version of the library, and a budget for what each piece may add to the page.

Could a build change get you most of this?

Build caching, a monorepo with task graphs, and clear module boundaries inside one application remove most of the slowness that starts these conversations. If the honest answer is that the build is the problem, I would fix the build first and keep the option to split for later. It is far easier to split a well-bounded single application than to merge three that drifted.

What is the way back?

Some splits do not work out, and the teams that recover are the ones that kept a path to recombine. Shared conventions, one component library, and no piece that depends on another's internals keep that path open.

Which question matters most

Ownership. In my experience a front end split along team lines, with a clear owner for the shared shell, usually goes well, and one split along technical lines with shared ownership usually does not. Where I am less sure is the very large product with dozens of teams, where some split is unavoidable and the real question becomes how few seams you can live with.

Photo source: https://photos.robertstowe.com/venice

What I think a one-on-one is for

Robert Stowe — Wed, 21 Oct 2026 13:20:01 +0000

The one-on-one is the meeting most likely to drift into a status update, and I think that is the one thing it should never be. Status has other places to live, such as the standup, the board, and the pull request. The one-on-one is the only half hour in the week that belongs to one person and their working life, and spending it on ticket numbers gives that away cheaply.

What I think it is for

Three things, in rough order of how often they come up. First, the thing that is bothering someone and has not been said anywhere else. A review that landed badly, a decision they did not understand, a worry about where the product is going. Second, growth. What they want to be good at in a year, and what in the next month moves toward that. Third, context from me that they would not otherwise get, such as why a priority changed or what a conversation two levels up actually meant.

None of these fit a status format, because none of them have a ticket.

Why I believe this

In fifteen years of running UI teams I have noticed that the problems that became expensive were almost always said out loud early, quietly, in a one-on-one, and then not heard because the meeting was busy with updates. The meeting that catches those is worth more than any report it could replace.

It also changes who owns the meeting. If it is a status update, the manager is asking and the engineer is answering. If it is about the person, the engineer brings the agenda and the manager mostly listens. I think the second shape is where trust gets built, and trust is what makes the hard conversation possible later.

The best argument against this

Some people genuinely want to talk through their work in that slot, and for them the work is the person. I think that is fine, as long as the conversation is about the work as they experience it, what is hard and what they are unsure of, rather than a readout for me. The difference is who the information is for.

Where it stops being true

A new hire needs more structure than this, and for the first month a one-on-one that walks through the week is a kindness, not a waste. A team in the middle of an incident or a release crunch will have status in every meeting whether anyone plans it or not. And a very senior engineer may want the meeting monthly and use the time between for the work. I would rather adjust the cadence than let the meeting become a form.

The question I keep asking myself afterwards is whether the person left with something they did not have before. When the answer is a list of tickets, I think the meeting went to the wrong thing.

Photo source: https://photos.robertstowe.com/tasmania

What I believe changes when you start managing managers

Robert Stowe — Wed, 14 Oct 2026 14:52:11 +0000

I think the move from managing engineers to managing managers is a bigger change than the move into management in the first place. The first move changes what you do. The second changes what you can see.

You stop seeing the work

A manager of engineers has direct access to the work, the pull request, the standup, the board. A manager of managers does not. Every signal arrives through another person's judgment, their summary, their sense of the week, what they chose to escalate. That distance is permanent.

The instinct is to close it. I think that is usually a mistake, because the time comes out of what you are now responsible for, the managers themselves. The distance is not a problem to solve. It is the shape of the job.

Your output is other people's decisions

The decisions that matter to a team, who works on what, what gets reviewed how, when something ships, are now made by someone else, in meetings you are not in. Your contribution is whatever shaped their judgment before they walked in.

I have come to think of that as the real output of the role. The time goes into what shapes judgment, being clear about what matters, explaining why, and talking through the hard calls afterward. A few decisions, usually about people, I still need to be part of.

Different is not wrong

Every manager runs their team a little differently than you would. At first every difference looks like something to correct. I think most are not. A team run differently from how I would run it, and healthy and delivering, is run well.

The exceptions have to be the same across teams, how people are treated, the standards the organization agreed to, and commitments to other teams. Those are not styles.

The feedback loop gets long

When you manage engineers, a change to how the team plans shows up next sprint. One level up, a change to how you support a manager might take a quarter to show. You can no longer trip over problems, so you have to decide on purpose what to look at, and how often. For me that means a few regular questions for every manager, and a few things I check even when nothing seems wrong.

What success looks like now

A good week as a manager of engineers was one where I did things. As a manager of managers, it is often one where I did little anyone could see and the teams did a great deal. I think the measure of the role is what happens without you, the decision made the way you would have made it by someone who did not need to ask.

Where this stops being true

On a small team, a manager of managers often still reviews code and makes many of the calls, and that is fine. Staying close enough to ask good questions is the job. Staying close enough to make the decisions is what to give up.

Photo source: https://photos.robertstowe.com/cumberland-island

What I think an estimate is for

Robert Stowe — Wed, 07 Oct 2026 13:59:45 +0000

I have sat through a lot of conversations about estimates. How to make them more accurate, which technique to use, points or hours or t-shirt sizes. I used to think the problem was accuracy. I no longer do. I think most of the trouble is confusion about what they are for.

An estimate is a planning input

An estimate is a guess about effort, made with incomplete information, by the people who will do the work. That is not a weakness. It is the definition. Nobody knows how long software takes until it is built, and an estimate is the best substitute when a decision has to be made.

It supports planning decisions. Is this worth starting? Which of these three goes first? Do we understand this well enough to begin, or does the wide range say we do not? Those need a rough size, which is what an estimate is good at. What it is not good at is being a date. It measures how much we do not yet know.

What goes wrong when it becomes a promise

The moment an estimate turns into a commitment, it stops carrying information and starts carrying consequences. The numbers go up, to leave room. Engineers stop saying the honest thing, usually some version of I am not sure, and say the safe thing. Nobody is behaving badly. They are responding to what the number now means.

I think the practical result is that estimates get less accurate as more weight is put on them, the opposite of what the weight was for.

What I ask for instead

A single number hides what I most want to know, how confident the person giving it is. So I ask for a range, and what would put it at either end. Two days if the API does what the documentation says, two weeks if it does not, tells me more than seven days ever could. It tells me where the risk is, and often what to find out first.

I also ask what the estimate assumes. Most surprises in a project were assumptions nobody said out loud. Saying them at the estimate is cheap. Discovering them in week three is not.

And I say which question I am asking. Is this sizing, so we can plan? Or a commitment, because a customer or a contract needs a date? A commitment should be made deliberately, with room built in, by someone who is allowed to say no. It should not be an estimate that got promoted when nobody was looking.

Where this stops being true

Some work has a real deadline. A regulation takes effect on a date, a contract names one, an event happens whether the software is ready or not. Then the team needs a commitment.

Even then, I think the honest path runs through the estimate rather than around it. Size the work, find the range, then decide what to cut or add so the commitment is one the team believes. The failure is not committing to dates. It is treating every estimate as one.

Photo source: https://photos.robertstowe.com/new-mexico

Writing technical standards people follow

Robert Stowe — Sun, 04 Oct 2026 03:09:13 +0000

Most technical standards I have met were written once, read twice, and ignored. The document was forty pages, it did not say why any rule existed, nothing enforced it, and the person who wrote it had moved to another team. The standard was true the day it was published and fiction a year later.

I have written a few that teams followed and more that they did not. Here is what separates them.

Brief enough to hold in your head

A standard is only useful if an engineer can remember it while working. A page or two of rules will be followed. Forty pages will be searched when someone is in trouble and otherwise forgotten.

So the discipline of writing a standard is mostly the discipline of leaving things out. If a rule does not prevent a problem the team has actually had, it does not belong. If two rules can be one, they should be.

Every rule says why

A rule without a reason is an order, and engineers are bad at following orders they do not understand, which is a feature, not a flaw. With a reason, the engineer can tell when a rule applies and when the author did not anticipate the situation. When the reason stops being true, the rule can be retired. A rule with no stated reason lives forever, because nobody can tell whether it is still needed.

Whatever can be enforced is

People should not have to remember a standard. Whatever a linter, a type, a template, or a pipeline step can check should be checked there, on every change. What is left is the part that needs judgment, the architectural decisions and trade-offs, and that part is short and worth reading.

Someone owns it

A standard without an owner decays. The platform moves, a rule turns out to be wrong, and nobody has the standing to change the document, so it drifts until it is ignored. Every standard needs a named owner with the authority to change it, and a date so readers know how stale it is.

The exception process

The last piece is a way to break the rule. Every standard will meet a case it did not anticipate, and if the only options are to follow it blindly or ignore it silently, the team will choose silence.

A good exception process is lightweight. Say what rule you are breaking, say why, get one other person to agree, and record it. The record matters more than the approval, because it is how the owner learns the standard has a gap, and a few exceptions of one kind mean the rule should change.

What a standard is for

I think a technical standard is a way of making decisions once so that nobody has to make them again. That only works if the decisions are few, reasoned, enforced where possible, and kept current by someone who cares. Everything else is documentation, and documentation is what people stop reading.

Photo source: https://photos.robertstowe.com/victoria