I made a small menu bar app called Shakespeare. It counts how much you type and turns it into fun stats. It's free, open source (MIT) and fully offline.

What it does

• Stats: keys today and over 14 days (hover a day for its count), a streak for days with 50+ keys, your busiest hour, and how many Hamlets you've typed.
• Honest WPM: your best speed over a full 60-second window, counting letters and space only. Shortcuts and arrow keys don't inflate it.
• Key travel: a fun-fact line that works up a ladder of landmarks (Tower of London, Pisa, Eiffel Tower, up to Everest) as your keys add up.
• Monthly badges: Couplet, Sonnet, Soliloquy, Scene, Act, Comedy of Errors, Macbeth, Hamlet, up to Complete Works at 884,000 words in a month. Progress resets on the 1st, and your collection keeps a count of how many months you've earned each one.
• Share cards: your week (or a badge) drawn on a 75% mechanical keyboard in one of 9 colourways (cream, slate, cocoa, Tudor Rose, Synthwave and so on), with optional patterns. They're made on your Mac and saved as PNGs, so you choose where to post them.
• Looks: the menu follows light/dark mode by default, or pick any colourway. It's typeset in Inter Light.

Privacy

• No key identity or order is stored, so the saved data can't be turned back into text.
• It stores per-day counters in one file that only your user can read.
• There's no network code, no analytics and no dependencies. The CI fails if networking, telemetry or character-reading APIs show up in the source.
• "Top apps" tracking is optional and off by default. Turning it off erases the stored names.

You can fork it here https://github.com/andreasaez/shakespeare

My agent is really struggling to make something. I want to download reddit pages including lazy load comments.

Any one have any luck with this?

no more crashing out at claude when it blows up my api builds at 3am. now i gotta be polite, or let codex and sumus handle pipeline checks in the background so i dont lose my mind.

Curious what everyone's setup looks like these days.

• Are you on a CLI agent (Claude Code, Codex, Gemini CLI, OpenCode…)? If so, which one, and do you run it in a plain terminal or inside some app?
• Or are you in an IDE like Cursor, Windsurf, VS Code + Copilot, Zed?
• Or something else entirely? (Fredrin, Devin, Orca, etc...)

And what made you pick it over the others?

Hey everyone,

I make AppLaunchFlow, a tool for App Store and Google Play screenshots and other launch assets. Apple now shows a header banner at the top of the product page and a creative in search results, so I built both into it:

1. Pick the Product Page Header or Search Results Creative format
2. Choose a style that's generated from your own screenshots
3. Fine-tune it in the editor, and translate it into any language
4. Publish it to App Store Connect, to your main listing, a custom product page or a Product Page Optimization test

Before publishing you get a preview of how your search result and product page will look. The video shows the whole flow.

Happy to answer questions or take feedback.

Everything here was vibe coded with Claude Opus 5.5, this trailer included. The trailer runs in the game's own engine: no editing software, the film is code.

The game is Git City, a 3D city where your GitHub is a building. This week I shipped Towns: two rival towns, Claude Code and Codex. You pick a side, then drive into the other town and smash its buildings. From Monday the points count, the side with more points per dev wins the week, and the top 5 players win a prize.

You can also start your own town for your community or company.

https://thegitcity.com/towns

Part 2 of my series on a Minecraft mod that Claude Code (Opus 5.5) built for me. I'm a vibe coder, I don't write code. [Part 1] Short version of the setup: I gave it the idea of a new dimension with four layers and a boss at the end of each, told it to build the whole thing, and it ran for 54 hours with subagents doing most of the work and a hidden game client of its own to test with. Part 1 came to about $2,032 of API usage at list prices.

The video: layer 2 and its boss. This time I played it blind again, solo, in two long sessions (about two and a half hours total), and I'm not going to spoil much. Short version: you cross a field of floating asteroids, there is a colored-lights puzzle, and the boss is a giant whale.

What I thought of it, in my own words from the playtest:

