Preview of the release blog here main.alchemy.run/blog/2026-1…

The new capability that we built to help defend php2shell is live. The @Cloudflare WAF now has full transaction detection that evaluates the request and the origin response together, and response rules block a match before it reaches the requester. Example from the post: unauthenticated hit on /admin that comes back 200 text/html. Block it. Auth failures and redirects can then pass through untouched. blog.cloudflare.com/full-tra…

TypeScript 7.1 Beta is now available! Now with a preview API, content mapper support, new features, and some great optimizations. Give it a try and give us some feedback! devblogs.microsoft.com/types…

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: <rant> 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. </rant>

Wrote up how we're trying to reduce PR review friction with concept of "small-change" as PRs/eng/week has increased 10x on some teams. (Aside: incidents down 42% HoH, critical incidents down 78%! Velocity vs quality never been a falser dichotomy.) lethain.com/small-changes/

Why are you still using pull requests? Is it for code review? If so, do you really think your or your colleagues catch bugs and mistakes that an Opus 5.5 or Fable or Astra won't find? You can literally spawn all three of them and have them check four times each. (Also, don't tell me you don't have a "stamp plz" Slack channel or group chat somewhere.) Is it for knowledge sharing? Surely there's better ways for that now than the PR, no? We have models that can generate explainer videos, presentations, podcasts, games, quizzes, walkthroughs, ... for any piece of code it can reach. Is CI the reason? Well ackshually, CI means continuous integration and its original meaning is the *opposite* of having long-lived branches and PRs. But, leaving that aside, your agents are hopefully already running the tests before they push something, and hopefully they can run as long as they want and don't block you so they can run the whole test suite and generate "irrefutable proof" and end-to-end demo videos and so on... And so they run the tests and confirm and then you push to a branch and everything runs again and then you merge and then it runs again? That doesn't make sense, does it? Maybe you work in open source and you accept contributions, in which case I can't speak to the value of pull requests. It's been 2 years since my last OSS contribution. But from what I heard, the time of the PR is coming to an end in OSS too? I honestly don't get why people still stick to PRs. With agents you can now move 10x faster, you can finally do real continuous integration, and get more confidence in the changes the agent made. Don't slow yourself down by having all the changes pile up in a PR.

Crazy how Anthropic started to hide the full names of engineers on its engineering blogs... never seen this happen in tech before. After the OpenAI espionage story I have empathy why they do it, but strange to see none the less Clearly shows eng at an AI lab is high stakes?

We started running "pirate and architect" pods at Coinbase back in May of this year and I used this slide to talk the team through it. It works. 1 pirate, 1 architect, and a part-time designer. It lets each archetype lean in to their superpower and get more shit done without all the coordination overhead and "what if-isms". The pirate ships like mad, is product-minded and customer-obsessed. Always willing to throw-away code for a better version. The pirate is usually the DRI at the beginning too, working with customers, driving requirements, and a ship plan. The architect makes sure stuff is built for scale, takes the pirate's prototype, and drives its scale-out through spec for agents. The designer is building with both to constantly shape the experience and hill-climb to delight. There's a helpful mental model that I like: -Make it possible. -Make it reliable. -Make it delightful (or efficient). Previously, those 3 were done in a waterfall approach and was slow. Most people were just stuck on "make it possible." With agents and a new way of working, you have every opportunity to parallelize them and go 100x faster.