RSS Feed

Rewriting cBioPortal's Backend in Go with AI Agents: Prototype and Prompt Analysis

Thu, 15 Oct 2026 12:00:00 GMT

A lot of code is being rewritten by AI agents this year. GitHub ported the Copilot agent runtime from TypeScript to about 800,000 lines of Rust in a few months, mostly with Copilot itself (write-up). Anthropic’s guide to AI-driven code modernization says projects that used to take years “can now finish in months (or weeks).”

Some are controversial. ArtCraft, an AI-built “Adobe-compatible” suite in Rust, launched with the line “I just one-shotted Photoshop.” People who tried it found that text editing and brushes didn’t work, and the Hacker News thread turned into an argument about overclaiming. Getting an agent to write a rewrite is quick now. Showing that it behaves like the original is the slow part.

Bioinformatics has its own wave, mostly into Rust. Heng Li lists many of them in The AI Rewrite Dilemma, from fgbio to fgumi and FastQC to RastQC, and argues that the people side is harder than the technical side: “Empathy matters more than technical benefit or legal correctness.” Anthropic’s guide says much the same: the slow part is getting everyone to agree on what the rewrite should do and how to check it. Phil Ewels at Seqera set out principles for doing it well at rewrites.bio: match the original’s output exactly, credit its authors, and say what you did and didn’t validate.

My own first attempt, in February, was vibe-vep, a Go rewrite of VEP in a single binary. VEP is one of the more expensive parts of keeping cBioPortal’s variant annotations up to date. vibe-vep worked well, but then we learned that Kuan-lin Huang’s lab at Mount Sinai was building a Rust rewrite, fastVEP. So we paused vibe-vep and benchmarked theirs instead. Meanwhile the models kept getting better at this kind of work, so this summer we tried something bigger as a proof of concept: cBioPortal’s own backend.

This post covers what came out of it and how the work went, measured from the agents’ session logs. Whether to roll it out is up for discussion in RFC 106.

Contents: The rewrite · Rewrite compared · How many prompts? · Prompts categorized · Prompts: the new source code? · Lessons

The rewrite

cbioportal-go replaces cBioPortal’s Java REST API and its importer, about 130,000 lines of Java and configuration built up over more than ten years, with Go. Everything else stays: the website, the ClickHouse database and the session service. The diagram shows what changes. It’s an experiment for now, not an official cBioPortal release. In the terms of Anthropic’s modernization guide, it’s a transform: new code in a new language, same behavior.

Hover over a box to see what it does and what it uses on the public portal. Click it to open its repository.

React website · cBioPortal/cbioportal-frontend

The website people use. It gets all its data from the REST API.

Unchanged: both backends serve the same website build.

Java API · cBioPortal/cbioportal

The Spring Boot REST API that answers the website, scripts and AI agents. About 80,000 lines of Java.

About 1.8 GB of memory per server on average and 0.34 s of CPU per request. MSK runs 20 Java backend servers across its portals, about $1,280 a month.

Redis cache · redis.io

Keeps the Java API's answers for 60 minutes, so repeated requests skip the database.

Answers 65 to 75% of Java's lookups. Its servers cost about $215 a month. The Go version has no response cache.

Importer (Java + Python) · cBioPortal/cbioportal-core

Checks study files and loads them into the database. About 33,000 lines of Java and Python.

Loading MSK-IMPACT (50,000 samples) takes 289 s and 3.9 GB of memory.

Go API · cBioPortal/cbioportal-go

Answers the same REST API as Java, field by field. Keeps study metadata in memory.

About 48 MB of memory per server on average (131 MB at most) and 0.11 s of CPU per request. The servers for all portals would cost about $160 a month.

Importer (Go) · cBioPortal/cbioportal-go

Loads the same study files into ClickHouse. It lives in the same repository and program as the Go API.

Loading MSK-IMPACT takes 80 s and 0.2 GB of memory.

Session service · cBioPortal/session-service

Stores users' saved pages, virtual studies and custom data.

Shared by both backends and not part of the rewrite.

ClickHouse · clickhouse.com

The database that holds all study data, on ClickHouse Cloud.

Both backends use the same data. On the API portal's traffic, Go used 0.92 times Java's ClickHouse CPU per request.

MongoDB · mongodb.com

The database behind the session service.

Unchanged.

What changes: the API and the importer (blue) move to Go, and the Redis cache goes away. The website, ClickHouse and the session service stay the same.

We picked Go because a Go server needs a fraction of a Java server’s memory, builds in seconds, needs few outside libraries, and is plain enough for others to review. I had actually started in Rust. After a day I asked Claude whether Go would fit better, and it said yes, even with part of the Rust version already written. The API mostly turns HTTP requests into ClickHouse queries, so the time goes to the database and Rust’s speed buys little. Rust rebuilds took 10 to 20 seconds. And cBioPortal’s contributors mostly write Java, which makes Go easier to pick up. When I asked again in October, it gave the same answer and added that most of the work had been matching Java in many small ways, where a fast compile loop helps. RFC 106 has the full reasoning.

The API has no complete written spec, so the Java code serves as one: “correct” means “gives the same answer as Java.” We check that in layers, from fast to slow:

