I keep coming back to the same question lately: what is your title?
It should be simple. It is one of those basic questions people ask when they are trying to place you in their head. Developer. Agency owner. Operator. Marketer. Strategist. AI guy. Systems person. WordPress person. Trades guy. Founder. Whatever.
The problem is that none of those are wrong. They are also not right.
That is the part that has been bothering me. Not because I need a better label for LinkedIn. I do not care about that as much as I probably should. It bothers me because the work itself has changed, and the language around work has not caught up. That is why the conversation around AI job titles feels so broken.
People are still asking title questions from the old map, but the terrain is different now.
The work changed, and the titles did not. The useful person now is the one who can combine judgment, tools, communication, and shipping discipline when the old labels stop fitting.
Key takeaways
- Old titles describe narrow roles. The current work crosses too many lines for that.
- AI capability is not the same as engineering judgment earned through consequences.
- The tool stack is multiplying faster than the language around the work.
- The valuable person is the bridge between code, business, agents, systems, and reality.
- The title matters less than the ability to carry context, protect quality, and ship without creating cleanup.
Everybody wants everything
This is the part that feels a little insane: everybody wants everything right now.
Clients want speed, strategy, implementation, communication, automation, reporting, and someone who can explain what is happening without turning it into a seminar.
Companies want engineers who can code, understand the business, manage the AI tools, think about security, talk to clients, clean up legacy systems, document the work, and not create a disaster for the next person.
Business owners want AI, but they do not always know what they mean by AI. They want agents, automations, dashboards, workflows, assistants, faster shipping, fewer people, more output, and some kind of layer that makes the operation feel less heavy.
Developers want tools that make them faster, but they also want the tools to understand context, respect the codebase, avoid dumb changes, and not leave them cleaning up a pile of confident mistakes.
Everyone is asking for the same thing in different language: make this whole mess work. That is not one traditional role. It is not cleanly “developer.” It is not cleanly “operator.” It is not cleanly “consultant.” It is not cleanly “AI engineer.” It is technical execution, business judgment, communication, risk management, and the ability to keep moving when the situation is not perfectly defined.
That is the work now, and the titles are still acting like everything fits in one department.
AI capability is not the same as judgment
The easy divide is “uses AI” versus “does not use AI.” I think that is the wrong divide. The more important divide is experienced people using AI with judgment versus people using AI without the hard lessons yet.
That sounds harsh, but I do not mean it as an insult. Everybody starts somewhere. New people using AI can move faster than new people could move ten years ago. A motivated person can build, write, research, code, design, and prototype at a speed that used to be impossible.
But speed is not the same as understanding.
If you have been doing this kind of work for twenty years, you carry a lot of scar tissue. You know what breaks. You know which shortcuts turn into expensive cleanup. You know when a clean demo is hiding a fragile implementation. You know when the request is not the real problem. You know when the client is using the wrong words. You know when a tool is producing something that looks polished but does not belong in production.
That experience changes how you use AI. You do not just ask it to make stuff. You direct it. You constrain it. You review it. You know when to trust it, when to challenge it, when to throw the output away, and when to slow down.
That is the difference. AI gives new people reach they did not have before. Experience gives AI users brakes they did not know they needed. Both matter, but only one of them keeps you from shipping a mess that someone else has to fix.
AI gives people reach. Experience gives them brakes. Both matter, but only one keeps speed from becoming cleanup.
The tools are multiplying faster than the titles
The tool stack is not the point, but it is part of the picture.
I am using OpenClaw, Hermes, Discord, Claude Code, Codex, Cursor, CommandCode, Minimax, and whatever else makes sense for the job. There are command line agents, chat agents, background agents, browser workflows, local files, Obsidian notes, GitHub issues, and more weird connective tissue than any normal person should have to explain.
Then you add the next layer: hyperagents, orchestration, local runtimes, remote agents, tool permissions, memory, context, review loops, and all the practical problems of letting software do more work without letting it make a bigger mess. That is the same reason every agent still needs a human harness.
That is where the title question starts to fall apart.
Am I a developer because I am working in code? An operator because I am designing the workflow? A writer because I am shaping the output? A strategist because I am deciding what should happen next? A manager because I am directing agents? QA because I am checking the work? Security because I am thinking about what should not be exposed? Product because I am deciding what experience the human should have?
Yes. No. Depends what minute you ask.
That is not me trying to sound special. It is the reality of the work. Once agents enter the loop, the person at the center has to carry more context, not less.
Someone has to know what the work is supposed to become. Someone has to know what good looks like. Someone has to know when faster is making the wrong thing faster.
The stack is evidence, not the thesis. The point is that the work now includes judgment, orchestration, review, and responsibility across tools that did not exist a few years ago.
AI job titles are too narrow
Most job descriptions still read like the work is stable. We need a developer. We need an AI person. We need a marketing person. We need someone to manage operations. We need someone to build automations. Fine. Those needs are real, but the real need is usually messier.
You need someone who can sit between the business owner, the client, the codebase, the AI tools, the security concerns, the customer experience, the timeline, and the part nobody has admitted yet. You need someone who can hear a vague request and figure out what job is hiding underneath it. You need someone who can use AI without treating it like a vending machine.
You need someone who can ship without turning every task into a research project or pretending the consequences do not exist. You need someone who can explain technical tradeoffs in human language. You need someone who knows when the answer is code, when it is copy, when it is process, when it is a conversation, and when the right move is to do nothing yet.
That does not fit cleanly into a title. It fits into a pattern: see the problem, understand the context, use the tools, protect the quality bar, and ship the thing.
The cleanup problem is the part people miss
This is where I get annoyed. A lot of the AI conversation is still stuck on output. How fast can we make the thing? How many drafts can we generate? How quickly can we ship? How many agents can we run at once?
Useful questions, but incomplete. The better question is: who owns the cleanup? Because there is always cleanup.
Bad code creates cleanup. Bad copy creates cleanup. Bad strategy creates cleanup. Bad client communication creates cleanup. Bad AI output creates cleanup. Bad assumptions create cleanup. Systems that look impressive but nobody understands create cleanup.
This is one of those lessons you only really learn by living through it.
The first version is never the whole story. The handoff matters. The next person matters. The maintenance matters. The security implications matter. The business reality matters. The thing you ship becomes part of somebody else’s day.
That is why experience matters so much right now. AI can help you create faster. It can also help you create more cleanup faster. That is not a small problem. If anything, it may be the central problem.
Because the people who can generate output are multiplying. The people who can judge output, integrate it into a real system, and keep it from becoming future debt are still rare. That is why judgment is still the moat.
Output is easy to count. Cleanup is where the real cost shows up.
The useful person is the bridge
I do not think the answer is to invent some shiny new title and pretend that solves it. The useful person now is a bridge: between code and business, clients and systems, agents and humans, speed and safety, old experience and new tools, and what people say they want and what the situation actually needs.
That role is not soft. It is active. It means you can step into the work at multiple levels. You can talk to the owner, open the codebase, brief the agent, write the copy, spot the risk, and decide what needs to happen first. It sits close to what I was trying to name in What Forward Deployment Engineer Means To Me.
That last part matters.
I have very little patience for people who can explain everything and carry nothing. The future does not need more professional narrators. It needs people who can understand the situation and move the work forward.
The title is less important than the carry. Can you carry the context? Can you carry the judgment? Can you carry the work over the line?
Maybe the title is get shit done
I do not know what I would call myself right now. Developer is true, but too narrow. Agency owner is true, but not enough. Operator is true, but too abstract. AI person is true in the dumbest possible way, because everyone is going to be an AI person soon if they are paying attention. Maybe this is just another version of the deep generalist being built the hard way.
Strategist sounds too clean. Consultant sounds too detached. Builder is closer, but still incomplete.
The closest honest answer might be: I get shit done.
Not in the hustle culture way. I mean seeing the whole messy situation, figuring out what matters, using whatever tools fit, and moving something real forward.
Sometimes that is code. Sometimes that is a system. Sometimes that is content. Sometimes that is an automation. Sometimes that is telling someone the request is wrong. Sometimes that is slowing the whole thing down because the fast path is about to create a bigger problem.
That is hard to title, but it is not hard to recognize when you see it.
The work changed
The work changed. The tools changed. The expectations changed. The speed changed. The relationship between one person and output changed. But the labels did not.
We are still trying to describe this moment with titles built for cleaner boundaries. Developer. Designer. Marketer. Operator. Writer. Strategist. Founder. Consultant.
Those words still mean something. They just do not cover the messy overlap anymore.
And maybe that is fine for now. Maybe the point is not to find the perfect title. Maybe the point is to get more honest about the work underneath it.
The valuable people in this next phase are not going to be valuable because their title sounds current. They are going to be valuable because they can combine old lessons with new tools.
They can use agents without outsourcing judgment. They can move fast without pretending speed removes responsibility. They can communicate across rooms. They can protect the work from becoming a cleanup problem. They can see the whole mess and still ship something real.
That is the job, whatever we decide to call it.
