mablopoule

Not OP, but the issue for me is that for the longest time doing software development meant translating potentially nebulous requirement into strict computer logic.

The process of creation is often a back-and forth between that fuzzy concept in your head (or an natural-language spec that is often ambiguous), and the (usually reduced) physical object / drawing / computer program you've created to materialize this idea. That imperfect projection of your initial idea then helps you refine what this idea implies, and what are the different tradeoff you could take [0].

That back-and-forth has to be made when writing the computer code, even if it's going to be compiled after, because code needs to be detailed enough to force you into expressing the desired behavior with clarity. Prompting Claude on the other hand usually means that you let the LLM resolve this ambiguity for you.

In some case the details don't matter, and it's a productivity gain, and in other case the devils are in the details, and you've let Claude make important technical decision for you, even though Claude doesn't know how much those decision match the needs of the project.

Personally I think of my role as a software developer as someone who know technical possibility (and technical limitations), and weight the different tradeoff it implies to propose code that solves a business problem. And that's the crux of the issue with only creating code by prompting Claude Code: it gradually robs me of my ability to understand the technical possibility and limitation of the system.

[0] This idea has largely been taken from the very good book "Sketching User Experiences: Getting the design right and the right design", about the processus of ideation / sketching.

> Maybe more important than that, it's about taking the time to build the mental models that facilitate product development and the next iterations of coding.

For me this is the big one. When you code by hand something (especially at the start of a project / feature), it gives you times and opportunity to evaluate different approach, like data-structure or overall architecture. When you're given agentic-generated code to review, those choices are already been made implicitly by Claude, and while it give you the impression that you understand the codebase, you actually haven't been able to process the tradeoff.

Of course, not 'hand-generated' code has the same ROI, and when you're about to do something derivative of something you already understand, agentic development is truly a huge productivity gain.

For me this is the difference between 'vibe coding' and 'coding with AI': Am I able to predict in advance the code that Claude is going to generate, and more importantly, am I able to be surprised when Claude doesn't generate the code I thought it would have (sometime for good technical reasons), or am I just looking at plausible-looking code diffs, and accepting thing without being able to understand the impact on the rest of the codebase. This for me is way more important than what percentage of code lines have been generated by AI.

I've had the opportunity to try both approach: one where I was given a vibecoded project and told to maintain it with Claude: I knew the details of some features, but haven't worked with the codebase enough to really understand the architecture, or be able to mentally reason about the codebase when I'm asked a question during a meeting.

On the another re-implementation of the same product, I've been given more leeway to develop how I wanted, so I've handcrafted the first few features in a transversal way (handling the file architecture, the routing, the way data and components are splitted, and how the API calls are handled), and then I've used Claude to generate the other feature (most of them I knew to be derivative of the first one). In the end something like 90% of the code is generated by Claude, but the end result is both much simpler because I knew where things should be simple and where edge case where, and most importantly I trust what I've put in production.

Because the AI one are soul-less, and the badly drawn ones are not, simple as that.

I agree with your take, most of it boils down to ego, I believe.

Lot of it was bad, sure, but there was so much games and animation done by literal kids back then, because of how easy it was to create something with the tooling. Nothing even come close today, unfortunately.

This will greatly increase developer velocity (by making them run far away).

Same, I'm currently working more in React project, and I miss Angular so much that I actually use it in my personal project, it can be a genuine pleasure to use if you avoid over-engineering the rest.

React shines when it comes to the composability of components, eg. for data-table with customizable rows. It's still possible in Angular, but it's heavier.

For the rest (syntax, the ecosystem, routing, data-handling, DI), Angular is so much more straightforward. Services with dependency-injection is 99% of the time way simpler to reason about than React hooks, especially when you start to need cascading changes between hooks after user interaction.

Agree. RxJS is a beast to approach at first but it's a genuinely cool library, as long as you don't spread observable around when you don't actually need them. I used the same approach for a few years (pushing my http calls behind domain-specific api services that only return promise), and it's way simpler to handle.

I still use RxJS, but mostly in the top-level component and/or service who orchestrate between data, url state and api responses. Those top-level page usually keep the default change detection instead of the 'on-push' strategy).

As someone who feels stressed about not feeling able to finish the side projects I have (that is, working on my music player, learn Arabic, and learning to draw), this is a very refreshing take. Thank you for this.

I think the implication is that even though the technological landscape is evolving, it's not as if people born in the 60's couldn't foray into computer science because they arrived too late to study the ENIAC first.

I'm not sure why you're downvoted, but this is the right take IMO. I hate cheating and lying in general, but in any job posting you have to separate what are the actual requirement in term of knowledge versus what can be realistically learned on the job / doing a prototype in a weekend.

Of course don't fraud by like pretending you're a statistician when you have absolutely no mathematical background, but also don't take at face value the "Must have {x} years of experience in {y} tech" requirement when you know you have the necessary work experience to have a good grasp on it in a few weekend prototypes, and you also know that the job doesn't actually require deep expertise of that particular tech.

I did the same for my first React.js job, and I didn't feel bad because 1) I was honest about it and did not sold myself as a React expert, and 2) I had 10 years of front-end development, and I understood web dev enough to not be baffled by hooks and the difference between shallow copy vs. deep copy of a data structure, so passing technical test was good enough for it.

I would agree, but the question feels less spiteful than playful in nature.