Hello fellow datanistas!

This post is my reflection on why standardizing data science ways of working is worth the investment, what actually works in practice, and the people work that makes change stick. I’ll share stories from my time at Moderna, lessons learned, and practical steps for teams who want to start (or restart) their own standardization journey.

Let’s be real: most teams only believe in standards after they’ve felt the pain of not having them. Early in my time at Moderna, I saw firsthand how messy codebases and inconsistent project structures made onboarding and migrations a slog. But when we finally standardized—on folder layouts, onboarding commands, and documentation—everything changed. Migrations (like moving from Bitbucket to GitHub, or Conda to Pixi) became predictable and fast. The upfront cost paid off in confidence and speed.

But it’s not just about picking any standard. The trick is to work backwards from what you actually ship. For us, that meant naming our deliverables (compute tasks, Python packages) and then figuring out which standards would remove friction on the path to shipping them. Standardize where divergence creates friction—like project templates or documentation publishing—not everywhere. Let science stay flexible where it matters.

The hardest part? People. Making the ROI case gets you in the door, but adoption is a people problem. Training, hand-holding, and building a culture of learning agility are what make standards stick. And as the stack evolves (hello, Marimo notebooks!), the playbook stays the same: demo, review, socialize, train, and repeat.

AI is lowering the cost of tooling and migrations, but it also amplifies whatever patterns already exist—good or bad. That’s why investing in standards pays off twice: it makes migrations easier and ensures AI tools reinforce the right patterns.

If you’re leading a team, hiring for curiosity and learning agility is just as important as picking the right tools. And if you’re already on a team, start with the one standard that removes the most daily friction. One small win beats a grand plan that never ships.

For the full story, including practical resources and more personal vignettes, check out the full blog post: Reflections from BioIT World Workshop: Standardization Is Worth the Effort.

Standardization is a people-first investment that pays off in speed, confidence, and adaptability—especially as your stack evolves. Start small, focus on where friction is highest, and remember: adoption is a milestone, not a finish line.

What’s one thing you wish your team would standardize first? Folder structure, CI/CD, documentation, or something else? I’d love to hear your stories and what’s worked (or not) for you.

If this resonates, read the full post for more stories and resources, or share it with a teammate who’s wrestling with the same challenges. And if you want more reflections like this, consider subscribing.

Cheers,
Eric

Hello fellow datanistas!

What if the most important job for data scientists in 2026 isn’t building apps or writing code, but defining what actually matters? I keep coming back to one word: measurement.

This post is about why measurement—rigorous, scientifically grounded, and defined by those closest to the problem—remains the core mission of data science, even as AI and LLMs transform how we work. I want to share why I think the industry’s push to make data scientists into full-stack developers is a mistake, and what we should focus on instead.

Let’s be honest: the buzz around AI coding assistants and LLM-powered apps is relentless. It’s tempting to believe that, since coding is easier than ever, data scientists should just become full-stack developers. I see this everywhere—managers expecting data scientists to own front-ends, databases, and deployment pipelines, while the measurement work that makes us valuable gets squeezed into the margins.

But here’s the thing: LLMs and AI tools are just new instruments. They don’t decide what to measure. That’s still our job, and it’s a job that requires domain knowledge, scientific reasoning, and a relentless focus on reliability. The industry is zigging toward building, but the real gap is in making sure these systems actually work—at scale, over time, in the real world. That’s where data scientists create massive value.

When we get pulled into full-stack work, we trade years of scientific expertise for mediocre engineering. The cost is real: cognitive switching degrades both measurement and engineering, and the measurement work itself gets displaced. Every hour spent debugging a UI is an hour not spent designing evaluation frameworks or defining metrics that matter.

So what should we focus on? LLM evaluation is the clearest answer. Every company building with LLMs needs to know if their system works, and that requires exactly the kind of rigorous measurement data scientists are trained for. The tools are immature, which is an opportunity: build single-purpose utilities for your own measurement work, but don’t cross into full-blown product development—that’s for software engineers.

The line is nuanced: scope, audience, and production boundary matter. Build tools for yourself and your team, but let engineers own the production systems. And always, always co-define measurement frameworks with the people closest to the problem—whether it’s document parsing or ML for drug discovery, the right metrics come from collaboration between data scientists and domain experts.

For managers, this means reframing the conversation: start with measurement, not building. Staff teams based on measurement needs, go for quick wins to build credibility, and prioritize by expected ROI. The trade-off is simple: every hour spent on engineering is an hour lost to measurement, and that’s where the real value lies.

Measurement is the heart of data science—AI tools change how we work, but not what matters. Stay close to the problem, focus on rigorous evaluation, and don’t trade scientific expertise for mediocre engineering.

How are you balancing measurement work with engineering tasks in your own team? Have you felt the pull toward full-stack, and what trade-offs have you seen?

If this resonates, I invite you to read the full post for concrete examples and practical advice: What data science is actually about in the age of AI. Share your thoughts or subscribe for more honest takes on data science in the AI era.

Cheers,
Eric

Hello fellow datanistas!

Ever wondered what really drives the conversation at a massive AI conference—beyond the buzzwords and hallway chatter? This year at ODSC East 2026, I ran a small experiment to find out, using a mix of agentic AI and a bit of old-fashioned curiosity.

In this post, I share how I mapped the true ‘center of gravity’ of ODSC East 2026 by scraping and analyzing every talk abstract, then letting a multi-agent pipeline surface the five big patterns shaping our field. Plus, a candid field note from my own workshop and what I learned from the experience.

