joshmarlow

I bet this was fun to think about and build. Thank you for sharing!

The ultimate goal of tokenized stocks is that the token is a share - just represented on the public blockchain instead of in the databases of companies like Fidelity. So in this respect, it's just changing the record keeping system. We're not quite there yet, but that's the vision.

Why would you do this? Current stock trading often takes a day or so to actually settle - you execute a buy but it doesn't settle immediately. There is room for leverage and counter-party risk to live in that gap.

Tokenized stocks (or any asset) is building towards atomic on-chain settlement - you have stock in MSFT, I have stablecoins, we perform an atomic transfer where you send me MSF and I send you stablecoins. This speeds up the system and eliminates counterparty risk. We each must have the asset ready to trade at this point in time.

The benefit is faster settlement, not keeping capital locked up because of long settlement times and decreasing the space where leverage and counter-party risk can live.

Longer term - this potentially means it could be easier for non-US parties to buy US stocks. I can put my savings in the stock market, but a farmer in a developing country cannot. But with tokenized shares, they could invest in US equities - or even a fraction of a US equity if they cannot afford a full share. So this longer term vision could democratize global access to capital markets.

I am reminded of this project having Claude supervise the care of a tomato plant - https://autoncorp.com/biodome/

There's definitely room to discuss how slop-like any of this is - but I do like the wholesome vibes.

Yeah I agree that monetization seems hard here. But one niche that might work - tons of people are using LLMs to build out side projects and keeping tickets in the same repo as the project could be really frictionless for LLMs to reach for without an MCP server.

Don't sell to developers for their day jobs, but sell to developers for their hobbies.

I've been thinking for a while that something like this could be a solution for the suboptimal UX in the digital assets space.

Imagine a very small LLM embedded into a MetaMask equivalent where you just specify the task you want to do - ie, "I want to send USDT on mainnet", "I want to import the token at address 0x..." - and the wallet assembles the UX for this task for the human to execute.

"End to end ownership is the job."

This is an incredibly good and concise articulation of where the role is going. Thank you.

I would not advocate nationalization of any operations - I think the free market will run the data centers better in general.

I'm only suggesting (eventual) negotiations between countries and automated corporations - to operate here, you contribute equity.

I don't understand why this got downvotes - simply extrapolating current trends leads to the need to answer all of these questions.

My own $0.02 on the economics piece - every country should have a sovereign wealth fund. Governments should block market access from automated[0] companies until those companies provide equity contributions to the wealth fund for that country. This aligns regulator and corporate interests. Dividends flow into the sovereign wealth funds and then can be allocated locally from there - UBI, job programs, etc. Let different jurisdictions explore different ways to structure a post-labor society.

On the broader social front - I think a lot of lack of meaning discussion boils down to the overemphasis we have on your job as your self-worth. We need to realign our societal expectations - and people need to spend more time with their families.

[0] for this to work, I think we would need well accepted metrics for 'how automated' a company is - and that probably needs a 3rd party auditing industry.

I've often thought that s-expression diff-viewers would be very nice tooling. I've also often wondered how easy it would be to just sling s-expressions across the wire to execute in another environment. What would modern infrastructure look like if you could just have lambdas running lambdas?

I've often wondered how viable it is to use AI to fill out the ecosystem gaps in awesome but niche languages (still looking at you OCaml...).

I've not gone too deep down this train of thought because a standard library/ecosystem should be solid and I don't think LLMs are quite there... but if we can use LLMs+Lean maybe we can get the quality we need to bootstrap more of the Lean ecosystem?

A couple of years ago I listened to a Lex Fridman podcast with a researcher at the MIT Media Lab. I don't know the status of it, but the researcher spoke about how people in developing countries were experimenting with using local resources as 3D printer feedstock - things like ground-up sea shells - as a way of using local supply lines.

One of the most interesting things he said was that the current waste from 3D printing (and other technology) is really a sign of technical immaturity; nature repurposes everything - there is no trash in an ecosystem, only food for something else. Maybe we'll eventually learn to build infrastructure like that.

