mgdev

Plus your agent (strictly speaking) doesn't need to generate parens as tokens. Instead they can generate imperative stack commands that manipulate the AST. Or something paredit-like.

They should reboot, focused on

1) humans (AI assisted or not) answering with real-money stakes, and

2) people betting on which humans are correct (borrow page from prediction markets)

This does four things simultaneously:

1) It introduces consequences for being wrong, which in turn introduces real asymmetric incentives to be contrarian-but-correct - which are high-value answers you don't get out of a stock model

2) It creates real-world incentives for human guided votes to answers (because, again, there's a real-world stake)

3) Together, this gets humans back on the platform answering questions, which creates meaningful exhaust data that can be sold back to the AI companies.

4) It creates incentives to game the system, which creates yet-more exhaust data for training anti-fraud AI systems

Wouldn’t it be wonderful if, in the world of LLMs, Lisp became the new lingua franca, because we don’t have to convince humans that parens are scary, and because it enables exactly this kind of magic.

Full circle for Lisp as an AI language.

This was true of software development before LLMs as well.

You may also consider that developers (like any person in any profession) exist on spectrum of competency, and you may just be better than most of them.

But models are climbing their way up the percentile charts.

90% of the software development in the work, by volume, can be done by people who are in the 50th percentile of skill.

So these model advances do meaningfully expand the amount of "useful" work that can be done without people. And simultaneously not be "good enough" for the specific kind of work you find yourself doing day to day.

Both can be true.

> I don't think either approach is insane, immoral, or any other hyperbole.

Agree! To me it comes down to intention and attention.

Depending on my *intention*, I should devote more or less of my *attention* to one thing vs another.

Another way to think about it is essential vs incidental attention, which I borrow from essential vs incidental complexity [0].

Many things require attention, or it doesn't perform correctly. Essential attention. Many, many more things don't require my full attention, and they'll still perform adequately. They satisfice.

Farm out the tasks that require only incidental attention.

[0]:https://github.com/papers-we-love/papers-we-love/blob/main/d...

It depends on how you use it.

AI helps you build more software in the same way that a C compiler helps you build more assembler.

I spend far more tokens on specification and verification than I do on actual feature-code generation.

And with it a small team of 3 developed something in just a few weeks that would have normally taken us 12 months. And we are selling it for multiple-seven figures to customers who (by all rights) should have been able to token-gen their way to the same outcome, but haven't.

So there is clearly some value in the people, and clearly some value in the AI. But I think people are misplacing/misattributing which goes where, in some cases.

False dichotomy IMO.

I've rarely met a "craft" person that authors TLA+ models to find correctness issues in their systems. And yet as an outcome person I frequently ask my AI minions to do this and similar exercises.

What I think you're actually describing is competency using AI as a tool to drive effective and correct outcomes. That takes practice and systems - same as it ever was.

If you buy in, I think you'll find you can create great, correct systems... only more than you could ever do alone. Without N*N comms overhead. Without having to convince your louder, less competent teammate to actually finish their work.

Not insane at all. There are two types of developers: those who do it primarily for the outcomes, and those who do it primarily for the craft. These are fundamental orientations.

Do craft people like outcomes? Sure. Can outcome people appreciate craft? Sure. But fundamentally, you typically fall more in one camp than the other.

And this assertion comes from the outcome people. Is it insane? No. To assert it's insane is insane, because it shows a fundamental disconnect from the economics of software development.

Which is about right, because the craft people don't do something primarily for the economics.

> This is likely a pricing failure.

Problem is while we have a visceral feel for what the "value" of GitHub is to human users for human usage, I'm not sure we have a feel for what the value of the agentic equivalent is.

IMO it's probably very high on paper if you think through what kind of work is unlocked at agent speeds, provided you have a very capable work-execution fabric.

But since we're anchored to human pricing, whatever they propose will feel expensive.

Sure, but now a single person can do newer, bigger things that were previously "impossible" for a single person, and now merely "hard".

YAML-defined agents are great.

Have you considered making a cloudy, managed version?

I want to believe, but the first phone was like six months late with no/bad comms, and when it came it was barely usable due. I believe in the mission but have lost some faith here.

