btown

From your experience are any of the big cloud providers more effective/careful at this than others?

I have a more nuanced take on this, which is that many engineers may have decent intuition on security - but that's entirely besides the point here, because without the political capital to have a large organization (and their customers and counterparties!) change their workflows and security stances, they're tilting at windmills. Security is not one of those things that one can throw bodies at - it requires true attention and commitment from leadership, and time to percolate across every facet of a company. If such a mandate is in place, talent is far from the limiting factor.

> the older code probably contains a ton of bugs already

The billion-dollar question is: what things might an LLM see as a bug or candidate for simplification, but supported a unique use case? https://xkcd.com/1172/ as always is prescient.

The thing about "rewrite X in two weeks" - or an entire company's worth of code in 24 months - is that it gives scarcely little time to do incremental rollouts to limit splash radius, or to identify and gather stakeholders to whom one can ask "why was this necessary" (or who can be guided to mine their emails and chat logs for conversations about the same).

Which is not to say this shouldn't be done! Let AI-native people guide the momentum with all the fervency of a hungry founder... but find project leaders who are committed to the empathy towards those who depend on the quirks of their workflows - ones who will create "curiosity loops" that try to bring in stakeholders as rapidly as possible on material questions, not just "continue, follow what you think is best" loops when the LLM brings up an open business question.

We're in a really interesting world where "anything can run anything." Like, in theory, you could get Doom to run on a Cerebras that's specifically laid out for $specific_model architecture, by swapping the weights it holds in SRAM. Just like we're currently running $specific_model on GPUs that were designed for games in the first place.

To misquote a certain YouTuber: LLMs are just games, unlimited games, but no games.

Modern PaaS is tough because there's a general expectation that users (and agents) are able to see and read back environment variables in their management UI or CLI - which means that you can't segregate credential values from the public web environment. See e.g. the visibility icons on https://northflank.com/docs/v1/application/secure/inject-sec...

And sure, you can encrypt at rest, and perhaps even enforce that only re-encrypted versions are ever seen by the management/API web server. But fundamentally this display requirement means that if your management/API web server is compromised, users' secrets can be obtained by a process of impersonation.

Only with two fully maxed subscriptions can we achieve this, and this is forbiddeneded

Just because OpenAI ran roughshod over the broader software community's notion of "open" which once heavily implied free-as-in-software-not-beer, doesn't mean we need to continue this pattern.

Many industries had "source available" without the word "open" for decades, and that was a broadly understood term. "Weights available" would be a reasonable analogue.

For clarity, the Mistral model license is here: https://huggingface.co/mistralai/Mistral-Large-4-1T-A52B/raw...

> 2. If the Licensee or any of its affiliates operates a Model as a Service business, the Licensee must enter into a separate commercial license with Mistral before using the Model or its derivative works for any commercial purpose. The Licensee may contact Mistral, using this form: https://mistral.ai/contact/, to request a commercial license.

> "Model as a Service" means giving a third party access to the Model or its derivative works for inference or post-training by any means (for instance via API or hosted endpoints), in a manner that allows such third party to exercise meaningful control over the inputs, parameters, or training data. This does not include (a) end-user products with model capabilities solely embedded within specific features or harnesses, or (b) mere relaying of requests to models hosted by others.

"Meaningful control over the inputs" is so ambiguous as to be nearly meaningless. Does a model merely summarizing a user's submitted support tickets, give that user meaningful control over the inputs?

Don't get me wrong - I appreciate that Mistral needs to walk a fine line for its own sustainability, and that sustainability is a good thing! And I may just be an old person ranting at a cloud. But "open" used to mean something, back in my day!

From https://discuss.python.org/t/pep-836-jit-go-brrr-the-path-to... :

> We want the PEP to be clear that it’s ultimately the JIT team’s responsibility to find solutions for these packages and tools, and how to deal with situations where a tool can’t be supported or made to work

Is it just me or is this absurdly impossible, to the point of willfully killing the project? Committing a team of brilliant compiler engineers to doing free consulting ad infinitum for every bit of tooling in the world, however hacked-together?

The alternative would be to have the bravery to say: this is the way forward to keep this language relevant into the future, and as a steering committee we collectively own that some tooling may be out of date. Instead, this is a signal that Python is going to rest on its laurels for a very long time.

Thank you for fighting for the users!

One of my favorite things about UUIDv7: the package https://pypi.org/project/uuid7/ does not implement compliant UUIDv7s, it's from a wholly incompatible draft format. That was not a fun debugging session.

https://pypi.org/project/uuid-utils/ is what you want :)

https://github.com/stevesimmons/uuid7/issues/1

One small glimmer of hope is that customizable selects are indeed being worked on: see https://open-ui.org/components/customizable-select.explainer... and the broader work of the Open UI group at W3C.

