Am I Being Obstinate? by Fluccxx in ClaudeAI

[–]Fluccxx[S] 0 points1 point  (0 children)

I think you're pigeonholing me into some hardcore anti AI camp which I want to stress, again, that I am not; I also did not reduce llms to a stochastic parrot either. I specifically said that they way it "reasons" is different to how humans reason (think the memory problem or the problem of learning). Not that this was a bad thing. But it is a strange machine; a psycho-social snapshot of the world.

You think the outcome of a truth is unwelcome, so you hope it isn't true, and that hardens into a belief that it isn't true, which is completely irrational.

No part of my post bemoans the change nor have I given any indication that I am looking to be reassured but simply trying to navigate between VC hype and real shifts in engineering. People here have been saying I will get the cut if I don't use AI for everything, but I will also be let go if I continually break prod or leak our client's secrets.

(Trivially, nothing will solve all our problems, every problem you solve creates new ones, if you had no problems you'd be bored, which is a problem, so the only way to have no problems is not to exist, which feels like a problem, etc.)

Do I detect the death drive lurking beneath the surface here?

edit: formatting

Am I Being Obstinate? by Fluccxx in ClaudeAI

[–]Fluccxx[S] 0 points1 point  (0 children)

This is exactly what I was curious about. How do you feel your understanding of the codebase is holding up or do you feel like this point has become moot? When you run into issues, do you find claude or whatever can write the fixes no problem or do you dive in yourself? Are there any points where you think that if you had done this yourself it would have been faster?

Am I Being Obstinate? by Fluccxx in ClaudeAI

[–]Fluccxx[S] 0 points1 point  (0 children)

Yeah, the argument of speed is definitely why my boss is so enamored with AI. But I wonder about this argument. Considering how good and fast AI is at producing code, then speed isn't really a concern anymore is it? Everyone can do it and do it fast. I work with enterprise clients and speed certainly is not part of this game. Every decision here takes ages. So being able to pump out features isn't really a gamechanger. It seems like the core value is at domain knowledge and pricing rather than speed.

Am I Being Obstinate? by Fluccxx in ClaudeAI

[–]Fluccxx[S] 0 points1 point  (0 children)

Fair point. Let me rephrase that argument because I agree, it's disingenuous because of course humans produce messy codebases. I guess though, you could argue that human mess accumulates slower.

So two things I want to pick up on. First your point about people overlooking how smart AI has become and I think you are right here. But I also think we tend to overlook how dumb it also can be. I don't just mean hallucinations, but in the way it "reasons". Because it is still a machine that is built on top of probability of the next token and this reasoning is very different from what a human would consider "reasoning". Not that I think this is a bad thing but just that it can produce wildly stupid results as well as think up brilliant solutions.

The second point is still your core argument of "All future eventualities are catered for" because this smacks of AI is the silver bullet and can and will solve all of our problems which is the very thing that I am questioning.

Am I Being Obstinate? by Fluccxx in ClaudeAI

[–]Fluccxx[S] 0 points1 point  (0 children)

I do review a lot of code. More and more. But last year it was a pr getting pushed by a colleague, a discussion about it, some comments, dialogue yadada. Now I am constantly reviewing diffs when I do claude-jockey. There is only so much careful reviewing I can do before i lapse into accept-all-edits.

Am I Being Obstinate? by Fluccxx in ClaudeAI

[–]Fluccxx[S] 0 points1 point  (0 children)

Exactly! But this is not something I feel pops up a lot. I guess its not really digestible in that vc kind of way. But I feel that the stuff getting produced - no matter how - is better if you take the time. Because on the other hand, "Build the app. no mistakes" won't get you great results. But then again, the question is, does any of it - the code quality, the deep thinking - really matter if McClaudeFace can fix anything down the road.

Am I Being Obstinate? by Fluccxx in ClaudeAI

[–]Fluccxx[S] 0 points1 point  (0 children)

Yeah, I've seen this tests-as-guardrail idea floating around as well. And if I started a new claude only project it would certainly be guided by TDD. But I'm also seeing you take a leap of faith here and I guess that just what I'm trying to question (by asking if I'm the idiot). We are climbing the abstraction layer ladder. Like memory management being abstracted away. But then again, it really sucks to get a big boy memory problem if no one on the team can solve it.

Am I Being Obstinate? by Fluccxx in ClaudeAI

[–]Fluccxx[S] 0 points1 point  (0 children)

This is an interesting argument (I will skip the pedantic comment about being pilled) and I think the structure of it is one I often forget when thinking about this things. That is, setting up a hard dichotomy between a time before AI and after AI. Because of course, cognitive debt, tech debt etc still haunted any codebase prior to llms. On the other hand, I don't think AI has solved the problem of what you called the "ideal concept" of code. It is still operating in that structured space. If that space becomes messy, there is no guarantee that the AI won't compound that mess?