unit tests for statistics, binning and query building
contract tests for every endpoint’s status codes, fields, order and errors
the same requests sent to the latest Java version, loaded with the same test studies
checks that both importers store the same data
cBioPortal’s own website test suite (about 365 Playwright test files), running in a real browser against Go
every night, about 5,000 of the previous day’s production requests sent to both backends and compared
a share of live traffic copied to Go to measure speed, memory, errors and database load

Rewrite compared

The numbers come from the public portal, cbioportal.org. Its API answers about 36 million requests a month, and on weekdays about a third of them come from scripts and AI agents (see the usage page).

Server errors (one day)

Hover over or tap a tile for what it measures.

Lines of code: The web API and the importer together. Java's count includes configuration. Go's code lives in one repository and has three outside dependencies.

Memory reserved: What each production server sets aside. Java can grow to 12 GB and Go to 2 GB.

Memory used (avg): Average over one day of copied traffic. Go peaked at 131 MiB, while carrying a tenth of Java's load.

Median request: Half of all requests are answered faster than this. Java answers many small repeated requests from its Redis cache; Go has no response cache.

Slow requests (p99): The slowest 1% of requests. Go's p99 is lower on every busy route, but rests on fewer requests than Java's.

Server errors (one day): Java answered all of the day's requests, Go a 10% copy. At Java's rate Go would have had about 6 errors, so zero is encouraging but not proof.

Monthly server cost: An estimate for the 20 Java backend servers MSK runs across its portals, about $1,280, plus about $215 for Redis. Go would fit on two servers, but hasn't been tested at full traffic yet.

MSK-IMPACT import: Loading the largest public study (50,000 samples) from its files. Java's importer used 3.9 GB of memory, Go's 0.2 GB.

Container image: The download size of the server, with the website included.

Speed, memory and errors come from one day in October when Go got a copy of 10% of the public portal’s API requests. Speed compares fairly. Memory, errors and cost are less certain until Go has run at full traffic.

Java’s Redis cache mattered less than we expected. It answers 65 to 75% of Java’s lookups, which makes Java faster on small requests that repeat often. Go has no response cache, yet it matches Java’s typical response time and beats it on slow requests. On the API portal’s traffic it even put slightly less load on ClickHouse per request. Leaving out Redis saves another $215 a month.

In the nightly check of October 12, 4,531 of 4,959 replayed production requests gave identical answers. The other 428 all had known causes, for example a Java bug that Go fixes, or an answer Java itself gives differently each time. None were unexplained. RFC 106 asks for seven clean nights in a row before Go serves real traffic.

The AI tools ran on Claude subscriptions, a few hundred dollars over three months. At Claude API list prices the same work would have cost about $2,000 ($550 in July and $1,400 in October), less than two months of the estimated server savings. 98% of what the agents read was served from the prompt cache. Without it, the bill would have been about $22,500.

How many prompts?

The work took a few weeks of supervised agent time, spread over three months next to my other work. It ran mostly as one long Claude Code session in a tmux window on a server (the setup is in my async software engineering post). That main session handed single tasks, such as one group of endpoints or one speed fix, to helper agents, each working in its own copy of the repository. A change went in only after the tests passed and its measurements were checked.

The work came in two stretches, July and October, with a pause in between. Git agrees: there are no commits from late July until October 2. The chart shows my messages, the agents’ tool calls, commits and the size of the code per day.

Hover over or tap a day to see its numbers.

Jul 8 to Sep 30: low activity, 11 messages and 5 commits in total.

Tue Jun 30: 1 messages from me, 7 agent tool calls, 0 commits, Go code not committed yet, Claude Opus 4.6.

Wed Jul 1: 0 messages from me, 0 agent tool calls, 0 commits, Go code not committed yet.

Thu Jul 2: 5 messages from me, 175 agent tool calls, 0 commits, Go code not committed yet, Claude Opus 4.8.

Fri Jul 3: 32 messages from me, 1,297 agent tool calls, 0 commits, Go code not committed yet, Claude Opus 4.8.

Sat Jul 4: 2 messages from me, 412 agent tool calls, 0 commits, Go code not committed yet, Claude Opus 4.8.

Sun Jul 5: 4 messages from me, 76 agent tool calls, 2 commits, 10,402 lines of Go, Claude Opus 4.8.

Mon Jul 6: 0 messages from me, 23 agent tool calls, 2 commits, 10,528 lines of Go, Claude Opus 4.8.

Tue Jul 7: 0 messages from me, 106 agent tool calls, 5 commits, 10,605 lines of Go, Claude Opus 4.8.

Thu Oct 1: 2 messages from me, 824 agent tool calls, 0 commits, 11,206 lines of Go, Claude Opus 5.5.

Fri Oct 2: 94 messages from me, 5,046 agent tool calls, 46 commits, 40,953 lines of Go, Claude Opus 5.5.

Sat Oct 3: 21 messages from me, 806 agent tool calls, 21 commits, 43,828 lines of Go, Claude Opus 5.5.

Sun Oct 4: 12 messages from me, 551 agent tool calls, 9 commits, 46,007 lines of Go, Claude Opus 5.5.

Mon Oct 5: 72 messages from me, 2,529 agent tool calls, 33 commits, 52,991 lines of Go, Claude Opus 5.5.