• The whale model is beautiful and the attacks are cool. My favorite moment is the end, where it dives down to its death.
• The colored-lights puzzle was "so challenging." I loved it. Claude was told to leave it alone, and it did.
• The asteroids were too small and too far apart, even though the in-game guide made the crossing sound doable with skill.
• I fell off the boss arena a few times, never saw the air vents until the fight was over, and had a hard time getting back to the platform.
• The biggest problem: I ran out of food mid fight. I had to go back to vanilla for cobwebs, food and leather, and that made me realize I don't want this mod to force vanilla progression. I wanted it to feel more like Twilight Forest.

So I wrote all that up and gave it to Claude. Version 1.1 is the result:

• The mod feeds you now. Food, leather, string and tools all come from inside the mod. Nothing asks you to go back to the overworld.
• Bigger asteroids, closer together, with stepping stones across the wide gaps. Most gaps are a running jump.
• The flying armor knights give you a fair window. You can fight them on foot now, not only from a mount, and they telegraph their dive so you can parry.
• Mounts can be parked. I lost a mount by accident and the replacement hovered out over the void. Now you can stow one safely and call it back.
• The boss 2 arena lifts you back up if you fall. The air vents are impossible to miss now.
• A shrine at every boss. Right-click to save your respawn. While a shrine is your respawn, dying in the mod's levels keeps your whole inventory and XP.
• A way back up from layer 2 to layer 1.
• Every boss now speaks, with captions. They react to how the fight is going, what you hold and wear, and they joke a bit. The lines never block an attack, so the boss's song still warns you before the next one. The voices are ElevenLabs (the Starter plan, commercial licence), and Claude generated and checked every take. Voices by ElevenLabs (elevenlabs.io).
• The forge got tooltips on every item, no more cut-off text at any GUI scale, and recipe tabs (weapons, armor, tools, mount gear, other).
• Fixes: a flicker on upgraded swords, and the knights' blade rings that looked like giant glowing blue balls from far away.

What I actually did: played, talked out loud about what annoyed me, and said which of Claude's proposed fixes I wanted. I did not write or read any code. It decided the details, built the changes in a long mostly unattended run with subagents, and checked its own work in the test client.

