Thariq Shihipar, a member of Anthropic’s technical staff, offers a field guide for finding the context an agent needs before and during implementation:

The difference between the map and the territory is what I call unknowns. When Claude runs into an unknown, it needs to make a decision based on its best guess of what I want. The more work being done, the more unknowns Claude might run into.

Claude Fable is the first model where I find the quality of the work is bottlenecked by my ability to clarify its unknowns.

Importantly, just planning ahead isn’t always enough. You can find unknowns deep in implementation, or your unknowns may point you to the fact that you should actually be solving the problem in a different way altogether.

The design-specific version is tacit judgment: criteria that become visible only after there is something concrete to react to. Shihipar’s recommendation is to use prototypes to surface those criteria while changing direction is still cheap.

When I’m working in an area with a lot of unknown knowns, involving criteria I only know to define when I see it, I like to ask Claude to brainstorm and prototype with me.

It’s extremely valuable to identify and verbalize unknown knowns early during prototyping, because finding them out during implementation can be (relatively) expensive. Small changes in a feature or spec can cause drastically different implementations in code, and it can be more difficult for your agent to revert previous changes.

For example, you may just want to see how a button added to a frame looks without having to wire up a backend route or maintaining additional state in the frontend.

This makes exploration part of specifying the work. The prototype helps the designer discover what the brief could not yet contain, while implementation notes preserve the choices that emerge after the plan meets the code.

The better models get, the more you can achieve with the right approach. When a long-horizon task comes back wrong, it’s likely you need to spend more time defining your unknowns or creating an implementation plan that allows for you and Claude to adapt through them.

Every explainer, brainstorm, interview, prototype, and reference is a cheap way to find out what you didn’t know before it gets expensive to fix.

Karo Zieminski spent nine days breaking Claude Cowork before writing this guide:

I’ve seen enough of shallow tutorials that simply rephrase the official docs to know I wanted to do something different. So I rebuilt some of my workflows from scratch, tracked what failed, measured what saved time, and mapped 56 practical tips into the resource I wish existed when I started.

I appreciate her methodical breakdown of the app, especially when to use which flavor of Claude, which for me TBH, has been an issue.

Zieminski’s nice breakdown of the differences between Claude Chat, Cowork, and Code.

The guide barely talks about prompting. It’s almost entirely about the pre-work: dedicated folder structures, global instructions via CLAUDE.md, chunked skills, delegation patterns that define end-states instead of steps. The distinction Karo draws between Chat skills and Cowork skills:

Skills in Chat were useful. Skills in Cowork are operational. They shape autonomous work. Your brand guidelines skill doesn’t just influence a reply. It governs every file Claude creates. Your writing guidelines skill doesn’t just shape a draft. It governs every article Claude writes autonomously.

Zieminski on skill architecture:

Chunk your skills instead of building one giant skill that tries to handle everything. I’ve tested both approaches and the results from one giant skill were much worse. For example, I use three separate writing skills instead of one: an overall voice skill, a corporate writing skill, and a newsletter writing skill. Each handles its own context. Claude never confuses who I’m writing for.

If you’re already using Claude Cowork or just Cowork curious, bookmark this one.

In Jason Lemkin’s account of SaaStr’s break with Adobe Marketo, the formal cancellation is almost beside the point. SaaStr had already moved most of Marketo’s work elsewhere:

And once you do that once, you start asking the obvious question. We’ve now migrated almost all of Marketo’s functionality onto Salesforce. Not because Salesforce has better features. Because Salesforce has an API our agents can actually use. One day you look up and realize you’re paying $60K a year for a product you’ve already routed around.

That is the new B2B churn motion. It isn’t a feature bake-off. It’s an agent-operability test, and legacy vendors are failing it quietly, one migrated workflow at a time, before they ever show up on the churn report.

I do think this is where a lot of software, especially B2B software is headed. Even in my own day-to-day, I’m loathe to use tools that don’t allow me to connect to one of my AI agents. Zoom out to an enterprise context and now agent operability becomes a product-quality problem that can eventually lead to churn.

Lemkin’s advice:

If you build or run a B2B company, the Marketo story is a checklist of what not to become.

Make your product operable by an agent, now. Not next year. The question is no longer “is our UI good.” It’s “can a customer’s agent do real work against our API without a human babysitting it.” If the answer is no, you are already on a churn clock you can’t see. Webhooks, an SDK, an MCP server, clean auth, real history. This is table stakes in 2026.

Matt Shumer, writer of the viral “Something Big Is Happening” essay, argues that most agent workflows try to prevent mistakes by specifying every move. His Gauntlet Loop takes a different approach: define what good looks like, then let the agents decide how to reach it.

You give a lead agent a goal and a real example of what great looks like. The lead agent decides how to break the goal into the smallest pieces that can be improved separately. Each piece gets its own builder and a separate critic with fresh context.

