What We Still Ask Each Other

Something has changed in what developers ask each other, and I noticed it first in my own behavior. For over a decade, across enterprise teams and startups, the questions moving between people were dominated by mechanics. Why does this regex not match. What does this error actually mean. How do I get these two libraries to agree on a version. I asked them, I answered them, and somewhere in the last two years I stopped doing either, because a machine now answers them in seconds, at any hour, without making anyone feel small for asking. The questions that still pass between people got fewer, and they got heavier.

I do not miss the old traffic. Fielding the same mechanical question for the fortieth time was never the good part of this profession, and having a tireless machine absorb it is a gift. But watching which questions still cross the gap between people, after everything else stopped needing to, taught me something about where a developer's worth is moving. Three kinds still make the trip, and they are not equally durable.

Newer than the training run

The first kind is born faster than any model can learn. A release ships on Tuesday, and by Wednesday it is breaking in ways nobody has documented, because nobody has lived with it long enough to document them. I write code with two different models, daily, and the moment a tool updates underneath me, both of them shift from sage to confident guesser without changing their tone at all. Recognizing that shift is a skill now.

The obvious objection is that models browse. They can pull release notes and issue threads on demand, and that has narrowed this window considerably. But retrieval reads text, and in the first days after a break, the text does not exist yet. The knowledge lives in the heads of the fifty people who hit the same wall in the same week, and in the messages they trade once they find each other. For that stretch of days, those people are the only place the answer exists. Everything the machine will eventually know about the break has to pass through them first, because someone has to write a thing down before anything can retrieve it. The window keeps narrowing, but every release opens it again at zero, so the questions living inside it keep needing a person. Just never the same person for long.

Deeper than a plausible answer

The second kind goes down instead of forward. The dark corner of a compiler. The paragraph of a specification that two implementations read differently. The question where a plausible answer is useless, because what is needed is a provably correct one, with provenance, from someone who can point at the exact clause that decides it. When someone asks why the optimizer is allowed to reorder those two writes, they are not asking for a paragraph that sounds like documentation. They are asking for the memory model, chapter and verse.

I should be clear about my own position here, because it cuts against me. I have spent a good part of recent years working on retrieval systems for legal and health domains, where an answer that cannot show its source is worth nothing, whatever it sounds like, and the whole engineering effort goes into pinning every claim to the document it stands on. That work is a bet that this category can be automated, and the bet is going well. A machine that answers with the exact clause attached is not a fantasy; it is roughly my job description. So of the three kinds, this is the one I expect to keep shrinking. The specialist who knows the specification cold will hold the edge in the corners where the documents contradict each other, and in the questions the documents never anticipated. But I am not going to build an essay on a moat I spend my working days draining.

The question that is about you

The third kind sounds the least technical and turns out to be the most durable. Look at my project. Which of these tools for my team, given our codebase and our deadline and the two people who will actually maintain this. What would you do.

Ask a model these questions and you get something genuinely useful, a survey of the option space with every tradeoff laid out. Press harder and it will even pick one, so I will not pretend the machine refuses to make calls. What it cannot do is weight the tradeoffs the way lived consequence weights them, and I think the reason is concrete rather than mystical. The written record the machine learned from is skewed. Dramatic failures get postmortems; slow ones do not. Nobody writes an incident report titled "this library was slightly wrong for our team and cost us three hours a week for two years." The person who has maintained the thing they once recommended carries exactly that missing data: which tradeoffs in the survey actually bit, how hard, and how long the bruise lasted. When they collapse the option space into a call for your situation, that missing data is what does the collapsing.

There is a less flattering reading of all this, and I will grant part of it. Some people asking "what would you do" want cover more than counsel, a name to point at if the choice goes wrong. But even that is a demand no machine can meet, because you cannot point at a model. And the better version of the same instinct is sound. They want the call to come from someone who pays some price for being wrong, in reputation if nothing else, because a recommendation that costs its maker nothing is easy to make carelessly.

The inversion

So the machine took the middle. The whole archive of solved mechanics now flows out of a prompt instantly, and from where I sit, the traffic in those questions between people has thinned to almost nothing. What still flows leans heavily toward the last kind, the requests for taste and recommendation and judgment.

That is a reversal worth sitting with, because our culture trained developers to treat exactly those questions as lesser. Ask what someone would choose, and the reflex was to wave it off as mere opinion, not a real question, since it had no verifiable answer. The reflex made a kind of sense. We reserved subjective calls for the people we paid to make them, the tech leads and the architects, and between peers we prized the questions that evidence could settle.

The questions evidence can settle are now settled by a machine before they reach a person at all. What remains is the kind with no verifiable answer, the kind that used to get waved off. It has gone from the noise in the channel to most of what the channel carries. And the people still asking it are not confused about how any of this works. They have correctly identified the thing they cannot get from a prompt, and they are asking the only place it exists.

Become someone worth asking

I should say where I stand. I build some of the machinery on the cheap side of this trade, tools that generate code and answers all day, and every one of them ends at a human who has to make a call the tool cannot make for them. When I say the value moved toward the person willing to make the call, I am describing the exact point where my own tools stop.

For a developer, the practical question follows directly. Are you someone worth asking? Is there a corner of this field where you have lived with your own choices long enough that your call means something there?

And when the question comes, answer with the reasoning, not just the verdict. A verdict goes stale with the next release, and it is the one part of your answer the asker could have prompted for. What they cannot prompt for is the weighting: how you compared the options, what it cost you when you chose wrong, what you would watch for now. Handing that over is what makes the asker better, and one day makes them worth asking too.

I will not claim this window holds forever. Every other window in this story has moved, and this one may move too. But today, when someone brings you their project and asks what you would do, notice what happened. They had a machine that answers everything, and they brought the question to you instead. Take it seriously, and answer it with your reasons showing.