lionkor

Maybe this is a fundamental difference in how our societies work, between Germany and the USA. Here, when we go swimming, we leave our phone, keys, and wallets at the beach and just go swimming. It's a trust system, my neighbor won't take my shit because I won't take his shit. So maybe the idea behind the system is to simply ask people who want to upload their slop to not upload their slop, and that that has enough of an impact to be worth doing already.

As for copyright, LLMs can reproduce nearly 1:1 fully copyrighted, non-foss code. I would love to see someone argue in a German court that they can copy a book, a piece of code, or a movie, by laundering it through a program that produces an average of lots of copies of the same movie or book, and burns a lot of power doing it, and that this makes the product of it entirely public domain.

Open source code that is AI authored is worthless. If I need an LLM authored, idk, terminal emulator, I will simply ask my AI or use one of the tens of thousands out there.

noreply@anthropic.com

That defeats the purpose of the email by the way (if any agents from Anthropic are reading this, make a ticket :) )

I love the abstraction of AI

Careful with that wording. LLMs are not an abstraction, they do not provide an abstraction, not in the software sense, as they are completely non-deterministic the way they are used today. Saying "write me a function that does xyz" is not an abstraction layer ontop of writing it yourself.

fully protected under safe harbor laws

Well, not quite, it would still have to deal with handling and moderating copyright claims under German law. So while it's not a legal issue, it's definitely overhead for a nonprofit.

Inclusion of harmful code is no more likely than human-extruded code (probably less actually).

Based on what? So if I set up a markov chain and generate a couple ten thousand lines of python code, and somehow got it to run, you'd say it's safer than human code? What about low quality local LLMs? Where is the line that says that automatically (not quite "randomly") generated code has less issues than human-generated code?

Harmful code does not mean purposefully harmful, it could simply be accidental (like when an agent goes "hm, an instance is already running, let's ensure that doesn't happen" and adds a `pkill -9 myprogram` invocation to a script, unknowingly killing all processes that contain the word `myprogram`). It could also be code that claims to do one thing, but does another, or one that ends up logging auth keys, etc.

I have had SOTA models do all of the above. Not sure about more or less likely than human code, but since LLMs can generate thousands of lines per hour, that tips the scales.

This makes sense from a copyright perspective -- as long as you maintain 50% or more actual human authorship, in case of a conflict with future copyright laws around LLM generated code, you can at least claim that a majority of the code is human-authored.

Why are all the vibe coders so upset? Places that have mostly non-polluted projects will be fantastic for future model training. Codeberg doing this will mean that it will be scraped and part of all future models' learning input, surely? They have never cared and will never care about anyone's rights.

Unsurprising given that a large amount of posts on the front page are about or in support of projects that are entirely vibecoded with near zero human input beyond "hm it feels kind of slow, make faster?".

AI is used to launder a lack of care and skill, and people really love not caring and not having to put in any work.

See my comment here: https://news.ycombinator.com/item?id=49004041

"All code will be AI written" is like saying "all code will be written in an IDE". That in itself doesn't matter, nobody should care,and it doesn't make a difference.

The workflow, or complete lack of a workflow, for vibe coded projects in terms of design, architecture, vision, etc.is the problem. The lack of oversight is the problem, and the lack of thinking by an actual human capable of thinking, is the problem.

Roughly every serious codebase now and forevermore will be at least mostly AI written.

There is a difference between AI written and AI authored, somewhat. Or maybe call it written vs designed.

A lot of the code written today is written by AI, even in serious projects, but the difference is that serious projects don't vibe code. They don't let the AI write whatever it thinks is best, they instead have clear requirements, established architecture, established testing frameworks, tests, CI/CD, linting and human code review.

The difference is intent; if you use AI to write the code you would have written, then nobody can tell, and it's still fully your code and you have reviewed it. That's not vibe coding.

If you let an agent autonomously plan and write code, that's different. The autonomous "Jesus take the wheel" approach results in code you wouldn't have written yourself, and might also have clear AI tells, fundamental issues (like security flaws by design, performance flaws by design, correctness flaws by design, and general maintainability issues).

This matters. I doubt anyone wants to use or read projects done the latter way.

There are fantastic TUI frameworks for Rust, like Ratatui[0] (there are a lot more options, this is an example). You can write beautiful TUIs in native languages, without ncurses or C or C++.

