@ibuildthecloud 100%, “by the way” implies something totally different what the feature is. If it was honest it would be something like /parallel-question but there is nothing cool about that , nothing.
announcer on this brisbane train now spruiking industrial action updates, that was weird
"we have restored 91% of services across brisbane"
"the next station is southbank"
So basically, today PHP got two critical bugs that let anyone run code on your server without even logging in, which is bad, and then the details leaked before the patch was even out, which is worse, and it works on WordPress and MediaWiki and Magento and Joomla and Laravel, and Censys says like 1.5 million servers are running a version with no fix, so the NSA was like "take your system offline," and the FBI was like "take your system offline," and CISA and the UK and CERT-EU were all like "take your system offline," and then the Prime Minister of Japan, the actual Prime Minister, posted at 5:55 in the morning telling 48.8 million people to take their system offline, so everyone took their system offline, like the Dutch cybersecurity agency took its own website offline, and the Dutch parliament went offline, and the Port of Rotterdam went offline, and Finland and France and Denmark started pulling government sites, and Wikipedia went down, and https://t.co/QlOXb3COq3 went down, and Asana and GOG and Something Awful went down, and the University of Vienna's webmail went down for some reason, and that's just PHP. Because GitLab also dropped a CVSS 10.0, which is the highest score they give out, for a bug that's been there since 2014, so that's every self-hosted GitLab for twelve years, and then LiteLLM 1.107.0 got hijacked and shipped a credential stealer and a remote access trojan in every single wheel and the Docker images, including latest, and you didn't even have to import it, just installing it was enough, and it's the second time this year, and then Railway paused every deployment on the entire platform because someone got into the environment variables, so now everyone has to rotate every secret they've ever stored there, and TiDB Cloud said someone was walking around inside with stolen credentials for basically a month and an extortion group says they took 10.6 terabytes, and Zeabur got breached for the second time in two months and is just shutting down, like the whole company, and Node.js patched remote code execution and a TLS bypass, and CISA says Plex is being actively exploited, and someone took over 300 Tor exit relays to steal SSH passwords, and SafePay ransomware has hit over 600 critical infrastructure orgs, and India's biggest bank filed a data loss incident, and Japan has been in an official state of emergency in cyberspace since October 9, which honestly explains the 5:55 AM post. Oh, and eMudhra, a certificate authority that's issued over 60 million certificates, whose entire job is proving websites are who they say they are, was supposed to be using private keys that are random numbers over a hundred digits long, and one of them was 4. Just 4. And the others were like 66 and 237. Anyway, it's Wednesday.
Today, we're sharing a major milestone in our mission to democratize frontier AI development:
Pretraining at scale without a pretraining team.
We set out to answer an ambitious question: Can we significantly reduce the time, human expertise, and compute needed to pretrain a competitive foundation model from scratch?
The result is Mirendil-Base, our first pretrained coding model, built by one researcher in just 3.5 months with less than $10M in compute, including all research, experimentation, and the final training run.
Our approach is already showing promising results as we scale to even larger models.
This is an important step toward a future where a single researcher, empowered by AI, can accomplish what once required an entire research organization. As these capabilities improve, we believe frontier AI development can become accessible to far more people and teams.
More to come soon, including independent evaluations, post-training benchmarks, and API access.
nice! good write up combining some recently solutions.
I am curious if you have a sense of the difference in cost? what limit/cost were you hitting and what was the difference after making these changes?
I am still using Claude predominantly but have ventured into Grok bot driving cursor (the default) and I have noticed the costs being potentially significant according to usage report (but not used enough yet to hit any limit)
You can now automate recurring engineering work with team tasks in ChatGPT, like pulling together what shipped and what’s blocked every Friday.
Your teammates can review the results and change what the next update covers, so you don’t have to maintain it on your own.
cool, but wonder if exclusive or it’s bringing it on par to Anthropic/xAi - how could you know?
As someone said the other day, software engineering is starting to feel like astrology
You can now choose 12-hour prompt caching in the API.
Persistent agents, like dots, reuse context throughout the day.
You can keep shared instructions, tools, and context cached longer and pay the lower cached-input rate, even when requests are hours apart.
As it stands, Grok Bot is heavily biased towards computer-use on the remote computer but you CAN get it to control software on YOUR computer.
THE TRICK is to be explicit in the prompt.
I use it for cases where I am not super comfortable with using a remote grokbot-owner computer such as banking app use.
But I get the vibe like maybe they are trying really hard to not have users use it like THIS because perhaps remote is a better UX or some other leverage.
I am interested in the specific points where the premise of in-house long lived (or curated) CI state/compute is not equally sound to an ephemeral remote runner architecture. On the long tests point, it will either scale on a remote provider or your compute, yes the economics are different but by how much, is it orders of magnitude ?
the builder agent (wherever it may be) must establish trust through a cryptographically verifiable chain of custody between your source code, the build process, and the artefact to be deployed. but technically speaking I can’t see how it couldn’t be done and attested with the same security posture as CO runners. you are probably right that it’s a heavier lift over just using CI runners
there is actually a remedy to CI cost blowout, and you can attain it fairly easily without doing anything drastic like migrating off GitHub. it’s this:
- don’t use GitHub actions for anything other than actions that would require a distributed mutex. this essentially limits CI to just the deploys and data migrations
- for everything else , have the agents run the builds and publish from whatever machine it’s coding on
but what about audit of build success on the commits , you ask ?
- add a lightweight skill that instructs the agents to do a github signoff[1]
- it’s easy to build your own signoff (it’s just an API call piggy backing off the logged in GitHub user to “gh”) or you can use @dhh’s https://t.co/WhjWqW7pG1
[1] signoff is one or more verification tick on the commit in github. you can add this without needing actions to run the actual build, it’s just an API call
We are either going to need more compute, or better CI.
AI driven dev means more code/tests and more frequent changes trying to merge and deploy to production.
E.g. 10× the changes × 5× the test suite cost = 50× the compute (and higher peak compute demand due to parallelism).
And that's before you rebase a few times to keep up with the fast moving trunk, then battle a merge queue due to flaky tests.
There are a few things everyone should be doing. First off, you make your test suites leaner and faster. High signal units, massive parallelism, thoughtful end-to-ends.
What needs to come next is compute reduction. You should only run the tests that relate to the change you are testing. The next step is getting even smarter. Models can be used to predict which subset of the related tests are most predictive of failure which lets you get to the failure fast and avoid unneeded subsequent test runs.
@zackerydev@lox if the local agent machine is permanent rather than ephemeral it will already have a warm cache, CI runners are generally short-lived so require remote caches and all network optimisations around that
@0xnfrith i agree. it's not that you shouldn't separate. it's that some of the things we traditionally used CI for could reasonably belong in the realm of the agents
maybe, but, the CI part is only really about integrating from a code/verification standpoint and that still happens on the CI/CD pipeline on main.
the technique i described in the prior post is technically called "progressive delivery". i added the concept of running continuous tests and deciding-based on metrics but this feels like the logical progression
k8s can help but it's not strictly necessary for doing progressive delivery.
https://t.co/8FYaEyfWN6
fair. that's a reasonable use case to keep using CI for
but, I think where it will go is that long running tests will happen inside the environment as part of the deployment progression. if it fails, then it doesn't promote, and if it passes it does.
this is what I'm doing with AnalysisTemplate on @argoproj , could be a heavy lift for many, but works well on K8s-architectures.