I’d had the kind of week with Artwell where you either ship something or break something, and I’d managed both, occasionally to the same feature. I’d also spent it neck-deep in the debate eating every feed I follow lately: the one about AI and taste, about whether, now that the machine can make the thing, having good judgment is enough to make you a creator – or only a critic. So on Friday, fried on both counts, I took myself out for a steak.

Two tables over, a couple was having an argument, and it took me a full minute to work out what they were arguing about.

She’d said the thing was technically flawless and completely forgettable. He said she was being impossible – it was obviously high quality, look at it. She said quality wasn’t the same as good. He said that was a meaningless distinction. She said it was the only distinction that mattered. He said, and I’m quoting, “everybody’s suddenly an expert.”

It was, almost word for word, the argument I’d been reading all week. So I assumed I was eavesdropping on two people from my own corner of the world – that the debate had followed me out of my screen and into dinner. I was, I admit, a little impressed by their command of the material.

Then he delivered the closer: “If you think it’s so easy, I’d love to watch you cook it better.”

Ah. The steak. They were arguing about the steak.

Here’s the part that stayed with me, past the steak and past the secondhand discomfort of watching a date go sideways over doneness. I hadn’t misheard them. I’d heard them perfectly. The argument about the steak and the argument about AI are, line for line, the same argument. You can swap “the steak” for “the output” in every sentence either of them said and lose nothing at all. That isn’t a coincidence, and it isn’t because steak is secretly profound. It’s because both arguments are circling the same confusion, and neither side has bothered to name it. But I will try.

There are two different things we call “taste,” and they only look like one thing from a distance.

The first is the diner’s taste. You take a bite and you know. Too salty, the texture’s gone rubbery, the sauce is fighting the meat instead of helping it. You don’t need a chef’s jacket to register any of that, and the man’s “I’d love to watch you cook it better” was a bad move precisely because she never claimed she could cook it. She claimed she could tell it was gray in the middle. Those are not the same claim. She was right, and he reached for a credential to avoid admitting it. Anyone who has ever been handed “well, you’re not a chef” while pointing at an obviously overcooked steak knows the move. It’s a dodge. The diner’s verdict stands on its own.

The second is the chef’s taste, and it only shows itself when the plate is wrong and has to be fixed. The diner says “this is too salty.” The chef tastes the same bite and knows the saltiness is actually a fat problem, and the fix isn’t less salt, it’s a hit of acid to cut it. The diner can reject. The chef can correct. The distance between “this is off” and “here is the specific move that makes it right” is the entire job, and it’s the part you only get from having stood at the stove and ruined the dish a few hundred times.

Hold onto that gap, because the AI conversation lives or dies in it.

The loudest story in AI right now is a democratization story, and the optimistic version of it is genuinely true. The barrier to making things has collapsed. Anyone can generate a draft, a design, a working prototype, a passable first cut of almost anything, in the time it used to take to schedule the kickoff meeting. From there the discourse has converged, with remarkable speed, on a single comforting conclusion: since the machine now handles the making, the scarce and valuable thing left to humans is taste. Judgment is the new moat. Curators beat creators. The editor outranks the engineer. There are now four-part courses promising to train your taste in ninety days, as if taste were a certification.

And the first half of that is correct. When generation is free, discernment is what’s scarce, and the person who can tell the good output from the plausible one is holding something real. The couple at the next table had stumbled into the true half: you don’t need to be a chef to know the steak is overcooked.

But watch the move the discourse makes next, because it’s the same move the man made, just run in reverse. He took “you can’t judge it unless you can cook it” – false – and used it to win an argument he was losing. The AI conversation takes “you don’t need to be a chef to judge it” – true – and quietly extends it into “so you don’t need to be a chef to make it.” That sequel does not follow. And the reason it doesn’t follow is that when you build with AI, you are no longer the diner. You’re the one in the kitchen.

