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.
The biggest problem is it’ll teach you bad habits. For example, Claude and gpt love to use fallbacks. They generate code that’ll get a positive result at any cost, even if it’s horrible in efficient. If you don’t have past knowledge you might just think that’s how it is.
Now before someone says that junior devs make the same mistakes, yes, to some extent.
If you don't have the experience you can't provide it with stylistic guidance, or idiomatic patterns or provide examples to direct it.
This leads to the idea that LLMs with existing languages can't really learn new idiomatic patterns.
For new engineers I think new paradigms will emerge that invalidate the need to know the current set of design patterns and idioms. Look at the resurgence of unit tests or the new interests in verification systems.
It seems to do this kind of stuff more when you're not looking too. Like I'll be approving edits all day without any problem then the second I set it to auto it gets a lint error about dead code and adds a pragma to allow the dead code instead of removing it, etc.
> They generate code that’ll get a positive result at any cost, even if it’s horrible in efficient.
If only efficiency is the only problem with that. Sometimes an error state should an error. This is the equivalent of eating all exceptions and pretending all is fine. It just means nothing works.
Models don't learn. They retrain them periodically, but junior engineers learn much faster and constantly improve. If you stop learning, you will only be as good as the model.
I've been coding (software engineering, I guess) for close to 15 years. The models skill set is a comfortable L1 (intern), pushing L2 (junior). They are getting better, but at a snail pace compared to a human learning the same thing.
get the system to build a clean architecture and explain it to you. it will help it to build a better system. a huge part of working with these models for engineering is getting them to create reports. for themselves and of course for us to read and understand. the bottleneck is actually our verification capacity.
Claude Code has a “learning mode” that makes it explain what it’s doing and leave “TODO(human)” placeholders in the code where you have to do part of it.
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.
The thing is that programming is not an end goal, it is a means to a end. No one is paying you to "write code", they are paying you to make a website shat serves as a storefront, to make a video game, something for accounting,...
It turns out that in many of these cases, code is an effective way of doing it, but there may be other options. For a storefront, there are website builders that let you do it very effectively if your needs match one of their templates, there are game engines that require no code, and a lot of accounting can be done in Excel.
What I wanted to say is that maybe you could have done without code, but thanks to LLMs making code a viable option even for beginners, that's what you went for. In fact, vibe coding is barely even coding in the strictest sense of writing something in a programming language, since you are using natural language and code is just an intermediate step that you can see.
The reason programmers use programming languages is not gatekeeping, unlike what many people who want to "eliminate programmers" think. It is that programming languages are very good at what they do, they are precise, unambiguous, concise and expressive. Alternatives like natural languages or graphical tools lack some of these attributes and therefore may not work as well. Like with many advanced tools, there is a learning curve, but once you reach a certain point, like when you intend to make it your job, it is worth it.
Good lord, thank you. I'm a huge fan of LLMs, they've replaced enormous amounts of toil for me but they are not 'my job'.
If you walk to the kitchen and fry up an egg are you now a master chef? What's the difference between a surgeon and a butcher ...they both cut things?
Most shops never really needed development expertise in-house as there's no shortage of many decent tools equally suitable as code for getting machines to do most business things.
In some ways this is worse because while it's functionally the same black box intermediary as the alternative-to-code tools there's an illusion of control and more sunk cost. Do you want your sales team selling or learning JavaScript churning out goofy knock-offs for a well-solved problem?
No. it was not. You could build a passable online shop after reading a django or ruby on rails book (250, 300 pages), and a couple tutorials to deploy it in some ease to use platform.
Maybe it wouldn't be visually nice, but you would understand what you've built, which is something really really important if you are processing online payments.
Congratulations. This is my favorite aspect of this whole thing: LLM tooling that's helping new people break into programming by lowering the friction and learning curve.
You could say the same thing about learning to fly a plane or play the piano. I’ve got no problem with people using llms to write useful utilities and programs for themselves, but it is leading us into a world where people are creating powerful things they don’t understand. That’s going to have consequences. We are already witnessing some of them.
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.
I plan to keep dumping tokens into it here and there to see where it goes, it's a fun rabbit hole.
I find that it's able to produce working code in the generated language just from the README and the previous examples without much trouble. And I've seen the strict typing help it catch and correct bugs quickly.
I steer it very little. The only thing I keep an eye on is not allowing it to cheat about things like writing lots of concrete functionality in the host language and then just calling that from the interpreter.
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.
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.
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.
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.
"The false binary of "rest OR work" is dissolving."
If you're like most people in this forum, there are people who stand to gain financially if you convince yourself that you don't need boundaries between work and rest. You may even believe that you stand to gain financially, and that this will be best for you in the long term.
Please, take some time to rest for a day or two and really think about what you want your boundaries to be. Write them down.
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.
> The false binary of "rest OR work" is dissolving
Sounds like someone hasn't yet worked multiple years with software engineering, or any job for that matter.
Your mind might trick you into believing it won't matter, but your body and mind NEEDS to be disconnected from work, 100%, at some point during your regular rhythms of life, otherwise you'll burn out much faster than the people you seemingly are trying to compete with.
Life never been a sprint, but it is a marathon, and if you spend all your young experience-less years on treating it as a sprint, you won't have any energy left for completing the marathon.
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.
How is this not solved by a simple voice recorder? You can process and act on it later while not forgetting your thoughts when inspiration hits. People have been doing that for at least like 50 years now.
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.
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).
reply