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.2K
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
Agreed, I was pretty skeptical it would work, but it’s better than it was.
I’m sure this one won’t make anyone angry. (But probably not here.)
daringfireball.net/2026/10/x…
Lachlan Donald retweeted
decanter whiskey is fine, but the real office booze pros offer you a batched mezcal negroni in an emptied Rittenhouse bottle marked with a blue-painter's-tape label
Lachlan Donald retweeted
Hot take for agents: there are situations were VMs work great, there are situations where sandboxes work great, there are situations where a durable object is all you need, and there are situations where you just need a javascript interpreter. And probably many more situations.
Lachlan Donald retweeted
counterpoint - this will be bad
compaction works and you should do it at 250k anyway
now everyone's costs will go up
Day 7/
We have increased default context length for GPT-6.1 Sol to 500k when used through Codex & Work, up from 272k or an ~ 80% increase.
We will go higher in the future, but it helps reduce occurrence of compactions and with tasks that require keeping a lot of context and nuance over periods of time. It was carefully tested and is the new sweet spot for most of our users. You can still override it if you want to be higher our lower, with maximum context length of GPT-6.1 Sol of 1M.
Lachlan Donald retweeted
I can't emphasize enough how important this @a16z chart seems and how few have internalized it.
Lachlan Donald retweeted
You know what's a great intelligence tell?
When someone confuses semantic issues with substantive ones.
If someone starts disagreeing over wording for something that's clearly-stated and correct as the words are used and intended, then they're probably not worth talking to.
Lachlan Donald retweeted
If you invest in me early, and you have pro rata, I know and you know you priced that in to your end of the deal.
If I come asking you to waive those rights later, I know and you know I’m asking you for a favor. You may (or may not) decide to do it.
If the deal is hot, and I’m asking you to waive your pro-rata, I have to build the case that says it’s in your best interest to do it.
If you say no, my job is to make it work some other way. Which I can absolutely do, because the deal is hot. I might make other folks upset (but I might blame it on your intransigence, if you’re really being a piece of work about it). But the deals a hot one. We can sort it.
What I don’t do? Post on X.
Lachlan Donald retweeted
🗞️ if your team is too busy doing their 'normal job' to experiment with AI, you're preparing them to be replaced
ghuntley.com/replaced/
In this post, I guess this's the last time I'll say it. AI use is no longer optional if you wish to be employed. What follows is advice for current employees and hiring managers on how to hire in 2026 to source AI-first candidates.
