
Senior->Junior mentoring has completely changed.
Experienced engineers now get fewer questions. Instead, people will ask their AI.
So the question you should ask yourself is: "How do I leverage all of my experience now?"
People ask how you trust code an AI wrote that a junior can't fully explain. The answer is that you don't just “hope.” You put up bumpers. Test suites, CI checks, AI reviewers, human reviewers, seniors on architecture. At this point, the job is keeping AI in its lane.
When users need help docs to understand a setting, we designed it wrong. And every option we add creates technical complexity, but it also gives the user one more decision to make. Good product design respects both of these factors, in my opinion.
Ask yourself today: “who am I truly happy for?”
Then ask yourself: “what have I done recently to show them that?”
Stop waiting or forgetting to show you are interested and care.
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.
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.
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
Replying to @AnthropicAI
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.






