Is AI going to take my job?

Not your whole job — but AI is absorbing specific tasks, and every job is a bundle of tasks. The useful question is which of yours are exposed, which get amplified, and which hold their value because a person has to be accountable for them.

Which jobs are most exposed to AI right now?

Not whole jobs — the exposed thing is a task with three properties: it's made of text or data rather than physical presence, its output is easy to check, and it doesn't carry personal accountability if it's wrong. Drafting a first version of a routine document, summarizing a long thread, reformatting data, writing boilerplate — those are exposed in any role. The roles that feel the most change are the ones where those tasks make up most of the week, not the ones with a particular job title.

Is "learning AI tools" enough to protect my career?

It's the entry ticket, not the moat. Everyone in your industry will be able to prompt a model within a year or two — that stops being a differentiator the moment it becomes normal. The durable part is what you do with the output: knowing which of five plausible drafts is actually right, catching the confident mistake, and being the person accountable for the result. Tool fluency gets you in the room; judgment keeps you there.

I'm not technical at all. Is it too late to start?

No, and the non-technical framing is itself outdated. The current generation of tools is driven by plain language — you describe what you want and read what comes back. The people doing the most interesting work with them right now are often subject-matter experts, not programmers, because the scarce input is knowing what good looks like in your domain. You already have the expensive half of that.

Should I hide that I use AI at work?

Hiding it is the worst of both worlds — you carry the risk without getting credit for the leverage. The better move is to be open about the process and unambiguous about the accountability: you used a model to draft, you checked it, and your name is on the result. Teams that make this normal get to talk about verification honestly; teams where it's a secret quietly ship unchecked work.

Isn't "taste" just a nicer word for design or aesthetics?

Aesthetics is one part of it, but only one. Taste as it matters now is three things at once: an aesthetic sense (does this look and feel right), a systems sense (how does this fit the wider product and where it's going), and a judgment sense (does the tone of this interaction match what it actually means). The unifying skill is knowing what to work on, how to frame it, and which medium communicates it — that's why it generalizes far beyond design into any field where building got cheap.

If AI can build anything, do we still need PMs and designers?

Yes — and collapsing everyone into a single 'builder' role is a real mistake, not a liberation. Using a tool doesn't make you a domain expert: writing code no more makes you an engineer than using a spreadsheet makes you a finance person. Each discipline carries hard-won best practices that quietly get abandoned the moment 'I built something that works' becomes the only bar. Roles are getting more fluid — designers write code, PMs are technical — but functional expertise doesn't disappear, it just stops being fenced off by title.

Should we abandon PRDs and just prototype everything now?

No. The 'PRDs are dead, prototypes are in' framing confuses the medium with the goal. A document is still the right tool when you need conceptual clarity on a vague problem; a prototype is right when you need to stress-test an interaction. The real failure is picking whichever medium is easiest for you personally — engineers writing docs nobody reads, non-engineers jumping straight to a build — instead of the one that fits the point you're trying to make.

How do I tell whether a feature failed because it's bad or because the model wasn't ready?

This is one of the most important judgment calls in AI-native product work, and it's genuinely hard. The tell is whether the failure was about the feature's shape (people didn't want it, the flow was confusing) or its ceiling (the idea was right but the underlying model couldn't do the task reliably yet). Shape problems are yours to fix; ceiling problems just need you to re-test the same feature, unchanged, after the next capability leap. The same feature can flop one quarter and succeed the next with nothing changed but the model underneath it.

Should we reduce engineering headcount now that agents write most of the code?

Almost certainly not yet — and maybe not at all. The industry data shows output rising much faster than delivered value because verification, not generation, is now the bottleneck; cutting the people who verify makes that gap worse, not better. The teams doing well redeploy the freed capacity into bigger scope: more products, more depth, faster response. And announcing cuts has a second cost — people who fear replacement stop sharing their best workflows, which quietly kills the leverage you were counting on.

Do we still hire junior engineers?

Yes — but you have to redesign what a junior does, because the low-stakes code they used to cut their teeth on is exactly the work agents now do first. The new apprenticeship is verification-first: juniors review agent output while a senior reviews their reviews, own small real changes with a limited blast radius, and rotate through the team's agent tooling. Teams that stop hiring juniors are quietly deciding to have no senior engineers in five years.

How big should an engineering team be now?

The durable unit is a pod of two to four engineers plus their agents, owning an outcome rather than a stream of tickets. Two to four because verification needs a second pair of human eyes and judgment needs a sparring partner — but coordination overhead is now the dominant cost, and agents removed the old reason to add more people (raw parallel typing capacity). The organization doesn't have to shrink; each pod just carries much more scope.

What AI is doing to work — Claude for Humans

Every other topic on this site tells you how something works. This one is different: these are arguments, not instructions. The pieces below take positions on what agentic tools are doing to careers, to product work, and to how teams are organised — and they are written to be argued with. Read them as informed opinion you can push back on, not as a manual.

Three of them share a spine. Will AI take my job? makes the case that jobs never get automated, tasks do, and gives you a way to sort your own week. Taste is the new bottleneck argues that once building anything is cheap, the scarce skill flips from making things to choosing which thing was worth making. Engineering team structure in the AI era follows the same logic into the org chart, and asks what shape a team takes when its founding constraint disappears. The common claim across all three is that the bottleneck has moved — away from producing work, toward judging it, choosing between options, and being answerable for the result. You can disagree with that; plenty of thoughtful people do. But it is the thesis, and it is worth knowing you are reading it.

One entry here does not belong to that conversation, and it would be dishonest to pretend otherwise. Answer Engine Optimization — along with the AEO term in the glossary section — is tactical marketing content about how AI search is changing which content gets seen and quoted. It is filed here because it is about AI reshaping a kind of work, but it is a practical how-to for people who publish, not a view on the future of employment. If you work in marketing or content it is probably the most immediately useful thing on this page; if you do not, skip it without guilt.

None of this will tell you what to do on Monday morning. For that, the how-to topics are the right place to be. What this material is good for is calibration — deciding how much of the noise to believe, where to spend your attention over the next year, and which arguments you actually find convincing once someone has laid them out properly.

The words

AEO Answer Engine Optimization · Generative Engine Optimization · GEO: AEO (Answer Engine Optimization) is writing your content so AI answer engines — ChatGPT, Claude, Perplexity, Google's AI Overviews — quote it directly when someone asks a question. Where classic SEO competes to rank in a list of blue links, AEO competes to be the answer the AI reads out. In practice that means answer-first writing, clear structure, real FAQ-style Q&A, and machine-readable facts a model can lift verbatim.

The words

Read more