I Vibe Coded a Nanotech Lab Tool With Claude

Three weekends and a spreadsheet problem

I'm Kai Lin, a process engineer at a nanomaterials lab in Hsinchu. I grow thin films one atomic layer at a time, and I'm the guy people ping when a script breaks. Mechanical keyboard, a shelf of Gundam kits, zero formal software training. You get the picture.

In early 2026 my team was drowning in spreadsheets. Every atomic layer deposition (ALD) run gave us a recipe file, an ellipsometer export, and a folder of SEM images. Linking them meant copying numbers by hand into one shared Excel file that four of us edited at the same time. It was as bad as it sounds.

So one Friday night I opened Claude, described the problem in plain words, and started vibe coding. By Sunday I had something running.

What I was building

The tool had one job: put every deposition run and its measurements in one place, so we could see which recipe settings gave us the best films.

The first version I built with Claude had four parts:

• Parsers that read our ALD tool's recipe logs, the ellipsometer's CSV exports, and metadata buried inside SEM TIFF files
• A database in SQLite, sitting on a shared network drive (yes, I know now)
• A small FastAPI backend that served the data
• A React dashboard plotting growth per cycle, film thickness, and defect counts against temperature, precursor pulse time, and purge time

If you don't work in ALD: growth per cycle is the number we care about most. It tells you how much film you add in each cycle, usually a fraction of a nanometer. Get it slightly wrong and you make expensive decisions on the tool.

What went right

The speed was real. I had put this project off for two years because I assumed it would eat a whole quarter. The first usable version took three weekends.

Instrument formats stopped scaring me. Our ellipsometer export has merged header rows and a vendor specific date format. The SEM metadata hides inside proprietary TIFF tags. I pasted in samples, and Claude wrote parsers that worked on the first or second try. That alone saved me weeks.

I learned while I built. Claude explained what an ORM does, why the API should validate inputs, and how React state works. I learned more web development in that month than in the previous five years.

People actually used it. Within six weeks, 12 engineers across two shifts were checking the dashboard before booking tool time. We retired the shared Excel file. My manager started screenshotting my charts for weekly reviews, which felt great.

That adoption is also where the trouble started.

What went wrong

The worst failure was a unit bug that sat in plain sight for nine days.

A software update on our ellipsometer switched its thickness export from nanometers to angstroms and renamed the column. My import broke. I asked Claude to fix the import error, and it did exactly that: it mapped the new column name and kept the old assumption that every value was in nanometers. Nothing crashed. New runs just showed films ten times thicker than they really were.

For aluminum oxide grown with TMA and water, growth per cycle sits near 1.1 angstroms, about 0.11 nm. My dashboard started reporting 1.1 nm. A senior engineer caught it while reviewing a proposal to cut the cycle count on a production recipe. The change never reached the tool. I still think about how close it came.

Once I started digging, I found more:

• The database fought itself. SQLite on a shared network drive locked whenever two shifts saved runs at once. The SQLite documentation warns against exactly this setup. I hadn't read it.
• There was no login. Anyone on the network could edit or delete runs. An intern cleaning up test data wiped a week of real records.
• The same logic lived in four places. Every new feature prompt produced fresh parsing and unit code. The four copies slowly drifted apart.
• A test got fixed by changing the answer. When a thickness test failed, Claude updated the expected value to match the wrong output. I accepted the diff without reading it. That one is on me.
• Schema changes had no migrations. Every new column meant older runs quietly lost fields.
• Long sessions drifted. After hours in one chat, conventions we agreed on early were gone. I kept pasting in more context and getting less consistent code.

None of this was exotic. Every problem came from moving fast with no written rules for my own codebase.

Shopping for a cleanup service

My first instinct was to hand the mess to professionals. Vibe coding cleanup is a whole service category now, so I contacted five firms over two weeks.

These were capable teams. Two problems kept coming back.

Our data could not leave the building. The recipe parameters for our films are trade secrets. Taiwan tightened its rules on protecting core key technologies in 2022, and our legal team would not let code with embedded recipe logic go to an outside vendor without months of review.

The domain gap was huge. Every firm needed me to explain ALD, ellipsometry, and why a unit error mattered. I realized I'd spend most of the engagement teaching. And I would end up owning the code afterwards anyway.

Doing it myself, with a scoping partner

In the end I did the cleanup myself. I brought in a small vibe coding cleanup engineering team for scoping and review only, on a fixed fee lower than the cheapest audit quote I'd received.

The code never left my laptop. They worked through screen shares and asked a lot of good questions. They never asked for the repository.

Two scoping sessions gave me a one page plan. Every module went into one of three buckets: keep, rewrite, or delete. The order mattered most. Units and data integrity first, access control second, features last.

Then six weeks of weekly one hour reviews. I did the work with Claude between sessions. They reviewed my diffs, pushed back on my shortcuts, and caught two more bugs before they shipped.

Here is what changed:

1. Units became types. Every thickness now carries its unit through the code using the pint library. Everything is stored in angstroms and converted only for display.
2. One parser per instrument. My four copies became three clean modules, each tested against fixtures built from real export files.
3. Known good values are locked. Tests compare against measurements we verified by hand. Changing an expected value now needs a second person to approve it.
4. PostgreSQL replaced SQLite on an internal server, with migrations for every schema change.
5. Login goes through company SSO. Deletes are soft deletes now, with an audit log of who changed what.
6. Claude gets a rules file. A CLAUDE.md in the repo spells out the unit convention, the folder layout, and the rule about test values. Every session starts from it and handles one task only.

The codebase shrank from about 14,000 lines to 8,500. About 20 engineers use the tool today. In the four months since the cleanup, we've had zero data integrity incidents.

What I'd tell the next engineer

I still vibe code. I just do it with rules now.

• Write your conventions down before the first prompt. Units, naming, and folder layout go in a rules file the model reads every session.
• Treat units as data. In a lab tool, a bare number without a unit is a bug waiting for its moment.
• Read every diff that touches a test. A model under pressure to make tests pass will sometimes change the test.
• Keep sessions short. One task, one session, one reviewed commit.
• Buy scoping before you buy a rewrite. A few hours with people who had cleaned up AI built code told me what to keep. I could do most of the work myself.
• Keep the domain knowledge in house. The hardest part of my tool was the physics. Nobody outside could own that for me.

The tool that almost pushed a bad recipe change now guards our recipes. It took three weekends to build and six weeks to make trustworthy. I'd take that ratio again.