Think about what the machine actually is in this arrangement. It’s a line cook with flawless technique and no palate of its own. It will execute anything you can specify, instantly, without complaint, and it will re-plate the identical wrong dish all night because it cannot taste that the dish is wrong. At a restaurant, the diner’s “this is off” is enough, because there’s a chef back there with the second kind of taste who translates the complaint into a fix. In an AI build, there is no chef back there. There’s just the line cook and you. If all you’ve brought is the diner’s palate, you can tell the plate is wrong, but you can’t say acid-not-salt, so you send it back on a loop and get something differently wrong every time. The only thing that breaks the loop is the correction, and the correction is the chef’s.

There’s a reason the whole culture reached for “slop” to name what’s wrong with mediocre machine output – a feed-trough word the dictionaries crowned word of the year. We walked all the way into the kitchen to find the insult and didn’t notice we’d done it.

Here’s what that looks like from inside my own build, on a perfectly ordinary day.

Artwell turns long-form audio into clean, speaker-attributed transcripts and then into story. So transcription quality is foundational, and at one point I had two transcripts of the same recording sitting side by side. One of them looked obviously better. It came dressed with segments, summaries, topic tags, sentiment analysis – the whole garnish tray. The other was plainer. Word-for-word they agreed about ninety-six percent of the time, close enough that a quick look would call them equivalent and reach for the prettier plate.

The plainer one was the better transcript, and it wasn’t close. The fancy one had quietly turned “Puget Sound Energy” into “Pizza Time Energy,” and a neighborhood named SoDo into “So To.” Those aren’t formatting nitpicks. In a transcript meant to carry someone’s actual words into a published story, a confidently wrong proper noun is the gray center of the steak – the thing that looks fine under the garnish and destroys trust the moment anyone who was in the room reads it. Choosing correctly here was not “which output has more features.” It was knowing that for this product, quality means the words and the names survive intact, and the analytics layer is parsley. That’s not a verdict a diner’s palate can deliver. It’s a directorial call about what the dish is even for.

It happens at every layer. Another time, a fix to the audio-editing playback sailed through every check – tests green, types clean, lint quiet – and was still wrong, because it had bought its passing grade by making playback hesitate for a beat before it started, trading the immediate, responsive feel of the thing for technical correctness. Every box ticked. The dish still didn’t eat right. Passing the recipe is not the same as the plate being good, and no test suite has ever been able to taste the difference.

Now the uncomfortable part, the part those train-your-taste courses are selling around. The chef’s palate – the one that can direct, not just judge – is not built by curating. You do not develop it by assembling a reference library of great plates and studying them, any more than you become a winemaker by becoming a sommelier. The sommelier develops exquisite preferences by tasting. The winemaker develops judgment by making bad wine for years until it stops being bad. They are different organs, grown by different work, and only one of them can fix the batch. The judgment that lets me see past “Pizza Time Energy” came from two decades of being responsible for the finished thing – of shipping the wrong cut, watching it land badly, and learning in my hands what the fix actually was. It did not arrive on a schedule, and it did not come from watching.

Which is the quiet problem underneath the cheerful democratization story. We have declared judgment the most valuable thing in the economy at the precise moment we’re dismantling the work that produces it. The reps that used to build the chef’s palate – the grunt passes, the owned mistakes, the years on the line – are exactly the reps the machine now does for you. You can have the diner’s palate for free. The chef’s palate was never free, and it’s getting more expensive to acquire, not less, because the path to it is quietly closing.

I can’t reopen the path for everyone coming up behind me, and I’m not going to pretend a LinkedIn post does anything about it. What I can control is whether I keep doing my own reps. So here’s the thing I actually do, and it’s the reason my build process looks heavier than a solo founder’s “should.” The multi-session, multi-role orchestration I run – the planning panels, the forced checkpoints, the reviewer pass that exists only to argue with the implementer pass – is not only quality control. It’s a structure that keeps me at the stove. Left alone with a fluent line cook, the gravitational pull is to slide back into the diner’s chair: glance at the plate, looks plausible, ship it, send it back if someone complains. The orchestration is what stops the slide. It forces the second-order question every time – not “is this good,” but “what is this allowed to become, and where does it live, and what’s the one cut that keeps the product true.” It makes me direct instead of merely approve. In a world where the reps don’t happen for free anymore, I’ve built a way to keep doing them on purpose. It’s an apprenticeship for one, and I’m both the master and the kid sweeping the floor.

