Tag: Career

A hand with a pencil rests on an unrolled plan covered in penciled question marks, with automated machines running out of focus in the background.

The Questions Are the Job

Allen Hutchison1 Comment

Last month I spent forty minutes on a call with a college student who had just finished a summer internship at Google. He was polite about it, but the question under all his questions was the one I’d ask in his position. The agents write the code. The platforms hide the infrastructure. The CI pipeline is something you copy from a template and never read. So what exactly is he supposed to get good at?

I gave him an answer on the call. It was mostly right and mostly unorganized, and I’ve been turning it over since.

Nobody Asks for You

Around the same time I fixed a bug in a small sync daemon I run on my homelab. It pulls things I’ve saved in various places into Readwise, and on every run it asks Readwise what it has already seen so it doesn’t save duplicates. The agent that wrote it did that the obvious way. It walked my whole Readwise library and built a set of URLs. What neither of us noticed for a while was that the walk included my RSS feed, and on a real account feed items outnumber the things you’ve deliberately saved by orders of magnitude. The daemon paged through 103,819 feed documents and never reached the end.

I caught it because I was reading the logs and knew what my account looked like. The agent wasn’t going to catch it. It had no idea what a normal Readwise library looks like, and nothing in the code was wrong in a way a test would find. Then I had to ask for the second fix too. The dedup set needed to be a cache on disk that warms incrementally, not something rebuilt from scratch every fifteen minutes. That’s a design decision, and the agent didn’t make it until I asked.

Both fixes took an afternoon. Neither would have happened without someone in the loop who knew to ask. I’ve been living the same thing at Vycari at a much larger scale.

What I Actually Do All Day

Chris and I have merged more than 2,600 pull requests across Vycari’s repositories so far, with two people. Two months of that work came to 1.1 million lines of new code. We have an army of agents doing most of the coding, and I wrote in The Backlog Was a Coping Mechanism about what that does to an issue tracker. What I haven’t written about is what it does to my job.

I write very little code and I’m busier than I’ve ever been. I’ve started calling what I do meta-programming, because the work has moved up a level. I write the plans, the rules, the guidelines, the checks, and the hooks that push everyone who touches the codebase, human or agent, toward the right decision. Chris makes changes all over the codebase, and he doesn’t need my sign-off to do it. He’ll check with me sometimes, especially on database changes, but nobody knows what they don’t know. The guardrails exist for that. Whoever picks up a change next, human or agent, needs enough context to get it right, and that context is mine to build. It never stops needing maintenance.

The second thing I do is think about the shape of the codebase over time. We started as one repository. As the product got more complicated I began splitting services out, each into its own repo with its own CI and its own rules. I wrote about why in The Test Suite Is the New Code Review. That makes iterating on any single service fast, and it forces a contract between services that has to be written down. Agents don’t do this on their own, not even the best or newest ones. They’ll add a new top-level directory next to the last one forever, and thirty days in I had a repository full of horizontal directories, repeated code, and no shared components. I refactored it from version zero to version one over a weekend, mostly from my phone while I was at a jazz festival.

The agents were excellent at the refactor once I’d decided what it should be. Mechanical moves, package relocations, extracting an interface and applying it across a dozen subpackages: I could hand those off and not watch. The biggest one moved more than a hundred thousand lines of code, not all of it mechanically, and I was reviewing it on a phone. I only slept because we require ninety-five percent test coverage, and because adversarial review agents were reading the diff alongside me. But the decision that the codebase needed reorganizing, and the decision about what the organization should be, came from me reading the code and recognizing a shape I’d seen go wrong before.

Proportional Scrutiny

The student asked how you get good at systems when the abstractions keep you from touching them. Part of my answer was that you have to read the code the agent writes, which is different from reviewing it.

The distinction matters to me because most code review I saw at Google was style review. Someone would tell you a line was too long, or a name didn’t match the convention, and both of you would feel like work had happened. I don’t do any of that anymore. We use Ruff for linting and formatting, it runs on every PR, and whatever it says is fine with me. I also don’t fight the agentisms. There are twenty-five line comment blocks in our codebase, and I leave them, because the next reader of that file is another agent and the comment might be useful context for it. A comment explaining how a for loop works is wasted tokens, but I’m not going to spend my afternoon hunting those down.