I hope they prove me wrong so I can buy Minimal Phone 3!

Never bet against Clay.

> Whatever they did to market the product

Not-JIRA + dark mode + usable APIs will take you far.

Mitchell is a bellwether.

This is a 'tipping point' situation. Exodus will be a little at a time, then all at once.

It's a mistake to confuse what you're seeing out of today's models with what you'll see out of future ones. We're barely out of the gate on this stuff. We'll borrow what works, and use it to bootstrap something better.

I can't tell if you're trolling.

Nothing precludes you from doing that with AI-gen code vs human-gen code. What you just described is downstream.

If you have a human authoring code, you re-roll every time they release a new version. AI just releases versions faster, and in response to different, faster-moving inputs.

You already do this with human-authored code, just slowly.

Project model capabilities out a few years. Even if you only assume linear improvement at some point your risk-adjusted outcome lines cross each other and this becomes the preferred way of authoring code - code nobody but you ever sees.

Most enterprises already HATE adopting open source. They only do it because the economic benefit of free reuse has traditionally outweighed the risks.

If you need a parallel: we already do this today for JIT compilers. Everything is just getting pushed down a layer.

This is an economically sound conclusion.

It also means that you need to extract enough value to cover the cost of said tokens, or reduce the economic benefit of finding exploits.

Reducing economic benefit largely comes down to reducing distribution (breadth) and reducing system privilege (depth).

One way to reduce distribution is to, raise the price.

Another is to make a worse product.

Naturally, less valuable software is not a desirable outcome. So either you reduce the cost of keeping open (by making closed), or increase the price to cover the cost of keeping open (which, again, also decreases distribution).

The economics of software are going to massively reconfigure in the coming years, open source most of all.

I suspect we'll see more 'open spec' software, with actual source generated on-demand (or near to it) by models. Then all the security and governance will happen at the model layer.

Once upon a time S3 used to cache small objects in their keymap layer, which IIRC had a similar threshold. I assume whatever new caching layer they added is piggybacking that.

This keeps the new caching layer simple and take advantage of the existing caching. If they went any bigger they'd likely need to rearchitect parts of the keymap or underlying storage layer to accommodate, or else face unpredictable TCO.

One thing you can try is powering Clawdbot with a local model. My company recently wrote[0] about it.

Unclear what kind of quality you'll get out of it, but since the tokens are all local, kinda doesn't matter if it burns through 10x more for the same outcome.

[0]:https://www.docker.com/blog/clawdbot-docker-model-runner-pri...

I offhandedly set it up to do a weather alert every 4 hours during the big winter storm. Absent a well-specified API, I can only assume it was repeatedly doing a bunch of work to access some open API it discovered.

Very much the LLM equivalent of “to bake an apple pie you must first invent the universe”.

To its credit, it did a great job.

This thing is cool except:

1) It chews through tokens. If you're on a metered API plan I would avoid it. I've spent $300+ on this just in the last 2 days, doing what I perceived to be fairly basic tasks.

2) It's terrifying. No directory sandboxing, etc. On one hand, it's cool that this thing can modify anything on my machine that I can. On the other, it's terrifying that it can modify anything on my machine that I can.

That said, some really nice things that make this "click":

1) Dynamic skill creation is awesome.

2) Having the ability to schedule recurring and one-time tasks makes it terribly convenient.

3) Persistent agents with remote messaging makes it really feel like an assistant.

It's the perfect honeypot.

After 20+ years with Apple, I'm 90% on Linux at this point.

Two desktops, two AI workstations, two laptops, and a handheld. Even my wife is running Linux.

My personal phone and work laptop are the last holdouts.

Very simple. Undermines their ad business - which is their fastest-growing profitable business.

Hear hear. Elixir is a dream for this kind of stuff. But it requires very different decisions "all the way down" to make it work outside of BEAM. And BEAM itself feels heavy to most systems devs.

(IMO it's not for many use cases, and to the extent it is I'm happy to see things like AtomVM start to address it.)

I'm just happy I can use Elixir + Zig for NIFs.

Yes. Obvious to anyone who writes AI garbage all day.

That makes zero sense.