The couple never resolved it, for the record. He paid, stiffly. She was still right.

But the argument they were having is the one the whole industry is having, and it’s worth getting right, because the stakes aren’t really about steak or even about taste. The people who can build something good with AI are the ones who already spent the years at the stove – who carry the chef’s palate into a kitchen that now runs at impossible speed. The discourse is handing everyone else a flawless line cook and a diner’s palate and calling them chefs. And that works beautifully, right up until the plate comes back wrong and nobody at the table knows what to fix.

#Artwell #FieldNotesFromTheBuild #AIStrategy #SoloFounder

Share

Subscribe now

Artwell

Just like Jason Voorhees, the agile-versus-waterfall debate never dies – it keeps coming back. It comes back because it’s a useful argument, and because every new wave of developers eventually has to reach their own conclusions about how much planning is enough and how much is too much. The current resurgence has a particular flavor – it lives mostly on LinkedIn and YouTube, and it leans hard against specs. Specs are heavy. Specs are corporate. Nobody reads them. Just ship. Waterfall is dead. The dinosaurs of the old way are still scolding us from the boardroom while the rest of us iterate.

There is something true in that critique, and there is something the critique is missing. Both halves are worth taking seriously, because building a real product in 2026 means navigating both at once.

The part that’s true is straightforward. The dead corporate version of a spec – the thousand-page document nobody reads, the approval chains, the false certainty, the planning that calcifies into fiction – really is a waste. That’s not the same thing as saying specs are a waste. It’s saying that one particular implementation of a spec is a waste, and confusing the implementation with the concept is the kind of category error that lets people argue against object-oriented programming because they once saw a bad Java codebase. The bad version of anything is always bad. The interesting question is whether the good version still has work to do.

The bigger problem with the current debate is that it’s being conducted in 2026 with the same binary it had in 2014, which in AI years is roughly the Cretaceous. The debate certainly is not extinct, but the framing of it is. Both sides of the argument still assume that a spec is a document a human writes for another human to read. Even when the spec gets handed to an AI rather than a human, the assumption underneath stays the same – the spec is a static artifact passed across a boundary, used as a one-time briefing rather than as a living substrate the work persists within. From that premise, the entire shape of the debate makes sense. Specs are heavy because humans are slow readers. Specs feel like waste because the people they’re written for never finish them. Defending specs makes sense from inside that frame. So does dismissing them. The two sides are both correct, and they’re both arguing about the wrong thing.

Before getting to what I actually think the debate is missing, there’s a useful principle from the older argument worth keeping, because it dissolves the binary on its own. Some decisions in front of you are expensive to reverse. Some are cheap. Architecture is expensive. A button label is cheap. You don’t iterate your way into a data model; you iterate from one. The cost of being wrong on the foundation is high, and the cost of thinking carefully about it up front is low. That phase rewards real specs. The wiring phase, where you’re shaping what the user sees and how a flow feels and where the copy lands, is different. Those things only reveal themselves once people start using them, and heavy specs there would actively hurt the work. The principle is simple: match the process weight to the reversibility of the decision. Spec the expensive, iterate the cheap.

Most serious builders already work some version of that, whether they call it that or not. The agile-versus-waterfall debate falls apart the moment you accept that different decisions in the same project deserve different amounts of upfront thinking. But the principle still isn’t the deepest thing the debate is missing. The deepest thing is that the audience for the spec has changed, and nobody on either side of the public argument seems to have noticed.

I’m building Artwell, an AI narrative and voice platform, as a solo founder. The foundational specification I worked through with multiple AI models, across many days of conversation, came out around 80 pages. The user-experience specification that followed is roughly 20 pages. I have never read either of them cover to cover, and I never will. Neither would anyone else. That isn’t the failure of those specs. That is the point of those specs.

