Avik Das

I’ve just published the next installment in my "Theory of Durable Execution" series. Across frameworks we hear terms like workflows, activities, virtual objects, handlers, and functions. Underneath the terminology, they’re all describing a small number of execution patterns. In this new post, I break durable functions down into three forms: 🔹 Stateless functions for one-shot deterministic logic 🔹 Sessions for long-running, interactive orchestration 🔹 Actors for persistent, message-driven state To get there, I walk through: 🔹 The behavior–state continuum 🔹 How identity, lifetime, communication, and concurrency shape execution semantics 🔹 How frameworks like Temporal, Restate, DBOS, and Resonate map onto these forms This builds on the previous two posts in the series: 🔹 Demystifying Determinism in Durable Execution 🔹 The Durable Function Tree (part 1 and 2) This was the last post in this series, distilling the various frameworks down to a simpler logical model. Full post: The Three Durable Function Forms https://lnkd.in/eJHpY9qC

77

7 Comments

Whenever you're writing something at work (whether it's a pull request, a document, a system design, a bug report, a feature request, etc.), make sure to give it a meaningful title and a TL;DR. Make it easy for folks to get a grasp of what it is you're doing.

52

5 Comments

"Because engineers had been through brainstorming and story mapping, they were able to identify the most promising direction and find a way to implement one key piece of it pretty quickly." Want to get your engineers more involved in continuous discovery? Learn how Ellen Juhlin, Senior Director of Product Management at Orion Labs, successfully brought engineers into the discovery process. Key takeaways from Ellen's experience: 🎯 Start by inviting engineers to customer interviews as listeners and note-takers 💡 Include engineers in brainstorming and solution mapping sessions 🗺️ Use assumption mapping to help engineers focus on validating ideas 🔄 Don't worry about following a linear process - iteration is key 🎯 Begin with just one or two engineers rather than the whole team 🤝 Keep engineers connected to business outcomes Check out the comments for a link to the article. ❓ What's one small step you've taken to include engineers in discovery work? Share your thoughts in the comments below.

39

4 Comments

Really loved this read, a very practical approach to languages and platforms. https://lnkd.in/ej3tGd9s 'Is it boring? Yes. But solving CRUD operations at scale shouldn’t be exciting. It should be boring and safe. It’s 2025 —we as an industry should know how to scale CRUD apps to hundreds of thousands of queries per second safely and reliably without bugs, without performance bottlenecks, and without “excitement.”'

13

Excited to share something our team has been working on over the past few months. We shipped Authorship in Superhuman Docs, giving students and educators clearer visibility into how AI is used throughout the writing process. Within Docs, you can now see: • When Citation Finder was used to track sources • Where Proofreader helped strengthen a draft • How different AI agents supported the writing journey Authorship is on by default, helping students reflect on how they write — not just what they submit — while giving educators insight into the full learning process. The goal isn’t “Did you use AI?” It’s “How did you use it?” Proud of my team for building this thoughtfully and with a lot of care. Awesome work team Mike Henkel, Ihor Skliarevskyi 🇺🇦, Ziyang Li, Jason Bastian, Pierre-Jean Quilleré, Matthew Guo, Isabella DeBoer, Jason Sperske, Vlad Nikityuk, Jennifer van Dam, Tal Havivi and Cliff Archey If you're interested, you can read more about the launch here: https://lnkd.in/g8bDHspA #EdTech #AI #Education

52

1 Comment

We just released SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks led by Xiangyi Li and I’m excited to be a co-author. The team saw so many agent skills being published, reused, and hyped, and just had to ask - are they actually useful? So we created a full blown benchmark! Key takeaways 1️⃣ Curated skills significantly improve performance Across 86 real-world tasks and multiple agent setups, well-designed human-written skills by subject matter experts delivered meaningful gains. 2️⃣ Skill design matters more than size. Focused, modular skills (2–3 clear components) outperform bloated documentation. 3️⃣ Impact varies by domain Skills aren’t magic. In some domains they help a lot. In others, marginally. Benchmarking is the only way to know. 4️⃣ Skills outperformed model scaling Smaller models with skills outperformed bigger models without them, both in terms of token use and correctness My personal takeaway Software is so saturated that it was genuinely hard to find tasks where strong frontier models clearly fail, but other fields such as healthcare, finance and cybersecurity are still lagging behind. Having said that, when skills are well-designed, they matter. For example, Vercel's react-best-practices skill was extremely practical - it directly helped solve real performance & layout issues in a webapp scenario where baseline models struggled. If skills are going to be the next packages for agents, we need proper benchmarks. No more vibes!

