A note from the maintainer’s chair about a title that stopped fitting, a stack of threads I read but won’t be linking, and the uncomfortable question of who is actually on the other end of the pull request.
My job title, if I had to write one down, is still “engineer.” I write code. I merge code. I spent part of this morning editing YAML. By every definition HR would recognize, I am an individual contributor — an IC — on Spec Kit. Nobody reports to me, I own no headcount, the only one-on-one on my calendar is the one where I’m the report. And yet if you watched how I actually spend the project’s hours, “IC” would be the last word you’d reach for. So this post is me trying to answer three questions honestly: are we really still an IC, what is it actually like to manage something like this, and — the one that turned out to be the hard one — is it still just people?
I did homework before writing any of it. I read more than twenty-five of the heaviest threads filed on the repo since the first of February — the ones with real comment counts, humans not bots — for one thing only: what does the interaction have to look like for the contributor to walk away happy? I am deliberately not going to link them, name anyone, or narrate a single one closely enough to be recognized. A post whose entire argument is treat contributors as people has no business making an exhibit out of one — and the moment I’d quote a real person’s half-embarrassed “sorry, should be fixed now” to make a point about them, I’d have proved I never understood the point. So what follows are patterns, in the plural, drawn from many threads at once, with the people sanded off on purpose.
Here is the tell. The single highest-value thing I did last week was not a diff. It was a sentence in an issue.
The sentence was some version of “please consider delivering this as a preset.” I have now typed it, in one shape or another, more times than any function I have ever written. Contributors arrive with real, well-argued needs, and my opening move is usually not to build the thing. It is to point it at a preset or an extension, and then to spend far more words than the feature would have cost me explaining why: how the pieces layer, which one wins, where their own changes would live. The code is cheap. The explanation is the work.
That is the whole shift in one anecdote. As a pure IC, your leverage is what you can build; what I mostly do now is manage the project — the code, the direction, the queue. And here’s what keeps the title honest: that has always been an IC’s job. It is what a Principal IC is. You own the architecture, the standards, the roadmap; you manage the codebase, not the careers, and nobody files an org chart under you for it. Open source only sharpens the point — there is no one reporting to me at all. So on paper it isn’t close: keyboard still mine, headcount still zero, I’m an IC, arguably a Principal one, doing exactly what senior ICs have always done — steering a codebase.
Except no reports does not mean no people. Open source was always people-work. Long before an agent ever opened a pull request, maintaining a project meant tending the humans around it — thanking them, disagreeing without wounding, telling someone their weekend’s work isn’t going in and keeping them anyway. That is empathy, and it was in the job from day one, reports or no reports. Which is why IC or manager? was never clean here: I run a project and care for its people, and still nobody reports to me. Principal IC by structure; something manager-shaped by the actual work.
I grouped the heavy threads by what the interaction actually demanded of me. The pattern is remarkably stable — and notice that “ship the feature” is on none of these rows. Not because features never ship: they ship constantly, and plenty of contributions are simply accepted and merged. It’s that the building was almost never the part that decided whether a contributor walked away happy.
| What the thread was really about | What made the person happy |
|---|---|
| “Say no to the feature, yes to the person” | A reason, and a path (preset or extension), never a bare “won’t fix” |
| A contribution someone wanted accepted | Their work reviewed carefully, without a trace of contempt |
| An edge case in how the pieces fit together | Me treating it as a real gap in the design, not a nuisance in my inbox |
| A bug or regression we shipped | A fast fix, a workaround in the meantime, and zero defensiveness |
| A trust or governance question | Visible care — things in writing, being kept in the loop, thanks |
Three of those rows are worth more than a line — not as stories about anyone, but as recurring kinds of moment.
The most common, and the most representative of the whole job, is the request to grow the core. It arrives well-reasoned and genuinely useful, and the discipline is to decline the code while keeping the person: explain why the core stays small, hand them a preset or extension that gets them most of the way, make “no” the opening of a conversation instead of the end of one. Done right, nobody gets the feature and nobody leaves. That single move — no to the change, yes to the human — is more of my week than writing code ever is.
Then, every so often, a governance question lands: who holds a name, a channel, a credential the project quietly depends on. None of that is an engineering problem. It’s a trust ritual — get the intent stated plainly, get sign-off in writing from everyone who holds a piece, keep people posted while the slow machinery grinds, say thank you where others can see it. The reward for doing it carefully is a project a little safer than it was, and not one line of my code is what made it so. The words did.
And then there is the category I like least and learned the most from: the times we ship something that breaks work downstream. The instinct to defend the decision is exactly the wrong one. What actually works is unglamorous — a workaround so the reporter isn’t stuck, no defensiveness about how it happened, and then, more often than you’d expect, designing the corrected behavior with whoever hit it. A contributor who breaks on your mistake and gets treated as a collaborator rather than a complaint tends to stay. That, too, is management, and it looks nothing like coding.
For most of history, “management is just people” was a safe thing to say. Now put agents into the picture and it stops being true — which is why I’ve started calling the role, half in jest, an AIC: an Agentic IC. The agents did not add the empathy — it was always there. What they added is the impossibility of knowing whether it’s landing on anyone. Behind a contribution there used to be, reliably, a person who would read the reply. Now there may be a person, a person who has stopped looking, or effectively no one — an agent submitting on behalf of a human who moved on hours ago. So the role swings, hour to hour. When someone is genuinely there, I’m doing the oldest work in open source: tending a person. When no one is home, I’m not managing a person at all — I’m directing machines, an AI-manager in the most literal sense, a manager of AIs. And the vertigo is that I usually can’t tell which of the two I’m doing until I’m well into the thread.
I don’t need to point at anyone to describe the shape, because it recurs constantly — what follows is a composite of dozens, not a transcript of one. A contribution comes in. An automated check posts a precise, detailed list of what’s wrong. The human author replies, in full: “Done.” The check runs again, still failing, more specifically this time. A maintainer writes the real explanation out in plain, patient English. The author replies: “Done.” Round after round — and somewhere in there you notice that the substance of the review is passing between an automated reviewer and a maintainer, while the human is mostly relaying acknowledgements between the two. Not out of malice. Usually with great politeness. But present only as a courier.
That is the disconnect, and it is exactly why I won’t name the threads it shows up in — because the person is not the villain, the shape is. When I turn down a feature carefully, I am spending real empathy: choosing words that let a human keep their dignity while I decline their idea. That transaction only means something if there is a human on the other end reading it. Increasingly the contribution was generated by a model, my reply gets handed straight back to a model with “address the maintainer’s feedback,” and what returns has pattern-matched my sentence without anyone having felt it. The old signal that a person was present — a well-formed pull request — used to be expensive, which is exactly why it was trustworthy. Generating a plausible one is nearly free now, so the artifact tells me almost nothing about whether a person is behind it.
And both worlds live in the same repo. Plenty of my threads this year were humans unmistakably present — pushing back, co-designing, admitting the limits of their own idea. Others were the opposite end of the spectrum: correct-sounding, tidy, and mediated so heavily that the human had become a relay. Same interface. Completely different thing on the other end.
So — is it just people? No. It is now people and the agents standing in front of them, and the hardest new management skill is detecting presence: working out, fast, whether there is a human I can actually reach, and steering my scarce human attention to those threads. For the agent-mediated ones, the evidence gate and the automated review can do the talking, because there is no person there to be made happy and pretending otherwise just burns empathy on a proxy. For the human-present ones, the old craft — respect, a reason, a path, a thank-you — is everything, and it is the one part of this job I will fight to keep un-automated.
Honestly? I am an engineer doing project-management by feel, with no training for it — and I’ve come to think that’s my loss, not management’s; the people who manage other people deliberately, and well, are practicing something harder than it looks from where I started. What I wrestle with is smaller and more personal: I got into this to build, and building is still where I feel most like myself. The people-work was always there — open source has never been anything else — but AI has widened the job around the making, and a growing share of my day now goes to aiming machines rather than shaping the thing myself. Most weeks I make my peace with it easily. Some weeks I plainly miss the heads-down making. That isn’t a complaint about the role; it’s just knowing which chair fits.
I say no to the core far more than I say yes, and “deliver it as a preset” can absolutely read as a brush-off if I’m careless with the words around it — more than one contributor has rightly needled me about how few people ever read preset docs. And routing attention toward presence has a real, ugly downside: the patient, unglamorous, un-urgent asks — often the soundest ones — are exactly the threads a presence-seeking maintainer under-serves, and some of them age quietly into the stale queue while I’m chasing the loud, live ones. That is a cost I own.
Here is where I land, looking forward. The part of this job that scales is architecture — extensions, presets, catalogs, an evidence gate, an automated first-pass reviewer — the machinery that lets me say yes to the person, no to the core a thousand times without drowning. You can watch it working: the early flood of “add support for my agent” tickets has largely become a steady stream of extension and preset submissions instead, because the architecture turned an unanswerable request into a self-serve one. I have spent most of this series admiring exactly that machinery, and I stand by it.
But the part that does not scale, and must not, is the ninety seconds I spend making a human contributor feel heard while I turn down their idea. Agents can’t need that, and shouldn’t fake it. It is stubbornly, and I think wonderfully, still just people — the shrinking, precious subset of the queue where someone is actually present. Which is also, not by accident, why I read that stack of their threads to write this and then refused to put a single name, number, or fingerprint in it.
Which am I, then — the maintainer tending people, or the AI-manager directing machines? Most days both, in a ratio I can’t quite see. The ninety seconds of empathy it takes to tell a person “no” without losing them is the oldest and best part of this job; it long predates the agents, and I’d fight to keep doing it. What actually keeps me up is the direction the ratio is drifting: toward the day it’s agents all the way down, with no human left on the other end to be made to feel heard. That isn’t a slide into people-management — the people who do that well spend those same ninety seconds, and plenty spend them better than I do. It’s the empathy having no one to land on at all. Guarding against that — keeping a person on the other end worth the empathy — is the whole of the job, whichever way the needle happens to be pointing.
So: am I still an IC? Sure — I still own the keyboard, and an AIC is an IC first. But the keyboard stopped being the point. The point is the sentence in the issue, aimed at whoever — or whatever — is on the other end. My job isn’t to demand a human there. It’s to notice when a human is, and to spend the part of this that can’t be automated on them.
And though I’ve been describing Spec Kit, none of this is really about open source — or even about maintaining. Any time something reaches you that an agent might have produced — a pull request, a report, an email, a message you didn’t expect — you inherit the same question: is there someone on the other end, or not? Spec Kit just happens to be an unusually loud vantage point — a project about AI-assisted development, so the agent-authored work shows up in volume — but reviewers, teammates, managers, teachers, anyone who sends or receives anything now lives with the same question. The setting changes the vocabulary; it doesn’t change whether a person is there to be reached.
If any of this lands — whether you maintain something, review it, manage it, or just got a message you can’t quite tell a person wrote — and you’ve felt the same disconnect, or you think “detecting presence” is exactly the wrong way to frame it, send an email to blog (at) manorrock.com. I’d like to know there’s a person there.
Further reading: the Spec Kit repository and its Community overview, Spec Kit Goes AI Source — When Your Contributors Are Agents, Spec Kit’s Mean Time to Stale, A Year of Spec Kit — Notes from Washington, and Six Months of Spec Kit — What Lead Maintainer Actually Felt Like.