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

Hello fellow datanistas!

Ever feel like your coding agent is just a really fast intern you have to keep correcting? I’ve been there. I wanted my agents to actually learn from my feedback—not just repeat the same mistakes every session.

This post is about making coding agents genuinely self-improving, even when the underlying model isn’t changing. I’ll share the two levers I use—AGENTS.md as repository memory and skills as reusable playbooks—to help agents remember corrections and get better with every run.

The user experience I’m after is simple: I want to stop repeating myself. No more end-of-day cleanups, no more re-explaining where files live, no more restating the same preferences. If the model weights aren’t changing, improvement has to come from the environment around the agent.

For me, that environment has two key pieces:

• Durable repository memory (AGENTS.md)

• Reusable playbooks (skills)

Once you have these, you can treat agent improvement like a runbook plus postmortem loop: write down repeatable steps, document surprises, and update for next time. The difference is, with agents, natural language can turn into tool calls—so writing things down precisely means the agent can actually execute them.

AGENTS.md as Repository Memory

If you haven’t used AGENTS.md before, it’s a convention for giving agents a persistent memory of your repo. It does two things:

1. Fast navigation: A code map helps the agent find files quickly, cutting down on wasted exploration.

2. Local norms: Corrections and repo-specific rules live here, so the agent stops making the same mistakes.

Here’s the loop I want:

• I spot a mismatch.

• I tell the agent what should be true.

• The agent writes the correction into AGENTS.md (or a local skill).

• The agent reads it next time.

A practical example: In my canvas-chat codebase, a simple code map let the agent one-shot a tricky spot for node rendering events. Without it, the agent needed 5-6 searches just to get close. The time saved is small, but the collaboration feels smoother—I steer less, the agent wanders less.

Keeping the Map Alive

The map isn’t static. When the agent finds it’s out of date, it should update AGENTS.md. This closes the loop and keeps the environment alive. You can even encode this as an explicit instruction in AGENTS.md.

Corrections That Stick

AGENTS.md also holds the rules you find yourself repeating. For example:

• Run Python in the pixi context.

• Don’t cheat by modifying tests to make them pass.

Once these are written down, the agent stops making you restate them. It’s the simplest way I know to reduce repeated friction.

Bootstrapping AGENTS.md

I use a one-time deep dive prompt to generate AGENTS.md, focusing on codebase maps, local norms, and self-correction rules. The goal is compounding value, not bureaucracy—keep it lightweight, but make sure it grows with your feedback.

Once AGENTS.md exists, skills are the next lever. (Stay tuned for Part 2!)

If you want your coding agents to actually improve, don’t just wait for better models—give them a persistent memory (AGENTS.md) and clear, reusable playbooks. That’s how feedback sticks and agents get smarter every week.

How do you help your coding agents learn from your feedback? Have you tried AGENTS.md or something similar? I’d love to hear your approaches and what’s worked (or not) for you.

Curious for the full details, including my starter prompt for AGENTS.md? Read the full post here: How to Build Self-Improving Coding Agents - Part 1. If you found this helpful, please share or subscribe for Part 2!

Happy Coding,
Eric

Hello fellow datanistas!

Ever found yourself deep in an LLM chat, wanting to branch off in a new direction—only to lose your train of thought or context? That was me, again and again, until I finally decided to build the tool I wished existed.

This post is about Canvas Chat: an open-source, visual, nonlinear interface for thinking with LLMs. I’ll share why I built it, how it works, and what I learned along the way—especially for those who’ve ever felt boxed in by linear chat interfaces.

The idea for Canvas Chat had been simmering since last January: what if LLM conversations could branch, merge, and form a visible map of your thinking? For a long time, it felt out of reach—my browser and UI skills weren’t up to the task, and the implementation cost seemed too high for a side project.

But a Christmas break ultralearning sprint (and some pressure-testing of Claude Opus 4.5) changed my mind. Suddenly, it felt possible to prototype this in a day. I went from idea to working prototype in about 24 hours, then spent another day refining and deploying it. The result: Canvas Chat.

Here’s the core problem: linear chat forces nonlinear thinking into a straight line. You lose context, copy-paste between windows, and struggle to synthesize ideas across sessions. Canvas Chat solves this by letting you branch from any message, highlight and drill into specific ideas, and even merge multiple threads for synthesis—all on an infinite canvas.

