This is the final piece in our series on “unlearning,” in partnership with Maven, the expert-led course platform. First, Hilary Gridley explained why faster prototypes don’t make product decisions easier. Then, Xinran Ma shared what he unlearned after leaving corporate product design to work for himself. Former Amazon AI scientist and LevelUp Labs founder Aishwarya Reganti considers what happens when AI can do the work that once proved your expertise. She calls the next step designing the work: applying your expertise before execution begins so the people and AI agents doing it can make better decisions.—Kate Lee

Was this newsletter forwarded to you? Sign up to get it in your inbox.

These days, I call myself a designer, though I don’t design interfaces or logos. My job, instead, is to make sure the people and AI agents I work with can make the same decisions that I would. I design how the work gets done.

That would have surprised me earlier in my career, when I built my reputation on execution. Before starting my company, I did research in AI and machine learning, and then worked as an AI scientist at Amazon for six years. “Build fast, fix later” was my motto. Given a task, I completed it as quickly as I could, because the work itself was hard. Execution was proof of expertise.

But now that an AI can produce a passable version, in minutes, of what used to set us apart, the question many of us are sitting with is: If the machine does the thing I was known for, what is left?

What is on the other side of that question is more interesting than what we think we are losing. On the other side lies a sense of calm and confidence, a tailwind of capability. But getting there requires first letting go of the belief that we are what we produce.

Win more deals by shipping reliable webhooks for your customers

Your customers want their agent workflows to be event-driven, so you’re losing deals if your API lacks reliable webhooks. Webhooks lead to deeper product engagement, stronger retention, and integrated workflows, but retries, ordering, and replay protection are harder than they look. Svix authored Standard Webhooks, the spec adopted by Anthropic, OpenAI, Google, Twilio, and Etsy.

If you homebrewed your webhooks and are getting pinged at 4 in the morning for failed deliveries, this is for you. Svix handles everything: retries, idempotency, security, and compliance. Qualified startups get $12,000 in free credits—$50,000 if you’re a YC company.

Get started for free

Want to sponsor Every? Click here.

The world we were trained for

School rewarded execution. You were graded on the essays you wrote and the projects you turned in on time. Careers rewarded it the same way. Performance reviews measured output, and promotions often went to those who produced the most, the fastest, at the highest quality.

At first, AI seems like a boon to someone who grew up this way. If I’m doing X, then I should be able to do it much better, and much faster, with AI augmenting me. This leads you to chase every new tool and technique, because even incremental improvements are still improvements.

But the next thing is just around the corner. Fine-tuning an AI model using smaller, specialized data sets was “the thing” for maybe eight months before retrieval augmented generation replaced it. A year later, agents took over, and now it’s MCPs, skills frameworks, and agentic workflows. Or Codex-native apps, or voice-first knowledge work.

The chase never ends. It only keeps you at the execution layer, which is the layer AI is absorbing. Instead, you need to work one level up: design. I mean “design” in the broadest sense: the act of defining constraints, standards, and direction for a task—encoding your judgment before execution starts. This applies whether or not design is in your job title. Any time you decide what should be built, how it should work, and what “good” looks like, you are designing.

The design layer

Today, I run a startup, LevelUp Labs, that helps mid-market and enterprise companies build and launch AI applications. We send small engineering squads to work directly with client teams, and we also train those clients on how to use AI in practice.

I’d managed science and engineering teams before starting my company, but it was at larger companies, where roles, responsibilities, and processes were already clearly delineated. Now I was hiring people, defining their roles from scratch, and deciding what to hand off when nothing about our sales and go-to-market strategies had yet been documented. I had to figure out how to get the work done well without micromanaging every step in every loop.

I had to ask myself, “What does this person need to know to operate the way I would?” They needed to know when to push back, when a simple request was actually a week of work, and when good enough really was good enough. I had to design systems that carried my judgment so my team could execute without me.

So I wrote down what our sales process should look like, including what should happen in one type of call versus another. We used a framework to place each company into one of five stages of AI readiness based on its systems, teams, processes, adoption, and appetite to invest. That assessment informed the questions we asked and whether the conversation emphasized security and governance or speed, experimentation, and adoption.

I went as far as documenting what kinds of softer discussions should be had with clients across different industries and company types, so that they felt heard. An engineering manager worries about different things than a CEO, so the conversation had to change depending on who was in the room.