When you build a real product with AI in the loop – through model versions that change, across context windows that overflow and crash, across sessions you start fresh tomorrow because the current one is exhausted, across multiple models running in different roles – you need somewhere for the work to live that isn’t just your head and isn’t just one fragile session. The spec is that somewhere. A new session, a new model, a new tool reads the document in seconds and comes up to speed on weeks of accumulated decisions, definitions, constraints, edge cases, and intentions. Without that document, every restart is a regression and every model swap is a tax. With it, the work persists across all of it.

And the conversation that produces the spec is itself iterative, which is the part that breaks the frame entirely. The 80-page foundational spec wasn’t a waterfall artifact handed down from a planning phase. It was the consolidated output of multi-day back-and-forths across multiple sessions, multiple models, and multiple roles – a planner session proposing, a reviewer session pushing back, an implementer session surfacing a hole the planner missed. Features I would never have discovered through pure vibe-coding came out of the planning conversation itself, because that conversation had the time and the surface area to let edge cases and competitor analysis and full workflows breathe. The output happens to be a long document, but the document is the consolidated record of an extremely agile process. The thing the public debate calls “spec writing” and the thing it calls “iteration” are happening in the same place. They just produce different artifacts at different points.

That changes the cost calculation entirely. A 50-page spec that humans have to read end-to-end before they can start working is corporate theater, and the critics are right to dismiss it. A 50-page spec that an AI ingests in seconds and that survives the next model swap is infrastructure, and dismissing it is a category error. Same document. Completely different function. Whether the work of writing it is wasted depends entirely on who’s reading it and what they’re using it for.

And the spec itself doesn’t stop evolving once implementation begins. We treat it as the working substrate of the project – not just as a planning artifact but as the implementation document itself, broken into phases, lanes, and slices that get worked through over the following weeks and months. As that work surfaces things the planning didn’t anticipate, the spec gets updated. Sometimes we revise the original document directly. Sometimes we preserve the original intact for the historical record and write addendums that capture founder-approved course corrections. Either way, the spec stays current with the actual state of the project, which means new sessions and new models always get the truth of where we are – not a snapshot of where we thought we’d be six weeks ago. The flexibility to change direction during implementation doesn’t break the foundation. It’s built on top of it, which is the entire reason the foundation was worth specifying in the first place.

This isn’t new thinking outside of software. Many years in media production taught me that the work you put into pre-production is what makes production possible. An indie filmmaker can shoot from the hip with no script, no shot list, no production schedule, and pull off something charming – the kind of thing that wins a festival short slot and becomes a calling card. The same filmmaker cannot pull off a feature that way. They certainly cannot pull off a series. The amount of structure required scales with the ambition of the thing being built. The script that nobody reads cover-to-cover on set is doing real work as a shared reference. The shot list the DP scribbles all over is doing real work as a daily handoff. The shooting schedule that gets revised every morning is doing real work as a coordination layer. None of it is waterfall, and none of it is wasted. It’s the substrate that makes the days on set possible.

Specs work the same way. A weekend script doesn’t need one. A product with customers, retention policies, billing, trademarks, compliance posture, and a brand audience whose trust breaks if anything breaks does. What changed isn’t whether the substrate matters. What changed is who reads it.

There’s a related point that follows from this, and it matters because it’s where the public debate quietly does the most damage. When people complain that AI claimed it finished a task it didn’t actually finish, or that the AI skipped a section of the spec, or that the AI ignored a constraint, the default response is to blame the AI. The more honest diagnosis is that the AI is doing exactly what its scaffolding allows it to do. A single prompt-and-pray session with no checkpoint, no completion verification, no review panel, and no orchestration layer is going to produce inconsistent results regardless of which model is on the other end. That isn’t an AI failure. That’s a builder choosing not to construct the orchestration that the work requires.