Some features I’m excited about:

• Branching: Reply to any node, not just the latest, and see your thinking split visually.

• Highlight & Branch: Select text, ask a follow-up, and keep the original intact while exploring new directions.

• Multi-select & Merge: Combine threads, ask synthesis questions, and let the LLM see the full context.

• Matrix Evaluation: Evaluate options against criteria in a matrix, fill cells with LLM help, and pin insights for further exploration.

• Web Search & Deep Research: Integrate neural search and multi-step research directly into your canvas.

• Local-first, Multi-provider: No server-side storage, open source, and supports multiple LLM providers.

Building this reinforced a lesson: you don’t need to be a UI expert to ship something useful. I stayed in product builder mode, described what I wanted, and let the LLM handle the mechanics. The creative work—deciding what nonlinear chat should feel like—remained human.

If you want to try Canvas Chat, it’s open source and easy to run locally. All the details (and the why behind each feature) are in the full blog post.

You don’t have to settle for linear thinking with LLMs—Canvas Chat lets you map, branch, and synthesize your ideas visually, making complex exploration possible.

Have you ever wished you could branch or merge your LLM conversations? What would your ideal interface for thinking with AI look like?

Curious to see Canvas Chat in action or want to try it yourself? Read the full post for details, screenshots, and setup instructions: Canvas Chat: A Visual Interface for Thinking with LLMs. I’d love your feedback—let me know what works, what doesn’t, or what you’d build next.

Cheers,
Eric

P.S. Friends who are hiring have been sharing job postings. For those interested in the life sciences, here is one roles that I know of that has opened up: Product Line Manager, Digital M&S AI Solutions, Sanofi, referred by my friend Yunke Xiang.

Hello fellow datanistas!

Have you ever spent hours chasing a simple bug, only to realize the solution came from a field you never expected? That was me this week, wrestling with a browser text selection issue in my canvas-based chat app—until a dusty bioinformatics algorithm came to the rescue.

In this post, I want to share how a frustrating UI bug led me down a rabbit hole of failed fixes, and how recognizing the problem as a sequence alignment challenge (yes, like DNA!) finally cracked it. If you’ve ever wondered when those old algorithms you learned might actually come in handy, this story’s for you.

The bug started innocently enough: users selecting text from a markdown table in my canvas-chat app would get weird, broken highlights—sometimes stopping mid-selection, sometimes highlighting the wrong characters. The culprit? KaTeX-rendered math and the way browsers mix up text from both the visual HTML and the hidden MathML for accessibility. The result was a selection string full of duplicated numbers, random newlines, and spacing that didn’t match the source HTML at all.

My first instinct was to normalize everything—collapse whitespace, remove duplicates, and try to map positions back and forth. But the deeper I went, the more tangled the code became. Every fix for one edge case broke another. I was trying to force two messy things to be identical before comparing them, and it just wasn’t working.

That’s when I remembered Smith-Waterman, the local sequence alignment algorithm I learned in undergrad bioinformatics. Instead of making things identical, it’s designed to find the best match between two sequences, tolerating insertions, deletions, and mismatches. Perfect for this mess!

I used the algorithm to align the start and end of the user’s selection to the HTML text, letting it handle all the browser artifacts naturally. Suddenly, all my test cases passed—even the gnarly ones with KaTeX duplication and cross-block selections. The best part? I didn’t even write the implementation myself; I described the approach and let Claude Opus 4.5 handle the code. My job was recognizing the pattern and guiding the solution.

If you’re curious about the nitty-gritty details (including code), I’ve shared the full story and implementation in the blog post.

Sometimes the best fix for a modern web bug is an old algorithm from a totally different field. Don’t be afraid to reach across domains—and let AI help with the heavy lifting.

Have you ever solved a problem by borrowing an idea or algorithm from a completely different discipline? I’d love to hear your stories—what unexpected connections have you made in your work?

If you want to see the full breakdown (with code and examples), check out the full post here: How I Fixed a Browser Selection Bug with Sequence Alignment Algorithms. If you found this helpful, feel free to share or subscribe for more stories like this.

Cheers,
Eric

Hello fellow datanistas!