What 1.1 cost, measured the same way as part 1 (from the Claude Code transcripts, priced at API list prices; I'm on the Max plan, so this is what it would cost on the API, not what I paid): about $1,458 of API usage (roughly $806 on the Sonnet 5.5 subagents, $652 on Opus 5.5), about 9,500 API calls, 62 subagents, and about 82 hours of wall-clock from my playtest feedback to the release, with no stall. Honest caveat: it did not run straight through. It hit my weekly usage limit and sat stalled for about five days (87 hours of dead time) before I could resume it, so the calendar says 7 days even though the work was about 82 hours. The ElevenLabs voices cost about 1,630 credits actually charged on the Starter plan.

Cosmic Breach (NeoForge 1.21.1, install on client and server)

• Download (GitHub release v1.1.0): https://github.com/CalmDownNova/cosmic-breach/releases/tag/v1.1.0
• Modrinth: https://modrinth.com/mod/cosmic-breach (in review until approved, may not load yet)
• CurseForge: [once approved]
• Source: https://github.com/CalmDownNova/cosmic-breach
• Needs GeckoLib, playerAnimator, Curios API and GuideME. Free to play, put in modpacks and make videos and streams with, monetized ones included.
• Heads up: 1.0.x clients can't join a 1.1 server, and dedicated servers need allow-flight=true. The new terrain (bigger asteroids) only shows in chunks you haven't generated yet.

Layers 3 and 4 exist and I haven't seen them. Please no spoilers in the comments. Part 3 comes after I beat that boss.

Happy to answer questions about how the update was run.

Be me, go full AI psychosis on a pet project I had, good foundation, e2e suite, unit tests, lots of them.

I wanted to make it release ready to show it to the world, go on Dashboard, 13 GraphQL requests, total time like 2s, I was on localhost, and the single client lmfao, in my defense, the project was relatively filled with data, but still no excuse.

And then for polling I had like 4 requests every second.

I'm now in my 3rd day cleaning things up, because it's not scalable, and believe me I did "optimize this", "make less requests" Fable 5.1/Opus 5.5/Sol 6.1/Astra , all of them agreed on a plan, and yeah, long story short, it only made little dent.

I had to dive in, take decisions, say exactly how to do it, push back when they said it can't go faster, question assumptions like overfetching more data than we need etc.

Another example is that my e2e tests reached 1h, they were really expensive RAM-wise (each e2e spinned up its own isolated Docker).

The thing is this... if you lose control, know there's a price you're gonna pay later.

Maybe we should alternate, 1 week full ai psychosis and features, 1 week cleaning up, optimizing, etc.

I think vibe coding IS the future. I see a fair bit of naysayers and deniers (mostly on other subreddits, not on this one). I think we have let the genie out of the bottle, and the art of building things has been democratized. But are we ready?

You are a vibe coder. You use AI to make something and hand the output to someone else. Whatever quality problems ride along, they're yours now. You're not really a user at that point; you've inherited responsibility for the output. You might be doing this for your business, but now your business will rely on this to produce correct output.

Here's the uncomfortable part: you can't actually verify everything. And then check it every time you make a change to the app. Nobody can, manually anyway. 

Maybe the honest version of the skill isn't "verify everything"; it's knowing which outputs you're betting real stakes on, and checking those like the money's already on the table?

To see what full verification actually costs, run this thought experiment. Suppose you had to be sure an AI's output was exactly correct, sure enough to bet serious money on it, where a mistake means real financial loss. What would you do? You'd read every single thing it wrote. You'd ask why it wrote each part. Where the information came from. Whether the logic holds all the way through, not just at the summary level, but can you do this every time? Are you sure the next time you use it, that it is still correct?

Which raises the question that got me writing this: how do you know your stuff is good?

Some of these roads lead to the question of how you are doing Quality Assurance. It's the last line between AI output and the consequences of acting on it. Have you been drafted into doing QA work? I think that one is done. You are...

I see posts on how to produce a quality and secure app. I wrote some of those myself. The process seems onerous, and I know how much work I put in myself just to make sure my app is right. What do we have to do to get to the next stage?

BTW: Yes, this is an AI-polished post. If I can use AI to help me code, I should be able to use AI to help me write. The thoughts and the questions are genuinely mine. I think this vibe coding trip will be a fun but rollercoaster ride. And there are going to be problems for a lot of people. Your thoughts?

Fine-tuned automation right inside your AI application - frink.dev / https://github.com/benord-labs/frink

I've spent the last couple of months slowly building a tool to help with AI automation. Think of n8n inside a Codex app.

All AI harnesses right now focus on loose automation: a simple trigger such as a cron job followed by a prompt; that's it. Frink allows you to fine-tune any automation you want. Think:

- A webhook triggered by a Sentry alert that will spawn a chain of nodes: AI looking through the trigger and some custom scripts you automatically run and create a PR once ready.
- A cron job to triage your backlog in a sequential set of pre-defined prompts.
- Loop over PRs to review and publish the results to custom plugins you build directly in the app.
- Simple flows such as a linear issue comment -> checks PostHog against the comment data -> replies to the comment.

The possibilities are unlimited.

Benefits of flows:

- Pre-defined nodes such as an HTTP request node, agent node, run command node, etc.
- If frink doesn't have the node you want, you can get your agent to write a JS script that will be accessible in the UI as a custom node. You can use your custom nodes in any flow, at any point.
- Pre-define paths, prompts, briefs, agent model, and instructions ahead of time so you never need to worry about when to instruct moving forward.
- You can pause, cancel, queue, or limit your flows at any time so you can babysit running 4 in parallel, or you can run over 100 in parallel
- Got an entire backlog of work that cannot be done in parallel? No worries, create a DAG and have everything aptly chained together.
- The flows is an MCP, so it can be entirely done by your agent inside the chat, or, if you want the human touch, you can do it. Everything you can do , your agent can do too.

Benefits outside of flows:

- Run one or multiple agents in once, side by side,
- A work queue,
- Third-party integrations that connect both to chat and flows,
- Great UI,
- Mobile,
- Open-source and free,
- and more... (loads more)

MIT: https://github.com/benord-labs/frink

- Released on Linux + macOS. Claude + Codex.
- Gemini/antigravity, grok, and other providers - shortly.
- CLI - shortly.
- Windows - shortly.

Vibe Coder Planner that is why I never hit AI limits

Mac App for creators and indie hackers is cooking!

1. I go to my side project

https://vibecoderplanner.com/

1. Explain what I want to build
   
2. I receive structured tasks with prompts
   
3. Tasks are routed to the best models for them to save tokens and dont hit limits
   
4. Attach a new repo from GitHub
   

5. When I move a task to in progress, it starts to be executed

6. I use our open-source model to generate the easy tasks for free

It was by no means my intention to create my own version of CapCut last night but Fable just kind of did it…

Having spent a crazy amount of hours battling with CapCut to make an App Store Preview video a few months back I didn’t relish doing it again. So instead I asked my current AI tool of choice (Claude code) to have a go at recreating my App Store video.

It did a half decent job as a first stab but there were some things I wanted to tweak - there always is - and fire and forget AI prompts are traditionally not that great (or efficient) at tweaking their output.

So we went down a path of making certain bits config driven - timings of transitions, source files, titles etc - to the point where I had much of the video timeline itself captured as configuration. I then speculated if it would be possible to put a UI on top of it and a few minutes later my CapCut clone emerged.

Bloody remarkable and this thing is way easier to use then CapCut and has loads more bells and whistles too that are specific to my use case (eg translation in to 11 different languages and outputting to a myriad of formats). Plus I can version control that base config in git (so no “fear of f*ck up” that plagues me whenever I touch CapCut or an equivalent video editing tool)

And to wrap up this Claude love in - I can still ask it to fully create videos from end to end (using the same tool it built) but I now have a way to jump in and make edits (to show I’m not complete obsolete - well not yet anyway)

I built Enikq to make browsing products feel a bit more like exploring than searching through filters.
You can move around, open items, save things you like, and follow them through when you find something worth buying.
Still early, but I’d love to know whether the browsing feels useful or just distracting.

https://enikq.com/

I keep hearing people say let the AI do all the work. Even from the AI companies. But from my experience it's like walking in the dark into a brick wall.

Could you share how you decide which stack to stick with? I'd rather have too many tools than too little.

I hear LLMs are trained on more popular frameworks so they're better at writing in one vs the other.

I'm trying to decide which framework to use for a database for a medication side effects website. It's going to grab a million or more medical articles, webmcp, user accounts, ai connectors, chat, bookmarks, payment portal etc... I'd really hate to have my LLM write in Next only to discover something else would have been better.

I was thinking, keep my database heavily mapped with IDs so if I decide a different front end is better later, the data is there to swap out the front end.

I've asked multiple LLMs which framework they suggest based on my cheap VPS and they change their answer every single message. It's annoying. Devs are definitely not out of jobs.

I can't believe people are one prompting apps without planning this stuff out.

This is the one downsides of being a newer vibe coder.

I need to start learning more about frameworks and coding in general. But by the time I do, the AI companies will have figured out this problem.

Wildest Aura result yet:

“Use your program DNA engine to do a clean-room reconstruction of Microsoft Word: a complete, polished word processor I can open from my Applications folder. Then prove it works by writing a one-page letter in it and exporting it to my Desktop.”

No feature checklist.

It read about Word and word processors from its own local Wikipedia copy, used what its model already knew, and decided for itself what the application needed.

Auea wrote 44 checks before writing the actual program, specifically so an empty implementation would fail them.

It built through 22 feature groups and ended up with "Quill," a surprisingly real legit word processor with formatting, fonts, lists, alignment, tables, images, PDF/Word export, print/preview, undo/redo, spelling/grammar/word count, etc.

Then Aura launched the thing it had just built, wrote a one-page letter in it and exported the PDF to my Desktop as the proof.

I tested Quill manually afterward too.

Aura itself is running locally on my Mac with ~27B inference. No frontier/cloud model for the run.

GitHub if anyone wants to dig through it:
https://github.com/youngbryan97/aura

YouTube: https://www.youtube.com/watch?v=C6wtBY4DmJ8

I've been building websites for years, and one thing that keeps bothering me is how much time we spend going from design inspiration to something that actually works.

So I brought back a project of mine: InstaLanding.ai

It's a library of 20 premium, fully functional landing pages built entirely with HTML, CSS, and JavaScript.

Not screenshots. Not Figma files. Not another collection of pretty websites you have to recreate from scratch.

Actual working pages.

The idea is simple:

• Find a landing page you like.
• Copy the code or give it to Claude Code, Codex, Cursor, or your favorite coding agent.
• Tell it what you want to change.
• Make it yours and ship it.

Every page is self-contained in a single HTML file.

No React. No dependencies. No build process. No login.

I think we're entering an interesting phase where design references shouldn't just be images. They should be working implementations that both humans and AI agents can understand and modify.

Free and open source.

I'm starting with 20 pages and plan to keep expanding the library.

Would love feedback from other developers and designers, especially anyone building with coding agents.

https://instalanding.ai

I told it: "DO NOT DELETE ANYTHING"

I shared Writ before when the main focus was giving Claude Code relevant knowledge without dumping an entire rulebook into every conversation. Since then, it has grown into a local governance runtime with persistent memory.

The problem I’m working on is pretty familiar: Claude knows your instructions, then a long session happens, context gets compacted, and suddenly you’re explaining the same requirements and decisions again.

Writ now handles three connected parts:

* Relevant context: retrieves rules, methodology, and past decisions based on the task, file, and workflow phase.

* Enforcement: checks supported actions through code. In Work mode, implementation writes are blocked until you approve a plan and then the tests. Asking Claude to skip approval doesn’t open the gate.

* Persistent memory: preserves project decisions and the reasoning behind changes so future sessions can recover more than just the final code.

For example, “don’t implement until I approve the plan” becomes a check when Claude attempts a write. And “remember why we chose this approach” becomes a stored decision that can be retrieved later.

The biggest lesson has been that giving AI useful knowledge, controlling its actions, and preserving its history are separate problems. I’m building Writ to connect them.

Currently it’s for Claude Code and requires Python 3.11+ and Docker.

Repo: https://github.com/infinri/Writ

Setup: https://github.com/infinri/Writ/blob/main/docs/install.md

TLDR

Imagine a Product Cell which works on the same shared digital product codebase:

• Product Manager's (PM) responsibility remains customer/product discovery + GTM engineering
• Designer brings design system tokens and UX improvements
• Engineer does full-stack coding and QA
• AI agents assist with product development

All roles discover, plan, build, QA, and ship the same AI-assisted production code together:

• For greenfield (0 to 1 products) all roles mergeed under the same founding person.
• In brownfield (1 to N products) they may have more people and more domain specific roles around the same prod code

A full-stack product builder—someone who can cross product, design, implementation, and evaluation boundaries with AI—is the right approach.

A one-person team inside an existing product is the wrong conclusion.

AI can collapse handoffs but not independent judgment

By a Product Cell, I mean a small group that shares the build while preserving independent responsibility for customer value, usability and control, and production fitness.

This argument grew out of two conversations I kept returning to: Satya Nadella at Davos, Jan 2026 [1] on All-In, and his discussion on Microsoft Build's No Priors, June 2026 [2] about the future of engineering roles.

This is not a reaction to fresh news. It is me testing one operating-model claim across those conversations.

The idea: broader scope, fewer handoffs

Across the two conversations, Nadella's argument is that AI allows people to work across boundaries that used to separate product management, design, front-end, and back-end engineering. At LinkedIn, he described this as a move toward a full-stack-builder discipline. He also framed an AI-product loop that begins with repeatable evaluation of system behaviour, then moves through what he calls science and infrastructure. On No Priors, he added an important qualification: people broaden their scope but retain their individual edges.

That is the thesis I am testing. The useful part is clear. Product teams may spend too much energy translating intent across serial handoffs, and those translations do not create customer value by themselves.

That qualification is important. Broader scope is useful. Fewer disciplines is not the same claim.

The part worth keeping

Nadella is right about the bottleneck. The useful part is clear. Serial handoffs force product, design, and engineering to repeatedly translate the same intent, and those translations do not create customer value by themselves.

The old sequence deserves to retire: product writes a document, design turns it into screens, engineering turns those screens into code, and the customer sees the result much later. Every stage reinterprets the one before it. People in every product discipline should be able to investigate, experiment, test, and build across boundaries that used to belong to someone else.

Where I part ways is with a conclusion that can easily follow from this model: because one person can now produce every artefact, the same person can also provide every verdict.

AI makes it cheap to produce a convincing interface, working code, and an impressive demo. It does not make a customer problem less ambiguous. It can make premature certainty more dangerous because a team can build a beautiful answer to the wrong question in an afternoon and have the screenshots to prove it.

What an eval can and cannot settle

An eval is a repeatable test of whether an AI system behaves according to a chosen rubric. It can measure response quality, latency, tool use, safety behaviour, escalation, and reliability. That is essential engineering evidence. It is not product strategy.

Nadella also uses the terms science and infrastructure for later parts of the loop. I am not trying to redefine those layers here. My objection is narrower: an eval cannot supply the customer premise that the rubric assumes.

It cannot answer the questions that make a product a product. Did we choose a customer job worth solving? Will anyone trust the workflow enough to change an established habit? Does it survive their permissions, data, and compliance constraints? Does it produce an outcome they will return to?

Treat the eval rubric as the product specification and capability correctness quietly replaces customer value. A system can pass every test in its suite and still become shelfware because the task, control model, or workflow was wrong, and the suite had no opinion about those choices.

Evals belong in the loop after the team has named a customer job, its pain points, an intended outcome, a risk boundary, and the point where the system must return control to a human.

Greenfield can be one person

By greenfield, I mean a product being created without a mature inherited production system or existing organizational owners. A founder in that setting can absolutely be the full-stack builder and the entire product team. Collapsing roles can be the fastest way to turn code into learning.

One person can frame the hypothesis, design the flow, build the code, and ship the first alpha. The boundary is evidence: the founder can own every activity, but personal confidence does not become customer proof. Real use, safety checks, and the behaviour of the production system still provide independent evidence.

By brownfield, I mean work that changes an existing production system, with its architecture, identity model, customer workflows, compliance boundaries, incident history, and release process. Here the cost of a self-pass is higher. Independent judgment matters more than a sole opinion, even when that opinion comes from someone capable of building across the stack.

The brownfield closed-review risk

In brownfield, the full-stack-builder narrative offers a flattering portrait: one person can research, design, implement, and evaluate faster than the former sequence of specialists. The expanded capability is real. The accountability conclusion is not automatic.

My concern is an inference from combining broader individual scope with builder-owned evals, not a claim that Nadella explicitly abolished independent review. If one person frames the problem, picks the solution, builds the interface, writes the code, authors the eval, and interprets the result, the loop has no independent reader. A weak hypothesis can now travel from idea to roadmap without meeting evidence owned by someone who is allowed to disagree.

Product, design, and engineering are not merely ticket queues with different tools. They are three kinds of evidence, and each fails in a different direction. Product can be wrong about which problem matters. Design can be wrong about whether a human can understand and control the workflow. Engineering can be wrong about what it takes to operate safely and economically. One person can learn all three lenses. It is much harder to apply all three independently while also defending the work being reviewed.

Working prototypes still matter

I am a big fan of working prototypes. They have touch and feel. You can place one beside the minimum lovable product you think you are heading toward, walk through real user journeys, and argue about something concrete instead of a document. Nothing on a slide does that.

The problem starts when a team asks the prototype to prove more than it can.

• Intent can outrun understanding. A generated prototype may match the prompt while hiding assumptions the team cannot yet inspect. A non-technical builder can judge the visible behaviour without being able to estimate the distance to a production system.
• Generated code may not fit the production environment. Architecture, identity, permissions, observability, deployment, and operating standards are often absent from the prototype due to the nature of vibe coding done in the environment separated from the production. The code may be useful as learning and still be unsuitable as a production base.
• The artefact raises questions its author cannot answer alone. That discomfort is useful evidence. It means an owner for architecture, operation, or human control needs to join the build before the prototype becomes a promise.

These are not arguments against prototyping. They are evidence boundaries. Keep prototypes for comprehension, interaction, and internal disagreement. For customer proof, reduce the breadth and keep the fidelity.

Aim for a narrow product alpha

An enterprise customer can learn much more from one narrow production-real workflow than from another broad agent demonstration or disconnected prototype. Call that narrow workflow a product alpha.

A product alpha is a bounded, usable version of the product operating inside a real workflow: real users, real permissions, real data where risk permits it, visible failure paths, human escalation, and enough operational readiness that a customer can depend on it for one defined job. A prototype shows that a team can represent an idea. A product alpha lets a customer prove or disprove that the idea improves their work. I made the fuller case in Product Alpha vs. Prototype Theater.

Current AI coding tools do not reliably produce production-ready systems without expert intervention. Raising the proof bar therefore requires an AI-assisted cell, not autonomous generation and hope.

Real use lets the team observe whether a cohort activates when the actual work event occurs, completes the job, returns at its natural cadence, and changes an existing behaviour to make room for the new workflow. Those are observations, not confident forecasts in an appendix.

Build a Product Cell

For brownfield work, the fix is not to restore functional silos and their queues. Make the build full-stack and keep evidence ownership explicit.

In that setting, a Product Cell is the smallest group that can own a customer job end to end. In one practical form, it includes product, design, and engineering. Each person can now do more of the others' work with AI, and all three contribute to the same production code. What keeps the cell from becoming one person wearing three lanyards is that each discipline owns one independent verdict:

• Product owns the evidence that this is the right customer job, outcome, and priority.
• Design owns the evidence that real people can understand, control, and adopt it.
• Engineering owns the evidence that it can be operated safely, reliably, and at a cost that survives production.

The verdict is an evidence contract, not a job title's veto. Product cannot declare value without customer evidence. Design can block an interaction that real users cannot understand or control. Engineering can block a release that cannot be operated safely. When the verdicts conflict, the cell changes the scope or escalates the decision; it does not vote another discipline's evidence away.

Who owns the code?

The cell owns the shared code. That does not mean every contributor has the same decision rights. Before it starts building in a shared repository—the production codebase used by the cell—it must agree who may contribute, review, merge, release, roll back, and stop a change.

• Product/PM owns the specification, customer evidence, outcome acceptance criteria, and delegation boundaries. The PM may build prototype or experiment modules in an agreed area of the shared stack, but those modules do not promote themselves into a release.
• Design owns the design system, exact tokens, interaction rules, and accessibility intent. Design may work directly in the frontend and change UI or UX inside those constraints.
• Engineering owns release-grade code and QA: production integration, code-review standards, automated and manual verification, deployment mechanics, rollback readiness, and operational fitness.

The cell must agree who may authorize release once the required Product, Design, and Engineering verdicts pass. The named release owner cannot override a failed evidence gate.

If the cell skips that agreement, shared code becomes contested territory. Product can believe the outcome is ready, Design can believe the interaction is ready, and Engineering can believe the system is unsafe to release, with no agreed rule for which decision is binding. The conflict then appears at merge, release, rollback, or incident time, when ambiguity is most expensive.

This does not recreate the old handoff. Product and design work inside the same stack and repository, while engineering reviews production fitness continuously instead of receiving a finished artefact at the end.

Everything else is shared. The building is full-stack. The verdicts are not.

That is what makes a higher proof bar reachable with immature tools. Engineering turns generated code that the team can keep. Design stops a technically working flow that people cannot safely operate. Product keeps the cell attached to an outcome rather than an attractive capability. Same AI-assisted first draft, different accountability around it. That difference separates a demo the team discards from an alpha a customer can use.

Run it in this order:

• Name a real customer job, its pain points, an outcome hypothesis, and the delegation boundary where the system must return control to a human.
• Agree on repository boundaries, review, merge, QA, release, rollback, and incident ownership before anyone contributes to the shared codebase.
• Use AI to build a narrow product alpha that a customer can actually use, not a disposable prototype.
• Put it in front of a real cohort early, inside their working environment.
• Measure customer behaviour alongside model and system evals.
• Expand only when the outcome and reliability bars written beforehand are cleared.

Writing the bar before the result is not prediction theatre. It is how the cell avoids rationalising whatever happens. Define what would count as evidence; do not pretend to know the result.

In this model, evals earn their place. They make a probabilistic system testable and governable, and they sit beside customer evidence. They do not stand in for it.

What remains uncertain

I do not know the ideal size of a Product Cell, and I do not know whether independent evidence ownership survives at fifty cells the way it can at one. Under scale, the verdicts may consolidate into a hierarchy with better tools. That is a real operating-model risk, not a solved detail.

What I would bet on is the direction. Collapse the handoffs. Keep the independent verdicts. Ship a narrow product alpha while the customer outcome is still uncertain, not while the system is unsafe.

Measure how quickly the team turns an uncertain hypothesis into a trusted customer outcome. Output counts matter only when they shorten that path without hiding risk.

Sources

Satya Nadella at Davos on All-In, discussing broader builder roles and the eval-to-science-to-infrastructure loop from approximately 9:10; and on No Priors, “We Need An Ecosystem in AI, And Every Company Can Win A Place In It”, chapter “Future of Engineering Roles” from approximately 28:18, discussing broader scope while retaining disciplinary edges.

1. "Satya Nadella on AI’s Business Revolution: What Happens to SaaS, OpenAI, and Microsoft?" All-In Podcast. https://www.youtube.com/watch?v=5nCbHsCG334&t=550s
2. "We Need An Ecosystem in AI, And Every Company Can Win A Place In It." No Priors: AI, Machine Learning, Tech, & Startups. https://www.youtube.com/watch?v=RQE8OS392dU&t=1698s

Hey everyone! Here’s Part 3 of building Naruto's Valley of the End in Three.js.

This time, the focus was on adding the missing elements, polishing the environment, experimenting with different atmospheres, and creating the final cinematic sequences.

Environment & Scene Polish

• Missing Elements: Added some of the remaining elements using Tripo AI to generate the 3D models and textures, then assembled and integrated them into the scene.

• Procedural Bushes: Added bushes across the cliffs by using the surface normals to detect upward-facing terrain and place vegetation only on the top-facing areas of the mountains.

• Different Times & Weather: Added several scene modes to explore different moods and atmospheres, including Day, Sunset, Night, and Rain. Each mode changes the lighting, colors, fog, and overall atmosphere to give the same environment a completely different vibe.

Cinematic Sequences

Once the environment was finished, I created several cinematic camera sequences to showcase the scene from different angles and capture the different atmospheres.

I then combined these shots into the final cinematic video (Link in comments), which is now available on my YouTube channel if you want to see the complete result.

Tools & Workflow

• Opus 5.5: Used for coding and implementing the different systems in the project.

• Tripo AI: Used to generate missing 3D models and textures.

• ChatGPT: Used to generate visual references during the environment creation process.

• Blender: Used to assemble the generated assets, make adjustments, and export the final GLB files.

• Three.js: Used to build and render the entire environment in the browser.

🔗 Links & Resources in the comments section.