Tue Oct 6: 19 messages from me, 928 agent tool calls, 29 commits, 54,158 lines of Go, Claude Opus 5.5.

Wed Oct 7: 49 messages from me, 898 agent tool calls, 12 commits, 55,302 lines of Go, Claude Opus 5.5.

Thu Oct 8: 63 messages from me, 4,618 agent tool calls, 100 commits, 71,413 lines of Go, Claude Opus 5.5.

Fri Oct 9: 16 messages from me, 449 agent tool calls, 6 commits, 71,917 lines of Go, Claude Opus 5.5.

Sat Oct 10: 7 messages from me, 25 agent tool calls, 2 commits, 71,984 lines of Go, Claude Opus 5.5.

Sun Oct 11: 4 messages from me, 561 agent tool calls, 17 commits, 72,894 lines of Go, Claude Opus 5.5.

Mon Oct 12: 47 messages from me, 1,054 agent tool calls, 25 commits, 75,961 lines of Go, Claude Opus 5.5.

Tue Oct 13: 34 messages from me, 131 agent tool calls, 3 commits, 76,067 lines of Go, Claude Opus 5.5.

Wed Oct 14: 13 messages from me, 239 agent tool calls, 7 commits, 76,566 lines of Go, Claude Opus 5.5.

Thu Oct 15: 0 messages from me, 60 agent tool calls, 3 commits, 76,626 lines of Go, Claude Opus 5.5.

My messages, the agents' tool calls, commits and code size over time, and the model the agents ran on. Lines show the 7-day average in October. The zigzag skips July 8 to September 30, a stretch of low activity.

My messages fall on 24 days. If messages less than 30 minutes apart count as one sitting, that’s about 38 hours of typing to agents, much of it from my phone. Reading results or clicking through the website without typing isn’t counted, so my real time was higher.

Here is what the session logs show:

Hover over or tap a tile for what was counted. The counts cover the main sessions and their helper agents in July and October.

508 messages I typed: Everything I typed to the agents, including messages sent while an agent was busy. Slash commands, automatic notices and scheduled prompts aren't counted.

18,501 agent messages: Replies and steps from the main sessions and their helper agents. One message can hold text and several tool calls.

20,883 tool calls: Every action an agent took: running a shell command, reading or editing a file, starting a helper. 17,174 of them were shell commands.

147 helper agents: Tasks the main session handed off, each working in its own copy of the repository.

1,266 build commands: Runs of go build, go vet and make build.

1,544 test commands: 1,103 unit test runs and 441 end-to-end runs, including cBioPortal's website test suite in a browser.

354 commits: Commit commands the agents ran. Git ends up with fewer, because some commits were amended or squashed before merging.

187 pushes: Pushes to GitHub, mostly to branches for pull requests. The agents opened 31 pull requests.

62 rebases: Rebases to bring a branch up to date with main before merging.

12 context compactions: Times a session filled its context and Claude Code summarized the history so it could keep going.

For every message I typed, the agents sent about 36 of their own.

Prompts categorized

GitHub’s Copilot write-up sorted its engineers’ messages to the agents by main purpose. I sorted my 508 messages into the same categories. An LLM did the labeling and I checked a sample by hand.

Hover over or tap a bar to see what the category means and an example message.

Status or explanation request: Asking what happened or why.

For example: "What's still missing before the API portal can switch?"

Approval or short answer: Replying to the agent's question.

For example: "Sounds good, go ahead."

Technical or design challenge: Questioning or proposing an approach.

For example: "I am considering doing this in Go instead of Rust. What do you think?"

Scope clarification: What's in or out, and what it should look like.

For example: "Keep the benchmark short and add a table of contents."

Git, PR and session logistics: Branches, commits, pull requests, crashed sessions.

For example: "Commit your work and open a pull request."

Kickoff: Starting a new task.

For example: "Add CI tests to the repository."

Resource and fleet coordination: Servers, secrets, DNS, helper agents.

For example: "I added the Docker Hub secrets."

Review, testing and CI: Reporting what's broken or reviewing results.

For example: "Several study view tables don't load."

Forward pressure and completeness: Pushing to keep going or finish.

For example: "Port the rest of the endpoints."

Course correction: Telling the agent it's on the wrong track.

For example: "It works in production, so it must be a backend bug."

Other: Anything else.

For example: "One-off commands and IDs."

What my 508 messages to the agents were mainly about. Examples are paraphrased.

A third of my messages were check-ins: asking how a task was going (18%) or answering yes or ok (15%). Another quarter steered the work, by questioning a technical choice (14%) or setting the scope (12%). Just 4% told an agent it was on the wrong track.

The mix is quite different from GitHub’s. Their three biggest categories, review and testing (31%), technical challenges (17%) and pushing for completeness (15%), make up 63% of their messages and a quarter of mine. Only technical challenges come out about the same. My agents ran the tests themselves, and my own checking happened in the browser.

Prompts: the new source code?

When an agent writes most of the code, people want to see your prompts as much as your code. Did you let it run wild, or did you question the language choice, the data model, the shortcuts it proposed? When I present this work, people ask the same questions I asked the agent along the way.