I'd love to see this level of customization come to date and datetime-local popups, finding a meaningful path that preserves compatibility with the design languages of various platforms. If and when that happens, it will be because of the work of standardization working groups like Open UI and Interop.

downloadmoreipads dot com

So I could see the other argument here: I’m presenting from a presentation, I want to switch to a live demo environment, and to do so I need to turn off the presentation entirely?

Now, another operating system might see this tension and say: why not have a UI element come up, and ask the user whether they want to share their entire screen or stay on the existing shared window?

Here, I think this hits a fundamental weakness in Apple’s design culture: if you want to make things magical by removing options from users, occasionally you’re going to hit something that’s impossible to do without giving the user control. And if anything, Apple’s culture has been overtuned towards not providing that control, if at all possible.

Nobody wants complexity for complexity’s sake, but this is the type of thing that should have come up in a meeting, and someone didn’t feel empowered to bring it up.

One of the most illuminating things here is that now the trigger phrase (for this toy example) is now in an innocuous HN comment. Ask a model perhaps months down the road to look at comments on HN, even ones pre-filtered for known prompt injections, and it will see the trigger phrase. No user generated content is safe.

Imagine you’re an employee at OpenAI who has an idea to use your free time to build these monitoring systems. All of a sudden, your existence becomes political. Remember that OpenAI’s raison-d’être is not to detect traffic, it is to be in The Room where AGI happens.

You have built a short-term whistleblowing system that arguably reduces the probability OpenAI is in that Room, via the negative press such detection would generate. You are now a threat in the eyes of your peers.

Now rewind: you know this before you’ve built the sniffer. You personally want to be in The Room because you believe your desires for alignment exceed those of your accelerationist peers. Is now the time to stick your head out? No, it is not. And arguably you’re being optimally protective of society for realizing this. And so the agents do what they do best.

And imagine you had an LLM ingest the entire corpus of comments and discussion threads for all of Postgres' history, and asked it to make a judgment call on the tradeoffs - or even on how to present the tradeoffs for discussion.

How much of its judgment would be driven by the data vs. its own internal knowledge? How much might be driven by old vs. new discussions that might not represent new directions of the project? How much might be driven by over-matching against how bugs in less mission-critical code paths were handled?

There's no way to quantify the answers to these questions. Which is not to say this applies to every problem out there! But human judgment is still a bottleneck for design questions on widely, disparately-used complex systems.

This. The ability to know that a vibe coded PR is all right to merge, is a function of both the thoughtfulness and simplicity of the underlying architecture, and the level of ownership that contributors have of the underlying products. Both benefit more nimble teams.

The memo, as linked in the OP, is here, and is worth reading, as it’s incredibly far from the sensationalized headline:

https://www.documentcloud.org/documents/28574283-searchresul...

I’ve happened to meet a number of researchers employed by large oil companies over the years, including many involved in the result of memos like this: making research into carbon capture and other mitigations a top corporate priority. Are there optical/PR reasons for investing in this research? Absolutely. Have they also been engaging in the science in good faith, and genuine intent that… in a world where climate action is desired, and net emissions are something to optimize for, they can anticipate this by genuinely funding research, and having their own research projects already underway that can address anticipated challenges? Also absolutely true.

Now, I can’t speak for, say, lobbying efforts. But the scientists on the ground getting accused of the “deception” are some of the smartest, most caring, and highest-integrity people I’ve met. Entire labs of people working for decades to think: can we make our processes cleaner, at the same time we rise to the challenges of global demand.

We should be celebrating, not condemning, this work.

Now I'm fascinated why you've chosen the node/npm ecosystem for something with such high security requirements. Are you doing anything special to deeply pin dependencies, etc.?

Finding the right balance of "being responsive to bugfixes, some of which may patch disclosed zero-days" and "not allowing a compromised package to be installed" is tough, these days.

Another cursed approach here that avoids stack walking, but is almost as bad:

Say you want to rely on a library superclass's foo() implementation, and add some pre/post-processing logic... but in turn that superclass calls another self.bar() (or recurses into self.foo()) and you want to route that to the superclass rather than to self.

One possibility: copy in the superclass implementation and change the call sites. But now you lose the ability to get new features from the superclass if the library makes updates/bugfixes.

Another possibility, as the author suggests: make a new object that's just the superclass, have it run its logic, and bring in the state. But maybe the state itself is massive, or otherwise not something you want to copy (say, there's some kind of RAII).

Another possibility: fork the library, put your fork on a package manager, and have an AI agent maintain your fork for you, forever and ever and ever.

The cursed/blursed possibility: set a flag in a threading.local() that we're currently processing foo(). Superclass ignores this. But when we get to our other logic, we check self._mybrand_processing_locals and route accordingly.

