wirthal1990

I am not a programmer. I have never written code myself, nor have I ever published anything technical.

The pipeline was built entirely by Claude Opus as a coding agent, and the results were reviewed by Claude Sonnet. Both AI models had to subject their output to a three-step iterative self-correction process after each work batch. My job was to read every code comparison, verify that the ChEMBL fallback logic actually covered the edge cases it claimed to, and figure out at 1 a.m. why the Stripe webhook had been silently returning a 400 status for three hours without me noticing. It’s a truly unusual workflow. I spent most of my time asking Claude Sonnet whether what the Coding Agent had built actually worked the way I had planned—and the answer is surprisingly often: “Not quite.” If there are errors in the methodology, I’d like to know about them. The METHODOLOGY.md was created precisely for this purpose and is publicly accessible.

This matches my experience when building my first real project with Claude. The architectural decisions were entirely up to me: I researched which data sources, schema, and enrichment logic were suitable and which to use. But I had no way of verifying whether these decisions were actually good (no programming knowledge) until Claude Opus had implemented them.

The feedback loop is different when you don’t write the code yourself. You describe a system to the AI, after a few lines of code the result appears, and then you find out whether your own mental model was actually sound. In my first attempts, it definitely wasn’t. This friction, however, proved to be useful; it just wasn’t the friction I had expected at the beginning.

My experience was exactly the opposite—I came from the other side entirely. I had absolutely no programming knowledge, and until three weeks ago, I didn’t even know what a Parquet file was.

While reviewing a deep research project I had started, I stumbled upon an inefficiency: The USDA’s phytochemical database is publicly accessible, but it’s spread across 16 CSV files with unclear links. I had the idea to create a single flat table, enriched with data from PubMed, ChEMBL, and patents. Normally, a project like this would have been completely impossible for someone like me—the programming hurdle is far too high for me.

With Claude Opus 4.6, I was actually able to focus entirely on the problem architecture: which data, from where, in what form, for which target audience. Every decision about the system was mine. Claude Opus took care of the implementation.

I’m probably the person your debate about “journey vs. destination” wasn’t meant for. For me, the destination was previously unattainable. My journey became possible, because the AI took over the part that I could never have implemented anyway.

I'm working on a phytochemical dataset product. The base is USDA Dr. Duke's Phytochemical and Ethnobotanical Databases — 16 relational CSV tables that I denormalized into a single flat table in PostgreSQL. Then I ran async Python enrichment pipelines against PubMed, ClinicalTrials.gov, ChEMBL, and PatentsView (USPTO), producing 8 columns per record across 104,388 rows.

The interesting engineering problem was ChEMBL: most phytochemical names don't have direct ChEMBL entries, so the pipeline first tries a name match, then falls back to PubChem for CID → InChIKey resolution before hitting ChEMBL's molecule API. Full enrichment with Aho-Corasick string matching took ~24 seconds for 24,771 compounds.

Building the commercial layer on top: Rust/Actix-Web API, 97K static pSEO pages on Cloudflare Workers/R2, Stripe for one-time purchases. Solo founder, bootstrapped, based in Germany.