321–330 of 337 posts
Earlier quoted context omitted.
> Mythos does not produce exploits. AI in general will, don't worry. "Move fast and break things" makes more exploits than "move steadily and fix things" does.
But doesn't AI ultimately obviate "move fast and break things" by making it easier to move fast without breaking things?
This move by Cal.com seems to be transparently an attempt to maintain that paywall against users who'd otherwise just use LLMs to remove it. I guess it's back to EasyAppointments, which still seems to work just fine.
The real threat is not security but bad actors copying your code and calling it theirs. IMHO, open source will continue to exist and it will be successful but the existence of AI is deterrent for most. Lets be honest, in recent times the only reason startups went open source first was to build a community and build organic growth engine powered by early adaptors. Now this is no longer viable and in fact it is simply…
> The only open source that will remain will be the real open source projects that are true to the ethos.
Well, the second point seems like the answer to the previous question. The original model of monetizing FOSS -- support contracts, risk indemnification, etc., for an otherwise functionally equivalent product -- will still remain viable.
But those trying to thread the needle of trying to use open-source to push a "freemium" model are now going to hit a wall: if you were withholding features from the community version in order to paywall them for the premium version, and now AI has made it easy for users to add those features back without paying you, then you're screwed. The people who were going to use AI to bypass your paywall are still not going to be your customers, but you no longer have the differentiator to put you ahead of the competitors that were already closed-source to begin with for the customers who are willing to pay.
I originally deployed Cal.com because I wanted an open-source solution. But now, why would I choose a closed-source Cal.com over Calendly? If I'm forced to go SaaS, I'll probably go with the more widely used Calendly. If I'm not forced to go SaaS, I'll forego them both, and go back to something like EasyAppointments, knowing that I won't be in conflict with the authors if I choose to add my own "premium" features to it, whether with AI or by hand. All Cal.com did here was remove any chance that I'd ever pay them anything.
I'm sorta suspicious. I don’t really think this is why they are moving to closed source. It’s true that there is more security risk, but that actually justifies being open source, because open source tooling can spend more tokens hardening itself against security vulns than closed source tooling (at least, that’s the theory). My strong hunch is they are moving to closed source because it is now trivial to copy a prod…
The "clean room" part of clean-room reverse engineering implies that there is no exposure to the original copyrighted code on the part of those doing the reimplementation, whether human developers or AI. Traditionally, if you're working of the source code itself, you have one party translate the source code back into a design document, specifying behavior, and then you have another party implement that design spec with original code.
If you already have a running copy of the software to model the behavior off of, then you don't need the original source code in the first place. So going closed source will have zero effect on the capacity of AI tools to be used for clean room reverse engineering: all you need is the runtime.
> But I'd want to see more adoption of something like the Ship of Theseus license (https://github.com/tilework-tech/nori-skillsets/pull/465/cha...) before giving up on open source entirely
This license doesn't seem valid: a license can't redefine what qualifies as a derivative work. That's determined by copyright law itself, and if copyright law says that a clean-room reimplementation isn't a derivative work, then it isn't restricted by copyright, so doesn't need a license in the first place.
Earlier quoted context omitted.
But doesn't AI ultimately obviate "move fast and break things" by making it easier to move fast without breaking things?
Not at all, no; AI makes it harder to not break things, and it takes a lot of work to not break things.
But why would responsible AI users -- actual engineers using it to accelerate grunt work, not vibe coders -- not use the AI tooling to increase their capacity to do all of the work it takes to avoid breaking things while still moving fast, relatively speaking?
Testing a new incremental feature against the entire extant codebase, not just the bits of it that they had the bandwidth to tackle within the deadline, seems like exactly the sort of thing well-disciplined engineering teams would use AI to do.
Earlier quoted context omitted.
And that is why the only winning move is owning a GPU.
With current GPU prices, I find it difficult to find hardware to run competent models. gemma4's 26B MoE model seems to offer the best performance per megabyte of RAM, but it's not good enough to use the way one would use cloud models. The big, impressive models all scale well for multi-customer setups because of the efficiency batching provides, but the base cost to run models like that as even a small business is in…
But also the Strix Halo 128 is pretty hard to beat.
Earlier quoted context omitted.
Not at all, no; AI makes it harder to not break things, and it takes a lot of work to not break things.
It does take a lot of work not to break things. That's why "move fast and break things" are traditionally closely coupled: it's hard to avoid breaking things without slowing down. But why would responsible AI users -- actual engineers using it to accelerate grunt work, not vibe coders -- not use the AI tooling to increase their capacity to do all of the work it takes to avoid breaking things while still moving fast,…
For one, you architect your codebase into separate layers and logical chunks that are self-contained and can be reasoned about independently. That's not always possible, but you draw as many firm boundaries as you can. You don't ever want to be in the position where you have to test an entire codebase against your new change. That's a horrible nightmare scenario.
So you don't "test as much of the codebase as you have time for", you write tests for your code and the interface between it and other systems. Maybe integration or FE tests depending on what you have.
So testing against a whole codebase is rarely the problem, and if it is, you have bigger issues.
Also, LLMs don't make mistakes like humans do. They fuck up in weird unpredictable ways that mean you kinda have to treat them like a hostile adversary trying to sneak in subtle backdoors. It slows things down.
Also, actually writing code is usually the fast and easy part. It's all the other bits -- getting the requirements, building mockups, planning, review, standing up new infra etc etc etc. LLMs can't help with most of that.
Earlier quoted context omitted.
This is much less work (= cheaper) to develop in-house with AI now than before.
I don't think it's much cheaper . Writing some code to do some CRUD has always been easy. Getting to a proof of concept is definitely quicker. But creating something that can be relied upon in production? That's as difficult and time consuming as it has ever been.
It sounds nice, but now you have something that takes an enormous amount of time and effort to use and maintain, plus you need to have someone with the skills to run it.
Drew Breunig published a very relevant piece yesterday that came to the opposite conclusion: https://www.dbreunig.com/2026/04/14/cybersecurity-is-proof-o... Since security exploits can now be found by spending tokens, open source is MORE valuable because open source libraries can share that auditing budget while closed source software has to find all the exploits themselves in private. > If Mythos continues to find e…
Security should be a non issue in the age of AI now that auditing is cheaper than ever. I'd give them more credits if they use the AI slop unmaintainability argument.