
Staff Platform Engineer @Superhuman | Engineering leadership and AI in practice -- from someone who builds the stuff.
Berlin, Germany
Joined August 2011
- Tweets1K
- Following168
- Followers223
- Likes2.1K
Serhii Vasylenko retweeted
🚨 Kyiv is under a massive Russian air attack right now. One of Ukraine’s most sacred landmarks - the historic Kyiv-Pechersk Lavra - is on fire. Putin sends his birthday wishes to Donald Trump.
Found this on Claude Cowork landing page and now I wonder whether it's an easter-egg-thing or really just a placeholder they forgot to remove?..
"Lorem ipsum dolor sit amet, consectetur adipiscing elit suspendisse varius."
claude.com/product/cowork
In Q3 2025, I had an infrastructure migration ahead of me that didn't fit the usual playbook, and I spent the early part of it asking the wrong question about AI agents.
Part 1 — flipping the axis to a layer-based approach: devdosvid.blog/2026/03/05/fl…
Part 2 — layers made it universal, harnesses made it run: devdosvid.blog/2026/04/07/la…
My TIL today: making F4 work in Tmux like it does on Mac, and showing me the windows.
This requires enabling F-keys to work as standard function keys in macOS settings first. And then this feels sooooo gooooood :-D
When OpenClaw emerged, people started buying Mac Minis to run it, even though it was never positioned to work only on Mac. Now I see more and more use cases on how it runs on Raspberry Pi, curious if @Raspberry_Pi saw any spike in sales.
Every AI memory tool I've looked at builds a knowledge base. Extract facts, embed them, retrieve on demand. Smart engineering, genuinely useful for some things.
But that's not what I need.
What I lose between sessions isn't facts -- it's the reasoning. Why I chose this approach over that one. The debugging chain that led to the fix, not just the fix. A pattern I noticed in one project that applies to three others. The stuff that's too contextual to extract into a fact, too valuable to forget.
I need a diary, not a knowledge base. And ideally -- one I can ask follow-up questions.
Think about on-call handoff notes. You read them. They're good notes. But you still have questions the notes can't answer, because the person who wrote them couldn't predict what you'd need to know. What you want is to ask them, not read their summary.
That's the gap. Most tools let you search text or retrieve facts. None let you resume a train of thought.
I haven't solved it. What I have is a dumb workaround: a hook that captures observations generated during Claude Code sessions and writes them to flat markdown files. When "Explanatory" mode is enabled, Claude emits Insight messages during the conversation, and the hook saves them. I never stop working to take notes -- they accumulate in the background. Crude, but it solves capture without breaking flow. Analysis happens later, with another model call. Yet sometimes, the model captures stuff that is far from the real insight.
And the bigger problem -- picking up reasoning where it left off -- is still open.
How do you carry context between sessions? Not tool recommendations -- I mean the actual workflow. Do you write notes? Grep transcripts? Just re-derive everything from scratch?
my conspiracy theory: Claude Code is so eager to amend commits all the fricking time because @AnthropicAI wants it to look like a tool that one-shots everything.
It would be sooo great to have skills support on Claude mobile. Please, pretty please @AnthropicAI 🙏
Most meeting advice says add behaviors -- nod more, paraphrase, ask clarifying questions.
The thing that actually changed a room was removing something. Read more in the new blog post here -- bit.ly/3Ps8zGj
Engineers describe what's wrong with the system.
Directors need to hear what's at risk for the business.
Three questions to force the translation:
1. What slows down or breaks because of this?
2. How often? How much time lost?
3. What can't we commit to because of it?
If you can't answer #3, the item won't get prioritized -- no matter how painful it feels.
One pattern I've learned to catch in myself: using curiosity as a polite "no."
Someone pitches an opportunity. You're not interested, but saying "no thanks" feels abrupt. So you say "that's interesting, let's continue the conversation" -- buying time you never intended to spend.
Now they prepare, follow up, invest energy. And you owe a harder "no" than the easy one you avoided.
I've started applying a simple rule: if I know the answer is no, I say it before the conversation ends. 30 seconds of discomfort beats days of avoidance.






