mgdev

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.

This is, as they say, "The beginning of the end."

Alyssa Henry is former AWS, and an absolute monster of a leader.

I was trying to be ironical.

it's pretentiousness thinly disguised as modesty.

trust me.

You are right, it is a good litmus test.

I suppose it depends on which battle you’re choosing to fight.

When I enter such orgs, I join to fix the org. And I want every tool at my disposal to do it.

I love turnarounds. But they require careful management of energy. So if I have an opportunity to convince someone to change a name now, it saves me a bunch of energy later.

FWIW, I learned this while getting both React and Clojure approved for internal use at a Fortune 100 co. Took me weeks. Both had problematic licensing issues, both of which could have been avoided if the authors had spent 10 extra minutes clarifying a few small things a few years before.

Profitable operations, doubling previous adjusted EBITDA. [0]

While not a yet an ROI-positive takeover, on an incredible valuation growth trajectory from the post-acquisition low. Likely to be positive the minute xAI meaningfully monetizes Grok. [1]

Gains strategic access to global training data, and real-time human sentiment. [2]

Incredible built-in distribution for new AI-powered products. [3]

Literally tipped the scales in an election, a role typically reserved for traditional media companies. [4]

Yes, a total failure of a business. /s

[0] https://x.com/Austen/status/1887363437518270757

[1] https://techcrunch.com/2025/04/12/the-xai-x-merger-is-a-good...

[2] https://www.reuters.com/technology/elon-musk-says-xai-will-u...

[3] https://digiday.com/marketing/with-600-million-users-xs-lind...

[4] https://techcrunch.com/2024/02/07/x-formerly-twitter-becomes...

My company had what was at the time one of the largest Slack enterprise contracts. You have no idea what internal corporate battles we had to face to get our higher-ups to take us seriously at every stage of adoption, and ultimately roll it out en masse. Slack succeeded in enterprise in spite of its name, not because of it. The actual product was phenomenal, relative to alternatives.

Yes, when you have the notoriety, distribution, and reputation-for-insults that Linus does, you can get away with things like that, because you're selling into a culture that already understands the "joke".

I know a little about getting large companies to use unknown and "risky" tech. I've done it a number of times (including one I'm especially proud[0] of, and that is relevant given the Clojure connection), and built more than one billion-dollar product doing so.

Names have incredible power, positive or negative, when something is in its infancy.

At the start, when it's just you, and maybe one other person, and maybe one more than that... and your entire effort is just a wisp of what it could one day be, all it takes is some random fly-by-night architect (or even project manager) walking by, hearing the name, and saying, "No way am I letting something called jank touch this project," and shutting it down. The ol' swoop-and-poop, but for incredibly understandable reasons: corporate drones are superstitious.

Now... if, as a matter of culture building, you're intentionally leaning into the "jank" name, that's different. Because names have incredible power. So if you're cobbling together a cadre of crack hackers, "jank" might be exactly what you need to telegraph exactly the ethos you want to manifest.

But if you're just looking for a memorable name to slap on something you hope will actually get traction in any production capacity, I'd just ask that Jeaye consider if the potential benefits outweigh the risks.

[0] https://www.linkedin.com/pulse/building-cloud-choosing-lisp-...

I love this project. I've been a sponsor on GitHub since late last year.

But for the love of... please pick a different name.

Whatever reasons companies/teams will have for not letting someone use Jank at work, don't let the name be one of them.

I wrote an app to help mitigate this exact problem. It sits between all my MCP hosts (clients) and all my MCP servers, adding transparency, monitoring, and alerting for all manner of potential exploits.

This is awesome. I've been in software for 20+ years now as well.

One thing I've noticed is many (most?) people in our cohort are very skeptical of AI coding (or simply aren't paying attention).

I recently developed a large-ish app (~34k SLOC) primarily using AI. My impression is the leverage you get out of it is exponentially proportional to the quality of your instructions, the structure of your interactions, and the amount of attention you pay to the outputs (e.g. for course-correction).

"Just like every other tool!"

The difference is the specific leverage is 10x any other "10x" tool I've encountered so far. So, just like every tool, only more so.

I think what most skeptics miss is that we shouldn't treat these as external things. If you attempt to wholly delegate some task with a poorly-specified description of the intended outcome, you're gonna have a bad time. There may be a day when these things can read our minds, but it's not today. What it CAN do is help you clarify your thinking, teach you new things, and blast through some of the drudgery. To get max leverage, we need to integrate them into our own cognitive loops.

Local LLMs will solve this.

If we zoom out far enough, and start to put more and more under the execution umbrella of AI, what we're actually describing here is... product development.

You are constructing the set of context, policies, directed attention toward some intentional end, same as it ever was. The difference is you need fewer meat bags to do it, even as your projects get larger and larger.

To me this is wholly encouraging.

Some projects will remain outside what models are capable of, and your role as a human will be to stitch many smaller projects together into the whole. As models grow more capable, that stitching will still happen - just as larger levels.

But as long as humans have imagination, there will always be a role for the human in the process: as the orchestrator of will, and ultimate fitness function for his own creations.