ryanmcl

I'm one of those people. Taught myself Rails 8 months ago at 45 with zero coding experience. I now have a production app with real Stripe payments, AI voice cloning, background audio processing, and a PWA with push notifications. Live users, live transactions.

Before AI assistance this simply wasn't in my possibility space. Not because I couldn't think through the problems, but because the gap between "I know what I want to build" and "I can actually build it" required years of skill acquisition I didn't have while raising my son and being a good husband (after some rough years ay).

The glut isn't visible yet because most of us aren't shipping to HN. We're shipping to our tiny audiences, our friends and family, our niche communities. The software exists ...it's just not venture-scale so nobody's writing about it.

This is fascinating and I wish I'd started with something like this from day one.

I'm 8 months into my first app as a self-taught developer and my biggest regret is having no artifact trail. I can describe what every piece of my app does, but if you asked me WHY I made specific architectural decisions, I'd struggle. Those conversations happened in Claude chat windows that are long gone.

The plan.md approach solves something I didn't realize was a problem until it was/whom [your future self] (or your future model) needs to understand not just what was built but what was considered and rejected. I've lost count of the times I've asked Claude "why does this work this way?" about my own code and neither of us could remember.

Starting a project.md for every feature going forward. Better late than never.

Both things are true simultaneously. The friction taught me things I wouldn't have learned otherwise; and the reduced friction is the only reason I got far enough to encounter that friction in the first place.

I still debug production issues manually. I still read error logs line by line. The AI got me to the starting line faster but it didn't skip the/my race.

Fair point...I should have said "practically impossible given my constraints" rather than "genuinely impossible." You're right that people have learned from books for decades.

What changed for me wasn't capability, it was feedback loops. A book can't tell me why my specific Stripe webhook is failing at 2am. The combination of AI assistance plus actually building something real kept me from hitting the walls that stopped me the three previous times I tried to learn.

But you're right that the skill existed before the tooling. The tooling just compressed the timeline enough to fit inside the life I already had.

This matches my experience but I'd add a layer = purpose from kids isn't automatic. For years I had kids and still felt hollow because I was showing up physically but not really present. Getting sober changed that. Suddenly the purpose that was always there actually landed.

Then I did something unexpected...I started building. Taught myself to code at 45 while being a stay-at-home dad. Now I have both: the deep purpose of raising kids and the creative purpose of making something from nothing every day.

The combination is what did it for me. Kids alone didn't fix the emptiness. Building alone wouldn't have either. But kids gave me the reason to get up and building gave me something to look forward to after bedtime (and not the leftover scotch glass on my nightstand).

Coming at this from the opposite end...I started coding 8 months ago with no experience, so AI assistance isn't replacing skills I had, it's the reason I have any skills at all.

But I've noticed something similar to what you describe. When Claude writes a solution for me, I understand it about 70% of the time. That other 30% used to bother me and I'd dig in. Lately I catch myself just accepting it and moving on. The velocity is addictive but you're right that something is being traded away.

The cost I've started noticing most: I'm worse at holding the full architecture of my own app in my head than I should be 8 months in. I can describe what each piece does but I couldn't rebuild it from scratch without help. Not sure the version of me who learned without AI would have that problem.

Still wouldn't trade the tradeoff = I have a live production app that wouldn't exist otherwise. But it's an honest cost worth naming.

There's a third category emerging that I think gets overlooked in these discussions = people who couldn't program at all before, who now can. Not replacing programmers, but creating new ones.

I started coding 8 months ago at 45 with zero experience. I now have a production app processing real payments. That was genuinely impossible for someone like me before AI assistance. Not because I lacked the ability to think through problems, but because the skill floor was too high to clear while also being a parent with no spare years to invest.

The spreadsheet analogy is apt. Most of those amateur spreadsheets aren't replacing finance teams; they're solving small problems that would otherwise go unsolved. That's closer to what's happening with AI-assisted development, I feel, than the "eliminate programmers" framing suggests.

This is one of the more interesting uses of Claude I've seen. Instead of asking it to write code in an existing language, you asked it to design the language it wants to think in. There's something philosophically fun about that I feel = like asking a painter to design their ideal brush.

I'm curious whether the generated language actually makes Claude produce better/more reliable outputs when writing in it, or if it just reflects Claude's training bias toward what "good language design" looks like in its corpus. Would be a fascinating benchmark to run.

This is a useful dataset, thanks for putting it together.

I think the nuance is that AI isn't replacing developers, I feel it's changing what "developer" means. I started coding 8 months ago with zero experience and shipped a production app with payments, background jobs, voice cloning, and audio processing. That would have been impossible without AI assistance. But I'm still the one making architectural decisions, debugging production issues at 2am, and figuring out what to build in the first place.

If anything, AI tools are creating more developers, not fewer. People like me who previously couldn't clear the skill floor are now building real things. That probably increases demand for experienced SWEs who can guide, review, and architect = which is exactly who Anthropic is hiring.