I’ll be honest: at big conferences, it’s impossible to catch every session, no matter how much you try. This year, instead of chasing every talk, I wondered—could I use the abstracts themselves to reveal the conference’s real themes? So I scraped the ODSC East 2026 schedule, pulled 237 session abstracts, and ran them through a multi-agent categorization pipeline. Each agent proposed its own taxonomy, then cross-reviewed and arbitrated until five clear zones emerged:

1. Agentic AI Systems: The biggest zone, reflecting the shift from prompt engineering to robust agent architectures, orchestration, and production deployment. Teams are wrestling with reliability, control planes, and long-running agent workflows.

2. LLM & Foundation Model Engineering: Focused on model training, quantization, inference, and the economics of deploying LLMs at scale. The pressure is on for latency, cost, and stability.

3. Data Engineering & ML Infrastructure: Where context, data quality, and operational pipelines determine whether agents succeed in the real world. The message: fix your data substrate before blaming the model.

4. Applied AI & Domain Solutions: Covering both intro skills and domain-specific applications, with a recurring question—how do we redesign human roles as agents take on more work?

5. AI Strategy, Governance & Workforce: Where technical capability meets organizational reality. The challenge: translating trust, policy, and risk into actionable, testable engineering practices.

To visualize these patterns, I embedded and clustered the abstracts, comparing agent-based zones to unsupervised clusters. The overlap (and divergence) between the two was instructive—sometimes the language splits a zone, sometimes it merges them. The upshot? ODSC East 2026 felt like the year AI builder culture became systems culture, with the practical energy shifting from models to the joints between architecture, data, evaluation, and governance.

On a personal note, I pivoted my own workshop last-minute to use Marimo Pair for a more modern, inspectable workflow. The response floored me—standing room only, hallway feedback, and a clear signal that hands-on, reproducible workflows resonate with practitioners.

For the full breakdown, including the interactive notebook and all the gritty details, check out the original post: ODSC East 2026 Zeitgeist.

The real story at ODSC East 2026: AI is moving from isolated demos to robust, accountable systems—where architecture, data, and governance matter as much as models.

What patterns or shifts have you noticed in your own AI or data science communities lately? Do you see the same move toward systems thinking?

Curious about the full taxonomy, the clustering visuals, or my workshop lessons? Read the full post and let me know what resonates—or what you’d do differently: ODSC East 2026 Zeitgeist.

Cheers,
Eric

Hello fellow datanistas!

Ever felt like AI is moving faster than you can keep up? For two weeks this spring, I found myself in a place I never expected: anxious, unmotivated, and completely burned out—decidedly un-capybara-like. If you’ve ever felt the same, you’re not alone.

This post is a candid reflection on my own experience with AI-related burnout—what it looked like, how I recognized it, and the small but meaningful changes that helped me reset. My hope is that by sharing my story, you’ll find something useful for your own journey, whether you’re deep in the AI trenches or just feeling overwhelmed by the pace of change.

Let me be honest: I’m usually the calm, steady type—my work profile pic is literally a capybara. But for a couple of weeks in April, I was anything but. Anxiety crept in, and with it came a host of symptoms: racing heart, decision paralysis, and a total lack of motivation to tinker with AI or even get out of bed. Work was a blur of triple-booked meetings and operational headaches, while spring allergies made everything worse.

What finally helped? A week in London, planned by my wife, where I let go of decision-making and just followed along. Wandering through the British Museum and Science Museum, I was struck by the vastness of time—ancient relics and cosmic timelines put my own stress in perspective. I realized how compressed and frantic my work life had become, and how easy it is to lose sight of what really matters.

I also noticed how the pace of life in the UK was different—people actually take time to enjoy themselves. Walking everywhere, unplugging from work, and reconnecting with my family reminded me of the importance of presence. Watching my kids play, catching up with my brother, and even just playing retro games at a museum—all of it helped me reset.

Most importantly, I remembered that AI is just a tool. It’s tempting to squeeze every ounce of productivity from it, but at what cost? We’re human beings, not human doings. The real magic is in the mundane: daily walks, board games with family, and genuine connection with others. If you’re feeling burned out, maybe it’s time to slow down, touch grass, and remember what makes us human.

AI is a powerful tool, but it’s not worth sacrificing your well-being or relationships for. Slow down, reconnect with what matters, and remember: you’re indispensable because you’re human.

Have you ever experienced burnout—AI-related or otherwise? What helped you reset, or what are you still struggling with? I’d love to hear your story.

If this resonates, I invite you to read the full post for more details and practical tips: How I Recognized and Handled AI Burnout. Feel free to share with anyone who might need it.

Cheers,
Eric

Hello fellow datanistas!

Ever wondered how different large language models (LLMs) actually perform when thrown into a real-world data science workflow? I recently put seven of them to the test using Marimo Pair, and the results were both enlightening and, at times, a little surprising.

In this post, I’ll walk you through my hands-on benchmarking experiment with Marimo Pair, where I evaluated seven LLMs on a practical data analysis task. My goal: to see which models could actually deliver usable, reproducible results—and what we can learn to improve our workflows (and our agents) going forward.

I’ve been following Marimo Pair since Trevor Manz demoed it to me back in March, and I was excited to finally put it through its paces. As someone who prefers to stay vendor-agnostic (I’m an OpenCode user, while Trevor codes almost exclusively with Claude Code), I wanted to see how Marimo Pair’s agent skill would fare across a range of LLMs.

