I saw this and like the perspective. Which of these do you think will be most valuable or highest demand? I think #4 As engineering, product, design, DS, etc. melt into a new kind of role, I was reflecting on what roles might look like in the future. For example, when I look at the Claude Code team I see what I think is five archetypes: 1. Prototyper: comes up with brand new ideas; churns out many ideas, most of which don't ship 2. Builder: quickly turns a prototype/idea into production-grade product/infra 3. Sweeper: cleans up the UI, simplifies the code and system, unships, optimizes performance 4. Grower: takes a product that has been built and iterates on it to improve Product-Market Fit 5. Maintainer: owns a mature system to make it secure, reliable, fast, and efficient as it scales Many people span across 2 roles, and sometimes 3 roles. I also notice that these roles are not really tied to job function -- eg. across Anthropic, some designers match category 1, some 2, some 3; same for engineers, PM, DS. A healthy team needs a mix of these, depending on the product: - A product that is new and pre-PMF needs people that are strong at 1+2+3 - A product that is growing and has found PMF needs 2+3+4 and some 5 - A product that has strong PMF needs 3+4+5 and some 2 Maybe product roles of the future will look more like this, and less like the domain-specific roles of toda? https://x.com/bcherny/status/2071379474277613732?s=46

Working through a long-term project with my agent (Hermes on a Mac Mini, talks through Slack right now). Right now it's just me talking to her, but as I bring in more people on the ops side, I want a real way to control who can tell her to do what, not just whoever's in the Slack channel. First piece I'm building: a permissions management UI sitting outside Slack. Before I start from scratch, curious if anyone in here has already solved this for their own setup. What did you build it on, and what would you do differently if you started over? For anyone who wants context on what I'm going to build (slowly) ---- What this is An internal tool for my own business, not a product I'm trying to sell. Alina is an AI agent running on a Mac Mini via the Hermes gateway framework, currently accessible only through Slack. This is a long-term, incremental build — roughly an hour or two a day, ongoing, no fixed deadline. Think of it the way you'd think about developing an employee: capabilities, access, and trust grow over time as Alina takes on more tasks, more integrations, and more data. The actual problem Talking to an agent purely through Slack conversation doesn't scale as a way to manage or trust it. Every instruction, every permission, every piece of context lives in scattered messages. There's no way to verify she actually did what was asked — only her own report that she did it. As she takes on more tasks, more connections, and more integrations, that gap gets worse, not better, because there's more surface area and no more visibility than before. This is a verification problem first, and a control/visibility problem second. A nice dashboard showing what she's capable of doesn't fix it if it can't also show what she actually did. The vision: a web control plane alongside Slack Not a replacement for talking to her in Slack — a second surface that gives direct visibility and control, instead of relying entirely on her self-reporting. It covers five things: Skills and jobs. What she's capable of doing, and what she's actively running or scheduled to run. Read-only visibility into her current capability set.

How is everyone hosting their business data?