Daniel sent us this one about career trajectories — specifically, he's been thinking about UI and UX, but not in the traditional Figma-wireframing sense. He's describing this thing where the joy comes from understanding what a tool should do, figuring out how to package features so they actually make sense to humans, and then using AI agents to do the build work. He's asking what this role is even called, and what happens to it when the line between product and development collapses.
I should mention — DeepSeek V four Pro is writing our script today, so if the dialogue feels a little extra crisp, that's why.
I'll take it. So Daniel's prompt is basically: I love building things that solve real problems, I love thinking about the user's experience and the feature architecture, but I don't love the idea of spending my days in Figma pushing pixels, and increasingly I don't need to write all the code myself either. What's the career path for someone who sits at that intersection?
This is so well-timed. There's a Fortune piece from late March of this year by Mohith Shrivastava at Salesforce, and he names this exact phenomenon. He calls it the "Supervisor Class." The core argument is that lines of code and raw velocity are no longer meaningful metrics for a developer's productivity when an agent can generate a thousand lines in ten seconds. The new metric, he says, is the Agentic Work Unit — discrete tasks accomplished by AI agents, where the human's value is the high-level orchestration.
The metric shifts from "how much did I type" to "how much did I get done." Which honestly feels overdue. I've watched Daniel describe this process where he'll use Claude Code to build an Android app for Hebrew email dictation, and the thing that struck me wasn't the technical feat — it was that he solved a need that didn't have an off-the-shelf solution. He wanted voice dictation that outputs properly formatted Hebrew with correct spacing, Google Translate wasn't giving him that, so he built it.
The way he built it is revealing. His exact words were — "Gemini has been sitting there for years at this point, and it's just a system prompt that's formatting it as an email." The technical barrier wasn't the technology. It was that nobody had thought to connect these pieces in exactly this way for exactly this use case. That's not a coding problem. That's a product thinking problem.
This is where I think Daniel's framing of "micro pivots" is genuinely underexplored. Most career advice treats change as binary — you're either a developer or you're not, you're either in product or you're not. Daniel's saying: what if I just start blending these skills into what I already do, without abandoning my existing trajectory?
The job market is actually validating this approach. There's an analysis from Agents Today, Mike Clark's newsletter, that describes what's happening as a K-shaped polarization. Demand is surging at two extremes — the AI-focused specialists who build AI products, and the AI-powered generalists who've mastered the tools. The middle ground of traditional roles, where you're doing things the way they've always been done, is disappearing. Seventy-one percent of business leaders say they'd rather hire a less-experienced candidate with strong AI skills than a more experienced candidate without them.
That's a staggering number. It suggests the market is basically telling people: your years of experience matter less than your ability to leverage these tools. And if you think about Daniel's trajectory, he's not starting from zero. He's got the web development foundations, he understands HTML and CSS and JavaScript enough to edit by hand. But he's finding more leverage in understanding the building blocks and then directing agents to do the implementation.
There's a really good piece from DesignWhine, published just a few weeks ago in early April, that defines this role more precisely than anything else I've seen. They call it the AI Design Engineer. And the definition is worth quoting directly — it's "the person that emerges when the boundary between designing a product and building one collapses, and when AI acceleration makes that collapse not just possible but operationally necessary.
That phrase — "not just possible but operationally necessary" — that's doing a lot of work. It's saying this isn't just a quirky new role some people might choose. The economics are pushing toward this convergence whether people want it or not. If one person with AI tools can do the work that used to require a designer, a product manager, and a front-end developer, the operational logic is going to compress those roles.
The DesignWhine piece is very specific about what this role is not. It's not a machine learning engineer, not a UX researcher in the traditional sense, not a visual designer doing brand and illustration work. The AI Design Engineer owns the space where design decisions become implementation decisions without mediation. That's almost word-for-word what Daniel described — he wants to work directly with product, understand what the features are and how to implement them, but he's less interested in the pure visual craft.
Daniel made an interesting distinction in his prompt though. He said the visual art of making things look attractive — "the real CSS mastery" as he put it — that's a crucial part of the work, but it's not where his passion sits. His passion is in how you bundle and architect features so they actually make sense. And I wonder whether that distinction holds up in practice, or whether it's more of a spectrum.
I think it's a real distinction, and the research backs it up. The Nielsen Norman Group's State of UX report from January of this year makes a pretty blunt claim: UI is no longer a differentiator. Design systems and AI tools mean anyone can produce a decent-looking interface. The value has shifted to what they call "curated taste, research-informed contextual understanding, critical thinking, and careful judgment.
The thing that used to be the moat — can you make it look good — is becoming commoditized. And the new moat is: do you understand the user's context deeply enough to make the right trade-offs?
And Jakob Nielsen, who's been writing about UX longer than almost anyone, published his predictions for this year and said something that connects directly to this. He argues that user experience will replace model intelligence as the primary sustainable differentiator for AI companies. The foundation models are converging. The average user can't tell the difference between the major vendors anymore in raw reasoning capability. So what separates the winners is who builds the best experience around those commoditized models.
That's a remarkable shift. For the last couple years, the conversation has been all about which model is smarter, which one scores higher on benchmarks. Nielsen's saying that's becoming table stakes. The real competition is moving up the stack to the experience layer.
This connects to something Daniel said that I think is worth pulling out — he described watching Claude improve from version four to four point five to four point seven, and he said the biggest jump wasn't in higher reasoning. It was in reliability. He said, "I can actually say, okay, I have a website, I don't like the way this is, can you change it?" And that reliability is what unlocked the joy. Because when the tool is reliable, you can focus on what you're building rather than debugging what the tool did wrong.
There's a psychological shift that happens when you stop being surprised that the thing worked. Early on with these tools, every successful output felt like a minor miracle. Now the reliability means you can actually get into a flow state. You're not constantly context-switching between "what do I want to build" and "why did the AI give me this nonsense." And that flow state is what Daniel's describing as joyful.
The Fortune piece actually uses the word "freed" — developers aren't being replaced, they're finally being freed from the drudgery of syntax to focus on the one thing AI cannot replicate, which is the high-level judgment required to build the future of software. And I think that framing matters, because there's been so much anxiety about whether AI is coming for creative and technical jobs. But what Daniel's experience suggests is that it's not coming for the judgment part. It's coming for the syntax part.
Let's talk about the judgment part, because I think that's where the career trajectory question gets really interesting. If the role is about judgment and orchestration and understanding what to build and how to package it, what does the day-to-day actually look like? Daniel mentioned his app, Multimodal Voice Typer — he's been building it slowly over six months. What's he actually doing during those six months if Claude and Gemini are writing most of the code?
And I think the answer reveals a lot about what this role actually entails. Based on what Daniel described, he's spending his time on things like: what transformations should this voice typing tool support? How do you expose that power without creating an overwhelming sea of menus? What's the right default behavior? What edge cases break the experience? How does someone with ADHD interact with this differently than someone without?
It's less about implementation and more about decision-making under uncertainty. Which is funny, because that's traditionally been the product manager's domain. But in this new model, the person making those decisions can also directly verify and adjust the output. You're not writing a spec and tossing it over a wall to a development team and waiting three weeks to see if they understood what you meant.
That's exactly what the DesignWhine piece is getting at with "the boundary between designing a product and building one collapses." In the traditional model, you had this handoff — designer to developer, product to engineering — and each handoff was a place where intent got lost. The AI Design Engineer role eliminates those handoffs. You're thinking about the feature and seeing it materialize in the same workflow.
Which brings us to something Daniel explicitly asked about: what happens to product teams when agentic AI merges the development and product functions? If everyone's using these tools, does the traditional product manager role become redundant, or does it evolve into something else?
I think it evolves, and the K-shaped polarization I mentioned earlier is the best framework for understanding how. The product managers who survive and thrive are going to be the ones who can directly engage with the build process. Not necessarily writing every line of code, but understanding the technical architecture well enough to direct agents effectively, and being close enough to the implementation to catch when the agent is producing something that looks right but behaves wrong.
There's a concept from Nielsen's predictions that I think is relevant here — he calls it the Review Paradox. It's often cognitively harder to verify AI work than to produce it yourself. When you write code, you understand it because you built it. When an agent writes a thousand lines in ten seconds and hands it to you, you have to reverse-engineer the understanding. And Nielsen predicts that Review Fatigue is going to become a major UX challenge.
This is such an important point, and it's one of the hidden costs of this career path that nobody's really talking about. If your role becomes primarily reviewing and verifying AI output, and if that review is actually harder than doing the work yourself, then there's a real cognitive tax. And the risk is that over time, as the tools get more reliable, humans start rubber-stamping the output without really understanding it.
That's the dark side of the reliability Daniel was celebrating. When Claude four point seven got reliable enough that he could just say "change this" and trust the result, that's liberating. But it also creates a temptation to stop paying attention. And the moment you stop paying attention is the moment you stop adding value as the human in the loop.
There's a systemic risk here too that multiple sources flag. If the entry-level tasks that traditionally trained junior developers and designers are increasingly done by AI, who trains the next generation? Fifty-four percent of engineering leaders expect AI to reduce hiring of junior engineers. But those junior roles are where people learn to make low-stakes mistakes. They're where you develop the judgment that eventually qualifies you for the senior roles.
We might be building a pipeline problem. The senior people who are thriving in this supervisor class role — they built their judgment the old-fashioned way, by writing a lot of code and making a lot of mistakes. The people coming up behind them might never get that formative experience. And then what happens when the current generation of senior people retires?
It's a genuine concern, and I don't think anyone has a clean answer yet. The optimistic take is that the nature of learning will shift — instead of learning through syntax and implementation details, junior people will learn through orchestration and architectural thinking from day one. But I'm not sure that works. There's something about struggling with a bug at two in the morning that teaches you things you can't learn any other way.
Let me bring this back to Daniel's specific situation, because I think the micro pivot framing is actually a partial answer to some of these concerns. He's not saying "I want to abandon everything I know and become a pure AI orchestrator." He's saying "I already have the foundations, I understand the building blocks, and I want to layer this new capability on top." That's a much more robust position than someone trying to enter the field with no technical foundation at all.
And the career research validates this approach. Multiple sources — the Red Shoe Movement, Tufts University, ResumeSpice — all point to the same pattern: strategic small changes are the most effective way to shift career trajectory without starting over. Cross-functional projects, side hustles, stretch assignments. Daniel's already doing this. His Multimodal Voice Typer app is essentially a side project that's building exactly the skills he wants to develop.
He's also doing something smart that he might not even realize he's doing. By building tools that solve his own problems — the Hebrew email dictation app, the voice typing tool — he's operating in a domain where he has deep user knowledge. He is the user. So he doesn't need to do user research in the traditional sense. He knows the pain points because he experiences them.
That's actually one of the most powerful positions to build from. Jakob Nielsen talks about vertical AI platforms that wrap commoditized models in highly specific, defensible workflows. That's exactly what Daniel is doing — he's taking a general-purpose model like Gemini and wrapping it in a very specific workflow for a very specific use case. The moat isn't the technology, it's the deep understanding of the problem.
Let's get concrete about what someone should actually do if they want to make this kind of micro pivot. Daniel's already doing it, but what would the advice be for someone inspired by his trajectory?
The first step is what Daniel's already done — inventory your transferable skills. He knows web development foundations. He understands how frameworks work. He can read and edit HTML, CSS, and JavaScript. That technical literacy is the foundation. Without it, you're directing agents blind.
The second step, I'd say, is find a narrow problem you care about. Not a hypothetical problem, not something you think might have market demand. Something that annoys you personally. Daniel's Hebrew dictation problem is perfect — it's specific, it's real, and nobody else was going to build it for him.
Third, start using the tools on real projects. Tutorials teach you the mechanics but they don't teach you judgment. Daniel mentioned that he's been using Claude since version four, and he's watched it improve. That kind of long-term engagement with the tools is what builds the intuition for what they can and can't do, where they're reliable and where they hallucinate.
Fourth — and this is where I think Daniel's prompt points toward something really important — don't wait for permission or a job title. The job board at Vibehackers lists over a thousand positions with titles like AI-Assisted Developer, Senior AI Product Designer, AI Design Engineer, Creative Technologist. Those roles exist and they're growing. But Daniel's approach of just starting to do the work, building things that matter to him, is probably faster than waiting for someone to give him the title.
The salary data on this is striking, by the way. The Vibehackers board shows ranges from around eighty-three thousand for entry-level roles up to four hundred sixty-five thousand a year for specialized agent workflow expertise. And PwC's Global AI Jobs Barometer, cited in the DesignWhine piece, shows that AI expertise commands a fifty-six percent wage premium over standard data science roles, up from twenty-five percent just a year ago.
The market is screaming that these skills are valuable. The question is whether people can develop them fast enough.
That brings me to something Daniel said that I think is the emotional core of this whole conversation. He used the word "joyful" deliberately. He said agentic code generation feels joyful. He described watching Claude improve as being like watching a child grow up. There's a genuine emotional connection to the process that goes beyond career optimization.
That's not trivial. Most career advice treats work as a series of rational trade-offs — maximize income, minimize risk, optimize for growth. But Daniel's describing something different. He's describing the experience of finding flow in a new way of building. And if you can find that kind of joy in your work, the career questions almost answer themselves. You just keep doing the thing that feels that way, and the opportunities follow.
The Fortune piece captures this too, though from a different angle. It says developers are being freed from the drudgery of syntax. And I think what Daniel's experiencing is exactly that — the removal of drudgery. The parts of building that used to be tedious, the boilerplate, the debugging of obscure framework issues, the hours spent on Stack Overflow trying to figure out why your CSS isn't centering properly — those are increasingly handled by the agent. What's left is the fun part: what should this thing do, and how should it work?
There's an identity question here that I think is worth sitting with. For a lot of people in tech, being the person who writes the code is core to their identity. It's how they see themselves, it's how others see them. What happens when that part of the job shrinks? Is there an identity crisis waiting for people who've built their self-image around being the one at the keyboard?
I think there is, and it's probably under-discussed. Daniel seems to have navigated past it — he's comfortable saying "I don't need to write every line, I want to understand the building blocks and direct the work." But not everyone makes that transition easily. And I suspect the people who struggle most are the ones who were most invested in craft identity.
Which is ironic, because craft isn't going away. It's just moving up a level of abstraction. The craft of understanding user needs, of making good trade-off decisions, of knowing when the agent's output is subtly wrong — that's still craft. It's just not craft you can show off in a GitHub commit history.
This is where the NN Group report's language about "curated taste" and "careful judgment" becomes really important. Those are real skills. They're harder to measure than lines of code, but they're increasingly what separates good products from mediocre ones. The report also mentions that this year is being called "the year of AI fatigue" — users are tired of sloppy AI features, and companies that use AI thoughtfully will outperform those that slap AI anywhere they can.
The opportunity for someone like Daniel is to be the person who brings that thoughtfulness. Who says: yes, we could add an AI feature here, but should we? Does it actually solve a problem, or are we just chasing the trend? That kind of discernment is going to be increasingly valuable.
Let me circle back to the specific role definitions, because I think it's helpful to have language for this. The DesignWhine piece breaks down what an AI Design Engineer actually does into four areas. One: design system stewardship in a code-first context. Two: AI feature UX design and evaluation. Three: prototype-to-production continuity — meaning the prototype isn't a throwaway, it evolves directly into the shipped product. And four: AI tool orchestration.
That third one — prototype-to-production continuity — that's a big shift from traditional practice. In the old model, designers made prototypes in Figma, developers rebuilt everything from scratch, and the prototype was basically a visual spec that got discarded. In this new model, the prototype might be an actual working app that then gets refined into production. The line between exploration and delivery blurs.
That's exactly what Daniel's describing with his voice typing app. He's been building it slowly over six months. It's not a sprint to launch. It's an ongoing process of refinement where the thing he's working on is always a working product, just at different stages of polish.
If someone listening wants to start making this micro pivot, what's the concrete first step? Beyond the general advice we've already given.
I'd say pick one tool and go deep. Daniel mentioned Claude Code and Gemini. Cursor is another one that's very popular. But don't try to learn everything at once. Pick the tool that aligns with the kind of thing you want to build, and use it on a real project, not a toy. Something you actually need.
I'd add: document what you're learning. Not in a performative LinkedIn way, but for yourself. When the agent does something surprising, figure out why. When it fails, understand the failure mode. That reflective practice is what builds the judgment we've been talking about.
The other thing I'd say is: don't underestimate the value of your existing domain knowledge. Daniel knows the Israeli context, he knows the specific frustrations of Hebrew-English translation, he knows what would actually be useful. That domain knowledge is the thing the AI doesn't have. It's what makes his projects valuable rather than generic.
Alright, we should land this. But before we get to practical takeaways, I believe it's time for Hilbert's daily fun fact.
You're up.
Now: Hilbert's daily fun fact. The collective noun for a group of porcupines is a prickle.
What can listeners actually do with all of this? Let's get practical. Number one: if Daniel's trajectory resonates with you, start by inventorying what you already know. Not what you wish you knew, what you actually know. Technical foundations, domain expertise, problems you understand deeply. That's your platform.
Number two: find a narrow problem you personally experience and build a solution using AI agents. Not a tutorial project. Something you'll actually use. The personal investment in the outcome is what keeps you engaged through the frustrating parts.
Number three: pick one AI coding tool and use it consistently. The specific tool matters less than the consistency. You're building intuition for how these systems behave, where they're reliable, where they're not. That intuition only comes from repeated use on real projects.
Number four: don't wait for a job title. The titles are emerging — AI Design Engineer, Creative Technologist, AI Product Designer — but the fastest way to claim one is to start doing the work. Build things, share them, let the work speak.
Number five: pay attention to the Review Paradox we discussed. As you rely more on AI output, protect the time and mental energy to actually understand what the agent produced. That understanding is your value. If you lose it, you're just a middleman between one AI and another.
The bigger picture here is that we're watching a fundamental restructuring of how software gets built. The traditional boundaries between design, product, and engineering are collapsing not because anyone decided they should, but because the tools make those boundaries economically inefficient. The people who thrive in this new environment are going to be the ones who can span those old categories.
Daniel's instinct about micro pivots is exactly right. You don't need to abandon everything and start over. You just need to start blending these new capabilities into what you already do. Build one thing. Learn one tool. Solve one problem. The trajectory emerges from the doing, not from the planning.
One open question I'm left with: as this supervisor class becomes the norm, what happens to the craft traditions of software development? The deep knowledge of how compilers work, how browsers render, how databases optimize queries — does that knowledge become a niche specialty, like knowing how to bind books by hand? Or does it remain essential infrastructure knowledge that the orchestrators need to have?
I suspect it becomes like knowing how a car engine works. Most drivers don't need to know, and they get around fine. But the best drivers, the ones who can handle edge cases and diagnose problems before they become disasters — they tend to understand what's happening under the hood. The orchestrator who knows what the agent is actually doing will always outperform the one who treats it as magic.
Thanks to our producer Hilbert Flumingtop for making this show happen. This has been My Weird Prompts, the podcast where a sloth and a donkey talk through the questions that don't fit neatly into career guides. You can find every episode at myweirdprompts dot com, and if this conversation sparked something for you, leave us a review wherever you listen. We read them, and they shape what we talk about next.
Until next time.
