Co-founder, CTO @buildkite, Dad, Llama Aficionado (not the model). Previously @GroqInc @cashapp @99designs.
Victoria, Australia
Joined March 2007
- Tweets7.6K
- Following1.5K
- Followers2.2K
- Likes5.3K
We've shipped Buildkite Cache, the first of several building blocks we're putting in place to make CI radically faster.
We've learnt a lot from how the fastest companies in the world run their CI. Great caching isn't just one technique, it's several working together: what you reuse, where it lives, and which work you can avoid doing in the first place.
We're starting with a save and restore primitive to control cached files across jobs, on hosted or self-hosted agents. You choose what goes into the cache key, when to fall back to an older entry, and which builds can share the cache.
There's a lot more coming.
buildkite.com/resources/chan…
Lachlan Donald retweeted
Run, do not walk, from any cloud provider who is throwing public shade at Railway (or any other provider). The better your security team is, the more internal pressure you have not to mouth off about security in Q4 2026.
Lachlan Donald retweeted
Ah there it is ☺️ ruby-lang.org/en/news/2026/1…
Lachlan Donald retweeted
we are now asking that everyone on-call tonight proactively join the incident call and leave it up overnight
we will sound the CVE claxon as 0-days drop
Lachlan Donald retweeted
i'm sure you're all better than me at this but just some of what we've seen if it helps - they're not going to stop. it's going to get increasingly sophisticated and they're going to go after every surface of your system and all of your employees
any old projects you've long forgotten about will be found and used against you
the only reason we're surviving is because we have agents going 24/7. we're still barely sleeping
good luck, sorry you're dealing with this, but really it's a collective problem we're all facing together
Lachlan Donald retweeted
ok I think the main thing we've learned this month is that computer programs get faster whenever they're ported to another programming language, and all we need to do is keep porting back and forth until every program only needs one CPU cycle to finish
I have essentially the exact same set of opinions about how to manage remote companies.
I've managed fully remote engineering teams for ~7 years, from small teams to rapidly growing orgs spanning 10+ countries.
I've developed some pretty strong opinions about what makes remote work actually work:
1. YOU MUST GET "THE TEAM" TOGETHER ONCE A QUARTER, NO EXCEPTIONS. The faster the team/company is growing, the more critical this is. If you follow no other piece of advice follow this one. Remote work is built on a foundation of trust which for most humans can only be built in person. Think about a person you know well who has extremely dry humor. Would you be able to detect that characteristic if you met them for the first time over SMS or slack? Bonds are built over dinner, a beer, an in person hackathon. And those bonds carry forward to the rest of the time spent remote. **for some definition of "the team" - can be a mix of immediate team, org, company-wide, all are useful at different cadences.
2. Managers must be pros and must be highly technical. Many non-technical managers rely on lazy half-ass signals like "who left the office last". As a remote manager you literally have no option other than to inspect the concrete outputs to understand what is going on. This tip is also very useful to non-remote teams 🙂
3. No juniors except for exception cases. Exceptional cases are obviously exceptional. Gotta build the muscle before you play on hard mode - for mere mortals at least. Don't expect someone to learn "how to remote" and "how to engineer" simultaneously. It is too much.
4. Establish a physical center of gravity, ideally 20-30% of staff. Company can still be fully remote and have "an office" where company events are held, some fraction of local employees cowork once a week even if on different teams.
5. Regardless of critical mass, all meetings must be remote first. None of this conference room with 10 people dialing into a zoom meeting with 3 other people nonsense. 100ms latency of conversation is real and you are at a disadvantage if you are trying to interject remotely into a room of in person attendees.
6. Hire managers into the critical mass (or who are willing to travel a lot). There will be lots of good reasons for the manager to make their way in on occasion (once a week, twice a month) to the home of critical mass for one reason or another
7. Onboard senior hires and leaders in person. I have seen new leaders, ICs, managers, design/pm/marketing leaders crash and burn over lack of building good relationships in the first 3 months. If you're bringing on a new leader for god's sake make sure they spend a few days in person with the other leaders they have to collaborate with.
8. Hire within a deliberate, manageable timezone range!!! This becomes more important the more varied the experience level is within your team. Is it possible with absolute engineering pros and remote veterans? Yes! But you need to ask yourself if your team is ready to coordinate work across Australia, UK, NYC, SF, Japan, and India timezones. Think hard about this one. My team is US west coast through Czech Republic. Teammates spanning every part of the US, Brazil, UK, Portugal, Denmark, and more.
8.a. Have a clearly established schedule for "time the whole team must be online". For us this is 8:30 - 10:00am Pacific, but many Europeans choose to work shifted schedules to have more overlap with their peers. I advertise this upfront in every hiring manager screen. Make expectations clear and let people decide. We're all adults and we're more likely to commit and make things work when we make a decision with complete information.
9. Onsite time is precious. Don't waste it on ordinary meetings. Use it for strategic conversations, solving hard problems together, hackathons, and high-bandwidth planning. This is where you build the relationships that make the next three months of remote work successful. For fuck's sake please do not fill a week making people stare at a projector while you read powerpoints!!!
Take the advice or don't.
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.
Lachlan Donald retweeted
AI agents can break out of sandbox. Sure. Multiple real world incidents substantiate that. But not all agents will be spending $50k and weeks to come up with novel sandbox escapes. So not everyone operating AI agents needs to worry about them breaking out of the sandbox using zero days.
This is no different than the fact that not every organisation needs to worry about the most sophisticated APT groups or nation state actors simply because the economics of attack and the reward does not match for them.
Sandbox is an excellent primitive for 99% of use cases that involve securing AI agents. You cannot really do rule based checks to align agents. It’s a losing game. But well designed sandbox sets a deterministic, low level (kernel) security boundary for agents that it cannot cross. Combine that with rule based feedback, credential injection, network proxy enforcement and that gives you solid primitives for securing agents.
Lachlan Donald retweeted
I cannot recall any other time in the tech industry when the COMPLETE industry (from small to large companies; nonprofits to VC-funded; private sector to government and academia) is trying to figure out how to change the dev tools and processes we use.
all AT THE SAME TIME!!
Have been thinking on this all weekend. I actually think I am probably wrong and that faster PRs tap out speed-wise quite rapidly. I think as merge rates climb, we probably need to go back to the 90’s and do something like sampling main branch for CI and deploy. I suspect CI on feature branches is just too compute expensive in 12 months, if not now.
I don’t always agree with @thorstenball on the details, but I really enjoy the mental gymnastics to figure out which is which. I think he’s right directionally here for high-trust projects where speed and quality are already established practices.
Gonna try this out at @buildkite.
You are conflating PRs and branches with “long lived”, there is no reason for them to be any more long lived than your commits to main.
Your premise only works if you have your history in Amp vs using a PR (or a merge commit) as the artifact of a lot of the automated risk assessments IMO, which means your all expecting us to count on Amp for compliance.
We haven’t moved off PRs because it seemed better to just make them really fast rather than try and rethink everything. IMO there is value in figuring out which things you don’t need to reinvent all at once.
Lachlan Donald retweeted
It boggles the mind why the Australian government works so hard to hold Australia back from energy and ai abundance.
A good breakdown of how short sighted energy governance is in Australia, and how it ensures we’ll never compete on the global stage for AI.
If Australia wanted to build out 10-15 GW of AI compute in the next three years, what would it actually take under the government's constraints of no net costs for consumers and 100% renewable backing?
I had great fun trying to work this out with Tim Nelson, one of Australia's sharpest energy economists.
The main idea we tested: what if the best place for training data centres is the outback -- far from cities, close to strong sun and wind, and maybe even off the main grid?
Watch/listen below or on YouTube, Spotify, Apple Podcasts, etc. Enjoy!
Timestamps:
(0:00:00) – Introduction.
(0:00:42) – Could AI data centres consume half the grid?
(0:06:13) – Can we power the build-out with only renewable energy?
(0:15:44) – What could bottleneck the build-out?
(0:24:36) – How data centres could lower power prices
(0:31:58) – What smelters teach us about building renewables quickly
(0:35:52) – How would Tim build 10-15 GW of AI compute in 3 years?
(0:40:38) – Special compute zones in the outback
(1:02:02) – Renewable energy certificates and the time-matching debate
(1:12:01) – Nuclear; unintended consequences; Jevons
(1:20:19) – Post-interview chat
Lachlan Donald retweeted
Does anyone know anyone at Slack that could help with expediting a Slack Marketplace submission?
We've been waiting on approval since August. It keeps getting pushed back because we keep shipping small improvements that require resubmitting and that apparently resets the clock on the approval process, which seems to take multiple weeks if not months.
The Amp Slack integration *is* working and usable but getting it into the Slack Marketplace would let us iron out some friction and let users use the MCP.
Lachlan Donald retweeted
Fast, flexible, economical. ⚙️
@buildkite ingests a trillion test executions a year. Paul Annesley on why they chose ClickHouse, and specifically ClickHouse Cloud, at Open House Australia 2026 👇
Start free with $300 in ClickHouse Cloud credits → clickhou.se/4hCzMjW