To keep things fair, I set up a benchmarking repo, stripped out any potentially interfering skills, and crafted a single superprompt to guide each model through the same data analysis task: loading a real dataset from my Novartis days, plotting a heatmap, generating an UpSet plot, and writing a recommendation—all while following strict cell structure and markdown documentation requirements.

The models I tested:

• Claude Opus 4.6

• Claude Sonnet 4.6

• GLM-5.1

• Kimi K2.5

• Qwen 3 Coder Next

• MiniMax M2.7

• Gemma 4 31B

I automated the whole process with OpenCode scripting, ran each model in parallel, and logged everything for later analysis. The results? Some models (Opus, Sonnet, GLM) sailed through, producing valid, well-documented notebooks. Others struggled with markdown, import handling, or even basic execution. Cost varied wildly—from $0.03 to $2.00 per run.

What stood out most was how small tweaks in instructions or skill design could dramatically improve outcomes. For example, adding explicit import isolation examples or a post-edit validation loop could help budget models like Kimi K2.5 close the gap with premium ones like Opus. And, as always, defining and measuring the right KPIs (not just generic metrics) was key to actionable insights.

If you’re interested in the nitty-gritty—cost breakdowns, error modes, and what each model got right (or hilariously wrong)—I’ve shared the full logs, chat transcripts, and notebooks in the marimo-pair-benchmark repo.

Systematic measurement and thoughtful experiment design are essential for evaluating LLMs in real-world data science tasks—vibe-based experimentation just won’t cut it.

Have you tried benchmarking LLMs or agents in your own workflows? What KPIs or metrics have you found most useful (or surprising)? I’d love to hear your stories and lessons learned.

Curious about the full experiment, including all the data and artifacts? Check out the detailed write-up and repo here: Benchmarking LLMs with Marimo Pair. If you found this helpful, consider sharing or subscribing for more hands-on data science experiments.

Cheers,
Eric

Hello fellow datanistas!

Since the start of this year, I’ve been deep in the trenches of agentic coding—juggling multiple AI sessions, chasing breakthroughs, and, honestly, feeling more exhausted than ever. The tools are faster, the possibilities are wider, but something fundamental has shifted: my attention span is collapsing under the weight of parallel work.

This post is about the subtle but critical shift in how AI tools have changed our productivity curve—and why calibrating our feedback loops to match our brain’s processing speed is now essential for sustainable work (and sanity).

I’ve noticed a pattern: as AI tools accelerate, the temptation to parallelize work grows. I find myself with five or six open pull requests, bouncing between Claude Code sessions, and feeling like I’m always one step behind. It’s not just me—recent discussions online (like the Reddit thread on “AI psychosis”) show a whole community wrestling with the same thing: the sense that if you stop, you’ll miss out, but if you keep going, you burn out.

The core issue? AI has steepened the productivity curve. Pre-AI, more effort meant more output, but at a manageable, sustainable pace. Now, the curve is taller and narrower: you get more output for less effort—until you hit a sharp drop-off, where exhaustion sets in fast.

The real bottleneck isn’t the tools; it’s our brains. AI can process and generate code at lightning speed, but our neural throughput—the rate at which we can actually process, reason, and act on feedback—remains stubbornly biological. When the loop cadence (the speed at which you open, process, and close tasks) exceeds what your brain can handle, attention bleeds out and exhaustion takes over.

So what do we do? Calibration. Not optimization—calibration. The goal is to synchronize your feedback loops with your neural throughput. That means:

• Closing the loop on one task before opening another (no more juggling endless sessions)

• Using external systems (like Kanban boards) to manage context when multitasking is unavoidable

• Recognizing the signal: when you start scanning multiple threads for “what was done,” you’ve exceeded your bandwidth

It’s a daily discipline, not a one-time fix. The aim is to stay on the left slope of the productivity curve, where effort yields sustainable returns, rather than chasing the peak and tumbling off the edge.

AI tools have made it easier to do more, faster—but our brains are still the bottleneck. Sustainable productivity now depends on calibrating our work pace to match our neural capacity, not just pushing harder or faster.

Have you noticed your own attention span or energy shifting as you use more AI tools? What strategies (if any) have helped you avoid burnout or overwhelm?

If this resonates, I invite you to read the full post for a deeper dive—and let me know how you’re calibrating your own workflow. Here’s the link: Calibration is Synchronizing Feedback Loops with Neural Throughput

Cheers,
Eric

Hello fellow datanistas!

Ever found yourself staring at a sprawling, AI-generated codebase and wondering, “How did it get this messy, this fast?” I have. And I want to share what it took to turn that chaos into something maintainable.

This post is the story of how I built canvas-chat—a visual, non-linear chat interface—with heavy AI assistance, and how I wrangled an 8,500-line monolith into a clean, modular plugin system. More importantly, it’s about why AI can execute, but not architect, and why your own hard-won convictions matter more than ever.

Let me take you back to December 2025. I started canvas-chat with a flurry of AI-powered commits: sessions, matrix evaluation tables, web search, node tagging, BM25 keyword search. Features stacked up like Tetris blocks. The result? A functional, but tangled, 8,500-line app.js monolith.

The AI could add features, fix bugs, and split files when prompted. But it couldn’t see the latent architecture—the system that would make the whole thing maintainable. That vision had to come from me, shaped by years of seeing architectures both fail and succeed.