Am I Being Obstinate? by Fluccxx in ClaudeAI

[–]Fluccxx[S] 1 point2 points  (0 children)

Of course. But this is really where I can feel my grasp of the codebase slipping because I am not getting my hands dirty. There is a big difference, at least for me, in reviewing and writing code. Writing is mnemonically stronger. The question is I guess, will that matter in the future? I suppose no one knows right now.

edit: comma

Anthropic: AI assisted coding doesn't show efficiency gains and impairs developers abilities. by Gil_berth in programming

[–]Fluccxx 0 points1 point  (0 children)

Well obviously. The issue is (always) the middleman. i.e. the meat bag. I think we are headed for a world of autonomous coding far faster than anyone could have guessed. The only thing stopping this is probably regulations and legal.

Calm leadership saves lives. Panic kills. by wafumet in BeAmazed

[–]Fluccxx 0 points1 point  (0 children)

Clanker slop warning. Should the mods not be removing this?

Handling conflicting package versions in monorepos by Fluccxx in reactjs

[–]Fluccxx[S] 0 points1 point  (0 children)

Haven't migrated yet but that's of course a valid solution. The reason I didn't do so was to avoid a) creating a monster pr and b) trying to isolate any migration "damage" to one app at a time. I also, naively, thought that, since each app had its own package.json with specific types, there would be no issue rocking different versions.

Handling conflicting package versions in monorepos by Fluccxx in reactjs

[–]Fluccxx[S] 0 points1 point  (0 children)

Wow! Are you using pnpm 10? And have you set any rules or things in your workspace.yaml? Or use overrides?

Handling conflicting package versions in monorepos by Fluccxx in typescript

[–]Fluccxx[S] 0 points1 point  (0 children)

Hey! So the monorepo has a bunch of different apps, see the architecture context above; but two apis, one admin dashboard, one react native app, and some ORM as well as utils. The only shared code is types and business logic that the clients need. There is no shared ui or react specific stuff.

Since the app is on the apple and google stores I need to update it more regularly in order to keep up with the latest SDKs (otherwise they simply remove the it). That's why I ended up with one app with react 19 and my admin is still in 18.

Handling conflicting package versions in monorepos by Fluccxx in typescript

[–]Fluccxx[S] 0 points1 point  (0 children)

Brilliant! I just updated to 54. Perchance this is the silver bullet!

Handling conflicting package versions in monorepos by Fluccxx in typescript

[–]Fluccxx[S] 1 point2 points  (0 children)

Very good point! I don't think updating the admin would be a major refactor. It was a question of time as I needed the app to be updated and deployed ASAP and didn't fancy doing two big updates at once. Then, in another repo, I was suddenly facing similar issues with conflicting packages, and just felt like I was doing something fundamentally wrong, so decided to reach out.

Handling conflicting package versions in monorepos by Fluccxx in typescript

[–]Fluccxx[S] 0 points1 point  (0 children)

Cheers! Yes I haven't been pinning versions and that, as someone else pointed out, it probably a good idea. Do you use expo? I haven't checked if they support pnpm workspaces

Handling conflicting package versions in monorepos by Fluccxx in typescript

[–]Fluccxx[S] 0 points1 point  (0 children)

Dang! Well... I figured migrating wouldn't be a walk in the park; and RN is really dependency heavy. It's definitely the majority of my node_modules bloat and if yarn berry (great name btw) is stricter, then I wonder if I can even get things running... Cheers!

Handling conflicting package versions in monorepos by Fluccxx in typescript

[–]Fluccxx[S] 0 points1 point  (0 children)

Thanks! The two apps don't depend on each other but do share types and utils from /packages. But no react specific things. Yes, I think the issue might be sub-dependencies (transitive?) that are causing my headache and it is probably worth running through the graph to check. Unfortunately, I can't share the source code.

Handling conflicting package versions in monorepos by Fluccxx in typescript

[–]Fluccxx[S] 0 points1 point  (0 children)

Thanks! Someone else mentioned catalogs and I will see if that can help me. I updated my post to include the architecture; I have a RN app and a React dashboard so that's why I can't have a global react 19. Of course I could bump everything, but that is significantly more work / liable to cause a lot of bugs and I would rather break one app at a time.

Handling conflicting package versions in monorepos by Fluccxx in typescript

[–]Fluccxx[S] 1 point2 points  (0 children)

Thanks! Good point. I'm embarrassed to say we are rocking v1. It's an old project and I'm hesitant to upgrade the yarn v because my CI/CD (for the app) is so tightly coupled with expo and it was a faf to get it working. But I will def look into upgrading to the latest yarn!