What I do instead is apply scrutiny in proportion to what the code is. If an agent rewrites a pile of CSS, I open the page in a browser, it looks fine, and I move on. I’m not a CSS expert and I have no plans to become one. When an agent touches our core agentic loop, I read every line and I make sure I understand why every line is there. That loop is one of the pieces of the product I’d call real intellectual property, and most of it was guided by me, decision by decision. The agent is the same in both cases. What changes is how much attention I give its work, and knowing where that attention belongs is most of the skill.

That’s proportional scrutiny, an idea I learned from Luiz Barroso. You watch the things that took a big investment, that have a large blast radius, that are consequential to the rest of the system, and you give everything else a lighter look. It applies to engineering management too. Luiz used it to let a few of us chase a long-shot project for a year while he ran an organization of fifteen hundred people.

What Breaks First

My favorite question to ask an agent, and the one I gave the student to take home, is what breaks first if usage goes up by three orders of magnitude.

A hundred queries a second to a hundred thousand. A thousand users to a million. The agent will give you a real answer, and the answer will teach you about the system you’re building faster than any textbook I know of. If you can get a project to the point where you’re confident it would survive that, you’ve done the distributed systems course. Very few systems actually run at that scale. Asking the question is still how you learn to think about scale.

I learned it the expensive way. I’ve taken large portions of Google down more than once in my career, and the lesson from those days was simple: you learn from the outage or you get fired. I once led a team that built a geographic photo search system, and it had to sit in the main search path, so every query to Google.com went through our code. The day we turned it on our baseline was over a million queries a second with a five millisecond budget at the ninety-ninth percentile. The naive implementation took a week. The version that could actually carry that traffic took two years. That gap, between the thing that works and the thing that survives, is what senior engineers carry around in their heads. It’s what the student was really asking how to acquire.

The Bargain We Used to Make

His question is harder now than it was for me. The industry used to run on a trade. A new grad could write syntactically correct code and not much else. We’d hire them, they’d write a lot of code, and a tech lead would sit alongside them and teach them how systems actually fit together. They gave us labor, we gave them judgment. It wasn’t efficient, but it worked, and it’s how every senior engineer I know got here.

Agents took the labor half of that bargain. A new grad’s first year of work, the part where you write a lot of code and learn by getting it wrong, is exactly the work agents do well and cheaply. What’s left is the judgment half, and that was always the part that was hard to teach and impossible to shortcut. I wrote in The Last Programmers that each rung on the abstraction ladder frees us to work on harder problems. I still believe that. But the ladder used to have a bottom rung you could stand on while you learned, and I’m not sure it does anymore.

I don’t think that’s hopeless. I think it means the apprenticeship has to be rebuilt on a different foundation, and so does the university curriculum. Whatever anyone thinks of AI, it isn’t going back in the bottle for coding. The new foundation is the same one the senior people are standing on: the questions.

The Most Patient Teacher You’ll Ever Have

The part of my answer I most want to be true is that agents are the best teachers most of us will ever get access to, if you treat them that way.

Don’t take the PR blindly. Ask why it did that. Ask what the trade-offs of that data structure are. Ask what the runtime implications of that table layout will be at ten times the rows. Ask it to explain the same thing three different ways until one of them lands. It will never get tired, never get impatient, and never make you feel stupid for asking the same question again. Some of the tools lean into this directly. Claude Code ships a Learning output style that explains its choices as it goes and leaves small pieces of the code for you to write yourself. That’s closer to what a good tech lead did for me than anything I got from a book.

I do a version of this constantly. I’ll point an agent at a subsystem and say I want to understand this deeply, walk me through the important files and the control flow. I’ll ask for a diagram of how a subsystem looks in main today and then interrogate the diagram. When I was a senior director that was exactly how engineering reviews worked: someone came in with block diagrams and sequence diagrams and we talked about the project at that level of abstraction. I wrote about coming back to the individual contributor side in Full Circle. One of the surprises has been how much of the director job I still do, just with an agent across the table instead of a team.

