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 today?
@OpenAIDevs /hatch is not recognized. /pet only toggles. I've updated desktop app and CLI. Distractions are extra distracting when you can't get it to work.
@LaurenceBrem@code My bet is that itโs got different instructions. It seems to be more thorough as if itโs being told to ultrathink and one-shot the solution.
@ah20im - It constantly thinks it doesnโt have tool access that it has
- It often attempts constructing raw API calls rather than use clearly defined MCP servers
- Planning mode!
- Sub-agents!!
- Keyboard shortcut to toggle perms
- pwd in prompt box
- Faster editing previous messages
3. In a 2nd Codex instance, same dir:
/dhh-linear-plan-review
- Fetches issue from Linear again (Linear MCP)
- Scans project
- Reads the md (named after dir in ./planning/)
- Provides savage feedback in the md file
Back to 1st instance:
/read-plan-feedback
- You know the rest
Not to fangirl, but Iโve gotten the best #AICoding results by telling one instance of Codex to code like they are @dhh (DRY, expressive, self-documenting, etc.) and another instance to review the work like DHH deciding if a PR should make it to Rails core.
Reviewer is merciless.
2. I have a few Codex prompts that make all this a breeze:
/dhh-linear-coder
- Sends the DHH bit
- Pulls a Linear issue based worktree name
- Reads the project
- Thinks about a plan
- Calls Gemini 2.5 Pro & Opus for feedback on its plan
- Saves plan in a md file named for issue
@zeekay Maybe we're all just a skilled fine-tuning away from being amazing. Maybe I've only been dating people who are very bad at fine-tuning. Honestly, reinforcement fine-tuning, where the reinforcement is snacks, would work on me.