unshavedyak

Does that happen on merge or before PR creation? I thought the setting only applied it when you hit the merge button, so you'd still have commits prior to the merge. Though that won't help if someone pre-squashes them :s

My problem with those abstractions is:

1. That the error messages for them i find to be awful. They really need to take inspiration from Rust to help users know exactly where the API error is happening relative to your code. I've spent quite a lot of time toggling things on and off to try and find which part of code, or which package, is causing a specific failure.

2. I've not found the APIs that the abstractions provide to be stable in the same way my Rust crates/etc are. Something can randomly break between updates and i'm not sure what caused it. Takes me quite a while of digging through source to find the root cause, and digging through Nix source i find extra painful.

All around i hate this side of Nix. A lot. However it's enough of "another level" that i stay with it and don't switch away.. I use it for my Linux machines and my Mac laptop. It makes so many things so easy, the majority of the time.. but when something goes wrong.. it's super painful.

If that's the case i feel like we need some other term. As you're saying that someone who ignores 95% of the written code is not vibe coding. That to me says we need a term that describes "i ignored almost all code" type of "coding" that LLMs provide.

I don't care about the 5% difference. I care about the bulk, the amount of bugs and poor logic that can slip in, etc. I have no attachment to the term "vibe coded", but it's useless to me if it doesn't describe this scenario.

I agree, i'm saying any code it produces. Eg if you ignore 95% of the LLM's PR, are you vibe coding? Some would say no, because you read 5% of the PR. I would say yes, you are vibe coding.

Ie you could say you vibe'd 95% of the PR, and i'd agree with that - but are you vibe coding then? You looked at 5% of the code, so you're not ignoring all of the code.

Yet in the spirit of the phrase, it seems silly to say someone is not vibe coding despite ignoring almost all of the code generated.

> There probably needs to be some settled discussion on what constitutes "vibe coding." I interpret this term as "I input text into $AI_MODEL, I look at the app to see my change was implemented. I iterate via text prompts alone, rarely or never looking at the code generated."

Agreed. I've seen some folks say that it requires absolute ignorance of the code being generated to be considered "vibe coded". Though i don't agree with that.

For me it's more nuanced. I consider a lack of review to be "vibed" related to how little you looked at it. Considering LLMs can do some crazy things, even a few ignored LOC might end up with a pretty "vibe coded" feelings, despite being mostly reviewed outside of those ignored lines.

Wish i could remember my issues with jj. I tried it, i wanted to stick with it because i loved the fact that i could reorder commits while deferring the actual conflicts.. but something eventually prevented me from switching. Searching my slack history where i talked about this with a coworker who actually used jj:

1. I had quite a bit of trouble figuring out a workflow for branches. Since my companies unit of work is the branch, with specifically named branches, my `jj ls` was confusing as hell.

`jj st` might have helped a bit, but there were scenarios where creating an commit would abandon the branch... if i'm reading my post history correctly. My coworker who was more familiar explained my jj problems away with "definitely pre-release software", so at the time neither of us were aware of a workflow which considered branches more core.

Fwiw, I don't even remember when the jj workflow had branches come into play.. but i was not happy with the UX around branches.

2. iirc i didn't like how it auto stashed/committed things. I found random `dbg!` statements could slip in more easily and i had to be on guard about what is committed, since everything just auto pushed. My normal workflow has me purposefully stashing chunks when i'm satisfied with them, and i use that as the visual metric. That felt less solid with jj.

Please take this with a huge grain of salt, this is 10 month old memory i scavenged from slack history. Plus as my coworker was saying, jj was changing a lot.. so maybe my issues are less relevant now? Or just flat out wrong, but nonetheless i bounced off of jj despite wanting to stick with it.

The rope in my example is complexity. Ie choosing to use "all teh features" when you don't need or perhaps even want to. Eg sometimes a simple clone is fine. Sometimes you don't need to opt for every generic and performance minded feature Rust offers - which are numerous.

Though, i think my statement is missing something. I moved from Go to Rust because i found that Rust gave me better tooling to encapsulate and reuse logic. Eg Iterators are more complex under the hood, but my observed complexity was lower in Rust compared to Go by way of better, more generalized code reuse. So in this example i actually found Go to be more complex.

So maybe a more elaborated phrase would be something like Rust gives you more visible rope to hang yourself with.. but that doesn't sound as nice. I still like my original phrase heh.

Rust is hard in that it gives you a ton of rope to hang yourself with, and some people are just hell bent on hanging themselves.

I find Rust quite easy most of the time. I enjoy the hell out of it and generally write Rust not too different than i'd have written my Go programs (i use less channels in Rust though). But i do think my comment about rope is true. Some people just can't seem to help themselves.

I think their skills have the ability to dynamically pull in more data, but so far i've not tested it to much since it seems more tailored towards specific actions. Ie converting a PDF might translate nicely to the Agent pulling in the skill doc, but i'm not sure if it will translate well to it pulling in some rust_testing_patterns.md file when it writes rust tests.

Eg i toyed with the idea of thinning out various CLAUDE.md files in favor of my targeted skill.md files. In doing so my hope was to have less irrelevant data in context.

However the more i thought through this, the more i realized the Agent is doing "everything" i wanted to document each time. Eg i wasn't sure that creating skills/writing_documentation.md and skills/writing_tests.md would actually result in less context usage, since both of those would be in memory most of the time. My CLAUDE.md is already pretty hyper focused.