The first wave of refactoring was straightforward: extract pure functions, isolate feature modules, split out infrastructure. The AI handled these tasks well when directed. But the real leap came when I asked for a plugin system. Suddenly, we had a three-level architecture: custom node types, feature plugins, and extension hooks. The codebase became modular, testable, and ready for future changes—like swapping out the rendering layer for Svelte Flow.

But here’s the kicker: the AI didn’t suggest this architecture. It could implement, but not envision. The plugin system, the event hooks, the dependency injection—these came from my own battle-tested convictions, not from the AI’s suggestions. And when the AI started dropping curly braces and introducing regressions, it was the plugin architecture and a solid suite of E2E tests that kept things sane.

The numbers tell the story: from 8,500 lines in 5 files to 4,700 lines in 35+ modules. But the real lesson is about the limits of AI and the irreplaceable value of human experience.

AI can execute your vision, but it can’t create it. Battle-tested convictions—earned through experience—are what turn AI-generated chaos into maintainable systems.

Have you ever had to rescue a codebase (AI-generated or not) from architectural chaos? What hard-won lessons shaped your approach? I’d love to hear your stories.

If you’re curious about the full journey—including the technical details and architectural patterns—I invite you to read the full post here: Undoing AI Vibe-Coded Slop (With AI). If you found this helpful, consider sharing or subscribing for more stories from the trenches.

Cheers,
Eric

Hello fellow datanistas!

Have you ever noticed that when the economy tightens, the first thing to go is often the budget for professional development? Co-ops get paused, training dries up, and suddenly, opportunities to grow as a mentor or leader seem out of reach. But what if the best opportunities are already within your grasp?

This post is about finding creative, practical ways to develop mentorship and leadership skills—even when formal programs and budgets disappear. I want to share what’s worked for me, and hopefully spark some ideas for you to keep growing and helping others, no matter the circumstances.

When budgets freeze, it’s easy to feel stuck. But I’ve learned that you don’t need a formal program or extra funding to make a real impact as a mentor or leader. In fact, some of the most meaningful growth happens when we get creative with what we already have.

Here’s what I’ve found: you always have three things to offer—your judgment, your skills, and your network. Judgment is the wisdom you’ve built up over time, knowing which tradeoffs matter and when to push or hold back. Your skills are the technical foundation you can share with others, helping them onboard or level up. And your network is a powerful tool for connecting people to opportunities, even if it’s just inviting someone to a meeting or making an introduction.

I’ve tried a handful of strategies at Novartis and Moderna that don’t require a budget, just a bit of initiative:

• One-on-one coaching: Teaching others not only helps them, but also builds your reputation and value within the organization.

• Presenting at internal guilds or events: Sharing your knowledge in a group setting creates mentorship moments and helps you reach a wider audience.

• Organizing communities of practice: Even a simple group chat can become a hub for learning and leadership.

• Hosting informal coffee hours: These relaxed gatherings are great for authentic connection and sharing.

• Supporting external meetups: Sometimes, just offering a space or making an introduction can open doors for others.

If you’re a manager, it’s worth recognizing and supporting these grassroots efforts. Growth isn’t just about climbing the ladder or chasing titles—it’s about helping others, sharing what you know, and building a culture of learning wherever you are.

You don’t need an internal university to foster growth. Sometimes, the best learning happens right in your own environment, with the people around you.

You don’t need a big budget or formal program to grow as a mentor or leader—your judgment, skills, and network are powerful tools for helping others and developing yourself, even in lean times.

What creative ways have you found to mentor or lead when resources are tight? I’d love to hear your stories or strategies.

If you found this helpful, check out the full blog post for more details and examples: Creative Mentorship Strategies for Career Growth in Challenging Times. Feel free to share your own experiences or forward this to someone who might need a little inspiration.

Cheers,
Eric

Hello fellow datanistas!

Ever find yourself copying files, pasting data, or doing the same manual task over and over? I used to think these were just part of the job—until I learned to spot the ‘air gaps’ that slow everything down.

This post is about recognizing and closing the manual bottlenecks—air gaps—in our workflows. By mapping out where humans are doing rote work that computers could handle, we can reclaim time, reduce errors, and free up our minds for more creative problems.

I first heard the term ‘air gap’ from my colleague Wenhao Liu, and it immediately clicked. An air gap is any point in a process where a human has to step in and do something a computer could (and probably should) do. Think of it as a bubble in your workflow pipe—slowing things down, introducing errors, and taxing your attention.

Air gaps are everywhere: copying files from a lab machine to cloud storage, manually tracking your GitHub activity, or physically moving plates in a lab. Each one is a tiny tax on your time and focus. The real cost isn’t just the minutes lost, but the mental overhead of remembering and repeating these tasks.

The first step to closing air gaps is mapping your process. Walk through each step and ask: where am I copying, pasting, or following a fixed rule? Where am I waiting for someone else? Each answer points to a potential air gap. Once you see them, you can prioritize which ones to automate away.

I’ve closed air gaps in my own work—like automating GitHub activity tracking and file transfers in the lab. Sometimes the fix is a simple script; sometimes it’s a coding agent that can handle more complex tasks. The key is imagination (can you picture a better way?) and just enough technical skill to get started. And if your tools don’t have APIs, browser agents can often fill the gap.