Ever put off a five-minute task for eight months, only to spend an hour reinventing it from scratch—just because you wanted to try a new tool? That was me, rebuilding my tmux status bar with a little help from OpenCode and Claude.

This post is about how I used AI pair programming to bridge the gap between my creative vision and the technical reality of theming my tmux status bar. It’s a story of iteration, failed attempts, and the surprising ways AI can amplify (not replace) our judgment and taste.

When I got a new laptop, I could have just copied my old tmux config. Instead, I procrastinated for months—until curiosity about OpenCode (a CLI tool for chatting with Claude right in the terminal) finally nudged me into action. What followed was a surprisingly creative session: I described what I wanted, Claude translated my aesthetic intent into working config, and we iterated in a tight feedback loop—no browser context-switching required.

We tried plugins like powerline-go (which failed hilariously), then tmux-powerline (which overloaded my status bar with info). When Claude Sonnet started looping on the same fixes, I switched to Claude Opus, which immediately suggested ditching plugins and going native. That was the breakthrough: using Unicode arrows and Nord color gradients, we built a clean, minimal, powerline-style status bar—no plugins needed.

The real lesson? AI let me work like a designer. I could say, “the arrows should overlap” or “make the battery segment green,” and Claude handled the syntax. Each iteration surfaced preferences I didn’t know I had. The process was less about technical know-how and more about expressing taste, with AI removing the friction.

If you’re curious about the nitty-gritty (including the final config), I’ve shared the full story and code snippets in the blog post.

AI can’t replace your creative judgment, but it can remove the technical friction—letting you iterate faster and get closer to what you actually want.

Have you ever used AI tools to help with a creative or technical project? What surprised you about the process?

If you want to see the full config, the step-by-step journey, and some lessons learned, check out the full post here: How I themed my tmux with OpenCode and Claude.

Happy Coding!
Eric

Hello fellow datanistas!

I used to obsess over code—syntax, edge cases, the nitty-gritty details. But something shifted. Now, I just describe what I want, and it materializes. It feels a little like magic, but it’s really just OpenCode and Claude Opus 4.5 doing their thing.

This post is about my journey from being a hands-on coder to becoming a builder who directs AI to create. I’ll share what changed, how I adapted, and what I learned after ten days of deliberate practice with OpenCode and Claude Opus 4.5.

The transition didn’t happen overnight. At first, I was skeptical—could an AI really handle the architectural decisions, the documentation, the refactoring, and the edge cases? But as I spent more time with Claude Opus 4.5 (accessed through OpenCode + Github Copilot Pro), I found myself letting go of the urge to micro-manage. I’d ask for a feature, and it would appear. I’d request a refactor, and it would just happen. The gap between what I imagined and what got built shrank to almost nothing.

Over ten days, I put this new workflow to the test. I shipped over 150 commits across six repositories: a ski trip coordination website, a teaching clock app for my kids, infrastructure work for pyjanitor, a new conda-forge package, a custom tmux status bar, and a visual chat interface. The variety was key—this wasn’t just luck on one type of project. The AI handled infrastructure, greenfield apps, documentation, and even languages I’d avoided for years (hello, JavaScript!).

What surprised me most was how my review process changed. Instead of scrutinizing every line of code, I started by reading the model’s reasoning traces. If the logic made sense, the code usually did too. When I needed a fresh perspective, I’d start a new session—like getting a second pair of eyes, but instantly.

I also had to unlearn old habits. My decade-old “no JavaScript” rule? Out the window. The model writes JavaScript just fine. The real challenge became keeping my assumptions up to date with what the tools can actually do. I still need enough technical vocabulary to direct the AI and spot when something’s off, but I spend far less time on the mechanics and more on the creative direction.

The upshot: I’m spending less time worrying about how things are built and more time focusing on what gets built and why. The creative work is still mine—the heavy lifting is handled by the AI.

The shift from ‘I code’ to ‘I build’ is real—and it’s powered by tools like OpenCode and Claude Opus 4.5. The more I trust the process, the more I can focus on creativity and impact.

Have you tried letting AI take the lead in your coding projects? What surprised you—or held you back—from making the leap?

If you’re curious about the details, check out the full story (with examples and lessons learned) on my blog: You can just make stuff with OpenCode and Claude Opus 4.5. If you found this helpful, feel free to share or subscribe for more reflections.