I’ve even considered running a full design review this way, asking an agent to build a presentation and walk me through its decisions the way a team would have. I haven’t taken it that far yet, but I may at some point.

That’s the rebuilt apprenticeship. You still have to write some code by hand, and you still need a couple of languages you’re truly fluent in. But the judgment you used to absorb from a tech lead over three years is now something you can pull out of an agent on purpose. You do it one question at a time, starting on your first day.

I don’t want to oversell this. Glyph Lefkowitz makes the strongest version of the opposing case in Programming Isn’t Special. Take away the mundane work and you take away the practice, because “the majority of true skill development happens on the job and always has.” He’s right about that part. Most of my own judgment came from getting things wrong in production, and asking an agent good questions doesn’t replace the experience of an outage you caused. What it can do is get you to your first real failures sooner, with a much better map of what you’re looking at when they happen.

There’s also something the agent can’t teach you, which is anything that happened after its training data ends. When a new language feature ships, the agent won’t reach for it unless you tell it to, because it has never seen it. Knowing when a change like that matters, and when to bring it up, takes judgment and experience of your own.

How We’ll Know

The student asked about hiring, and I gave him a split answer. Google and the other big companies will move slowly on this. The interview you get there in five years will look a lot like the one you’d get today: computer science fundamentals, system design, distributed systems. Those things aren’t going away, and the big companies are right to keep testing for them.

Startups will change faster, and I’m one of the people who gets to decide how. We’re not hiring at Vycari yet, but when we do I’m not going to put anyone in front of a whiteboard. I think that’s archaic now. What I might do is hand a candidate a coding challenge and an agent, and ask for the transcript instead of the code. How they worked with the agent will tell me more about how they’ll work with us than the code will. Did they read what came back? Did they ask why? Did they notice the thing that was going to break at scale, or did they ship the first thing that passed the tests?

I recently built a whole project in Swift, and I had never written a line of Swift before. I mention it because it shows how little the language matters now, and how much everything else does. The student was worried the abstractions were taking the important skills away from him. I think they’re taking the unimportant ones and leaving the important ones exposed, with nothing to hide behind. That makes the job harder. But the questions were always the job. We just used to let people spend a few years writing code before we told them.

An overhead view of a wooden desk holding two laptops side by side. The left laptop is closed and covered in old stickers with a security badge on top. The right laptop is open with fresh stickers and a code editor on screen. A sheet of dated notes lies between them.

Writing My Way Out

Allen Hutchison1 Comment

I started writing this blog two years ago because I wanted to share what I was learning about AI, and the projects it kept pushing me to take on. A year ago I wrote the first anniversary post, and it ended with a plan. Two thoughtful posts a month instead of the weekly pace that had already beaten me once. More explainer series, because the embeddings posts had been the most-read thing I published. Some shorter pieces in the spirit of Simon Willison. And permission, finally, to write about the woodworking and the guitars instead of quietly worrying that they were off topic.

I had no idea, when I wrote it, that by the time I sat down to write the next one I would not be at Google anymore.

The plan mostly worked

I published fifty seven posts between that anniversary and this one, which is a little under five a month against a goal of two. I am not sure that counts as keeping a promise so much as failing to keep it in the more enjoyable direction.

I had been afraid that I would run out of things to say. The opposite happened. If I look at my drafts and ideas folders right now, there are close to fifty posts in there that I still want to write and have not found the time for.

The explainer series happened. The Agentic Shift was planned as twelve parts, and it came in at twelve parts, thirteen if you count the introduction, running from September through April. The structure held up almost exactly as I outlined it. What I did not anticipate was how much the ground would move underneath it. I thought I was writing a textbook, assembled in public. What I actually wrote was a journal of a landscape that would not hold still long enough to be documented. I outlined Part 9 as speculation about a future problem and published it as reporting on a present one. I am really proud of that series, and I think it has stood up well.