Tools are starting to keep this record next to the code. Claude Code links the session in the pull requests it opens, so a reviewer can read the conversation behind a change. Entire is a company built on this idea: its open-source CLI stores every agent session in the repository, paired with the commit it produced and with secrets redacted.

Sessions also hold things you can’t publish, like credentials that showed up in tool output and internal hostnames. Sharing them inside your team is fine. In public, share summaries and short excerpts instead. The numbers from my logs in this post are all counts.

Lessons

A mature codebase with lots of tests is easy to rewrite today. We invested a lot in testing cBioPortal over the years, including end-to-end tests that click through the website in a browser. Our Kubernetes and Traefik setup also makes it easy to try things against real production traffic. That gave the agents a way to check every change against the original. In 2025 I wrote that AI tools struggled with large, mature codebases. With the latest models, that maturity is what made this rewrite possible.
You still need to know how the original works. A rewrite is full of small decisions. Should the API reproduce Java’s row order, even where Java never sorts and returns rows in whatever order the database left them? (Many differences came down to that.) Is Java’s answer correct, or a bug worth fixing? The agent will decide for you if you let it. It’s better to tell it, and that’s much easier if you know the original code and how the program is used.
The agents needed the most help with unclear Java code. The API has plenty of old bugs and some non-deterministic behavior, and the intent behind the code wasn’t always clear.
Store your prompts somewhere safe! Those small decisions are exactly what others will ask about later, so keep a record of them. Claude Code deletes sessions after 30 days by default, so raise cleanupPeriodDays in your settings before you start.
Rewrites will only get easier. So if you want to speed one up, you could just wait :).

Anyone Can Build cBioPortal Features ✨

Wed, 25 Mar 2026 12:00:00 GMT

AI has commoditized software development. I think anybody can now build a cBioPortal feature. If you’re an analyst familiar with Python and R, it’s definitely within reach. But even if you have no coding experience, it’s doable with some effort. You tell an AI coding agent what you want and watch it build.

This post walks through the entire workflow: from setup to a shareable preview URL.

What you need

A terminal. Terminal.app or Termux on Mac, Windows Terminal, or any Linux terminal.
An AI coding agent. GitHub Copilot CLI, Claude Code, Gemini CLI, or Codex.
A GitHub account.

You don’t need to learn much about the command line anymore. It’s all one command now: claude, copilot, gemini, or codex. After that it’s just chatting. It won’t judge you: ask it all the questions you never dared to ask your programming friend. By default it will ask if it’s ok before executing a specific command, so you can see exactly what it does. And you can always ask follow-up questions if you’re not sure.

Setup: ask the agent

Open your terminal, start your agent, and tell it:

🤖 “Clone https://github.com/cBioPortal/cbioportal-frontend, install dependencies, and run the project”

The agent will handle everything: downloading the code, installing dependencies, and starting a local version of cBioPortal. You don’t need to know what any of those steps mean. First-time setup takes about 15-20 minutes. After that, subsequent runs start in seconds.

Once it’s running, visit https://localhost:3000. Your browser will show a security warning because you’re running a local server. Just click “Accept risk and continue” when prompted.

Try a patient page to confirm it works:

https://localhost:3000/patient?studyId=lgg_ucsf_2014&caseId=P04

The data comes directly from cbioportal.org, so you get real public data out of the box. You should see the cBioPortal homepage:

Not working?

Right-click anywhere in the browser, go to Inspect, then the Console tab. Copy the error and paste it into your agent. It’ll diagnose and fix it for you.

Add a new patient view tab

Tell the agent:

🤖 “Add a new tab called ‘My Feature’ to the patient view page in cbioportal-frontend”

The agent will figure out where to add the tab and create the necessary files for you. Your new tab shows up right away:

Want to understand the codebase better? Just ask:

🤖 “Can you explain the codebase structure of cbioportal-frontend to me?”

Prototype with mock JSON data

Normally when you build a cBioPortal feature, you’d format your data into cBioPortal’s expected format and import it into the database. That’s a significant amount of work, especially if you’re just trying to prototype an idea or see if a new visualization makes sense. During prototyping, you can skip the database entirely by including your data as a file directly in the code.

The file format used is JSON (JavaScript Object Notation), the standard data format on the web. If you’ve worked with spreadsheets or TSV files, it’s a similar idea: structured data in rows and columns, just written in a format that web applications can read natively. You don’t need to learn the format yourself though. Just ask the agent to convert your data.

Got a TSV or Excel file with your data? Tell the agent:

🤖 “Convert my spreadsheet data.xlsx to a JSON file called mockData.json”

Or have the agent generate realistic sample data from scratch:

🤖 “Generate a JSON array of 10 mock cancer patients with fields: patientId, cancerType, age, tmbScore (mut/Mb), msiStatus, treatmentResponse. Use realistic but entirely fictional values.”

AI agents are great at generating realistic test data. Once you have your JSON file, the agent will hook it up so the data shows up in your tab. From there you can iterate on the visualization. Tell the agent to add a table, a chart, or whatever you have in mind, all using your own data.

⚠️ Important: cbioportal-frontend is a public GitHub repo. Any data you commit (including JSON files) is publicly visible, including in preview deployments. Never commit real patient data or PHI of any kind.

Get a shareable preview link