The builder makes something. The critic compares it against the reference example. If the reference example wins, the critic explains the biggest remaining gap and sends the work back to the builder. The builder fixes it. Then another round begins.

That continues until the result reaches the bar (or, more likely, you decide it is ready).

The agents get specificity about the outcome, not a recipe for producing it. On a design team, one agent could decide how to build a prototype while a fresh critique agent—Shumer calls them critics—compares the result with a reference and an explicit quality bar. Shumer separates the critic so freedom in execution does not weaken the judgment:

The builder and critic should be separate agents.

The builder has seen every decision it made. It remembers why it made them. That makes it very good at explaining why its work is reasonable.

You do not want reasonable. You want an independent judgment.

Spawn a fresh critic and give it the goal, the bar, the relevant rules, and the actual artifact. Do not give it the builder’s history or explanation.

Smarter agents can work with fewer procedural rules when their output remains inspectable. Shumer puts it into practice with a goal, reference, artifact, and independent review.

The startup grind is often the same: ship fast, but maintain a high bar of quality. At least that’s the sentiment. Those things are in opposition and the system incentivizes people to just move on.

Miguel Fernandez, writing for Slack Design, describes why shared standards matter:

Craft is subjective, until it isn’t. Disagreement surfaces the moment you have to define it. Is this interaction good enough? Is this component polished? Without shared standards, these discussions become battles of personal taste rather than principled decisions. You can’t argue craft in a document. You can only experience it.

That makes the quality bar a cross-functional working agreement rather than a designer’s private standard. Fernandez continues:

It seems like craft competes with velocity. Engineering and Product are often rewarded for shipping, not refining. Craft requires slowing down at key moments, which feels costly when measured against sprint commitments. The incentive systems work against craft, but this is a false trade-off: craft debt compounds just like technical debt, and eventually you pay for it in churn, reputation, and the slow erosion of what made your product special.

Fernandez then quotes Linear co-founder and CEO Karri Saarinen on the conditions beyond the individual:

“Craft is the mindset that creates quality. But it’s not enough. You need to have the right skills and ideas. You need individuals who take their profession and craft seriously, then build teams that work this way together, and have a company that creates the conditions for it. Not only incentivizing with deadlines and metrics, but also caring if the experience is good enough.”

Judgment and craft may help a designer survive today’s freelance market. But Madeleine Morley, writing for Fast Company, gives us little reason to believe that either would guarantee economic security.

She interviewed Cari Sekendur, founder of the independent branding and web-design studio Butter.

In Fast Company ’s report, more than half of designers surveyed believe AI is undercutting their rates, and 68% believe it is eroding the value of human creativity.

“Clients now expect more while paying less,” wrote one survey respondent on AI’s effect on the industry. “Many clients are taking advantage of AI to underestimate our professionalism and pricing,” said another.

Morley writes that only 22% of survey respondents reported losing work because of AI. But the lowish number hides a sense that “AI isn’t replacing design, but it is changing how clients perceive it.” A designer can keep getting hired and still lose leverage over what the work pays and demands.

That pressure isn’t distributed evenly. She describes what has happened among illustrators doing smaller jobs:

Eric Carter, an illustrator whose clients include The New York Times, believes the disruption has been most acute at the lower end of the market. “There is this whole gig economy of illustrators doing smaller jobs,” he says from his studio in Los Angeles. “Fiverr was already cheapening everything… the bottom was already pretty low. And then having AI replace that, it just cut it out.”

Carter has been insulated from that shift because, as he puts it, “I get paid to think.” This idea—that a designer’s value is increasingly about their taste and approach as opposed to pure craft or technical ability—reverberates throughout the freelance industry. “You can’t automate taste and creativity,” one survey respondent wrote. Another: “Ideas and taste is what is needed to succeed.” And another: “AI is only as good as the strategy and input.”

Carter’s “I get paid to think” is encouraging, but it comes with a nasty condition. Judgment and recognizable craft offer more protection when clients already know whose judgment they’re buying. I wrote about the same trap in my series on the design talent crisis: entry-level work is how designers develop and prove their judgment, yet it’s the first work the market is stripping away.

Morley concludes:

What is evident across the survey data and multiple interviewers is that the labor of design is increasingly fragmented in today’s creative industry. Designers are forced to sell their labor in multiple markets simply to maintain the same standard of living that they used to and the market is not compensating highly skilled creative work in the way it did even a few years ago.

All of this raises bigger questions. For many years now, the freelance creative has been not only someone who simply sells their craft, but an entrepreneur expected to market themselves and build a personal brand. Diversification and resilience are emerging as absolutely vital and central capacities for freelancers navigating the age of AI. What gets lost in the urgent need to find sources of income and to adapt are questions like: Shouldn’t clients pay more? Why are corporations cutting budgets? The burden, as always, shifts to the individual.