So yea, anyway my point was that skills might have potential to offload irrelevant context which seems useful. Though in my case i'm not sure it would help.

They added a "How is claude doing?" rating a while back which backs this statement up imo. Tons of A/B tests going on i bet.

Briefly turned off? Oh it's back on? That's good at least. I thought he permanently turned it off the moment it didn't align with his goals.

Is using CC outside of the CC binary even needed? CC has a SDK, could you not just use the proper binary? I've debated using it as the backend for internal chat bots and whatnot unrelated to "coding". Though maybe that's against the TOS as i'm not using CC in the spirit of it's design?

Oh man, PRQL looks so good.

I just wish they had mutation in there too. I don't like the idea of swapping between PRQL and SQL, let alone some complex update statements where i'd rather write the query in PRQL. .. Yea you could argue they shouldn't be that complex for updates though heh.

Dumb question, but is this Claude for Excel the.. app? The webapp? Does it work on Google sheets? etc

There are quite a few spreadsheet apps out there, just curious what their implementation is or how it's implemented to work with multiple apps.

I always find Excel (and the Office ecosystem) confusing heh.

Sneezes are security risks. Sounds neat

That's fair, but i also don't cross check news sources on average either. I should, but there in lies the real problem imo. Information is war these days, and we've not yet developed tools for wading through immense piles of subtly inaccurate or biased data.

We're in a weird time. It's always been like this, it's just much.. more, now. I'm not sure how we'll adapt.

I'm just an ignorant bystander, but is the training dataset the ground truth?

Kind of feels like calling the fruit you put into the blender the ground truth, but the meaning of the apple is kinda lost in the soup.

Now i'm not a hater by any means. I am just not sure this is the correct way to define the structured "meaning" (for lack of a better word) that we see come out of LLM complexity. It is, i thought, a very lossy operation and so the structure of the inputs may or (more likely) may not provide a like-structured output.

Honestly it helped quite a bit. There are a lot of obscure (imo) errors in Nix that LLMs spot pretty quickly. I made quite a bit of progress since using them for this.

Seconded. I have a mostly CLI setup and in my experience Nix favors that on Mac, but nonetheless it makes my Nix and Linux setups a breeze. Everything is in sync, love it.

Though if you don't like Nixlang it will of course be a chore to learn/etc. It was for me.

I imagine the devil is in the details though, no? Ie it definitely changes at least one, right? So the real question is cost vs voted gained.

Yea, i find success in LLMs overall but the quality of the work is proportional to how much oversight there is.

It is, though not worded as nicely as the GP comment.

docs: https://doc.rust-lang.org/std/vec/struct.Vec.html#method.res...

> Countless people in comments say this, but other people fail to see evidence of that in the wild. As has been said in response to this point many times in the past: Where's the open source renaissance that should be happening right now? Where are the actual, in-use dependencies and libraries that are being developed by AI?

The thing that this comment misses, imo, is that LLMs are not always enabling people who previously couldn't create value to create value. In fact i think they are likely to cause some people who created value previously to create even less value!

However that's not mutually exclusive with enabling others to create more value than they did previously. Is it a net gain for society? Currently I'd bet not, by a large margin. However is it a net gain for some individual users of LLMs? I suspect yes.

LLMs are a powerful tool for the right job, and as time goes on the "right job" keeps expanding to more territory. The problem is it's a tool that takes a keen eye to analyze and train on. It's not easy to use for reliable output. It's currently a multiplier for those willing to use it on the right jobs and with the right training (reviews, suspicion, etc).

Offtopic, but do you have any comparison to math academy to something like Khan, or other platforms? MA seems a bit expensive for someone just wanting to improve a general skill, but perhaps it's well worth it? I thought Khan was also investing in similar AI offerings, so i'm curious how they intersect

Sidenote, Claude Code now has a thinking toggle. Maybe it did already, but that's new to me. I see better results by just leaving that toggle on.

I like this a lot, going to try it! One issue i have though is in the current world of LLMs scraping content, i'd prefer there to be more discussion about compensation of authors.

I know the announcement page talks about not scraping, but to me personally the value i see in this product is that i don't have to go to those ad ridden, poorly organized and often terrible pages of the authors. Which then seems really unfair to the actual content providers.

I'd like to see this type of service cost $3-5/m ontop of my normal Kagi sub to compensate the authors of the articles i read. A Streaming Music model for news, ish.

This proposed value is quite small, but my assumption is only a very small amount of money would reach them from my ad views anyway so a $10/m addition feels extreme to me.

Weird, i use it exclusively in the terminal (in raw term, tmux and zellij) and i've not noticed any difference in behavior. On both MacOS and Linux.

Wonder what changes that i'm not seeing? Do you think it's a regression or intentional?

> why does it default to full screen?

Pardon my ignorance, but what does this mean? It's a terminal app that has always expanded to the full terminal, no? I've not noticed any difference in how it renders in the terminal.

What am i misunderstanding in your comment?

I'm concerned that i don't see the "Plan with Opus, impl with Sonnet" feature with Claude 2.0.

Interesting, in the new 2.0.0 claude code they got rid of the "Plan with Opus then switch to Sonnet" feature. I hope they're correct in Sonnet being good enough to Plan too, because i quite preferred Opus planning. It wasn't necessarily "better", just more predictable in my experience.

Also as a Max $200 user, feels weird to be paying for an Opus tailored sub when now the standard Max $100 would be preferred since they claim Sonnet is better than Opus.

Hope they have Opus 4.5 coming out soon or next month i'm downgrading.