I don't hear about them a lot but it looks like arcee.ai is aiming to be just that.

Here are some of their current open weight offerings: https://www.arcee.ai/open-source-catalog

That makes sense and had never occurred to me!

I just asked and Claude says it's Haiku.

Absolutely the same. Now that Fable is back, the Claude voice interface is... worth dealing with. The app mostly seems to have trouble recovering from networking issues which is jarring in a deep conversation.

I'm so mad that this might make me re-subscribe to ChatGPT. I wouldn't have believed how much I use the voice feature before LLMs and ChatGPT currently has the best voice interface. I think Grok's interface is the next best, then Claude.

One of the more counter-intuitive parts of management that I've found is that your focus shifts from delivering a technical outcome to care-taking a team that delivers technical outcomes. It's a meta-function.

A related physics metaphor - in general as you move from IC to SR to management, your focus shifts from changing the position to changing the velocity and acceleration of those around you.

It definitely violates DRY but if you keep passing the JWT down the call chain, you can do redundant permission checking in your business layer.

Now the reasonable response to the above is that this should be happening in a dedicated authn/z concern - and that is correct! But when paranoia is called for, it's not unreasonable to have redundant checks in logic where authz is critical.

His Blindsight is one of my all time favorite novels (sequel is good to). His short story Malak - about a military drone given a prototype ethical program - is so good.

This feels like this is exploring the reasons for what Doctorow calls "Enshitification" which is really exciting.

Another suggestion for optimizing local inference - the Hermes team talks a lot on X about how much better results are when you use custom parsers tuned to the nuances of each model. Some models might like to use a trailing `,` in JSON output, some don't - so if your parser can handle the quirks of the specific model, then you get higher-performing functionality.

I propose a claude skill to email glitter bombs where appropriate.

> Treat code design and architecture as the thing that lets your slop canons (90% of engineers even pre-ai) move fast without breaking things

I'm currently of the opinion that humans should be laser focused on the data model. If you've got the right data model, the code is simpler. If you've got the relevant logical objects and events in the database with the right expressivity, you have a lot of optionality for pivoting as the architecture evolves.

It's about that solid foundation - and of course lots of tests on the other side.

That's very interesting and is good evidence against the thesis - thanks for sharing!

Very true - which is why this piece "that translations of others words into 'happy' are somewhat approximate." would be very interesting if accurate.

I've not read Aristotle directly but translating eudaimonia was an example in the book that I mentioned. The argument was that eudaimonia is often translated as happiness but that doesn't make sense in contexts where we talk about a soldier dying experiencing eudaimonia (suggesting a loose translation).

A few years ago I read a claim that the word 'happy' is relatively young - ~500 years old - and that translations of others words into 'happy' are somewhat approximate.

My takeaway is that (presuming the argument is correct) that much of human striving is probably better described with specific words (as you suggested - joy, accomplishment, fulfillment, excitement, etc). For most of human history, most people probably didn't think "I want to be happy" but "I want to have a good partner", "I want a big family", "I want my crop to grow so I don't die."

I wonder how much unhappiness is caused by seeking a poorly-defined ideal of happiness.

The book was called "Power, Pleasure, and Profit: Insatiable Appetites from Machiavelli to Madison".

On a related note, this type of reasoning is what made me flip my opinion on microservices. I've generally been skeptical of a many-microservice architecture for the last decade but LLMs change that - a small microservice is more likely to fit in a context window.

I think this gestures at a more general point - we're still focusing on how to integrate LLMs into existing dev tooling paradigms. We squeeze LLMs into IDEs for human dev ergonomics but we should start thinking about LLM dev ergonomics - what idioms and design patterns make software development easiest for AIs?

Now I want my main agent to be modeled after the Adjutant and any subagents to sound like SCVs.

CoinBase sure does - https://www.x402.org/

Adding to your comment, I've found that frequent squashing of commits on the feature branch makes rebasing considerably easier - you only have to deal with conflicts on one commit.

And of course, making it easier to rebase makes it more likely I will do it frequently.