Think about the engineer on your team who says the least in AI discussions. Are they still getting started, or are they quietly missing something they were very good at? If you do not know, your next announcement may land on a loss you have not yet noticed.

Molly Graham became known for an essay about giving away your Legos, meaning the responsibilities and skills you release to make room for new ones. Her core idea is that when the ground shifts, people cling to what they know, including their roles and the expertise behind their identity. Holding on does not stop the change, she says. It makes adapting harder, and the people she saw thrive let their roles evolve.

Her new piece applies this to AI, which she says is changing jobs faster than anything she has seen in her career. She makes three points. First, believing in the opportunity and disliking the change can coexist, and forced excitement tends to bury feelings that return later. Second, mourning what is ending is different from resisting what is coming, so she suggests naming what you loved before looking ahead. Third, almost everyone is a beginner right now, and she argues that is less of a handicap than it feels. In her experience, curiosity about what the next form of the job demands mattered more than a relevant background.

She also notes that handing work to AI is different from handing it to a person, because with AI the mental load stays with you. You explain, supply context, review, correct and remain accountable. So she keeps judgment, taste, accountability, vision and trust with people, and asks what AI can help her become better at. She ends by saying that change brings opportunity and exhaustion together, and that people are allowed to mourn while they look forward.

Graham is describing something engineering leaders see every week and rarely discuss. The losses are real and specific. The craft of writing code by hand. Long stretches of deep focus. Being the person everyone asks. The pride of an elegant solution. The ladder of small tasks that taught juniors how systems work.

Picture a staff engineer who is known for deep knowledge of an old service. Agents now answer many of the questions that used to come to her. Nothing has gone wrong, and the change may be good for the team. She may still feel smaller. If her manager responds with "isn't this exciting?", she learns that her feeling is not welcome.

In my experience, an enthusiasm mandate is a common misstep. It sounds positive, but people hear a signal that their feelings are not welcome. The alternative costs very little. A useful check is whether your last announcement contained a sentence about what the change leaves behind. If it did not, assume that some people are carrying a loss in silence. Say what the change ends, say that you notice, and then say what happens next. A short ending note at the close of a migration or tool rollout works well. The team writes down what the old way gave them and what they want to carry forward.

It also helps to separate three kinds of loss, because each needs a different response. Some losses are about craft, such as the satisfaction of writing code by hand. Some are about status, such as being the person everyone asks. Some are about security, such as not knowing what your role will look like next year. Craft losses are honored by finding a new way to apply the same care. Status losses are met by offering a new kind of authority, such as owning the standard for agent output. Security losses need the most honesty, including a plain statement of what you know and when you expect to know more.

Do not stop at the group setting. Quiet people rarely volunteer a loss in a meeting. Silence after a tool announcement is information, so follow up privately. In a one-to-one, ask which part of their work they enjoy most and worry might shrink. Then connect each loss to something new that comes with the change, such as specifying work clearly, reviewing agent output or designing systems. Without that link, the change can read as a step down.

This has limits. Naming a loss is not a promise to preserve it. Without a next step, a conversation about loss can drift into a reason to pause. Keep it short, give it a place on the agenda, and follow it with a concrete decision. Be honest about what you do not know, especially about roles. A vague promise helps less than saying you cannot yet say.

Graham says almost everyone is a beginner right now. In engineering teams the effect is uneven, and it can shift status. A senior engineer with years of hard-won judgment may feel less certain beside a colleague who picks up tools quickly. A newer engineer may feel pressure to look fluent when they are not.

Picture a senior engineer who quietly steps back from agents because the first attempts looked rough. Nobody notices, because the work still gets done. Six months later the gap has grown, and so has the hesitation about asking.

The leader's job is to lower the cost of seeming unsure. Go first. Share an attempt of your own that did not go as planned, in the team channel, and say what you learned. Hold a short session where people show a rough result and what they changed. Put learning time on the calendar so that it does not depend on being brave. Praise good questions as warmly as good results, because a question is often the first sign of real learning.

Make the first projects small and real. A bounded task with a clear owner, such as drafting tests for one module or summarizing one week of alerts, lets people practice in the open at low risk and produces a result the team can discuss.

A useful pairing is across experience levels, with each side teaching something different. One brings fluency with the tools. The other brings judgment about how the system behaves and where it is sensitive. Both are needed.

Managers should check their own feelings too. If you built your standing as the person who could always go deepest into the code, this change touches your identity as well. Leaders who have not looked at that can pass it on to their teams, as impatience with people who need longer to let go.

Here I would push back a little on "everyone is a beginner." It is true of the tools. It is not true of engineering judgment. Experienced people are better at telling whether the output is right, and a team that forgets this will not get the full value of its best reviewers. Also resist measuring early adoption with usage counts. Counting prompts shows activity more than it shows learning.

Graham lists the things she is reluctant to hand to machines: judgment, taste, accountability, trust and vision. For a team, I would turn that into a working map. Which tasks go to AI with human review? Which go to people who own them fully? Which do we keep as leaders, such as trade-offs between architectures, taste in design, incident command, mentoring and relationships with other teams? And who is accountable for each agent workflow?

There is a catch that Graham's list hints at. Judgment and taste come from doing the work. Many of the small tasks that built them are the ones now handed to agents. If juniors never write a function by hand or trace an incident themselves, where will their judgment come from? Keep some practice on purpose. Pick a few small tasks that people still do themselves, and treat them as training, not as inefficiency.

Picture a team that lets agents draft its incident summaries. The draft is cheap to produce, so the team keeps the judgment: a named engineer decides what the incident means and what should change. The agent saves time, and the accountability stays with a person. That is the shape of the map in practice.

Her point about mental load matters for planning too. Supervising agents is work. An engineer running several agents does not produce the sum of their output, because attention is the limit. Watch the signals: review queues that grow, errors that reach production, people who seem tired despite shipping more. Count supervision in your capacity plans.

Be explicit about the reason behind each placement. "People keep this because it needs accountability" is a principle that carries over to new cases. "People keep this because we always have" is a habit that will be questioned the next time a tool improves. Write one sentence of reasoning next to each row of the map.

Different people will draw the line in different places, and that is healthy. Let the engineers closest to each workflow propose where it belongs, then settle it as a team, so the rule has owners and not only an author.

Expect the line to move. A task you keep human today may be safe to hand over in a year, and the reverse can also happen. Revisit the map each quarter, and do it with the team. Check it again when someone joins or leaves, because a map that quietly assumes one expert is always available deserves a second look.

Which part of your own work has AI changed most, and is there anything you miss about the old way? Hit reply and tell me. I read every answer.

Keep going, one small spark at a time.

Erwin