The shorter pieces happened too, though this one is still a work in progress. Eight Reading Lists, which started as an experiment in whether I could publish something in under an hour and turned into the format I reach for when an idea is real but not yet a post. I never got to the point of posting one every week, and that is something I want to get better at this year.

And the hobbies made it in. A bill in the California legislature that wanted my 3D printer to police itself. A French band I could not stop listening to. A Starlink dish on the roof of a car. The Köln Concert, as an argument about creative constraints in software. Nobody unsubscribed, as far as I can tell, which suggests the worry was mine and not my readers’. There is more of that to come, I hope.

The post that turned out to be about something else

In April I counted my GitHub contributions for the year. There were 4,255 of them, and the post was supposed to be a light piece about the shape of a year of building in the open.

The interesting number was not the total. It was that my most productive day of the week was Saturday, by a wide margin, and the reason was not discipline. It was that Saturday was the day nobody had scheduled anything. I wrote at the time that this was a diagnosis rather than a brag, and I meant it more casually than it turned out to deserve. Given time and no meetings, I build things compulsively, and I am happier. That is a useful thing to learn about yourself. It is also the kind of thing that, once you know it, quietly reorganizes every other question you were asking.

Four months later I left, after twenty one years, most of a career, and about half my life. Twenty One Years is the post about that. Not Everyone Wants a Hobby is the post about what I left to go do, which is a company called Vycari that I am building with Chris Perry. Chris was the product lead for Colab when I ran the AI Developer organization, we were both on the founding team of Gemini CLI, and somewhere in there he became the person I most wanted to build with. He is the CEO, I am the CTO, and our first product, Pepper, is a personal assistant for your life. And Thousands of Goodbyes is the post about pointing an agent at twenty one years of my own sent mail because I could only remember about a hundred and fifty of the several thousand people I had worked with.

I did not plan any of those as a trilogy. Reading them back to back, they are obviously one thing.

What the blog was for, and what it is for now

When I started writing here, the blog had a job inside a larger job. I said as much in the first anniversary post: building in the open and writing about it was how I contributed while my calendar was still too unpredictable for mission critical work, and it let me lead by example, demonstrating the kind of developer engagement I was hoping to inspire in an organization I was running.

That is a perfectly good reason to write, and it is gone now. There is no organization. There is no example to set for anyone but Chris and me. The blog is no longer a thing I do alongside the work, and it is not marketing for the work either. It is the only continuous artifact I have from before to after, which I did not appreciate until I went looking for a through line and found that the writing was the only place one existed.

There is an obvious hazard in this, and I would rather name it now than have you notice it in six months. Founder blogs decay into product announcements. It happens gradually and the person writing them is always the last to see it. So let me be clear about what you should expect. I am going to write about Vycari and Pepper, because they are the most interesting things happening to me right now. We are building a new kind of agent harness and a new kind of agent, and there are a lot of stories in that. Some of them will be technical, like the recent post about what happened to our issue backlog once agents were filing most of the issues. Some of them will be about philosophy, like why the chat window is the wrong interface for most people and why almost nothing a consumer agent does needs a frontier model, and a few of them will be things I did not feel I could say while I worked at Google. What I can promise is that everything I write here is here because I think it is useful to share, because I think you will enjoy reading it, and because I think it articulates why Chris and I, and the company we are building, are different.

The people who read this blog are people who will happily install a CLI, configure an API key, and read a changelog for fun. They are the reason it exists. I am aware that I have just started a company premised on the argument that requiring all of that is a failure of product design, and I do not think those two things are in tension, but I understand why it might look that way. Working out loud on that confluence is most of what I expect year three to be about.

Year Two, By the Series

The Agentic Shift

Twelve parts and a retrospective, September 2025 through April 2026. The series that ate the year, and the work on this site I am proudest of.

Building the Things I Write About

The Reading Lists

Eight of them, starting in April. Short, fast, and the closest thing this blog has to a running commentary.

The Work Itself

Building Vycari

The first three posts of the next chapter. None of them is a launch announcement, which is the point.

Everything Else

The promise I made last year to stop worrying about staying on topic.