A PR (pull request) is how you propose changes to a project on GitHub. It lets others review your code before it gets merged into the main project. Tell the agent:

🤖 “Open a draft PR to cbioportal-frontend with my changes”

Here’s an example of a PR opened by an agent:

We’ve set up the cbioportal-frontend repo so that every PR automatically gets a preview URL (build takes about 10-15 minutes):

Share the preview link with collaborators. They can see and interact with your feature without any setup on their end.

Have fun building

The commoditization of software development means anybody can build features and perform analyses using natural language. A major challenge for scientists and software engineers has always been formulating the requirements. Now non-coders can define requirements in incredible detail by building fully working prototypes.

Whether you’re a bioinformatician, clinician, or researcher: if you can describe what you want, you can build it. Pick a feature you’ve always wanted in cBioPortal, open your terminal, and start chatting.

My Current Coding Setup: Async Software Engineering

Fri, 27 Feb 2026 12:00:00 GMT

I’ve been evolving my coding workflow to more async agentic coding: checking in on how the agents are doing on specific tasks and guiding them when necessary. It’s very similar to how one would manage a human software engineering team. I’ll give some example tasks below and describe how you can set this up for yourself.

📱 Simple one-shot tasks: Snippy

For quick, self-contained stuff I use Snippy—my OpenClaw assistant. I fire off a request from my phone and it handles things like small bug fixes, formatting changes, or minor refactors autonomously. It opens a PR and I review it when I get a chance. Here’s an example where a collaborator emailed about something that needed to be fixed in our HTAN portal—I just told Snippy to fix it via Signal and it immediately submitted a fix:

Some more examples:

I needed to remove a banner from our website. I messaged the agent and immediately got a PR to do so.
I received a ton of PRs to fix an issue for cBioPortal, so I asked it to merge them into one combining the best of each (see PR)

💻 Complex tasks: VPS + tmux

For anything more involved I connect to a VPS—from my phone using Termux with mosh, or from my MacBook via SSH. On the server I use tmux with one window per project, each running a Claude Code session. Here’s what my current tmux session looks like:

0:sys — System install stuff and server health management
1:snip — Chat interface to Snippy, so beyond phone and email I can also talk to it directly on the server
2:init — Starting new projects. I organize my work by projects, where a project might span multiple repos
3:vibe-vep — Working on vibe-vep, a variant effect predictor. This project spans multiple repos as you can see in the screenshot
4:cbiotest — Dealing with flaky tests in cBioPortal
5:transcript-match — A transcript alignment tool
6:mcp — The MCP project for cBioPortal
7:blog — This blog post

The whole thing is very async: give Claude Code a bunch of tasks, check back later to review the plan, approve or redirect, and move on to the next window. It’s a fundamentally different rhythm from the old “sit down and write code for 4 hours” mode—more like managing a small team that works fast but needs guidance. I’m coding way more from my phone now.

How to set this up

🤖 Simple tasks: OpenClaw

OpenClaw lets you run your own AI assistant that you can message from anywhere—WhatsApp, Telegram, Slack, etc. I set mine up with a coding agent skill so it can open PRs on GitHub. The VPS setup is pretty much the same as described in the complex tasks section below, except you’ll want to create a separate user with more limited permissions, a separate Google account, and a separate GitHub account to keep things isolated.

Fair warning: I’d only recommend this to tinkerers with some sysadmin experience right now. There are many potential security issues when you’re giving an AI agent access to all kinds of services. Prompt injection becomes a major concern. I’m sure this will be available to more people in a more secure manner soon.

📟 Complex tasks: VPS + tmux + mosh

Get a VPS — I use OVHcloud, but any provider works. You want enough RAM for your coding agents to run comfortably.
Set up a user and SSH — Create a non-root user, set up SSH keys, and configure your firewall. Same as you’d do for any new server.
Install your dependencies — Git, Node, Python, Docker, whatever your projects need. I keep a dotfiles repo to help bootstrap new machines.
Install tmux — This is what lets you keep multiple sessions alive. One window per project.
Install mosh — Way more resilient than plain SSH, especially on flaky mobile connections.
Install your coding agent(s) — Claude Code, GitHub Copilot CLI, Codex, Gemini CLI, whichever you prefer.
Connect from your phone — On Android I use Termux with mosh. One nice trick: you can talk to Claude Code using Gboard’s dictation. In Termux you need to swipe left on the extra keys row to get to the regular keyboard, voice input works surprisingly well for giving instructions.

Tips and tricks

🔄 Extending sessions with the Ralph loop

One thing with AI coding agents is that they tend to stop and wait for input. The Ralph loop helps with that—it catches when Claude Code tries to exit and feeds the prompt back in, so it keeps iterating on the task. Great for longer jobs where you want the agent to just keep going. My longest unsupervised run so far has been about an hour. Hoping to get to the level of day long runs at some point (tips anyone?).

🛠️ Configure your own workflow

There are many ways to do this async style of software engineering—the various coding assistant integrations available via Slack (like Claude Code in Slack), assigning issues to GitHub Copilot directly in the GitHub UI, using Claude Code on the web, and more. Each has its own pros and cons. My setup requires a lot of configuration and might not be ideal for others. I’d recommend experimenting to figure out what works best for you.