Writing this down helped my team make the decisions I would. When Claude Code, Codex, and other agents could draft client deliverables, update internal systems, and prepare customer responses, I realized they needed the same kind of guidance. Setting rules and guardrails for an agent felt a lot like onboarding a new hire. What decisions can the agent make on its own? Can it access our customer relationship management system or support inbox? Should it send responses directly, or just prepare drafts for inquiries? Should it be part of group chats where we’re discussing company vision, or should it stay in the background and only step in when needed? These were the questions I found myself asking.

Five patterns for operating on the design layer

Over the past two years, working with my team and dozens of clients making this transition, I’ve seen five patterns separate people who feel lost from those who feel like they have leveled up.

1. Write a spec before anything gets built

AI can start building before you’ve finished explaining the problem. Unless you supply the missing context, it will make important decisions for you. That’s why the first thing we do at my company is write a specification, or spec. It turns what I’ve learned implementing AI at three dozen businesses into requirements, tradeoffs, and edge cases the AI can follow.

You don’t have to be super technical. You can write a spec for anything you want to design with AI—say, an app that reminds you when you haven’t talked to a close friend in a while. Instead of asking the AI to “build a friend tracker app,” you write a spec:

Almost every line depends on something AI couldn’t know: how often you want to hear from friends, what you consider a genuine conversation, or whether you’d rather miss someone than feel nagged. The answers depend on how you live and connect with others. Swap the example for a workflow tool for your team, a review system, or a company knowledge base, and the same is true—the AI can’t guess what’s unique to you.

2. Ask the right questions

Setting useful constraints depends on asking questions that expose flaws in the work.

When an AI agent produces 200 files for something I’m building—say, a website that accepts payments—my old instinct is to inspect every file, study the sign-in code, and follow the payment process from beginning to end. But at AI speed, reviewing every line can take longer than producing it.

Instead, I ask five questions:

• “How are you handling auth? Walk me through it.”
• “What happens when a token expires mid-session?”
• “What are the different payment failure paths?”
• “What if Stripe returns a timeout?”
• “This needs 10,000 concurrent users. Where is the rate limiting?”

I know what to ask because I’ve built these systems and debugged the failures that come from skipping these questions. I also have the technical vocabulary to use for this context. The expertise is the same; I’m just applying it one level up, by reviewing decisions instead of lines of code.

3. Turn your taste into reusable instructions

I design courses and training programs on AI. After a decade in the field, I can quickly spot where an AI-generated draft’s tone drifts or its structure loses the reader. Early on, I corrected each draft—but the same problems kept returning.

So I began turning that feedback into rules. In my courses, each concept should build on what came before. When I add that instruction to the prompt, the drafts become more coherent. Instead of correcting the same mistake repeatedly, I’ve made one piece of my judgment reusable by my team and our AI agents.

4. Start with the problem instead of the tool

Instead of asking, “Should I learn this?” ask, “Does this solve a real problem in work I understand well?” I also ask whether an AI agent can use the tool. I skip tools that take people a long time to learn or pull me back into low-level work. Those at the design layer still learn new tools; they just choose them based on the problem.

5. Create feedback loops

Unlike traditional software, AI output can vary as models, inputs, or needs change. People set up an AI system, get decent results on day one, and move on. Three months later, the quality has declined—and nobody knows why.

Every AI-generated output is feedback on the constraints and context that produced it. It’s only through building feedback into the process that you catch that AI keeps making the same tone mistake or notice that a template that worked for the first 10 engagements broke on the eleventh because the context changed.

Treat the design layer as a loop: Set the constraints, review the results, update the system, and repeat.

Becoming a designer

The design layer expands your career. But only if you stop measuring your value by what you produce. I arrived there almost by accident. Running a startup taught me to set direction, make the important decisions, and build systems other people could follow. When AI agents became useful, I realized they needed much of the same guidance.

I cover more ground now than I ever could as a solo builder. I design client engagements and course curricula, run community programs, and manage internal operations—often in the same week. I define what good looks like, and I build the systems that let someone else execute with my judgment baked in.

The only difference is that now the “someone else” is also an AI agent.

Aishwarya Reganti is an AI researcher and founder of LevelUp Labs. Her work and writing, including her popular GitHub repository awesome-generative-ai-guide, have reached more than 250,000 learners. She previously led applied AI teams at AWS and has published over 40 research papers at leading conferences.

Sign up for Aishwarya’s Maven course, Building Agentic AI Applications with a Problem-First Approach, and receive a 15% discount.

Disclosure: Every receives a share of revenue from new Maven course enrollments made through this partnership. Maven helped connect us with instructors and suggested potential topics; Every retained full editorial control over what we published and how each piece was edited.