Modern VS Code tooling for IBM Z mainframe development
VS Code Extension
6 weeks
Case study in progress!
I’m still working on putting this case study together, but I wanted to share my work in the meantime. There are a few things I’m still refining and documenting, but I hope this gives you a glimpse into the project and my design process.
IBM Z Open Editor is a VS Code extension for mainframe development with 200,000+ installs. IBM is moving developers off its older Eclipse-based IDE and onto VS Code, and this feature was one of the gaps between the two. The backend logic was already built, so engineering was waiting on design to ship it. When engineering set a ship date, I had about three weeks left, and I worked with the developer on US East Coast and my design lead Bangalore to get there.
As a design intern on IBM's Z DevOps team, I designed how IBM Z Open Editor tells COBOL developers when a variable they declared is no longer used. I took the feature from competitive analysis and journey mapping through four concepts to a final recommendation, then refined it with engineering until it shipped.
PROBLEM
Developers aren't told when a variable they declared goes unused
When developers refactor COBOL, variables from the old logic get left behind, and Z Open Editor never flags them. Newer developers don't know to look, so they find out in code review. Experienced developers switch to the older Eclipse IDE to run a manual check that goes stale as soon as they keep editing.
How might I surface unused variables so early tenure developers notice them and experienced developers can manage them without leaving VS Code?
solution
Unused variables flagged automatically, from first signal to fix, inside VS Code
Unused variables are now dimmed as soon as they stop being referenced, with a hover explanation, a Quick Fix, and a Problems panel list that stays current as developers edit. The feature shipped on August 21, 2026, on the date engineering set. Since Z Open Editor runs on-premises, usage data isn't available yet; my mentor will share impact numbers as they come in.
Single unused variable
key DECISIONS
Designing for two developers who feel the same problem differently
I worked from two personas IBM's researchers had defined: Deb, an early-tenure developer, and Kathleen, an experienced z/OS developer. Mapping their journeys showed they needed different things. Deb needed to be told unused variables exist, and Kathleen needed a check she could trust while she kept editing. Each decision below serves one or both of them.
A quiet signal the moment a variable goes unused
I compared how seven languages handle unused variables in VS Code. Almost all treat them as code quality hints, not errors, and the most common cue is dimming, because developers don't want to be interrupted while scanning code. I also explored a louder squiggly underline and a banner above the editor, but both added noise, especially in large COBOL files.
So unused variables are dimmed right where the developer is working, as soon as they become unused. For Deb, that closes the gap my research kept pointing to: developers can't investigate issues they're never told about.
Dimmed unused variable
A list that stays current, so developers don't have to remember
Kathleen's real problem wasn't switching to Eclipse. It was that the Eclipse check is a snapshot, so it's outdated the moment she makes another change, and she loses confidence mid-refactor.
The Problems panel keeps a running list of unused variables that updates automatically as she edits, and a status bar badge shows the count for the file. She can jump from the list to each variable without leaving VS Code or keeping track of when she last checked.
Problems panel
One path from noticing to fixing
The competitive analysis showed developers expect every flag to come with a way to act on it. Hovering over a dimmed variable explains that it's declared but never referenced, and a Quick Fix removes it in one click, from the editor or the Problems panel.
I kept the wording short after the engineer building it pointed out that COBOL developers would see extra explanation as clutter. The dimmed text already shows where the variable is, so the hover only needs to say why.
In line hover
Quick fix