The builders who are shipping serious products with AI assistance are running multi-session, multi-model, multi-role workflows with forced checkpoints, completion verification, and review passes. The builders who are shipping weekend tools and clever demos can get away with one session and a good prompt. Both are doing AI-assisted development. They are not doing the same job. The advice that works for the second does not port to the first, and treating the two as equivalent is the original sin underneath most of the loudest takes on agile, specs, and how to build with AI today.

So the real debate isn’t agile versus waterfall, and it isn’t even spec versus no-spec. It’s whether you’re building something that requires a real orchestration architecture and a persistent record of its own thinking, or whether you’re building something that doesn’t. It’s whether the documents you’re producing are written for human readers who’ll never finish them, or for the AI collaborators who actually carry the work across the sessions you can’t.

I don’t read my own specs. They aren’t for me. They’re for the next session, the next model, the next implementer, the next reviewer, the next time the context window blows up and tomorrow’s version of the project has to be reconstituted from yesterday’s decisions. The specs are how the project remembers itself. They are the foundation that makes everything else I do possible, even though they look, on the surface, like exactly the kind of artifact the current debate has decided to dismiss.

That isn’t waterfall coming back. It isn’t the old discipline in new clothes. It’s a new discipline that the public debate hasn’t built the vocabulary for yet – and one that the people still arguing about specs versus no-specs are going to need, whether they decide to learn it or not.

#Artwell #FieldNotesFromTheBuild #AIStrategy #SoloFounder

Share

Subscribe now

Artwell

Nine months ago, when I began building Artwell in earnest, Deepgram was the right call for speech-to-text. Best quality at the time. Best pricing. Solid intelligence layer.

I also flagged, in the first week, that Artwell should not be permanently coupled to a single transcription provider. That was not some brilliant revelation. Every senior architect would have seen the same thing.

But there is a difference between seeing an architectural need and building it immediately. Early in the build, the more important job was learning the shape of the product: the workflow, the transcript model, the editing layer, the downstream story outputs, the places where quality actually mattered. Premature abstraction is its own kind of debt. So we kept moving.

This week I went back and re-tested the speech-to-text market against Artwell’s real needs – long-form audio, diarization, speaker handling, intelligence layers, downstream editing, cost at scale. The landscape had not moved by inches. It had moved by miles.

ElevenLabs’ latest Scribe v2 has overtaken on quality and pricing. AssemblyAI is right behind it, with a comparable intelligence layer – sentiment, topics, summaries, speaker identification inferred from transcript context. For the configuration Artwell needs, the incumbent provider now costs more than double what the leaders charge, with measurably higher word error rates (WER) and a thinner intelligence layer. This is no small thing. This changes margins, pricing flexibility, and what a product can afford to offer users.

With Artwell’s launch on the horizon, this became the moment to build the abstraction layer.

Artwell now has a transcription layer that can route across providers, support fallbacks, separate development from production, and absorb the next provider change without touching the product itself. The intelligence layer is next, same pattern – OpenAI and Anthropic today, whatever proves best tomorrow.

The lesson though is not “build abstraction layers.” The lesson is that AI infrastructure decisions have a shorter shelf life than most teams are conditioned for. The right provider today may not be the right provider one year from now. It might not even be the right provider one month from now. That’s simply the speed of the market we are all building in.

“Which provider is best” is the question every team asks. The better question to ask is what it will cost you to switch when that answer changes.

Architecture buys you the right to change your mind.

And in AI, that optionality may be the difference between building a moat and building a wrapper.

𝘛𝘩𝘢𝘵 𝘪𝘴 𝘸𝘩𝘢𝘵 𝘈𝘐 𝘴𝘵𝘳𝘢𝘵𝘦𝘨𝘺 𝘭𝘰𝘰𝘬𝘴 𝘭𝘪𝘬𝘦 𝘧𝘳𝘰𝘮 𝘛𝘩𝘦 𝘉𝘶𝘪𝘭𝘥.

#Artwell #FieldNotesFromTheBuild #AIStrategy #SoloFounder

Share

Subscribe now

Artwell