RSS Feed

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.