Happy coding!
Eric

Hello fellow datanistas,

First off, Merry Christmas to all! I wanted to thank everyone here for your readership and support.

I started 2024 with a simple challenge: write one blog post every week. Two years and 104 posts later, I’m surprised by how much my thinking—and my work—has changed. This is a look back at what I learned, what I built, and where I’m heading next.

This post is a personal reflection on two years of near-weekly blogging, with a focus on the evolution of my work with coding agents, Bayesian statistics, and the realities of data science in biotech. I want to share the patterns, tools, and lessons that shaped my year, and offer a candid look at what’s next.

Looking back at 2025, one theme stands out: coding agents. I went from experimenting with AI as a tool to treating it as a true collaborator—teaching agents with AGENTS.md files, letting them work autonomously, and developing patterns for agent-assisted programming. This shift changed how I approach both code and research.

But it wasn’t just about AI. I dove deep into Bayesian methods, especially the R2D2 prior, and found real satisfaction in applying new theory to messy lab data. Writing about these topics helped me clarify my own thinking and (hopefully) made the math more approachable for others.

I also got excited about new tools—Marimo for reactive notebooks and Modal for Pythonic cloud computing—because they actually made my workflow smoother, not harder. And I kept writing about the human side of data science: standardizing ways of working, communicating with lab scientists, and navigating the unpredictable biotech industry.

After 104 posts, I’m shifting my goals for 2026. I want to learn quantum computing fundamentals, write more about data science leadership, and build at least 10 experimental AI projects. I’m also giving myself permission to slow down: four posts a month instead of one a week, with more space for rest and strategic planning.

If you’re curious about the full journey, including a categorized list of all my posts, you can find it here: Two Years of Weekly Blogging and What 2025 Taught Me.

Sustained, reflective writing not only documents your journey—it transforms how you think, work, and grow. Letting yourself evolve (and rest) is just as important as showing up every week.

How has your own approach to learning or working changed over the past year? Have you found any tools, habits, or mindsets that made a real difference?

If you want the full story—including all the posts by theme—check out the full blog post. And if you found this helpful, feel free to share or subscribe for more honest reflections and practical tips.

Cheers,
Eric

Hello fellow datanistas!

Have you ever wondered why you should keep giving your best at work, especially when the company—or the industry—feels shaky? I’ve been there, and I want to share a perspective that’s helped me through the lean times.

This post is about reframing why we work hard, especially when motivation is low or the environment feels uncertain. I want to offer encouragement and a philosophy that’s helped me invest in my own growth, regardless of where I am or who’s watching.

This year in biotech has been a rollercoaster—ups, downs, and plenty of uncertainty. It’s easy to fall into the trap of doing just enough, especially when the world is talking about “acting your wage.” But I’ve learned that the real reason to do your best work isn’t for your company—it’s for yourself.

When you treat your effort as an investment in your own instincts and habits, you’re building the person you’ll become in five or ten years. Your reputation, your skills, your ability to make judgment calls—these are the things that stick with you, no matter where you work next. I’ve seen this firsthand with colleagues who went on to lead teams and startups, not because they waited for the perfect assignment, but because they consistently showed up and owned their work.

But this goes beyond technical execution. How do you handle mistakes and setbacks? I’ve made my share of blunders—like the time I wrote a scathing internal blog post early in my career. It was a tough lesson in humility, but it taught me that owning up, proposing solutions, and moving forward is the best way to build character and trust. Most mistakes aren’t career-ending; they’re opportunities to grow, if you let them be.

Ultimately, the wealth you build through your work will be more than mere titles or promotions. You will have the satisfaction of mastery, the strength of your reputation, and the resilience you develop along the way. Even when things are tough, don’t give up on investing in yourself. Fortune really does favor the prepared!

If you want to read the full story and dive deeper into these ideas, check out the original post: The selfish reason to do your best work.

Do your best work for yourself, not for your company—but because the habits, reputation, and resilience you build are the real, lasting wealth of your career.

Have you ever had a moment where doing your best—despite tough circumstances—paid off later in your career? I’d love to hear your story.

If this resonated with you, please read the full post, share it with a friend, or subscribe for more honest reflections on work and growth.

Cheers,
Eric