52

5 Comments

What I'm Reading This Week 📚 🤖 Vibe Code Reality Check Steve Krouse's piece argues that "vibe coding" where you "forget that the code even exists" creates legacy code nobody understands. Programming is fundamentally theory building, not just producing lines of code. This resonates - I recently spent hours trying to fix a frontend bug with Claude Code and Gemini CLI stuck in a dead loop of guesses. Two minutes of human inspection found the inefficient hook render. We still very much need the human (expert) in the loop. https://lnkd.in/g_Dt-_kz 📐 Mathematics as Code Dan Abramov's exploration of Lean shows how mathematicians can treat mathematics as code - breaking it into structures, theorems, and proofs that are statically checked and composable. His playful example of "haunted math" where 2=3 demonstrates how axioms shape mathematical reality. Always fascinating to see bleeding-edge programming language theory, especially when it bridges math and code in such elegant ways. https://lnkd.in/gebHeMSU 💻 Local LLMs Innovation Simon Willison highlights how his 2.5-year-old laptop can now write Space Invaders using GLM-4.5 Air and MLX. Open source models are rapidly pushing the frontier of what's possible on a chip. The future where we get GPT-4 level intelligence running on phones feels closer than ever and a powerful enabler for humanity. 🚀 JavaScript's Wild Decade Jamie Birch's comprehensive dive through JavaScript runtimes reveals a staggering ecosystem - from Node.js to Cloudflare Workers to React Native's Hermes. I remember when Apple had a strict no-JS-runtime policy for the App Store. We've come so far that every platform now has multiple JS engines optimized for specific use cases. The proliferation shows JavaScript's incredible adaptability across contexts. https://lnkd.in/g843sYBk 📊 Amazon's Dev Experience ROI Amazon's "Cost to Serve Software" framework quantified a 15.9% reduction in delivery costs through developer experience improvements. The key insight: giving developers back time and reducing toilesome work. For a company with 1,000 developers, a 15% improvement translates to $20M in cost avoidance. Good concrete ROI numbers on investing in developer productivity. https://lnkd.in/ghv5CTfa Which trend do you think will have the biggest impact on software development: local AI democratizing access, the continued JavaScript runtime explosion, or finally having concrete metrics for developer experience ROI? #AI #JavaScript #DeveloperExperience #Programming #LocalLLMs #VibeCoding #SoftwareDevelopment

9

2 Comments

Post-train once, reuse many times! Up next in my "Why Continuous Pretraining is Awesome and Its Time May Have Come" series: insights from the area of model merging. I've posted about model merging a few times before, so I'll link those in the comments below if you need to get up to speed. With continuous pretraining, you take a base model (one without any post-training: instruction following, safety training, etc.) and pretrain it more on a new dataset. This could be to update its data cutoff period or to transfer it to a new specific domain. Then you have to reapply your whole post-training stack on top, or do you? Model merging has uncovered a very useful property of models: that of "Task Arithmetic". We can fine-tune a model and subtract the base model weights, leaving a task vector [1]. These vectors can be combined with models from the same base to add the corresponding capability. For example, if we have pretrained a base model and then instruction-tuned it, we can compute the instruction tuning vector for this model. Later, we can continually pretrain the base on a new dataset and then simply add the instruction tuning vector on top to get the best of both worlds: a domain-transferred model with deep knowledge in a new field and top-quality instruction following. This was demonstrated clearly in [2, 3], showing this transfer of instruction following on both Llama and Qwen models — with [3] achieving 46.9% improvement on instruction-following benchmarks without any additional training. Best of all, this transfer doesn't only apply to instruction tuning but all sorts of capabilities you may want to fine-tune for, as shown with DPO, RLVR, and RLHF on the OLMo models in [3]. Practical implication: Organizations can maintain a single high-quality post-training pipeline and apply it to multiple continuously pretrained versions of their base model, dramatically reducing the cost of keeping models up-to-date. References: [1] Editing Models With Task Arithmetic https://lnkd.in/ekM7VdK3 [2] Balancing Continuous Pre-Training and Instruction Fine-Tuning: Optimizing Instruction-Following in LLMs https://lnkd.in/eUM2PkgM [3] Efficient Model Development through Fine-tuning Transfer https://lnkd.in/e6AuRbQs Shoutout to Alessandro Giagnorio for highlighting some of this excellent research to me!

