Big congrats to the @useblacksmith team. They’ve built really nice systems for CI.
Crazy fast cache and sticky disks alone can knock off huge % of your CI wall times. Definitely recommend.
@sequoia is leading our Series C at a $1B valuation.
We started Blacksmith in 2024 to make CI faster and less painful. In January we ran 5 million CI jobs a week. Today it's over 90 million and growing, and we’re still early.
ALT Line chart of weekly CI jobs run on Blacksmith, growing from 5.4M in January to 90.5M in October 2026.
AI is reshaping software engineering into two increasingly distinct paths: product engineers focused on what to build and why, and foundational engineers focused on the deep systems, infrastructure, security, and scale that make it possible.
As AI handles more of the "how," engineers will have to decide where they want to create the most impact.
99.92% uptime this year. Highest we've ever had at @calcom , by far. We could ship faster and let users eat the bugs. Some big names in our space do exactly that. But that's just not how we roll anymore. If people are relying on us to run their scheduling, it has to actually work. In fact, I want this number to be 99.99% soon.
Keith Williams retweeted
There will come a time when how code is written won't matter. But for now, I still care that the code looks and reads right.
I'm not ready to let go :)
I still spend a LOT of time figuring out the right abstractions and interfaces (user and programming).
I recently built two components for shadcn/react. Each took weeks of UX research, experimentation, and iteration to get right.
AI hasn't accelerated this part yet, at least for me.
What it has done though, is help me fail faster. I can now go through many more failures before a component or code is ready.
I've always hated "move fast and break things." It's an excuse for not doing the work right. So why are we constantly okay with breaking things? And with AI there's no excuse left.
Great to see this
To secure open-source software, we’re launching OSS Scanner.
We’ll use our frontier models to periodically scan opted-in open-source projects for vulnerabilities, at no cost. Our reports will provide a proof-of-concept, explanation, and suggested fix.
anthropic.com/research/launc…
I'm a private person. Barely touched social media for years.
Then my brother, a robotics professor, convinced me to start posting. After 20 years in this, if I can share something that actually helps another engineer, why wouldn't I? That's the whole point. I just want to teach.
AI can accelerate engineering, but you can't build trust by assuming everyone understands everything it generates.
Strong test suites, CI checks, AI and human reviews, and experienced engineers create the guardrails that keep AI-assisted development moving in the right direction, especially for junior teammates still building judgment.
Great leaders don't control every task. They create the space for people to think, challenge, and solve problems creatively.
Leadership is about serving your team, being a sounding board, and helping people find the best solutions rather than using the role to control them.
"Bring me solutions, not problems" is the fastest way to kill trust with your engineers. It teaches them to hide problems or show up with half-baked fixes they're scared to be judged on. So bring me the problem. We'll figure out the solution together. That's the job.
I bet engineering teams who built their systems using DDD are quietly smiling these days as exposing domain capabilities to APIs/MCPs/agents would be a breeze.
We’ve been working hard to building guardrails such that AI produces the code we actually want, the same way each time. Product teams spec an idea and ship it. Then best practices make sure what comes out is on-pattern. Because consistency is what lets you move fast with confidence.
The question isn't whether teams should use AI anymore. It's how to use it well.
The biggest wins come from moving idea to output dramatically faster, while keeping human judgment, clear standards, and discipline in the loop so speed doesn't turn into chaos.
Being a great engineer doesn't automatically make you a great leader, and wanting the promotion certainly doesn't either.
Great leadership comes from genuinely understanding people, building strong teams, and having enough experience to recognize when to step in, pull the handbrake, and steer the team toward a better outcome.
The divide won’t be teams using AI vs not using AI. It’ll be teams using AI to raise their standards vs teams using it to lower them. The more code AI generates, the more judgment matters. I suspect most people won’t figure that out until they’re far behind.