The goal isn’t to eliminate humans from the loop, but to let us focus on creative, judgment-heavy work. Let robots handle the dull, dirty, and repetitive. The compounding effect of closing even small air gaps is huge—what feels like a minor efficiency today can transform your workflow tomorrow.

Map your processes, spot the air gaps, and close them one by one. The small wins add up to big changes over time.

What’s the most annoying manual task you still do at work? Have you tried mapping your process to find air gaps?

If you’re curious about how to spot and close air gaps in your own workflows, check out the full post for practical examples and steps: Read the full blog post.

Cheers,
Eric

Hello fellow datanistas!

Have you ever built an agent skill and realized it’s not just about the code? I’ve been thinking a lot about this as I tinker with agent skills at home and at work. There’s a subtle but important distinction between skills that just use tools, and skills that actually capture how we work.

This post is about why workflow-specific agent skills are more than just automation—they’re a form of documentation for humans, too. I want to share how our personal systems and assumptions get baked into these skills, and why making those explicit matters for anyone who wants to use or share them.

Let me give you a concrete example. I have a daily sign-off skill that helps me wrap up my workday. It pulls my GitHub activity and formats it into my daily bullet journal in Obsidian. But here’s the thing: this skill assumes you have the GitHub CLI installed, that you do PRs as part of your work, and that you organize your notes in a monthly file—not a daily one. That last bit is pretty opinionated, but it’s how I work.

If you wanted to use my sign-off skill, you’d be adopting more than just the code. You’d be stepping into my way of working—my file structure, my tool preferences, my mental model for organizing information. The skill comes with all these implicit assumptions, and unless they’re documented, someone else might find it half-useful at best.

I call this the procedural context. Workflow-specific agent skills encode not just what to do, but how and why. They’re not just for the agent—they’re for the next human who wants to understand or reuse your workflow. Without documenting the dependencies, environment, and what success looks like, it’s hard for anyone (or any agent) to verify if the skill is working as intended.

At the end of the day, agent skills are automation and documentation rolled into one. But if you want your skills to be truly useful for others, you have to teach the next person how to use them, not just what buttons to press.

Agent skills are also human skills—they document not just what to automate, but how we work. If you want your skills to be useful for others, make the assumptions and context explicit.

Have you ever tried to use someone else’s workflow or automation and run into hidden assumptions? How do you document your own workflows for others (or your future self)?

If this resonates, check out the full post for more details and examples: Agent Skills Are Also Human Skills. If you found it helpful, feel free to share or subscribe for more thoughts like this.

Cheers,
Eric

Hello fellow datanistas!

Have you ever tried to revive a magical demo from a few years ago, only to find that the tech landscape has quietly shifted beneath your feet? That was me this weekend, chasing the dream of running full Bayesian inference with PyMC—right in the browser, no servers, no installs.

This post is about my hands-on journey to get PyMC running in the browser using Pyodide and WebAssembly. I’ll walk you through the technical hurdles, the code changes I made, and the lessons I learned about open-source contribution and the current limits of browser-based Bayesian inference.

It all started with a sense of nostalgia: I revisited PyMC Labs’ 2022 blog post showing PyMC running entirely in the browser. The promise was huge—define models, run NUTS sampling, and visualize posteriors, all client-side. But when I tried the examples, nothing worked. The Python ecosystem had moved on, dependencies had shifted, and the Pyodide environment had changed.

So, I rolled up my sleeves and dove in. The main challenge? PyTensor, PyMC’s computational backend, needed to build for WebAssembly. That meant wrangling C and Cython extensions, Emscripten, and Pyodide’s build system. My key breakthrough was making Numba (PyTensor’s JIT compiler) an optional dependency for WASM builds—since Numba simply doesn’t exist for WebAssembly. This let PyTensor install, but at the cost of losing JIT compilation (and, heartbreakingly, the NUTS sampler).

I also experimented with a new Pixi-based dev environment for reproducible WASM builds, but ultimately, I realized that open-source contribution is about meeting maintainers where they are. My actual PR respected PyTensor’s existing mamba-based workflow, keeping changes minimal and maintainable.

The big letdown: NUTS (the gold-standard sampler) doesn’t work in WASM, and none of the modern MCMC backends (JAX, nutpie) have WASM support yet. It’s like getting a Ferrari with no keys—you can admire it, but you’re not going anywhere fast. Still, PyTensor now installs in WASM, PyMC can be imported, and simpler samplers might work for small models. The roadmap for full browser-based Bayesian inference is clearer, even if we’re not there yet.

If you want the nitty-gritty details, including code snippets and the full story, check out the original blog post: My Weekend Experiment: PyMC, WASM, and the Browser.

Sometimes, the most valuable outcome of a technical experiment isn’t a working demo, but a deeper understanding of the ecosystem—and a clearer path for the next person to follow.

Have you ever tried to port a Python package to WebAssembly or run complex scientific code in the browser? What roadblocks did you hit, and how did you work around them?

If you’re curious about the technical details or want to see the code changes, read the full blog post here. If you’ve tackled similar challenges, I’d love to hear your stories—reply or leave a comment!

Cheers,
Eric

Hello fellow datanistas!

Ever feel like you’re drowning in meetings, projects, and random documents—and your brain just can’t keep up? I’ve been there. Managing twelve people across two teams, each juggling multiple projects, forced me to rethink how I handle information. What started as a simple experiment with Obsidian and plain text turned into a system that changed how I work (and think).