🔮 This is constantly evolving

What requires async interaction today might be near-instant tomorrow. Take Taalas for example—they’re literally printing AI models directly onto silicon chips, running Llama 3.1 8B at 17,000 tokens per second. What currently takes minutes of back-and-forth could happen in the blink of an eye.

That said, even as individual interactions speed up, we’ll likely continue working with many parallel async processes with humans in the loop. The AI does the work, you review. The AI proposes a plan, you approve. Figuring out how this new way of working fits into your day-to-day—how to manage multiple agents, when to check in, what to delegate—that’s becoming a skill in itself.

How Researchers Use cBioPortal - An AI-Powered Analysis

Wed, 24 Dec 2025 12:00:00 GMT

Measuring research software impact is hard. Software often gets mentioned without formal citation, or used programmatically without any mention at all. These challenges have been explored by colleagues (Istrate et al., 2022; Afiaz et al., 2024), work funded by CZI and ITCR respectively. The former extracted software mentions from millions of papers; the latter surveyed tool developers on how they measure impact. Inspired by these efforts, we wanted to explore more deeply for one software tool how it is used based on published literature. In this experiment we look at cBioPortal, the tool our team works on—classifying which cancer types, analysis methods, and data sources researchers work with.

As a user-facing website for accessing cancer genomics data, cBioPortal has been cited many times, providing a unique opportunity to analyze usage patterns. This goes beyond conventional tracking via Google Analytics or Heap, and aims to paint a clearer picture of how researchers actually use cBioPortal.

Implementation

The idea was simple: take all papers that cite one of the cBioPortal publications, download the PDF for each open access paper, extract the text, and have an LLM classify each paper by cancer type, usage patterns, and data sources. I vibe coded an automated pipeline using Claude Code which leverages AWS Bedrock for classification.

As usual, it initially seemed to work with relatively little effort—but of course parsing PDFs turned out to be much harder than I anticipated. In retrospect, I should have maybe just used the structured HTML from PMC.

Some Findings

The analysis examined 13,890 papers citing cBioPortal from 2012-2026. Top analysis types were gene expression (10,549 papers), mutation analysis (7,282), and survival analysis (7,050). TP53 was the most frequently queried gene (1,062 papers). TCGA dominated as the data source (8,993 papers). USA and China led geographically.

For the full report with the latest data and visualizations, see the usage report.

Reflections

This experiment made me appreciate how complicated it is to analyze software usage from publications. Many articles detail what data they used rather than how they used cBioPortal. In its current form, the approach isn’t as useful for identifying UI usage patterns—though detecting cBioPortal visualizations in paper figures (e.g. OncoPrints, MutationMapper lollipop plots) could help. That said, I think we need more meta analyses like this to understand how research software is actually used. Citations alone don’t tell the full story, and there’s a lot of room for the field to develop better approaches.

I haven’t verified many of the findings yet, but it’s promising that some check out with orthogonal lines of evidence. Google Analytics also shows USA and China as top users. A survey from a few years ago indicated strong interest in gene expression analysis, and our second most popular YouTube video is about gene expression.

At the end of the day, just talking to your users is probably still the best way to understand how they use your tool. But this is a nice complementary approach for getting a broader picture.

Work in progress—stay tuned!

about

Thu, 17 Jul 2025 17:21:13 GMT

Ino de Bruijn

LinkedIn: https://linkedin.com/in/inodb
GitHub: https://github.com/inodb
CV: https://cv.ino.bio
Papers: https://scholar.google.com/citations?user=Pze5p28AAAAJ
Contact: ino@ino.bio

Thoughts on AI-Assisted Coding

Wed, 18 Jun 2025 12:00:00 GMT

Been using AI-assisted coding across a bunch of software projects, from quick prototypes to production work. Seeing a few recurring themes:

🚀 Amazing for greenfield and prototyping

They speed up early development dramatically. What used to take weeks can often be done in days or hours. Boilerplate, scaffolding, docs—they handle it all surprisingly well. In the cBioPortal team we leveraged Lovable to build websites, including an installation map (by Zain Nasir) and an about page (with help from Melissa Nguyen), occasionally going back to VSCode to edit source code directly. I also used VSCode CoPilot to build some command line tools/scripts, such as a parquet file generator.

🏗️ Struggle with large, mature codebases

LLMs still have trouble with deep, repo-wide context. I can’t get it to fix even a single “good first issue” in either the frontend or backend of the cBioPortal codebase! It often doesn’t understand the ask, the codebase, or both. One workaround might be breaking things into smaller, focused “throwaway” components or modules, where context is tighter and code quality matters less. I can also imagine a future where LLMs are seeded with all your repo’s issues and PRs to better interpret the ask—or maybe I’ll finally learn to write the perfect task specification 🙃.

🧩 Structured data models and APIs are key

LLMs perform much better when they can understand your domain. Clean schemas, OpenAPI specs, and strong data modeling unlock everything from UI generation and code completion to natural language querying and “chat with your data” interfaces. Investing in this kind of foundation is a huge time saver for anyone building or using interfaces on top of your data. It makes the data product more robust and easier to work with, no matter who’s interacting with it (machines or humans).

🎨 Blurred lines between devs, designers, and domain experts

