jake
@yetanotheruseless.com
he/they
/in/jakemannix, fka @pbrane
professionally: Tech Fellow, AI/Relevance, Walmart Global Tech
here: bad math/physics jokes, AI++, puns, OSS ML news, ultras/MTB/outdoorsy stuff, DL papers, shitposting, the fall of democracy
Abolish ICE, full stop.
/in/jakemannix, fka @pbrane
professionally: Tech Fellow, AI/Relevance, Walmart Global Tech
here: bad math/physics jokes, AI++, puns, OSS ML news, ultras/MTB/outdoorsy stuff, DL papers, shitposting, the fall of democracy
Abolish ICE, full stop.
terminal if I have laptop available, otherwise phone
January 13, 2026 at 4:39 AM
terminal if I have laptop available, otherwise phone
I pretty much agree with you on that. I've used it for a year, and if I were price-sensitive, I probably wouldn't pay for it.
January 12, 2026 at 7:10 PM
I pretty much agree with you on that. I've used it for a year, and if I were price-sensitive, I probably wouldn't pay for it.
for a different purpose.
OpenCode is like OSS Claude. Warp.dev is to have a shell which allows you do just do normal terminal things, but also
/home/me $ find all my pdfs i've opened in the last week which are at least 5mb
and it writes the bash on the fly to do that for you
OpenCode is like OSS Claude. Warp.dev is to have a shell which allows you do just do normal terminal things, but also
/home/me $ find all my pdfs i've opened in the last week which are at least 5mb
and it writes the bash on the fly to do that for you
January 12, 2026 at 6:31 PM
for a different purpose.
OpenCode is like OSS Claude. Warp.dev is to have a shell which allows you do just do normal terminal things, but also
/home/me $ find all my pdfs i've opened in the last week which are at least 5mb
and it writes the bash on the fly to do that for you
OpenCode is like OSS Claude. Warp.dev is to have a shell which allows you do just do normal terminal things, but also
/home/me $ find all my pdfs i've opened in the last week which are at least 5mb
and it writes the bash on the fly to do that for you
it's good! post! other than recon, it's the one good reason to be on there.
January 12, 2026 at 6:23 PM
it's good! post! other than recon, it's the one good reason to be on there.
I actually *love* transforming my terminal into something I can talk to in natural language: warp.dev is a uplift in terms of *nix productivity. In theory it can help bring the terminal to the masses, as well.
Warp: The Agentic Development Environment
The fastest way to build with multiple AI agents, from writing code to deploying it. Trusted by over half a million engineers, Warp gives developers speed, privacy, and control to ship faster.
warp.dev
January 12, 2026 at 6:22 PM
I actually *love* transforming my terminal into something I can talk to in natural language: warp.dev is a uplift in terms of *nix productivity. In theory it can help bring the terminal to the masses, as well.
you're referring to consumer software? Hasn't that turned into a lost cause, long before AI?
Or are you talking about BigAI locking people into their LLM APIs via subscriptions as well, in some new way?
Or are you talking about BigAI locking people into their LLM APIs via subscriptions as well, in some new way?
January 12, 2026 at 6:20 PM
you're referring to consumer software? Hasn't that turned into a lost cause, long before AI?
Or are you talking about BigAI locking people into their LLM APIs via subscriptions as well, in some new way?
Or are you talking about BigAI locking people into their LLM APIs via subscriptions as well, in some new way?
Ah, the nebulous "they". As someone who's been doing "general purpose computing" professionally for more than half of my life, I'm finding it *so much better* with the new AI coding tools.
(but yes, google AI snippets are utter garbage)
(but yes, google AI snippets are utter garbage)
January 12, 2026 at 6:04 PM
Ah, the nebulous "they". As someone who's been doing "general purpose computing" professionally for more than half of my life, I'm finding it *so much better* with the new AI coding tools.
(but yes, google AI snippets are utter garbage)
(but yes, google AI snippets are utter garbage)
yeah, maintainability, auditability, versioning (MCP doesn't allow you to version tools, currently!), governance, allowing some amount of workflow determinism in our otherwise floppy magical stochastic space... would be a nice start, huh?
January 12, 2026 at 6:00 PM
yeah, maintainability, auditability, versioning (MCP doesn't allow you to version tools, currently!), governance, allowing some amount of workflow determinism in our otherwise floppy magical stochastic space... would be a nice start, huh?
<dr strangelove voice> "Vat is the point of heffing a distributed version control system to protekt your projects eff you're not going to tell your ozzur nodes about your project?!?
January 12, 2026 at 5:15 PM
<dr strangelove voice> "Vat is the point of heffing a distributed version control system to protekt your projects eff you're not going to tell your ozzur nodes about your project?!?
and amazingly, I managed to avoid Groucho's Pardox, following the list when it sensibly did not yet include me!
January 12, 2026 at 5:03 PM
and amazingly, I managed to avoid Groucho's Pardox, following the list when it sensibly did not yet include me!
so you can just re-clone it, since presumably it was pushed to origin <padme meme>?
January 12, 2026 at 5:01 PM
so you can just re-clone it, since presumably it was pushed to origin <padme meme>?
Well since I'd never join a club which would let me in, I should follow this list, as I'm not on it for some reason!
January 12, 2026 at 4:58 PM
Well since I'd never join a club which would let me in, I should follow this list, as I'm not on it for some reason!
y u no like git, fren?
January 12, 2026 at 4:55 PM
y u no like git, fren?
yep, my (partly done) plan of record is have a protobuf/JSON intermediate representation (so not tied to one set of impls) which define the combinations, but a primary typescript DSL for authoring it (strongly typed, maybe even a slick UI), and a rust backend for execution in a gateway/sidecar.
January 12, 2026 at 4:54 PM
yep, my (partly done) plan of record is have a protobuf/JSON intermediate representation (so not tied to one set of impls) which define the combinations, but a primary typescript DSL for authoring it (strongly typed, maybe even a slick UI), and a rust backend for execution in a gateway/sidecar.
yeah see, for local agents (Claude Code and the like), I think "give them a shell" is totally correct!
It's when you want some observability + governance and you want to factor out work into different teams and not have everybody reinvent the same rules where a little bit of structure might be nice
It's when you want some observability + governance and you want to factor out work into different teams and not have everybody reinvent the same rules where a little bit of structure might be nice
January 12, 2026 at 4:51 PM
yeah see, for local agents (Claude Code and the like), I think "give them a shell" is totally correct!
It's when you want some observability + governance and you want to factor out work into different teams and not have everybody reinvent the same rules where a little bit of structure might be nice
It's when you want some observability + governance and you want to factor out work into different teams and not have everybody reinvent the same rules where a little bit of structure might be nice
like, you maybe don't need a full stateful tool orchestration engine, but maybe having the ability to do simple schema projections, joins, unions, and sequences might be used.
January 12, 2026 at 8:12 AM
like, you maybe don't need a full stateful tool orchestration engine, but maybe having the ability to do simple schema projections, joins, unions, and sequences might be used.
yeah there's a point at which the power is so high, that the amount of complexity you've got is such that you're basically programming, and then a) only programmers would use it, and b) they'd need proper language tooling, so it'd be wasted.
But dial back the power/complexity a bit, and... useful?
But dial back the power/complexity a bit, and... useful?
January 12, 2026 at 8:11 AM
yeah there's a point at which the power is so high, that the amount of complexity you've got is such that you're basically programming, and then a) only programmers would use it, and b) they'd need proper language tooling, so it'd be wasted.
But dial back the power/complexity a bit, and... useful?
But dial back the power/complexity a bit, and... useful?
but I think we can get something close to that with ReAct + MCP + not break backwards compatibility, in the short-medium term.
January 12, 2026 at 7:13 AM
but I think we can get something close to that with ReAct + MCP + not break backwards compatibility, in the short-medium term.
Oh people can always code. And they can always prompt. I just think we're missing the ability to also just "configure" lego blocks of tools into deterministic bigger tools. That's the part I'm trying to see how far down the path of a "tool algebra" we really need (+whether stateful tools are needed)
January 12, 2026 at 7:13 AM
Oh people can always code. And they can always prompt. I just think we're missing the ability to also just "configure" lego blocks of tools into deterministic bigger tools. That's the part I'm trying to see how far down the path of a "tool algebra" we really need (+whether stateful tools are needed)
Yep. I think the *right* medium term state is really taking CodeAct and adding on some semblance of library management so the agents know what building blocks to code with, and then bolt on the stateful-agent setup, and they can re-use their functions, and sprinkle some progressive disclosure: boom!
January 12, 2026 at 7:11 AM
Yep. I think the *right* medium term state is really taking CodeAct and adding on some semblance of library management so the agents know what building blocks to code with, and then bolt on the stateful-agent setup, and they can re-use their functions, and sprinkle some progressive disclosure: boom!
Oh I'm not waiting for that shit. I've got a prototype that does what I want much better than this, with a configuration-driven, versioned virtual tool layer over MCP.
Just trying to see how far down the abstraction road I should go before putting it in front of more people.
Just trying to see how far down the abstraction road I should go before putting it in front of more people.
January 12, 2026 at 6:49 AM
Oh I'm not waiting for that shit. I've got a prototype that does what I want much better than this, with a configuration-driven, versioned virtual tool layer over MCP.
Just trying to see how far down the abstraction road I should go before putting it in front of more people.
Just trying to see how far down the abstraction road I should go before putting it in front of more people.
basically: we're currently "programming" by prompt, or: coding up big LangGraphs / bespoke harnesses / buggy, poorly specified, half-implemented pseudo-workflow engines, or even heavyweight full-fledged workflow engines like Temporal / BPMN.
Am I the only one who wants something in between?
Am I the only one who wants something in between?
January 12, 2026 at 6:33 AM
basically: we're currently "programming" by prompt, or: coding up big LangGraphs / bespoke harnesses / buggy, poorly specified, half-implemented pseudo-workflow engines, or even heavyweight full-fledged workflow engines like Temporal / BPMN.
Am I the only one who wants something in between?
Am I the only one who wants something in between?
i.e. the "inner join" of the (virtual) scores table with the catalog table.
Other example: You have search_jira, search_confluence, search_github_issues, search_asana. Would be nice to have search_docs = union(map(search_*, normalize_schema)) as one tool
Or "process_return then email_confirmation"
Other example: You have search_jira, search_confluence, search_github_issues, search_asana. Would be nice to have search_docs = union(map(search_*, normalize_schema)) as one tool
Or "process_return then email_confirmation"
January 12, 2026 at 6:19 AM
i.e. the "inner join" of the (virtual) scores table with the catalog table.
Other example: You have search_jira, search_confluence, search_github_issues, search_asana. Would be nice to have search_docs = union(map(search_*, normalize_schema)) as one tool
Or "process_return then email_confirmation"
Other example: You have search_jira, search_confluence, search_github_issues, search_asana. Would be nice to have search_docs = union(map(search_*, normalize_schema)) as one tool
Or "process_return then email_confirmation"
Each owns the service corresponding to these, knows the guts of the system inside and out, and then sees agents being built, so they each build MCP tools for their services. They are useful!
However, usually, you want (query + num_hits + col_list) -> rows w/item_id: (score, hydrated columns).
However, usually, you want (query + num_hits + col_list) -> rows w/item_id: (score, hydrated columns).
January 12, 2026 at 6:19 AM
Each owns the service corresponding to these, knows the guts of the system inside and out, and then sees agents being built, so they each build MCP tools for their services. They are useful!
However, usually, you want (query + num_hits + col_list) -> rows w/item_id: (score, hydrated columns).
However, usually, you want (query + num_hits + col_list) -> rows w/item_id: (score, hydrated columns).
So you're at a company where the catalog team and the search teams are separate.
* One owns forward lookups: list of item_ids + list of columns you care about -> rows with item_id: hydrated columns.
* other owns searching: query + num_hits -> length_num_hits pairs of (item_id, score) matches.
* One owns forward lookups: list of item_ids + list of columns you care about -> rows with item_id: hydrated columns.
* other owns searching: query + num_hits -> length_num_hits pairs of (item_id, score) matches.
January 12, 2026 at 6:19 AM
So you're at a company where the catalog team and the search teams are separate.
* One owns forward lookups: list of item_ids + list of columns you care about -> rows with item_id: hydrated columns.
* other owns searching: query + num_hits -> length_num_hits pairs of (item_id, score) matches.
* One owns forward lookups: list of item_ids + list of columns you care about -> rows with item_id: hydrated columns.
* other owns searching: query + num_hits -> length_num_hits pairs of (item_id, score) matches.