829

27 Comments

If coding is the easy part now, what’s actually the moat? Claude, Cursor, Copilot...they're churning out production-ready code in hours. Friends have cloned Typeform and Calendly in days. Backend, payments, multi-language. Done. Garry Tan just rebuilt his old company with Claude Code in 21 days. One person. $1,000. That's 35x faster, 174x fewer person-days, and 5,000x cheaper. But replication ≠ success. The barrier to 𝘣𝘶𝘪𝘭𝘥 has (almost) collapsed. The barrier to 𝘸𝘪𝘯 hasn't. I've been obsessing over this. Here's what I keep seeing: 𝟭. 𝗚𝗧𝗠 & 𝗗𝗶𝘀𝘁𝗿𝗶𝗯𝘂𝘁𝗶𝗼𝗻 Building is commoditized. Getting it in front of users? Still brutally hard. OpenClaw took over my feed this month. Not because 🦄 Peter marketed it...but because the community he built did. That flywheel is the moat. Lovable and Superhuman had that same energy early on. Other paths: lock-in through contracts, guerrilla marketing like Corgi, Rho, or Known's launch, or building an audience first like the Phia founders did with their podcast. 𝟮. 𝗨𝗜/𝗨𝗫 Obsess over user behavior like it's religion. I rave about Granola, Superhuman Mail, and Wispr Flow like I built them. I use all three daily. Someone on those teams has 𝘥𝘦𝘦𝘱𝘭𝘺 felt the problem 𝘰𝘰𝘰𝘳𝘳 they're just impossibly close to their customers. Every small detail makes you fall in love with using it. What products do your users already love? What's the ONE feature that's 80% of why they stay? How easy is it to install, use, customize? 𝟯. 𝗖𝗼𝗻𝘁𝗲𝘅𝘁 & 𝗠𝗲𝗺𝗼𝗿𝘆 Think about the first time ChatGPT remembered something you said. It just understood you differently. Try asking it: "𝘛𝘦𝘭𝘭 𝘮𝘦 𝘴𝘰𝘮𝘦𝘵𝘩𝘪𝘯𝘨 𝘢𝘣𝘰𝘶𝘵 𝘮𝘺𝘴𝘦𝘭𝘧 𝘵𝘩𝘢𝘵 𝘐 𝘥𝘰𝘯'𝘵 𝘬𝘯𝘰𝘸." If you're a power user, you'll be surprised...the answer is creepy good. We're betting on this BOND (YCX25) making sure your AI Chief of Staff knows your company context, remembers past decisions, and connects dots across Slack, email, calendar, and Linear without you having to repeat yourself. 𝟰. 𝗖𝘂𝘀𝘁𝗼𝗺𝗶𝘇𝗮𝗯𝗶𝗹𝗶𝘁𝘆 & 𝗣𝗿𝗶𝗼𝗿𝗶𝘁𝗶𝘇𝗮𝘁𝗶𝗼𝗻 Many of our users first tried to build their own daily brief with Claude or OpenClaw. Why? They wanted it personalized to 𝘵𝘩𝘦𝘪𝘳 needs. Tools like Lovable, Claude Code, and OpenClaw are all enabling people to build their own thing. Domain experts with tacit industry knowledge now have an edge over pure coders. These tools shouldn't scare you. They should excite you. Because the real moat you always had, still have, and will always have is... 𝟱. 𝗦𝗽𝗲𝗲𝗱 & 𝗜𝘁𝗲𝗿𝗮𝘁𝗶𝗼𝗻 The only thing that compounds is learning velocity: how fast you ship, gather feedback, iterate, improve. Y Combinator calls speed "the moat before all moats." Slow movers get lapped...even with great ideas. 𝗕𝗼𝘁𝘁𝗼𝗺 𝗹𝗶𝗻𝗲: Optimize to try, fail, and learn faster than everyone else. And do it with people you can have a ton of fun with Flor & Tibo 🥂

95

15 Comments

I've been thinking a lot lately about being a "respectful" engineer for the web. When someone visits a site, their browser dedicates a single thread to running *our* JavaScript code and responding to *their* interactions. If our code runs too long, the browser sides with us and stops listening to them, and that's when users experience "jank" and a whole lot of frustration. We're just borrowing the main thread from the user. We need to share it, and be more respectful with it. I wrote a new post about this with some examples and practical advice: https://lnkd.in/ePJEdqcX #JavaScript #WebPerformance #Frontend

61

14 Comments