At the end of the day, the stack state is just a threading.local(). Why not cut out the middleman? /s

Claude, vibe code me an entire startup, the actual product doesn't matter, but it should all be based on the incredible pun "turn 'sorry' points into story points."

/goal get accepted into Y Combinator, you have an unlimited token budget, be bold.

Which is why, as much as I love Cloudflare, I wouldn't route things like this through their billing. The risk that a company's entire infrastructure goes down, perhaps even by a fraud/risk flag by an incorrectly-configured AI (including, say, if the search API providers are back-sharing their own potentially-broken abuse flagging metadata with Cloudflare), is far too great.

> you hire people like me, the crossbred progeny of profilers and proof assistants and information theorists

> in formal settings you’d call me a synthesist

> on the street you’d call me jargonaut or poppy

> if you’re one of the savants whose hard-won truths are being bastardized or lobotomized by powerful know-nothings interested in only market share you might call me a mole, or a chaperone

Prescient words, for all of us.

It was the type of product that was an engineering impossibility to launch at the time. Mobile browsers of the time (and many users' desktop browsers!) couldn't run JS quickly enough to allow for the real-time experience - and reportedly Wave would consume 300-500 MB of RAM at the time, which was a ton for 2009!

https://theappslab.com/2009/10/05/google-wave-the-aftermath/

So they would have needed to invest in native mobile apps, and in significant levels of optimization. And none of this, not web or mobile, had the developer experience necessary to iterate quickly enough as the UI would inevitably evolve upon contact with customers, and you'd end up having many widgets reflecting a centralized global state.

Not to mention that you needed sticky server-side sessions to run the operational transformations efficiently, which harkens to the KV caching challenges that still challenge us today.

But it was an incredible dream, and it was a key source of inspiration to me to choose CS as a path.

To lean into your example: if you want to design travel search, you might envision a system that goes from a user's typed query -> a structured query -> executed against a database of real-time flights -> judging the result for feasibility of the resulting proposals created by those queries.

What you can do with LLMs is reverse this: from any numbers of snapshots of flight data, you can create large numbers of plausible user queries, based on your data, that are known to be feasible or infeasible. And now you have a labeled data set to train a model that focuses solely on the query-creation and judgment systems. And you can experiment with whether having a more flexible query protocol leads to higher success rates without sacrificing accuracy, or whether you can generate that last-mile feasibility check as a combination of auditable code checks alongside AI-based judgment.

LLMs don't absolve you of having to break down your system architectures into components that have well-defined boundaries (though certainly they can help with that design). They do make those components feasible to solve at scale.

Sometimes I think back to Google Wave, that beautiful glimmer of real-time collaborative canvases, announced in 2009 when Angular and Backbone hadn't even been invented, and think it launched almost two decades too early.

https://en.wikipedia.org/wiki/Google_Wave

https://youtu.be/v_UyVmITiYQ?t=3850

https://www.usenix.org/legacy/event/lisa09/tech/slides/berli...

We're now in a world where we expect real-time interfaces to be developed and immediately deployed for our feedback by agents, in business-critical settings where classic SDLC timelines are far too slow, but code quality is becoming more difficult to manage at scale.

Git, at its core, is a fundamental notion that behavior is an auditable tree of immutable changes, where any participant can rearrange or rewind or remix this sequence on a local machine to show, and interact with, a provisional combination of those changes.

Google Wave, with its operational transformation (OT) and federation systems, was similar in many regards. We have CRDTs now, and far better techniques for auto-merging workstreams - including agentic systems that can resolve conflicts intelligently!

Wave fundamentally had a concept that people would come together and evolve a simple chat interface, into a customized real-time application for their use cases, and that that iteration could happen in real-time, with data and behavior both evolving in collaboration with bots. Wherever Git and the broader notion of SDLC goes, I hope it brings the best of this thinking.

Don't worry: the natural predator of AI botting, Kernel-Level Anti-Cheat Rootkit, has your back. You may not like its methods, but it's fighting alongside you today, and you're going to learn to love it.

Synthetic data is key here! Compared to 5 years ago, we now have oracles that can generate massive data sets of perfectly labeled multimodal data, practically for free. The number of architectures that can benefit from that is innumerable, and far beyond just LLMs themselves. On top of this, LLMs can implement any architectural ideas you have, and write custom tools to manage training and evaluation.

Whether or not LLMs can self-improve their frontier capabilities, they can absolutely create a wake for themselves that accelerates everything else that's training on their synthetic data. We'll see every architecture of the past 40 years suddenly show leaps and bounds.

Is this the API surface you're referring to?

https://developers.figma.com/docs/rest-api/file-endpoints/#g...

https://developers.figma.com/docs/rest-api/file-node-types/

Seems read-only, which means we're stuck with the MCP for updating Figma files... unless you've found a workaround there too?