They’re Not Asking About Taste Anymore

A junior catches you in the hallway. Or the coffee line. Or on the curb outside the office. The setting changes; the question doesn’t: how do you decide when to use AI and when not to?

You give them an answer. It is a version of the answer everyone in your chair has been giving since the question started showing up: something about judgment, something about trusting your gut, something about knowing the difference between a tool that helps you think and one that thinks for you.

They nod. The conversation moves on.

Later, you replay the answer in your head, and you realize you have heard it before. A version of it landed on you in your twenties, from your own senior, when you asked them how they decided whether a piece of work was good. They told you you’d know. They said it warmly. They meant it warmly. It was useless.

You have been handing the same thing back. The vintage on the platitude has changed. The shape is identical.

The gap nobody admits to

Most of us in the senior chair do not have a framework. We have instincts that took us decades to build, a vague company policy written by someone in legal that nobody reads, and a low background hum of guilt about whatever we did with Claude or ChatGPT yesterday afternoon. When a twenty-six-year-old asks us to explain how we decide, we reach for the language we have available, and the language we have available was built for a different problem.

Our seniors taught us about taste. Taste was the answer because taste was the thing that separated the work. Anyone with a Quark license could lay out a page. The difference was whether the person making it had been in enough rooms to know what fit. So the answer to how do I know when it’s good was, reasonably, you’ll know when you’ve been in enough rooms.

The juniors today are not asking us about taste. They have access to taste-shaped output before they have taste. The tool will hand them a layout that looks like it was made by someone who has been in a thousand rooms, and they will be looking at it on day one. What they are asking is something the seniors never had to answer, because the seniors never had to face it.

The question is not how do I know when my work is good. The question is: how do I tell when I’m in the work at all.

That deserves a better answer than the one in the hallway.

Four questions to ask before you ship

No acronym. No five-step process. Four questions, the kind that come out of enough cycles of finishing something with AI and feeling a small static of whose is this? underneath the keyboard. They are not a corporate policy. They are not a discipline. They are four questions you can ask yourself before you hit send.

The first one is the cleanest:

What part of this requires my judgment, not just my prompting?

If the answer is all of it, the prompt is doing the actual work and you are typing it. That is fine for some tasks. It is a problem for others. The test is whether you can point at specific decisions in the output and say, I made that one. I rejected the version where it went the other way. I overrode the default the tool wanted to give me. If you can list those decisions, the work has your judgment in it. If you cannot, the work has your account name on it. Those are not the same thing.

The second one is harder to answer honestly:

Would I stake my reputation on this output without reviewing it?

The honest answer for most of us, most of the time, is no. We would not. We know the tool gets confident about things it has no business being confident about: invents citations, misreads charts, writes paragraphs that sound right and are not. So if the answer is no, the next question is whether you actually reviewed it, or whether you skimmed it and felt the warm relief of being done. Skimming is not reviewing. Reviewing is the slow read where you put your name on every claim and refuse to ship the ones you cannot stand behind.

The third one matters most when the work is for a client:

If the audience knew exactly how this was made, would they still value it the same?

This is not about disclosure rules. It is about the implicit contract. When someone hires you, they are paying for a thing they think they are buying. Sometimes that thing is the output. Sometimes it is your judgment applied to their problem, and the relationship and responsibility that comes with both. Run the audit. If they saw the process from the inside, would the price still feel right to them? If the answer is yes, you are clear. If the answer is probably not, you have a conversation to have, either with them or with yourself.

The fourth one is the only one that is really about you:

Am I learning from this process, or just accelerating past it?

The tool will let you finish a task at a speed that does not require you to understand it. That is the trap. Finishing is not the same as learning, and a career is not the sum of finished tasks. It is the sum of the things you had to think through hard enough that they changed how you think. If every project you do with AI is making you faster but not deeper, you are not building a career. You are running down a battery you started charging twenty years ago. The work will get done. You will get hollow.

This is the one that does not let go of you.

What the questions do, in practice

Run them on the next few things you ship. The answer will sometimes be clean and sometimes not. The not-clean ones are the work. They are the moment you either rewrite the part that was the machine’s, or, occasionally, make peace with the fact that you let the tool drive a piece you should not have. The questions will not make you better. They will make you honest. That turns out to be a more useful starting place than confidence.

The questions start working on the people around you once they hear them. Someone walks over with something they are about to send. You ask question two. You watch them realize the answer. They go rewrite it. No policy document required. They needed a question they had not yet asked themselves.

That is the function of a framework like this. Not enforcement. Permission to slow down for forty seconds before you hit send.

What to do in the hallway

Four questions will not make you a better mentor on their own. Mentoring is mostly showing your work, not the polished deliverable but the judgment-laden, occasionally embarrassing middle. The reason the juniors are asking us this question is that nobody is letting them see the middle of anyone’s process anymore. Everything around them looks finished: the deliverables, the Slack channels, the internal docs. The work looks solved.

What is missing is the part where you go: I asked it for three versions, I hated all of them, I figured out why, I wrote the actual thing by hand, then I asked it to clean up two paragraphs. The audit, in other words. The line between you and the machine, drawn in pencil, in your own handwriting.

You can give them the four questions. You can also tell them you are still working them out, that you gave a platitude in some hallway last month and went back to your desk feeling like a fraud, and that the questions are what you came up with so the platitude does not have to happen again.

That is more useful than trust your gut. It treats them like the colleague they are about to become, and it treats you like the practitioner you actually are: still figuring it out, with the years of judgment behind you, still willing to be honest about where the judgment runs out.

Send them the questions. Send them this piece if it helps. Then ask them what is broken in the version they were going to ship today, and walk through it with them.

The mentoring gap closes the same way the trust gap closes. You show the work.