jseabra

The "professional report version nobody read" observation is important and undersold. Feedback only works if people actually process it, and sharp tone forces processing in a way that polite summaries don't. The risk is overshooting into mean-for-laughs rather than mean-for-change, but that's a calibration problem not a direction problem. The requirement inflation catch is the most genuinely useful thing here. "8 years of Kubernetes" is funny as an example but the underlying pattern, requirements copy-pasted from a previous hire's resume rather than derived from what the role actually needs, is endemic and causes real damage. It shrinks the pool, filters for credential-holders over performers, and signals to good candidates that nobody thought carefully about the role. A roast that makes that legible is doing something useful. On the architecture decision: separating deterministic scoring from LLM commentary is the right call and worth explaining more prominently. It's what makes the scores comparable across JDs, which is the thing that would make this actually useful at scale for recruiting teams rather than just a one-off novelty. Right now it reads like a fun tool. That separation is what makes it a platform. Remote clarity is worth adding. In 2026 "hybrid" without defining what hybrid means is its own category of dishonesty.

The plan-as-living-document idea is the part that actually changes outcomes. Most people treat the spec as a throwaway artifact that gets stale the moment implementation starts. Versioning it alongside the code and closing the loop after each commit turns it into something the agent can actually trust on the next session. That compounds fast across a long project. The step I'd add between Diagram and Mockup is a constraints doc. Not architecture, not UI, just the things that are off the table: third party services you won't use, patterns that caused problems before, decisions that were made for non-obvious reasons. Agents are optimistic by default. They'll reach for the clean solution without knowing why you're not using it. A short "don't do X because Y" document prevents a whole category of review comments. One thing I've noticed with the test-first step: it works best when you write the acceptance criteria in plain language first, before asking the agent to generate the test code. If you hand it to the agent to interpret, it tends to write tests that pass rather than tests that catch failures. The distinction sounds subtle but it shows up in code review constantly.

Cloudflare's free tier has been the same story for years but pairing it with Claude Code genuinely does compress a full weekend project into a few hours. Curious what the actual session looked like, one long context or did you break it into pieces?

Graham's central thesis, that brand is what's left when substantive differences disappear, is accurate for the watch industry but it's describing a degenerate case. Most brand work isn't about papering over commoditization. At its best it solves a different problem: the difference is real but not legible to the buyer. I spent over 20y doing brand work for companies where the product was genuinely better. Harder problem than you'd think. Technical superiority doesn't sell itself, especially when the buyer can't evaluate the difference before purchase. Brand in that context isn't a substitute for quality, it's the translation layer between quality and comprehension. When we worked on HSBC's positioning in emerging markets, nobody was pretending the banking products were interchangeable. They weren't. The challenge was making a real advantage visible and credible in markets where trust in institutions was historically low. The "branding is centrifugal, design is centripetal" line is the best thing in the essay and it's genuinely true for the luxury watch case. But it breaks down in categories where the design space is still wide open. Early software brands, health tech, financial products, anywhere the user can't directly compare outputs before committing. There the centrifugal force isn't vanity, it's disambiguation. Where Graham is absolutely right is on the moral hazard. The further brand drifts from something real, the more it starts depending on the worst parts of human psychology to do its job. The Patek bubble management story isn't an outlier, it's the logical endpoint of brand fully detached from product. Most brand people I know are genuinely trying to avoid that. The ones who aren't are usually the most financially successful in the short run, which is its own kind of lesson.

The orchestration point is right but I'd reframe it slightly. The real differentiator isn't orchestration, it's context. Most AI content workflows fail not because the tools are wrong but because the model is working without a coherent brand model. It gets the topic right and the voice completely wrong, or it's consistent post to post but inconsistent with what the company actually stands for. That's not a prompting problem, it's a context architecture problem. What's actually broken in 2026 is that almost nobody has solved structured brand context at inference time. People treat it as a system prompt you write once and forget. The ones getting real ROI are the ones who've built something closer to a living brand spec that the model actually queries against, not a paragraph of adjectives at the top of a template. On the stack question, SurferSEO is fine for keyword scaffolding but I'd push back on using it as a content strategy layer. It optimizes for what's already ranking, which is useful for informational content and actively counterproductive if you're trying to build a distinctive voice. The 30% human judgment you mention should probably land there first, before ideation, not just at the editing stage.