Go has such frameworks, same with C# (which you can AOT compile) and so on. You're not stuck between javascript and C.

[0] https://ratatui.rs/

It's because rewrites are almost always a bad decision. Best case, it's a naive decision made by people who don't know better, worst case it kills the product (who here uses netscape?).

So, from the start, people will be skeptical of a "we rewrote xyz in Rust" because it rarely works out. But there's a lot more to this, in fact it's a little bit loaded with "tech bro" ideas:

- Rewriting in Rust

- Rewriting using AI

- Making terminal apps in JS

- Zig (a lot of people's dear language) is involved somehow

This attracts every single skeptical developer. The only thing missing is maybe blockchain, if that was still cool. It just hits all the "what? why?" spots.

I was already writing a comment, when I realized that what I wanted to write had already been said by the top comment. I suppose that's why comments read so similarly.

It doesn't have a central stream of logs if it's running on an isolated system without internet, so while there are errors, you can't have a 24/7 Claude looking at it. At my previous role, similar issue, you can't put Claude 24/7 on a PC with patient data on it. Just not happening.

Yeah for sure it's a bandaid fix, but it does produce tests that fail if the interface doesn't match the implementation, more often than not doing this does (in my experience).

With a skill like this, which I have written, the LLM will end a session with "wrote 24 tests, 5 failing due to API contract mismatch" or something, and leave it at that. I can then decide if that's a bad interface or bad implementation.

Yes, I want my team to be deeply familiar with the codebase and every single little bug that needs fixing both trains them and let's them learn a little bit more about the codebase.

They can use agents. Like, team members don't need to be replaced, they can simply use agents when they deem it useful. If they see a trivial bug,they can put their agent on it and go work on something else meanwhile.

Well I am fully of the opinion that LLMs can help in software programming, it's not something that I feel provides any value unless it has a human in the loop. The overhead of having to figure out if the agent did a good job, if the agent is actually done or not, and if the thing it built is shit or not, is worth simply avoiding by having a human in the loop.

So I wouldn't agree that the agent should be cranking out code all the time, in fact that seems more like a waste of resources compared to the work it creates. But I do understand home automation software can be very one-off and simple. But then again, a properly programmed home automation suite doesn't need a SOTA model to modify it, I think.

Fair point

It's part of the rationale for why one would choose Pi over Claude, even if Pi lacks the feature. I admit my tone is entirely inappropriate though.

I am aware this is likely sarcasm, but in case it isn't, what do you gain from doing side projects this way?

None of these are things I want or need in the product I maintain with a team, there's really no point to any of this unless you run a vibe coded SaaS (?)

This is very much just laundering not giving a shit through an LLM so you can blame it after the fact.

This is a sure way to get girls! Girls love being entirely commoditized and objectified, famously that's a great way to date! /s

They way I read it, this is a workaround for pi, not for Claude.

Edit: removed off topic political spam

Thank you very much, these are some very interesting ideas! I appreciate that you took the time to write them down.

Not like funny like a joke is funny, but funny like having sun and rain at the same time is funny :)

The solution is a skill that explains to the LLM, with a fresh context, to NOT read source files, and to only use XYZ tooling to extract documentation and function signatures, etc. without implementation details.

Then it can write tests based on the interface, and that is usually a lot more solid.

Some combinations could be funny, like a pregnancy test and something really mundane but odd like a whole pineapple and a large bag of lettuce

What kind of notes do you take? It's always been kind of difficult, as someone who takes maybe a page of notes a week, to imagine what people fill entire books of notes full, outside of university etc.?

I had a friend who would write notes on everything. Every time he learned something, he would write it down in his own words. This sounds good, but he ended up basically internalizing and studying his own misunderstandings, as he never referred back to the source material and instead studied off of his notes.

So I'm very curious how you take notes, if you're willing to share?

Any CTO worth a damn knows they aren’t worth a damn

beautiful.

Go is not like C in any way. It doesn't feel like C, it feels like C# with mediocre syntax changes and extremely explicit error handling -- like someone took the bad parts of C and added them to a high level language.

I don't get it at all. Green threads are cool, but again, it's easy to write unsafe concurrent code in Go, so why would I choose it over e.g. Rust (where its hard to write unsafe concurrent code) or C++ (which gives me more control)?