The Vibe Coding Paradox: What Happens When a 50-Year SWMM Expert Gets AI Superpowers
A Harvard study warned that AI intensifies work. Here's what that looks like when the work is stormwater modeling and the worker has half a century of hydraulic knowledge to unleash.
Updated July 2026.
The Moment Everything Changed
I first learned about SWMM from a brochure at the University of Florida when I was 17 years old. That was 1974. Fifty-two years ago.
Since then, I've worked with every generation of the software: SWMM3, SWMM4, SWMM5, XP-SWMM, InfoSWMM, InfoSewer, InfoWorks ICM, ICM SWMM, InfoDrainage, Civil 3D Drainage, and now SWMM5+.
For most of that half-century, my output followed a predictable pattern: think deeply about a hydraulic problem, write about it, build models, share knowledge.
The software was always someone else's job. I was the domain expert. Developers wrote the code. That division was clear, comfortable, and (I now realize) protective.
Then I discovered vibe coding. And everything changed.
What Is Vibe Coding?
Vibe coding is a term from Andrej Karpathy, one of the founders of OpenAI. Instead of writing code line by line, you describe what you want to an AI, and it writes the code. You guide it with conversation.
Karpathy coined the term in early 2025. Eighteen months later, the tools have grown from autocomplete with ambition into agents that plan, execute, and test their own work overnight while you sleep. Hold that thought. It matters later.
For a domain expert with deep knowledge but no training in web frameworks or deployment pipelines, it is liberation.
Suddenly, every idea I've had in 50 years of stormwater modeling can become a working application. Not in months. In hours.
When I first published this essay, the list below had ten items, and I was proud of it. The count has now passed one hundred single-file apps. A sample from the past year:
- SWMM5 Benchmark 3D Viewer: any .inp file as a walkable Three.js scene, with a TRANSECTS parser I verified station by station
- dynwave.c, Deconstructed: the SWMM5 dynamic wave solver explained function by function
- EPANET and SWMM5 Rosetta Stones: two engines, one cross-reference
- ReSWMM CFL Analyzer: Courant stability conditions, made visible
- RDII/RTK Explorers: the unit hydrograph I coded into rdii.c during the EPA CRADA years, now interactive
- SWMM Aesop Fable Forge: hydraulic principles retold as animal fables. My grandchildren in Singapore are the QA department.
- SWMM Infographic Studio: point it at a folder of models, get infographics back
- An InfoSewer-to-ICM migration toolkit: used on a live district council migration in New Zealand, not a demo
- SWMMCRAFT: Lego-style SWMM5 network building, because the 17-year-old with the brochure still gets a vote
- A Claude archive explorer: every AI conversation I've had since 2023, full-text searchable, with a heatmap of my own habit. Yes. I built an app to audit the habit of building apps.
One hundred applications. All functional. All public. All built by a 70-year-old grandfather who has never taken a course in web development.
If you stopped here, you'd think this was a pure success story.
A Harvard Business Review study tells a more complicated truth.
The Harvard Study: AI Intensified Work
In early 2025, HBR published results from an 8-month field study. Their finding was counterintuitive:
AI didn't reduce the amount of work. It intensified it.
Five mechanisms:
- Task Expansion. AI fills knowledge gaps, so you take on work that was previously not attempted. Scope creeps.
- Boundary Blurring. Starting is so easy that work bleeds into personal time. The friction that protected your off-hours disappears.
- Multitasking and Mental Load. Running multiple AI threads creates constant context-switching. Mental load increases even as individual tasks get faster.
- Specialist Review Burden. AI generates drafts rapidly, but experts must review everything. Fixing becomes the new bottleneck.
- Faster Rhythm and Raised Expectations. Visible speed becomes the new normal. Pressure increases without anyone explicitly demanding more.
When I first saw this, I felt a jolt of recognition. Not because I'd read about these patterns. Because I was living every single one.
A year later I can report: all five got stronger. So did my reasons for staying on the treadmill. Both halves of that sentence are the point.
Task Expansion: From Expert to One-Man Software Company
Before vibe coding, my contribution was knowledge: blog posts, Ruby scripts, tutorials, tech support.
AI removed the barrier to packaging that knowledge into interactive tools. Overnight.
The problem: removing the barrier didn't let me build one or two apps. It opened a floodgate. Every concept I've ever taught can become an app. Every comparison table can become interactive. Every Ruby script can become a full tool with UI and visualization.
Last year I wrote that I'd gone from doing 4 things well to doing 11 things at varying quality. This year the expansion jumped categories. The Ruby toolkit for ICM grew to 440-plus scripts across 14 library files, roughly 105,000 lines of code. I wrapped a three-tier agent architecture around it, with a catalog of 34,115 scripts an AI can search and reuse. I started writing journal-format papers about the apps. At the EWRI water resources conference in Mobile this year, my presentations shipped with live companion apps instead of static slides.
Nobody asked me to do any of this. I did it because I could. AI made the gap between idea and artifact vanishingly thin, and then made the gap between artifact and infrastructure thin too.
Boundary Blurring: Every Idea Becomes an App by Midnight
There was a time when having an idea at 10 PM meant writing it in a notebook and revisiting it Monday.
The 2025 version of my problem looked like this:
9:47 PM: "What if you could visualize every SWMM5 report file section as a chart?"
9:48 PM: Opens Claude
10:15 PM: Working prototype
11:47 PM: Sharing on LinkedIn
12:15 AM: Thinking about the next feature
The 2026 version is either worse or better, depending on which hour you ask me:
9:47 PM: Idea.
10:10 PM: I write one careful prompt. Scope, constraints, checkpoints, and a success test the agent must pass before it can call anything done.
10:20 PM: I hand it to the agent and go to bed.
5:30 AM: I wake to a finished draft, a run log, and a lessons file.
Some nights there are two runs going at once. The work no longer needs me awake. I used to lose my evenings to the treadmill. Now I lend the machine my nights and audit the results over breakfast.
Was that work? Was that hobby? Was that a healthy use of a Tuesday night? I still don't know. But I know the exact scale of the blur, because I built the app that measures it: 1,305 conversations with an AI in three years. 371 megabytes of me describing what I want built.
I have 50 years of SWMM knowledge. AI can express any piece of it as working software in 30 minutes, or overnight, unattended. There are thousands of pieces. The math is still sobering. It just runs while I sleep now.
The Specialist's Burden: Only I Know If It's Wrong
This is the paradox that keeps me up at night.
AI can generate a Ruby script for HEC-18 pier scour calculations in 30 seconds. It will be well-structured, properly commented, syntactically correct. It will look professional.
But is the K1 factor for a round-nose pier correct? Is the Froude number exponent 0.43 or 0.44? Is the upper limit on scour depth 2.4 times the pier width, or 3.0?
I know the answers. AI generated plausible answers. They are not always the same.
The Yarnell afflux tool I described last year had this problem: the AI's implementation matched the textbooks, not Yarnell's 1934 paper. This year's version of the same story came from the Benchmark 3D Viewer. The first TRANSECTS parser read the station-elevation pairs plausibly and wrongly, and the first pass at LINK_OFFSETS rendered a network that looked beautiful with the geometry subtly off. Only someone who knows what those sections mean inside the engine would notice. The 3D scene doesn't crash. It lies.
And this year the stakes stopped being hypothetical. I spent months with Stewart Sargent helping migrate a district council's sewer models from InfoSewer to ICM in New Zealand. A real network, a real regulator, real peaking factors that had to survive an engineer's audit. The conversion scripts were AI-drafted Ruby. Every field mapping was human-verified, because "plausible" is not a standard any council can certify.
Getting this wrong doesn't crash the program. It gives you a confident, well-formatted, professionally displayed wrong number.
The review burden scales with domain depth. The more you know, the more you can catch. The more you can catch, the more you must check. It is peer review where both peers are me.
The one real dent I've made in it: moving my judgment upstream. Over the past year I wrote what I know into skill files the AI reads before it drafts. SWMM5 engine internals. The ICM Ruby API and its field names. The InfoSewer migration traps. Even my own writing voice. A second brain, living in a repository. The first draft gets better when the reviewer's notes arrive before the draft does. The red pen still comes out. It bleeds less.
The Treadmill: Speed as the New Expectation
Before vibe coding, two blog posts in a month was productive. A new Ruby script was notable.
After vibe coding: apps weekly, posts constantly, a blog past 1,700 entries, and (the newest wrinkle) a newsletter subscriber count I check more often than I'd like to admit, with a 10,000 target I set for myself.
Nobody told me to produce at this rate. Nobody assigned me the subscriber goal either. But once you ship at this pace, the pace becomes the expectation, and once you put a number on a dashboard, the dashboard runs you. Slowing down feels like regression. Taking a week to think deeply feels like wasted time when you could have shipped three apps.
The treadmill goes faster, and you can't find the stop button, because the stop button is your own discipline against a tool that makes creation effortless and addictive.
What I've Learned (So Far)
I don't have this figured out. I'm writing this, again, partly to think out loud.
1. The apps are real and valuable. Don't dismiss them.
Every tool serves a real need. The report reader helps people who've squinted at text output for decades. Junior engineers use the quiz apps and grasp concepts that used to require 300-page manuals. My grandchildren read hydraulics fables at bedtime. This isn't vanity coding. This is 50 years of knowledge finally expressed in forms people can use.
2. Depth is still the differentiator. Protect it ruthlessly.
AI can generate breadth. It cannot generate the insight from 50 years of watching models fail in the field. The most valuable things I produce are the judgment calls embedded in the apps: which defaults matter, which edge cases will bite you in a FEMA review, which peaking factor will survive an audit. That depth comes from thinking time, not shipping time. Thinking time is still the first casualty of the treadmill.
3. "Done" is a discipline, not a failure.
Not every tool needs continuous improvement. The educational value of a tool that's 85% complete and publicly available is vastly greater than one that's 100% complete and still on my laptop. Ship it. Blog it. Move on. This rule is the reason a hundred things shipped instead of ten things stalling.
4. Review is the real work now, and it's invisible.
When I spend 45 minutes reading a 200-line Ruby script the AI generated in 30 seconds, checking every equation and every unit conversion, that is the most important work I do. It produces no visible output. The stormwater community does not need more apps that produce confident wrong numbers. It needs fewer, better apps that produce correct numbers because a 50-year expert read every line.
5. Teach the machine before it drafts.
New this year, and the highest-leverage change I've made: encode your expertise where the AI can read it first. Skill files, reference notes, a second brain in a repo. You will still review everything. But reviewing a draft written by an AI that has read your engine notes beats reviewing one written from the general internet's idea of hydraulics.
6. The boundary must be rebuilt manually.
AI removed the friction separating work and not-work. That friction was healthy. Without it, I build boundaries deliberately. A status report on last year's rules:
- No vibe coding after 9 PM (renegotiated: no interactive coding after 9. I may write one prompt, hand it to an agent, and go to bed. The lawyer who approved this loophole was me.)
- No more than 2 active app projects at once (let's call this rule aspirational)
- One deep-thinking day per week with no AI (still zero-for-fifty-two)
- Every app gets a "done date" when I start it (still the most useful rule I've adopted)
Where the Treadmill Actually Went
Last year's essay couldn't see this part coming.
I never found the stop button. So I changed what the treadmill is attached to.
This summer, after decades inside the companies that make the software (XP Software, CAiCE, Innovyze, Autodesk), I'm stepping outside. I'm trading the employee badge for Autodesk Expert Elite status. I'll keep paying for ICM Ultimate and the AEC Collection like any other customer. I'll keep chairing the SWMM5+ Technical Advisory Committee at CIMM.org and keep the EWRI stormwater committee work. The difference is that there's no longer a job title between me and the work. There's just the work.
And the hundred apps turned out to be a curriculum in disguise. For a while now I've spent months at a time at Network School in Malaysia, a short causeway away from my grandchildren in Singapore. Later this year we're aiming to welcome the first cohort of a residential hydraulic modeling intensive there: graduate students, real models, the quiz apps as mastery gates, the fables as proof that St. Venant survives translation into a bedtime story.
Fifty-two years ago, a brochure at the University of Florida changed my direction. This time I'm the one making the brochure.
One More Thing
I'm 70 years old. I'm a grandfather. I've been doing this work since before most of my colleagues were born.
And I'm having more fun building tools for the stormwater community right now than at any point in my career.
The paradox is still real. The work is more intense, not less. The boundaries blurred further; the work happens while I sleep now. The review burden got heavier as the drafts got better, because better drafts hide better mistakes.
But I'm building things I couldn't have imagined five years ago. I'm sharing knowledge in forms that actually reach people. And the treadmill, it turns out, can be pointed at something: a school, a cohort, grandchildren who think their grandfather writes animal stories about conduits.
The paradox isn't that AI makes work harder. It's that AI makes the most meaningful work you've ever done also the most consuming work you've ever done. Learning to hold both truths is still the real skill of the AI age. A year further in, I can report that it doesn't get easier. It gets clearer.
Last time, I closed by admitting I'd probably build an app about it that night. I did. It's the one that counts the conversations.
I'll probably build another one tonight. The done date is Friday.
Robert Dickinson: 50+ years shaping hydraulic modeling, from SWMM3 at the University of Florida to cloud-powered ICM SWMM. Autodesk Expert Elite. SWMM5+ Technical Advisory Committee Chair at CIMM.org. Grandfather. Vibe coder. Still learning the balance.
swmm5.org · swmmfive.com · LinkedIn