Translating pseudo-code to real code is almost table stakes for any decent LLM at this point. But getting architectural feedback in the same abstraction layer you think in, that's a different thing entirely. I've noticed something similar when working with Claude Code. The quality of the back-and-forth improves significantly when you stay at the intention level rather than jumping straight to implementation. Once you're in the weeds of actual syntax, the conversation tends to collapse into micro-corrections. Staying pseudo keeps the design space open longer. One thing I'd be curious about: how does it handle the translation when your pseudo-code has ambiguous control flow? That's usually where I hit the wall. The semantic intent is clear to me but there are three or four valid ways to implement it and the model just picks one without flagging the decision.

The abstraction-over-CLI framing is mostly right, but it undersells what's actually new. APIs required you to know the API existed, read documentation, write integration code. Agent-native discovery, if it matures into something like MCP or structured capability registries, removes all three of those steps. That's not nothing. The trust question is the interesting one nobody has solved. Right now agents trust whatever the model provider trusts, which is basically whoever got into the training data or the plugin store first. That's not a ranking system, it's incumbency dressed up as curation. An open protocol layer sounds good in theory but you'd need some coordination mechanism that isn't controlled by OpenAI or Google, and I'm not holding my breath. On the discovery question specifically, I think the answer is already partially visible. If you're building something agents will call, your actual surface area is your schema, your error messages, your response latency, and whether your outputs are deterministic enough to be reliable in a chain. That's a completely different product discipline than conversion rate optimization and landing page copy. Some teams will find that freeing. Most will find it disorienting because they've spent years optimizing for the wrong thing. The human-as-supervisor model also has a quiet assumption baked in: that humans will know when to intervene. That's probably the hardest part.

The friction you're solving is real. Most testimonial tools assume the hard part is displaying the content. It's not. It's the collection step, specifically the moment between "customer is happy" and "you actually ask them." That gap is where most testimonials die. One thing worth thinking about on pricing: the white-label add-on at $10/mo feels underpriced for agencies. If an agency is running this across 10 client sites, they're getting it for $1/client/month. That's a rounding error on their invoice. You could probably 3x that without losing agency customers, and it'd help you figure out early whether agencies are actually your real market or just a nice-to-have segment. The "unlimited everything" angle is a good call. Usage-based pricing for something like embeds creates constant mental overhead for the customer. Removing that is a genuine product decision, not just positioning.

The information asymmetry framing is the most useful part of this. But I'd push back on where you locate the problem. It's not really a paradox, it's a design failure. The prompt-as-interface forces users to encode what they know into natural language on the fly, which is lossy and inconsistent. The solution isn't better prompting or bigger context windows. It's structured context gathering before inference. Interview the user systematically, build a high-resolution data model upfront, then let the model work against that. The quality difference is significant. I've spent the last year building AI systems that do exactly this. Not chat, but structured intake flows that front-load the information problem. The outputs are categorically different from what you get in a back-and-forth chat session. Not because the model is smarter, but because it's better informed. The NBA coach analogy holds: give the coach a 30-minute intake session before the first lesson and suddenly the advice stops being generic. On the agent systems critique, fair, but I'd separate two things. Token cost is an engineering problem, solvable with better retrieval, caching, compression. The "just a big system prompt" criticism is more interesting. Some of what gets marketed as agentic is basically dressed-up RAG. The genuinely agentic stuff, dynamic tool use, multi-step reasoning with actual state, is meaningfully different. The problem is the category is polluted by hype. The game interface idea is interesting but I suspect the real bottleneck isn't visual metaphor. It's persistent memory and reliable state management. Fix those and the interface question mostly solves itself.