This post is my honest, behind-the-scenes look at how I built a personal knowledge management (PKM) system using Obsidian, plain text, and AI coding agents. My hope is that sharing my process—warts and all—will inspire you to experiment with your own workflow, no matter your technical background.

When I first set out to improve my PKM at work, I faced a familiar dilemma: stick with the usual suspects (Confluence, OneNote), or try something new. I chose Obsidian and, more importantly, I chose plain text. At the time, it felt like a nerdy preference for graphs and open formats. In hindsight, it was a lucky break—plain text turned out to be the perfect foundation for integrating AI agents down the line.

My system revolves around a few core note types: monthly bullet journals, structured meeting notes, dossiers for people I work with, and project control towers. Everything is linked, everything is searchable, and—crucially—everything is in a format that both humans and AI can process.

Ingesting information used to be a slog. Now, AI skills handle the heavy lifting: parsing meeting transcripts, summarizing documents, and even extracting structure from messy Excel files. I’ve written Python scripts for everything from converting Word docs to plain text, to generating PowerPoint decks from Markdown. Each script declares its dependencies inline, so I never have to worry about environment issues or ‘works on my machine’ headaches.

The real magic is in maintenance. When I hit a context block—forgetting a detail about a person or project—I trigger a sweep. My coding agent updates notes based on source material, always quoting the original. I stay in the loop for verification, but the system does most of the grunt work. Retrieval practice and periodic reviews keep the vault trustworthy.

Sharing is intentional. I curate what gets published, whether it’s to Confluence, GitHub, or Google Docs. The agent creates publishable versions, and I review before sharing. The workflow isn’t perfect (I still wish I could ingest cloud docs by URL), but it’s reduced my knowledge management overhead from 30-40% of my time to less than 10%.

If you’re curious about the technical details or want to try some of my agent skills, I’ve published a few (like html-presentations and gh-activity-summary). The bigger picture: this system lets me offload repetitive work to AI, freeing up time for deeper thinking and more meaningful interactions. It’s not a prescription—just an invitation to experiment and find what works for you.

For the full technical breakdown and scripts, check out the original blog post: Mastering Personal Knowledge Management with Obsidian and AI.

Plain text plus coding agents is a powerful, future-proof combo for managing knowledge at work. The best system is the one you actually use—and document.

How do you keep track of everything at work? Have you tried building your own PKM system, or are you still searching for something that fits? I’d love to hear what’s worked (or not) for you.

If you found this helpful, check out the full blog post for scripts, technical details, and more stories. And if you’re experimenting with your own PKM setup, hit reply—I’d love to swap notes!

Cheers,
Eric

Hello fellow datanistas!

Speed without control is just chaos. I’ve watched teammates compress weeks of analysis into hours with coding agents—only to end up with a pile of plots and no clear answers. The real unlock isn’t speed. It’s staying in the driver’s seat.

This post is about how I use structure and intentional slow-downs to keep coding agents from running wild, so I can actually do better science—not just generate artifacts faster. I’ll share the design patterns and session structures that keep me (and my team) in control, and why that matters more than ever.

Let’s be honest: coding agents are eager. Hand them a CSV and they’ll spit out a dozen plots before you’ve finished your coffee. It feels productive, but it’s easy to lose the thread. I’ve been there—reacting to whatever the agent produced, rather than steering toward an answer.

So I started doing things differently. I built two skills for my agents: one for exploratory data analysis (scientific-eda), one for machine learning experiments (ml-experimentation). The pattern is the same: slow down first, gate on plots, and structure the session so both human and agent can follow what happened.

Slow down first: the Socratic opening

Instead of jumping into code, the agent asks questions. What’s the problem context? What are you hoping to learn? Any constraints? There’s even a guardrail: “ask ‘why’ before executing.” It feels slower, but it prevents wasted effort and rabbit holes.

Gate everything on plots

One plot at a time. If I can’t describe the x-axis, y-axis, and what I’m looking for, we don’t run the code. This forces clarity. The tradeoff? A bit of upfront thinking for a huge execution speedup—and far less wasted work.

Session structure: traceable by design

Each session lives in a timestamped folder: a journal.md for actions and findings, a plots/ directory for figures, and scripts/ for disposable code. The journal is the memory—timestamped, tagged, and scannable. Anyone (including future me) can follow the analysis without reading the code.

What changed for my teammates and I

The conversations shifted. We stopped defending code and started critiquing the analysis. The agent writes the code; we focus on the questions. It’s more collaborative, less ego-driven, and way more productive.

The key insight: design for the human, and the agent follows. Structure keeps you in control, and the agent becomes a force multiplier—not a loose cannon.

If you want to see the skills or the full breakdown, I’ve linked everything in the full post.

Speed is only valuable if you stay in control. Structure your agentic analysis to keep yourself in the driver’s seat—slow down, gate on plots, and leave a clear trace.

How do you keep your analysis focused when using coding agents? Have you found ways to stay in control, or do you sometimes feel like you’re just reacting to what the agent produces?

Curious about the full approach, including the skills and session templates? Read the full post here: Speed Without Control: How to Stay the Scientist with Coding Agents. If you find it useful, feel free to share or subscribe for more practical data science insights.

Happy coding!
Eric

Two P.S.-es :)

#1: quick plug for an open position with my wonderful colleague Mihir Metkar in the mRNA Design Team at Moderna, and that position will be in tight collaboration with my teammates in the DSAI Research team:

We’re hiring a Scientist, Platform & Therapeutic Area Bioinformatics at Moderna (Cambridge, MA).