Tools like Lovable let non-devs build real, functional UIs, and help devs build better-looking ones. But deep expertise is still essential across all roles: developers for system design, security and integration, designers for intuitive and accessible UX, and domain experts for making sure the output is actually meaningful—especially in complex fields like cancer genomics.

🎮 Using LLMs can feel like cheating

There’s something undeniably addictive about using LLMs. It’s like having a stack of cheat codes for work. It shifts how you think about what’s even worth building/maintaining. That said, it’s easy to fall into a prompt-and-fix rabbit hole where you realize later that stepping back and thinking through the problem would’ve been faster; the dopamine rush of rapid iteration is hard to resist 🙂.

Link to original post on LinkedIn: https://www.linkedin.com/posts/inodb_been-using-ai-assisted-coding-across-a-bunch-activity-7335052413378138113-SNMj

GSoC Mentor Summit 2019 ☀️

Fri, 25 Oct 2019 17:11:38 GMT

Just got to the airport in Munich after a successful Google Summer of Code (GSoC) Mentor Summit. This is a yearly event where all open source organizations that participated in GSoC come together. There are a few scheduled sessions but the rest follows the unconference formula:

Really like the unconference idea: give participants a bunch of rooms and time slots and let them organize their own sessions. Participants know what will be useful to them! Doing an Open Source Bioinformatics session at 11am tomorrow (top left) pic.twitter.com/OK0c9p1bTP
— 🔧 Ino de Bruijn 🧬 (@inodb) October 18, 2019

I was there having a blast representing the cBioPortal organization together with Angelica. This is us:

The cBioPortal organization had 6 students coding over the summer, working on various projects related to the Open Source cBioPortal for Cancer Genomics website. The majority of the contributors are at Memorial Sloan Kettering Cancer Center in New York but the users, a combination of clinicians and researchers, live all over the world and so do its contributors. For more information about cBioPortal see here. For a complete overview of the student projects see the cBioPortal GSoC wiki.

Before I dive into the GSoC mentor summit and elaborate why it was useful to go other than experiencing the great joys of drinking giant beers and eating wild deer schnitzel; I need to share some experiences from Munich. I won’t be offended if you prefer to skip the next paragraph.

Munich 🛴

I loved that the summit was in Munich this year. Last time I went (two years ago) it was at the Google campus in Silicon Valley. That was cool, but it was great to get the opportunity to visit a new place. Munich is a beautiful city and has a lot to offer.

I had to be in Amsterdam the week before anyway, so I did not feel too bad about my carbon impact from flying to Europe. I did take the train from Amsterdam to Munich to save some carbon and more importantly: blog about my pretentiousness later. Along the same vein I got to the airport just now by Green Uber:

Haven’t seen this back home in New York yet. The price was actually slightly cheaper than Uber X. It was also my first time sitting in a Tesla Model 3. Not the best user experience trying to open the car door lol; I wasn’t able to get in or out of the car without the driver explaining to me how to operate the door. Munich had a bunch of other things I hadn’t seen in New York: electric scooters and bikes you can dump anywhere. Things do look slightly messy with those scooters and bikes scattered all over the city but it was pretty convenient. I didn’t end up using the subway at all, because the weather was perfect and it was so easy to rent scooters and bikes. In general I find the experience of navigating a new city so much easier compared to a decade ago, since you’re using all the apps and interfaces you’re familiar with from back home. That being said I did end up doing some stupid tourist things using the same apps. I took an electric scooter from Uber at night and Google Maps pointed me to go through this unlit park. Halfway through the park the scooter died on me. It was only then I realized that parking the scooter there would get me a 25 euro fine. I ended up trying to push the scooter out of the park before giving up and taking a cab back to the hotel.

Lightning Talks ⚡️

The next morning, decently well rested, Angelica and me presented at the Lightning Talks session. Organizations that signed up can tell a story about their students in under three minutes, see our two slides here:

The lightning talks are a great way to get a quick overview of all the different projects. My favorites were from Vicky Vergara from the Open Source Geospatial Foundation:

Watch the video @OSGeo
@gsoc
2019 student Hang
working on pgRoutinghttps://t.co/llNxKPufXQ
— vicky vergara (@VickyVvergara) September 6, 2019

and the Public Lab one presented by Jeffrey Warren:

I LOVE this slide from @jywarren - growing your community is what -gets- your work done, not something you do -instead- of work. @PublicLab encourages recent new contributors to prepare github issues for newbies - great onboarding path! #gsoc pic.twitter.com/08peKo7zEl
— yo yehudi🏳️‍🌈🇪🇺 (@yoyehudi) October 19, 2019

Unconference Sessions 🗣

Managing a Welcoming Open Source Organization

Since I enjoyed Jeffrey’s lightning talk so much, I decided to go to his session:

Amazing effort by @PublicLab to make #opensource contributing more inclusive: https://t.co/Ddz9Pu41lb. Great session by @jywarren at #GSOC. Feeling inspired!
— 🔧 Ino de Bruijn 🧬 (@inodb) October 20, 2019

I learned about the importance of language when writing contributing docs e.g.

"Please give back" vs "you have the ability to help others"

The former feels like a request whereas the latter emphasizes your unique abilities. For an example of that see code.publiclab.org:

Visual aids are very important as well for welcoming new contributors to your project. The GitHub checks give big red errors when contributors submit their pull request which can be discouraging:

Showing this as a progress bar could be one way to make this less intimidating.

It was great to see in the session afterwards about Bots for maintainers and contributor onboarding organized by Oleg Nenashev that another major project like Jenkins made great efforts to incorporate similar ideas in their organization. Kai Blin remarked that people find it sometimes less intimidating to see a bot message something than him messaging the exact same thing himself. As an example he mentioned linting, e.g. a message like “improve the code styling here and here” was usually appreciated more when it came from a bot. Jeffrey added to this that in his organization they try to let encouraging words come from a human, since that is experienced as more welcoming. This leads to some interesting questions for an organization regarding what type of work should be done by bots versus humans. On the one hand it might be nice to automate parts of Pull Request reviews by bots but on the other hand the same task could be good for a relatively new contributor to the project so they feel good about contributing and for a new contributor to feel appreciated by a human being. I imagine metrics around contributor acquisition and what they end up contributing might help answer some of these questions.

There were a ton of other bioinformatics, life science and research/academics related organizations. Angelica and me organized a session at the start of the conference that was simply a round of introductions, which was helpful in getting acquainted with these types of orgs at GSoC. Angelica made great notes for our session: link. I ended up sitting down with Egon after. He organized a session around wikidata and I was curious about using their API for pathway data shown at wikipathways.org to feed the querying of cancer genomic data by pathway in cBioPortal:

We actually had a GSoC project around integrating PathwayMapper into cBioPortal (more info here). Pathway mapper provides a great interface for people to curate their own pathways and subsequently query them in cBioPortal. Extending that with pathway data from wikidata seems like a great project. The neat thing is that wikidata connects all kinds of different entities with each other, allowing for instance to connect pathways to publications. That might provide for another interesting project to e.g. point users querying particular pathways on cBioPortal to relevant literature. I am on the wikipathways slack now so the first contact has been made 🙂

Collaborations with other organizations is something that came up during the session on universities as mentoring orgs. In our experience GSoC provides an excellent vehicle for collaborations between institutions. The pathway mapper integration project was a collaboration between our group and Bilkent University. The GDC import project was a first time collaboration between our group and the GDC team. This is a great way to involve more people in the open source process. I believe the academic world can learn a lot from the open source world. Open source development for instance often starts out in the open. There is a movement in the academic world to be more open, but it is usually only at time of publication. Somebody mentioned during the session that open source should probably be part of the curriculum. I did my undergrad in computer science and can’t remember any course that talked about open source and the process around contributing code. It might be different today but if not that should really change. Software carpentry is a great resource for educating scientists on this. For next year’s GSoC I’d like to try and involve more scientists. Another thing that Egon mentioned is that PhD students often list travel grants on their CV so having submitted a successful GSoC organization application is definitely something one can include there as well. Other ways to get academic credit for GSoC would be to publish papers on the work. We have successfully published on e.g. the CPTAC integration in cBioPortal and the G2S webservice. Another approach for open source tools is to list all contributors on the paper. Frequent publications of a tool can help give contributors academic credit.

These were just a few personal highlights of the unconference sessions. There is a full list of sessions and notes contributed by participants here:

https://docs.google.com/spreadsheets/d/18DwHPmqhh2rbxbbPA9OYitmlwsh3nI3azrngRuKfMGk/

TODO 🚧

I made a TODO list of all the things I want to follow up on after having been to the summit:

Make an awesome contributing page like public lab: https://code.publiclab.org. Try to follow in their footsteps in how to make

an inclusive community. Try using e.g. welcomebot. In addition to that it would be cool to adapt this a bit for our org. Like make a tutorial/demo on cBioPortal for people unfamiliar with cancer genomics and cancer. Our contributors are often a) people familiar with cancer genomics and little to no software engineering experience or b) people with software engineering experience but no cancer genomics knowledge. Some contributors might not be familiar yet with either. Figuring out some onboarding procedure for each of those would be great.

Look into other open source programs such as Outreachy, specifically for underrepresented communities and Google Code In for high school students.
Use wikidata to pull pathway data and incorporate in cBioPortal. If complicated this could be a good GSoC project for next year.
Try to include more scientists/academics in GSoC. Try to convince them how it could be beneficial academically. Comentoring projects seems like a good

approach. Need to start thinking about projects early.

Some bots to try: welcomebot, releasedrafter, the CircleCI artifact bot to post links to our screenshot comparison page in the pull request. Currently

it’s hard to find these for newcomers.

Goodbye and thank you! 👋

I furthermore had a bunch of other really great interactions with folks at GSoC. To name one: JJ Gao, our awesome team lead at cBioPortal receives a lot of notifications on GitHub but they don’t always end up in his inbox:

Just met https://t.co/bCRzWQBdKR at #GSoC - he gets all GitHub notifications intended for you @gaojj 😂😂😂 pic.twitter.com/UQaZfriZNo
— 🔧 Ino de Bruijn 🧬 (@inodb) October 19, 2019

A final thank you to Google, the organizers, the participants, the students and everyone that contributed to GSoC! Hope we will be able to participate again next year.