Year Three

More of the same, with one change I am now a month into.

For two years I wrote about agents from inside a company with essentially unlimited access to models, infrastructure, and the people who build them. Everything I published came with that thumb on the scale, whether or not I acknowledged it. For the past month I have been building the same class of system with two people and a budget. In the first thirty days of that, the two of us merged 657 pull requests, our agents filed most of the 449 issues that came out of them, and something like a hundred and fifty million tokens went through the product for about forty dollars. Those are not numbers I could have written from inside Google, and they are the constraints almost all of my readers have always lived with. I expect that to make the writing better, and the series on how the two of us build, which started with the issue tracker, is where I intend to find out.

I also want to keep doing what Thousands of Goodbyes turned out to be, which was the first time in two years of writing about agents that I pointed one at something that was not work and had the output make me feel something. There is a great deal more of that available, and almost nobody is writing about it, because we are all still busy benchmarking.

Beyond that, my goals are simple. I want to keep sharing what I learn. Last year I said a weekly pace was not sustainable, and then published nearly five posts a month, so this year I am going to say it out loud: at least one real piece a week, with shorter things sprinkled in on the other days. I am trying to be more active on X and LinkedIn as well, so if you see me there, say hi. I will keep bringing more of my outside interests into this space, though it will almost always have a technical angle. There are more management posts planned, a tribute to a friend who is gone, some book reviews, and more.

Two years ago I hit publish on the first one of these with no idea where it would lead. I have a much better idea now, and I am still not going to tell you it is a plan. I am looking forward to what comes next, and I am glad you have decided to come along.

A laptop on a dark desk with thousands of small glowing blue points of light rising from the screen and spreading outward like a constellation, connected by faint threads, with a small bright cluster near the screen and the rest fading into darkness.

Thousands of Goodbyes

Allen Hutchison1 Comment

There is a problem with leaving a job you held for twenty one years, and nobody warns you about it. You cannot remember who you worked with.

Not in the sense of having forgotten them. In the sense that the list does not exist anywhere, including in your head. I left Google earlier this month after twenty one and a half years across Search, Maps, ads, mobile, Core, Core ML, and DeepMind, in roles that ranged from running large organizations to writing code with three people. Somewhere in there I met, argued with, mentored, was mentored by, shipped alongside, and occasionally annoyed several thousand people. When I sat down to write my goodbye note, I could produce maybe a hundred and fifty names from memory, and I knew with total certainty that the hundred and fifty were wrong. They were the recent ones and the loud ones. The person I had one extraordinary conversation with in a London conference room in 2008 was nowhere near that list.

This is the sort of problem that used to have exactly one answer, which is that you accept it. There is no roster of everyone who mattered to you, no internal system that will hand you the list. What you actually do is type out the names you can think of, send the note, and add a line asking people to please forward it to anyone you missed. It works, in the sense that something gets sent. It is also a sloppy solution that quietly hands the entire decision to your recency bias. The people you saw last month get a goodbye. The people who changed how you work, fifteen years ago, on a team that no longer exists, do not.

I did not want to accept it. So I did the other thing.

Letting the machine do the remembering

The tool I reached for was Antigravity, paired with the Google Workspace MCP server I had originally built as a Gemini CLI extension. That extension exists because I wanted my terminal to be able to see my calendar. It turns out that giving an agent access to your mail and calendar for ordinary convenience also gives it access to the complete archaeological record of your working life, which is not something I had thought carefully about until I needed it.

The first pass was mail. I had the agent go through twenty one years of sent messages and pull out every address I had ever written to individually. Not mailing lists, not the thirty person threads, not the announcements. One to one mail, or close enough to it, on the theory that if I had bothered to type your name into the To field, we had a relationship worth closing properly. That produced a very large and very stale list, because a lot of those people left Google years ago. So the second pass compared the addresses against an internal directory and kept only the ones still active, which cut it down considerably and also produced a small, unexpected inventory of people I had lost track of.