This role sits at the intersection of RNA biology, algorithm development, and machine learning. You’ll develop new optimization algorithms and ML approaches for therapeutic mRNA design, working closely with RNA biologists, NGS, and high-throughput screening teams.

https://lnkd.in/ev9P5SeE

#2: my friend Hugo Bowne-Anderson is doing another cohort of his course, Building AI Applications for Data Scientists and Software Engineers, on Maven. It’s a useful course if you’re interested in learning how to build the new wave of AI-native software for the future. 25% off with the code friendsoferic. While he’s offered a referral fee, I’ve asked for it to be donated to the SciPy Financial Aid fund instead.

Hello fellow datanistas!

Ever wondered what happens when you let a coding agent loose on your data science workflow? I did too. After seeing the promise of agentic coding in software, I couldn’t help but ask: what if we applied the same principles to training machine learning models and answering scientific questions?

In this post, I share ten lessons I’ve learned from hands-on experiments with coding agents in data science—both at work and at home. My goal is to help you avoid my mistakes, leverage agents more effectively, and maybe even have a little more fun along the way.

Agentic coding isn’t just for software development. When I started experimenting with coding agents for data science, I quickly realized the parallels—and the pitfalls. Here are a few of the most important lessons I picked up:

1. Be prescriptive in your prompting. You need to know what you want and how you’ll evaluate it. In data science, that means framing hypotheses and iterating your way to answers, not just building features.

2. Strong patterns in the file system. Agents (like humans) need predictable places for experiments. A clear folder structure helps the agent know where to put things and where to look.

3. Put logging instructions in AGENTS.md. Logging is your agent’s window into what’s happening. Make sure your agent can introspect logs and learn from them.

4. Give it report-writing skills. Ask your agent to summarize what it observed, flag anything weird, and help you triage without reading every log line.

5. Keep an append-only journal. Both you and the agent should jot down observations. This running log becomes invaluable for understanding what happened and why.

6. Have the agent generate diagnostic plots. Plots are for you, logs are for the agent. Both are needed to build intuition and catch issues.

7. Instruct the agent to write the minimalist version first. Start small, debug fast, then scale up. The agent doesn’t get impatient—use that to your advantage.

8. Ask the agent to guide you step by step. Let it walk you through what it’s done, especially when you’re context-switching or running low on energy.

9. Learn the agent’s vocabulary. Pay attention to the terms it uses—you can reuse them for more precise prompts in the future.

10. Treat the agent as an executor of your curiosity. You lead, it follows. Don’t let it run ahead; use it as a jazz partner for your exploration.

These practices have helped me turn coding agents into true research partners, not just code generators. The full post dives into each lesson with stories and practical tips.

Treat coding agents as partners in your data science journey—set clear goals, structure your work, and use their strengths to amplify your own curiosity and expertise.

Have you tried using coding agents in your data science work? What lessons or surprises have you encountered along the way?

If you’re curious about the details (and want to see some real-world examples), check out the full post here: How to do agentic data science. If you found this helpful, please share it with a fellow datanista or subscribe for more hands-on insights.

Cheers,
Eric

Hello fellow datanistas!

Most conversations about AI coding models obsess over benchmarks and pass rates. But if you spend real hours in the loop, you know: what actually shapes your day is the feel of working with the model, not just its numbers.

In this post, I dig into the qualitative side of using LLMs as coding agents—how their personality, feedback style, and the tools around them shape your flow, trust, and productivity. I’ll share what I’ve learned from bouncing between models, why the agentic harness matters as much as the model, and how I now pick my tools based on the phase of work, not just the leaderboard.

When you start using LLMs as coding agents, the experience quickly becomes about more than just accuracy or latency. It’s about how often you have to intervene, how much you trust the process, and whether you stay in flow or get derailed by weird breakage.

Two axes keep showing up for me: time horizon (long-horizon autonomy vs. short-horizon iteration) and personality/verbosity (how the model behaves when it’s wrong, how much it narrates, and whether it stays constructive or spirals into apology loops).

But there’s a third ingredient: the agentic harness. The tools and checks that let the agent verify its own work, and the feedback you get while it’s running. A good harness—one that gives you live traces and fast tests—often matters more than swapping models.

For example, when refactoring a big codebase, long-horizon models like Opus-4.5 or GPT-5.2 can generate plausible scaffolds, but they struggle with careful, incremental work. Short-horizon models (Sonnet, Minimax M 2.1, Composer-1) shine when you need to walk through changes step by step, watching traces and intervening early.

The real breakthrough for me wasn’t just picking the right model, but adding simple, fast tests (like Cypress reloads) to the harness. Suddenly, the agent could catch basic breakages immediately, and I could trust the loop again.

Personality matters too. Some models apologize endlessly when they mess up (looking at you, Gemini 2.5), while others stay upbeat and constructive. That emotional texture shapes the whole coding experience. Enthusiasm, it turns out, is a feature.

And don’t underestimate the illusion of speed: streaming feedback and live traces make the wait feel shorter and keep you in the loop. A spinner with no feedback? That’s a recipe for frustration, no matter how fast the model is on paper.

After enough hours, you start to build muscle memory for a model’s quirks. That comfort is sticky—and a subtle form of vendor lock-in. I try to stay fluent across models, so I don’t end up optimizing my workflow around one set of quirks and calling it productivity.

