Adding MCP and code mode seems so antithetical to the minimal ethos, I almost would believe they got incentives from Jen, but I don't want to be that cynical.
I adopted Pi for both of these reasons, and the strength with which they were stated gave me the confidence to lean in.
The rationale for MCP and codemode I can swallow, Armin's writing on that makes a lot of sense, and meeting models where they are seems critical to me based on my own experience.
But for me, fullscreen mode is a huge turn-off. I already have a backbuffer that I strongly prefer to use, it's called my terminal, and it's important to me. If the backbuffer-based version disappears, I'll be forced to migrate to something else (seems there are a few options here) or make my own tool, but that involves abandoning or porting my extensions, which turned out to be a huge superpower with Pi. Perhaps Pi Durable helps with that and lets me keep my extensions, but I'd rather this was not necessary in the first place.
If switching to full-blown TUI has anything to do with how slow the "expand thinking" and "expand tool output" features get as the session gets longer, could that be mitigated by only expanding the n most recent behind the default shortcut, and the slower "nah, I really do want you to expand them all thanks" can be a different shortcut?
If it's to add more fancy features that require fullscreen rendering and a dyed-in-the-wool terminal user like me might reasonably tolerate as a dismissable modal, make those bits TUI, but keep the backbuffer in the terminal (for e.g. the session tree or the settings, those don't need to be in the terminal's scrollback).
And if it's for any other, richer interactions... can we just... not, instead, and let the terminal be the terminal rather than a single page web app?
blahgeek · · focus · HN ↗
They explicitly said no MCP and no fullscreen TUI, which makes it minimal and attracts many people.
skohan · · focus · HN ↗
capocasa · · focus · HN ↗
shabbyrobe · · focus · HN ↗
The rationale for MCP and codemode I can swallow, Armin's writing on that makes a lot of sense, and meeting models where they are seems critical to me based on my own experience.
But for me, fullscreen mode is a huge turn-off. I already have a backbuffer that I strongly prefer to use, it's called my terminal, and it's important to me. If the backbuffer-based version disappears, I'll be forced to migrate to something else (seems there are a few options here) or make my own tool, but that involves abandoning or porting my extensions, which turned out to be a huge superpower with Pi. Perhaps Pi Durable helps with that and lets me keep my extensions, but I'd rather this was not necessary in the first place.
If switching to full-blown TUI has anything to do with how slow the "expand thinking" and "expand tool output" features get as the session gets longer, could that be mitigated by only expanding the n most recent behind the default shortcut, and the slower "nah, I really do want you to expand them all thanks" can be a different shortcut?
If it's to add more fancy features that require fullscreen rendering and a dyed-in-the-wool terminal user like me might reasonably tolerate as a dismissable modal, make those bits TUI, but keep the backbuffer in the terminal (for e.g. the session tree or the settings, those don't need to be in the terminal's scrollback).
And if it's for any other, richer interactions... can we just... not, instead, and let the terminal be the terminal rather than a single page web app?
badlogic · · focus · HN ↗
shabbyrobe · · focus · HN ↗