The second source was calendar. Mail catches the people you write to, but it misses the ones you only ever talked to in a room. So the agent went through twenty one years of my calendar looking for anything that was genuinely a one to one: a recurring weekly, a single mentoring session someone booked in 2017, a skip level, a coffee that got a calendar entry because that is how Google works. Every one of those has a person on the other side of it, and a surprising number of them never once appeared in my sent mail.

Then it merged the two. I had expected this to be the hard part and it was not, for a boring reason: Google email addresses are stable. People change teams constantly and the address follows them, so deduping on the address alone does nearly all of the work. What I was not prepared for was reading the result. Whole eras came back. I would hit a cluster of addresses and remember an entire project I had not thought about in a decade.

The last problem was purely mechanical and almost funny after all that. Gmail will not let you put several thousand addresses on a BCC line. The agent did not raise this, which is worth saying in a post that is otherwise about how capable these things are. I had to notice it and ask. Once I did, it split the list into batches that fit under the limit and drafted the same message across all of them, and I sat there and hit send, over and over, until the list was gone.

What came back

I expected silence. You send a goodbye to someone you shared one project with in 2011 and you expect it to land in an archive folder, if it lands anywhere.

One person wrote back to tell me, politely, that he had no idea who I was. I liked that reply enormously. I assume he was not the only one who felt that way and just the only one honest enough to say it, and I would rather have sent that mail and been forgotten than not sent it at all.

But most of what came back was not that, and the volume of it caught me completely off guard. A solutions engineer in Japan wrote about a Street View collaboration with Nintendo that had been his very first project at Google, and told me I was probably the first real engineer he ever encountered. We were born the same year. He had turned fifty a month earlier and was finding the number about as strange as I am. Someone I managed for only a few months thanked me for trusting him and called it one of the most engaging windows of his career. A former colleague opened by saying he had just been telling someone we both used to work with how much he missed working with me, and then reported that he still has not gotten his motorcycle license because his friends staged an intervention dinner about it. A director in Munich offered a beer if I ever make it back and reminded me of work we did together that I had honestly stopped thinking about. Someone I have known for close to twenty years said he had been meaning to call, and instead of trading contact details we ended up at lunch off campus the following Friday, which is the best possible version of what one of these notes can do.

That is the part I keep turning over. Not one of those replies exists if I send the note from memory.

A hundred and fifty, the number of names I could produce on my own, is roughly Dunbar’s number, the size of a stable social group a human can actually maintain. I do not think that is a coincidence, and I have stopped treating it as a personal failing. My recall of my own career landed almost exactly where the research says it should, which means the ceiling was never effort or affection. It was architecture. Twenty one years builds a network many times larger than the one a head is designed to hold, and the overflow is not forgotten so much as never retrievable in the first place. The agent was not being clever here. It simply was not subject to the constraint.

The people who wrote the most moving things back to me were, almost without exception, the ones my brain had not surfaced. They were on the list because software read my calendar from 2013 and did not care that it was 2013.

The gap this points at

I have spent two years writing about what agents can do, and most of my examples have been about work. Code, pipelines, research, the machinery of building software. This is the first time I have used one for something that was purely about people, and it is the only agentic project I have run where the output made me feel something.

It is also, and I want to be honest about this, a completely unreasonable thing to ask a normal person to do. To get here I needed an agent platform, an MCP server I wrote myself, OAuth credentials, a working mental model of what a tool call is, and enough patience to iterate on the approach a few times when it came back wrong. The capability was extraordinary. The cost of access was absurd.

That gap is the whole reason I am doing what I am doing next. I wrote last week that using agents today is effectively a hobby, and this is the cleanest example I have of why that matters. Everyone leaving a long job has this problem. Almost nobody gets to solve it, because solving it currently requires you to invest in the hobby first. Closing that distance, so that an ordinary person on an ordinary Tuesday can ask for something like this and simply get it, is the work.

Twenty one years of colleagues got a goodbye from me because software remembered what I could not. I would like that to be an unremarkable thing to say.

And to everyone who wrote back: I replied to every thread I could, and I am sure I still missed some. I want all of you to know how deeply your words and your wishes landed. Thank you for that.