Now, I pick my tools based on the phase of work: long-horizon autonomy for scaffolding, short-horizon iteration for refactoring or debugging, and always, always improving the harness before blaming the model. Fast, agent-runnable tests have saved my sanity more than any leaderboard-topping model ever could.

If you want the full story, including concrete examples and code, check out the full post: Model Feel, Fast Tests, and AI Coding That Stays in Flow.

The feel of your AI coding agent—and the feedback harness around it—matters as much as raw model performance. Fast, agent-runnable tests and constructive feedback loops keep you in flow and make the whole system more trustworthy.

How do you choose between long-horizon autonomy and short-horizon iteration in your own coding workflows? Have you found a harness or feedback loop that changed the way you work with AI agents?

If this resonated, read the full post for more stories and code examples, and consider sharing your own experiences or subscribing for future deep dives.

Happy Coding,
Eric

P.S. My friend Zhaojie Zhang is hiring a Principal Scientist for Safety and Regulatory Data Insights! He’s an awesome guy to work with. Applications are here.

Hello fellow datanistas!

Ever find yourself explaining the same thing to your coding agent over and over? I’ve been there. It’s a sign that something in your workflow wants to be systematized—and that’s where the real compounding value starts.

In this post, I’m sharing how to move beyond ad hoc prompting and start building self-improving coding agents—by combining repository memory and reusable skills into a practice that actually evolves with you.

Let’s be honest: most of us start with agents by just typing prompts in chat, hoping for magic. But if you want your agent to become more than a chat box—if you want it to feel like a teammate—you need a system for memory and skills that grows over time.

Here’s the maturity model I’ve been using:

• Stage 0: Ad hoc prompting — You keep re-explaining things. It works, but it doesn’t compound.

• Stage 1: Repo-local memory — Add AGENTS.md to capture repo-specific rules, navigation, and guardrails. Now your agent knows the lay of the land.

• Stage 2: Global personal skills — When a workflow repeats, promote it to a global skill. Tools like `skill-creator`, `openskills`, and `agents-md-improver` help you bootstrap this.

• Stage 3: Shared skills — If your team keeps repeating a workflow, promote it to a shared skill. But don’t start here—let pain guide your promotions.

The trick is to watch what your agent does in practice. When it takes a weird path or misses something obvious, ask: is this a repo rule (AGENTS.md) or a repeatable procedure (skill)?

What’s wild is that Markdown is becoming executable. When your agent can run tool calls, a SKILL.md isn’t just documentation—it’s a playbook the agent can run: searches, edits, tests, you name it. The agent loads skills on demand, so you can write instructions at the level you actually think about them, and let the agent handle the clerical work.

The real meta skill here is metacognition: noticing what you do repeatedly, and deciding what should be systematized. That’s how you build a compounding loop—your agent handles more of the grunt work, and you get to focus on judgment and design.

This isn’t just about coding. Once your agent can run commands and manipulate files, the surface area expands to almost anything intellectual—writing, release notes, even structuring messy notes. The label “coding tool” is starting to feel more like marketing than reality.

The combination of repository memory and reusable skills turns your agent from a chat box into a true teammate—one that learns from your workflow and grows with you.

How are you currently using agents in your workflow? What’s the biggest pain point you wish you could automate or systematize?

If you want the full breakdown (including concrete tools and decision criteria), check out the full post: How to Build Self-Improving Coding Agents: Part 3. If you found this useful, feel free to share or subscribe for more.

Happy Coding,
Eric

Hello fellow datanistas!

Ever find yourself explaining the same workflow to your coding agent over and over? I did, and it was draining my energy. So I started building skills—reusable playbooks that let my agents handle repetitive tasks without me having to spell things out every time.

In this post, I dig into the concept of ‘skills’ for coding agents: what they are, how I use them, and why they’ve become essential in my workflow. If you’re tired of repeating yourself and want your agents to actually learn, this is for you.

Skills are the other half of the self-improving agent system—prompt compression in action. Instead of re-explaining a workflow, I want a playbook I can invoke. For me, a skill is just a folder with a SKILL.md file (the prompt) and any scripts or assets needed. A good skill makes three things explicit: when to use it, what steps to take, and what good output looks like.

Some examples from my own work:

• A GitHub debugging skill for CI failures, so the agent follows a repeatable process.

• A release announcement skill, so I don’t spend half an hour composing messages for Teams every time.

• A report-writing skill for ML model training sessions, using real logs and artifacts.

• A domain expertise skill, where a teammate encoded her chromatography debugging process—making tacit knowledge explicit and reusable.

What I like about skills is how easy they are to iterate on. I can feed my agent examples of what “good” looks like, and as my taste evolves, I update the skill. It’s a feedback loop: edit, improve, repeat. Skills are also reviewable and shareable—open a PR, get feedback, and everyone benefits.

Distribution is still a work in progress. Tools like OpenSkills are making it easier to install and update skills across machines and repos, but discovery isn’t standardized yet. Still, the direction is promising, and I expect things to converge soon.

With both memory (AGENTS.md) and skills (playbooks), the next question is: what do you invest in next? That’s what I’ll cover in Part 3.

Skills turn repetitive workflows into reusable playbooks for your coding agents, making them smarter and saving you time.

What’s one workflow you wish your coding agent could handle without you having to explain it every time? Have you tried building a skill for it?

If you want to see concrete examples and my full process, check out the full post: How to build self-improving coding agents - Part 2. If you find it useful, feel free to share or subscribe for updates.

Happy Coding,
Eric