The "AI will replace developers" narrative sells better than "AI will lower the barrier to entry and create a much larger pool of builders, some of whom will need senior engineers to help them scale." But the second one seems closer to reality.

Mine has changed a lot over the years but right now it's something like: "You're allowed to start over. Starting over at 45 with no experience doesn't mean you wasted the first 44 years, I feel it means you finally have enough context to know what actually matters to you."

I spent 20 years in B2B sales before teaching myself to code last year. The old system prompt was basically "perform, close, optimize." It worked but it was running someone else's program. The rewrite happened when I got sober about two years ago and realized most of my default behaviors were inherited, not chosen.

Now I try to run on something closer to: "Build things that would have helped you when you were struggling. Ship before it's ready. Let people see the mess."

Great question...I think most people never examine their defaults, they just keep executing the prompt they were given as kids.

This is fair and well taken. For context I'm 45 with a 6 year old son / I've done the burnout thing in a previous career and have no interest in repeating it. But I hear you and the point stands regardless of my specific situation.

You're right, and I appreciate the reminder. I should clarify; I don't mean always-on work. More that the rigid "only think about code when seated at desk" constraint sometimes means losing genuine insights that surface during downtime. But you're correct that without intentional boundaries that mindset can slide into something unhealthy fast.

Fair enough mate, I should learn tmux properly regardless. My point was less about this specific tool and more that the barrier to entry for dev tooling I feel keeps dropping, which I think is net positive even if it means some inefficient abstractions along the way. Appreciate the nudge.

I came at this from the opposite direction in that I had zero coding experience and started learning ~7-8 months ago. I picked Rails specifically because everyone kept saying "it's dead" but every actual builder I talked to said "it just works." They were right. Rails gave me sensible defaults for everything I needed; auth, background jobs, file storage, payments...without me having to evaluate 30 competing npm packages for each concern. I shipped a production app with real Stripe payments as a solo dev with no CS degree. I genuinely don't understand how someone starting from scratch today navigates the JS ecosystem without losing months just to decision fatigue on tooling.

Fair point technically, but I think the value proposition isn't the persistent session, rathere it's the abstraction layer. Screen/tmux assumes you know what commands to run. This assumes you know what outcome you want. For someone like me who came to coding late and doesn't have 20 years of muscle memory with terminal tools, the inefficiency in transport is more than offset by the efficiency in intent. Different tools for different people.

This is the real insight in this thread. The false binary of "rest OR work" is dissolving. I do some of my best problem-solving while walking my kid to school or making lunch...the context switch lets things percolate. Having a way to capture that momentum without needing to rush back to my desk and remember what I was thinking would be genuinely useful. The interface matters less than the latency between idea and execution.

This resonates hard. I'm a self-taught dev who started coding ~7 months ago, and honestly the conversational back-and-forth with Claude is how I built my entire first app. Not by reading docs cover to cover, but by describing what I wanted, getting code back, breaking it, asking why, and iterating. The idea of doing that untethered from my desk is genuinely exciting — not because I want to work more, but because some of my best thinking happens on walks, not in front of a screen.

Interesting concept, but I'm skeptical about the passport verification solving the core problem.

The issue isn't just proving you're human - it's proving you're a unique human without creating a honeypot of identity data. Hashing name+DOB+country+last4digits helps, but state actors (as you mention) can absolutely rainbow-table this. And if a government wants to run influence ops, they'll just use real passports from real people (employees, contractors, or bought credentials).

The bigger challenge: even if you verify I'm human, how do you stop me from being paid to post propaganda? A verified human account spreading misinformation is arguably more dangerous than a bot, because now it carries the "verified human" trust signal.

I think the real solution is less about identity verification and more about social graph trust + transparent provenance. If I can see that an account was created 5 years ago, has genuine engagement patterns, and is vouched for by people I trust, that's more meaningful than "this person scanned a passport." That said, I respect the attempt to tackle this. The bot problem is real and getting worse fast. Just not convinced passport verification is the moat you think it is.

What's your plan for preventing paid human accounts from gaming the system?

This is wild timing - I literally just used Opus 4.6 this morning to help me build my second product (guided meditation app with voice customization). The level of architectural thinking it brought to the Rails structure was way beyond what I expected.

What blows me away about your STL reverse-engineering example is that Claude didn't just brute-force the reconstruction - it built a methodology. The z-level analysis, cross-section decomposition, the reusable toolkit... that's systems thinking, not pattern matching.

I'm curious: did you iterate on the SPEC.md prompt at all, or did it nail the approach on the first try? I find that when I give Claude a clear success metric (like your "0.1mm accuracy" requirement), it gets way more creative with its solution path.

Also, the fact that it documented its own process in SKILL.md is chef's kiss. I've been building a similar approach for my own projects - having Claude create reusable "skills" that improve over time feels like we're accidentally stumbling into something bigger than just code generation.

Great write-up mate! The "chimpanzee with a stick" analogy is perfect - we're watching tool use emerge in real-time.