Home   2026-08-03 17:31:33

←

Softwareontwikkelplatform Codeberg verbiedt cryptovalutaprojecten en AI-code

Original article

Softwareontwikkelingsplatform Codeberg verbiedt projecten die ontwikkelaars grotendeels of volledig hebben geschreven met AI-tools. Ook staat de website niet langer cryptovalutaprojecten toe.

Codeberg nam de besluiten na stemmingen binnen de community. Codeberg omschrijft llm's als een 'opkomende maar controversiële technologie'. De community heeft daarom onder meer een motie aangenomen om het gebruik van AI voor het schrijven van code te verbieden.

De motie kreeg 358 stemmen voor, 144 stemmen tegen en 14 onthoudingen. Daarop paste Codeberg zijn voorwaarden aan. Daarin staat nu dat gebruikers geen projecten mogen delen 'die voornamelijk bestaan ​​uit code geschreven door generatieve-AI-tools'. Volgens het platform is de auteursrechtelijke status van die tools onduidelijk en bieden ze weinig garanties om te voorkomen dat projecten schadelijke code bevatten.

De community nam ook een motie aan over een verbod op het gebruik van Codeberg-projecten om AI-modellen te trainen. Daarmee legt de gemeenschap in een formele verklaring een standpunt vast dat de organisatie al langer uitdraagt. Codeberg belooft nu officieel dat het gebruikers- en projectgegevens niet zal gebruiken om llm's of andere AI-tools te trainen.

Ook geen cryptovalutaprojecten meer

De community heeft ook besloten om cryptovalutaprojecten op Codeberg te verbieden. Een motie daarover kreeg 306 stemmen voor, 154 stemmen tegen en 34 onthoudingen. Codeberg verbiedt die projecten nu nadrukkelijk in zijn voorwaarden, omdat deze 'de reputatie van Codeberg schaden'.

Codeberg logo

Door Imre Himmelbauer

Redacteur

Feedback • 25-07-2026 11:41
180 • submitter: Jerie

25-07-2026 • 11:41

180

Submitter: Jerie

Reacties (179)

Op een soort meta- of macroniveau vind ik dit interessant. Een partij die het gebruik van AI-/LLM-modellen verbiedt voor projecten die bij haar gehost worden, zorgt er in ieder geval voor dat niet iedereen elkaar blind achterna loopt. Daardoor kunnen we over een paar jaar ook zien wat er gebeurt als je bewust een andere afslag neemt.

Ik snap de beweegredenen, maar tegelijkertijd voelt het een beetje alsof je compilers zou verbieden omdat handgeschreven assembly betrouwbaarder is. Dat was op een bepaald moment ook zo.

Het copyrightargument is valide, en er is ook nog steeds discussie over het eigenaarschap van gegenereerde en geschreven code. Dus als we eerlijk zijn, steken we met z’n allen, nou ja, veel van ons developers, nog wel een beetje onze kop in het zand. In Europa zal er waarschijnlijk steeds meer regelgeving komen, want ik denk niet dat AI zomaar weer verdwijnt.

De meest waarschijnlijke eindtoestand is volgens mij niet dat AI verdwijnt, maar dat het gebruik ervan volwassener wordt: met strengere kaders, duidelijkere licenties, betere bronvermelding en meer onderscheid tussen wat wel en niet acceptabel is. Daarmee verschuift het debat waarschijnlijk van “wel of geen AI” naar “onder welke voorwaarden en met welke garanties”.
Alsof je trein en rails verbiedt omdat paard en wagen nog steeds voldoet.
Misschien helpt het om de beargumentering te lezen. Je kunt met AI coding tools de meest prachtige dingen bouwen in een tempo dat voorheen ongekend was, dat zal niemand ontkennen, maar dit:
Volgens het platform is de auteursrechtelijke status van die tools onduidelijk en bieden ze weinig garanties om te voorkomen dat projecten schadelijke code bevatten.
is gewoon waar. Veel AI programmeurs hebben gebrekkig zicht op wat er daadwerkelijk in hun code gebeurt, waar die code vandaan komt en of er foute dingen in zitten. Handmatig reviewen van de enorme bergen aan code die nu geproduceerd wordt is ook onbegonnen werk. Dan is het niet zo vreemd dat een hosting platform zegt "hier gaan wij geen verantwoordelijkheid voor nemen", want het risico dat ze er op termijn hun vingers aan gaan branden is aanzienlijk.
Maar wees dan consequent. Verbied bijv. ook code die je copy paste van Stackexchange, daar wordt vaak ook niet de licentie bij gezet. En door zo heel generiek AI-tools te verbieden verbied je juist wel weer AI-tools die zich wel netjes aan de regels houden, zoals het aankomende GPT-NL.

Niettemin, het zou mooi zijn als voor coding getrainde modellen specifiek getrained zijn op enkel code met een vrije licentie. Dat je zelfs een keuze krijgt tussen modellen op basis van welke trainingsdata is gebruikt (een model met enkel heel vrije traininsdata, of een model die een wat striktere licentie heeft, bijv. dat code die daarmee gegeneerd wordt ook open source moet worden, etc.).
Met name dat laatste is van belang. Op het moment dat er stront aan de knikker is met projecten gehost op Codeberg heeft het als non-profit niet de middelen zoals Github om het gevecht aan te gaan.
Moeten ze dan een gevecht aan gaan? Ze kunnen ook gewoon een takedown procedure toevoegen. En ja, dat kost ook tijd, maar wat denk je wat er met dit idee gaat gebeuren? Wie gaat bepalen of iets door AI is geschreven of niet? En wat is grotendeels?

Gezien zo ongeveer elk beetje software bedrijf AI gebruikt om software te maken, of op zijn minst bezig is met pilots om dat te doen, ben ik toch heel erg skeptisch of dit nou echt gebaseerd is op juridische angsten, of meer gebaseerd is op anti-AI gevoelens.
Tja je moet een takedown nog steeds vetten, kost ook weer tijd en energie. En dit moet je al omdat mensen gewoon plagieren. Door geen LLM code op het platform te hebben verklein je attack surface voor legitieme en illegitime takedowns. Dat is al waar voor als het huidige aantal projecten voor zoveel % uit LLM code zou bestaan maar bovendien zou met LLMs het totale projecten en de hoeveelheid code in elk project veel sneller toenemen. Dat is voor een kleine organisatie gewoon lastig bij te benen, gewoon marktwerking. GitHub kan door hun positie hun eigen weg inslaan en Codeberg moet een ander niche vinden in plaats van concurreren op een identiek product op een te kleine schaal.
Aan de andere kant: door geen LLM code toe te laten maak je jezelf in een versneld tempo overbodig. Zoals met alles gaat deze ontwikkeling ook volgens de bekende S-curve.
snap hoe dat voor een groot blok mensen irrelevant maakt maar als geheel hoeft het toch niet eenheidsworst te zijn. Als je handgemaakte chocola verkoopt doe je inderdaad niet zoveel nummers en omzet als Nestle maar betekent niet dat er nul interesse in is. Vervult gewoon een andere rol. Misschien wordt het wel heel niche of zelfs retro ofzo of misschien valt het allemaal wel mee.
Dat kan maar dan moet je jezelf niet als alternatief van GitHub presenteren, want dat ben je dan niet meer. Net als je met handgemaakte chocola niet moet beweren dat je dezelfde productie capaciteit hebt als Nestle
Tja je hebt gelijk want k denk ook dat vooral tijdens de eerdere fases van Codeberg het niet heel duidelijk werd gesteld. Inderdaad 'alternatief voor github' of 'github replacement' klinkt alsof je hetzelfde wil doen. Ik was wel op de hoogte van dat het beetje gekkigheid was vanwege de "Github for lesbians" landing-page die ze een tijdje hadden, het was allemaal beetje tongue-in-cheek maar moeten ze niet verbaasd zijn dat anderen het letterlijk overnemen en mensen het zonder context voorgeschoteld krijgen. Codeberg wil kennelijk heel erg niet GitHub zijn maar Git functionaliteit bieden voor mensen die moe zijn van GitHub, ze willen (naar mijn weet) alleen pariteit voor Git en dan verder expres zoveel mogelijk anders doen... en hun communicatiestijl is tot nu toe erg slecht geweest dit idee over te brengen. De insteek is dus de technische gereedschappen bieden om GitHub te verlaten omdat het niet-technische er omheen van GitHub niet bij je zou passen. Maargoed de scheve marketing werkt voor hun want nu heeft iedereen het over Codeberg zelfs al is het meer richting 'outrage', er is geen incentive om dus duidelijker of eerlijker te zijn net zoals elk andere commerciële partij in de software wereld, ben ik 8)7 ze ook niet dankbaar voor maargoed.

Ik kijk er denk ik minder van op omdat ik al veel langer (9 jaar?) mensen zag met privé of ~3 gebruiker Gitea instances zag ook voordat LLMs zo aan GitHub verbonden waren. Veel van deze mensen hadden de ergenis dat voor sommige type samenwerking ze niet om GitHub heen konden, beetje zoals Microsoft Office (software zelf of bestandsformaten) vaak je leven/workflow binnenstromen als een overstromende rioolput. Dus die hadden dan selectief hun projecten al verdeeld over self-hosted en GitHub. Er waren vroeger ook andere populaire FOSS hosters of rehosters en menig Tweaker artikel over hoe ze officiële installers wrapte met adware of spyware naarmate deze van eigenaren wisselde. (Zelf was ik als student heel blij met Bitbucket maar daar zijn ook 1000 kleine cuts geweest dat ik zoveel mogelijk heb verwijderd nog voor LLMs uberhaupt in the picture waren.) Ik denk dus vooral dat mensen hopen een verenigingsvorm te vinden die bestand is tegen enshittification, idee (geloof) dat een co-op of andere owership structuur er beter tegen opgewassen zou zijn. Maar Codeberg is nog te jong voor enshittification dus nu lijkt het gras sowieso super groen.

Op een gegeven moment loop je tegen de paal aan of je het omgekeerde wil doen van GitHub omdat je hoopt (maar niet weet) dat dit enshittification voorkomt of dat dit gewoon de logische industriestandaard manier was van een bepaald probleem op te lossen en nu schiet je iedereen in de voet. Codeberg trekt nu een aantal mensen aan die genuanceerd over features en ecosystemen denkt maar ook een veel grotere groep met 'sports team' mentaliteit dus als je dan niet alles zwart wit anti-GitHub uitspeelt en uitbouwt zijn die weer ontevreden maar als je kern (repo/issue-tracker) te verschillend wordt van GitHub dan kan je weer niet groeien met nieuwe gebruikers die willen overstappen naar iets wat ze behappen. Ik denk dat die tweestrijd die jij aanstipt eigenlijk een grote overhead voor governance van Codeberg gaat worden. Verwacht zelf dat met name projecten waar mensen brood op de plank brengen niet zitten te wachten op dit soort onzekerheid.

[Reactie gewijzigd door Abbu-kun op 26 juli 2026 10:41]

Als je handgemaakte chocolade uiteindelijk niet beter, lekkerder is dan die industriële (bij chocolade is dat vaak wel lekkerder handgemaakt maar kom) dan ga je jezelf exht wel oveebodig maken. Buiten voor een mini niche haters of zo.
tja een groot deel van boutique voedsel verkopen is een verhaal er bij spinnen, gaat een aantal codeberg projecten ook wel lukken. Soms zijn bepaalde producten best wel midden segment of fungible maar heb je een mooi verhaal over hoe je biodynamische boerderij al 300 jaar in dezelfde vallei zit blablabla. Denk dat Codeberg dat soort mensen wel nu even aantrekt en die zullen elkaar dan wel vinden.
Maar controleren of code door een LLM is geschreven kost net zo goed tijd en energie. En het is dus niet dat je geen LLM code mag hebben, alleen niet grotendeels.

Gezien hoe snel AI gebruik in software groeit, is dit volgens mij meer jezelf richting irrelevantie duwen. Je bent al de kleine partij, maar goed je zet je naar als de Europese partij, alleen dat moet blijkbaar ook gecombineerd worden met gaan bepalen wat wel en niet mag qua coding. En natuurlijk ook Github heeft zo zijn limieten waarnaar het verwijderd wordt. Maar bij Codeberg vinden ze wel heel snel dat het aan hun is om te bepalen of iets wel of niet mag. (En natuurlijk het is hun platform, dus dat mag, maar of het goed is voor de levensvatbaarheid van het geheel? Ik heb mijn twijfels).
Ja het klinkt niet heel uitvoerbaar maar meer 'stok achter de deur' om bepaalde projecten de laan uit te sturen als ze stront aan de knikker richting Codeberg rollen. Maar dat is ook een probleem want dan wordt het dus niet eerlijk enforced of je kan een soort 'witch hunt' krijgen waar bepaalde projecten veel strenger worden doorgelicht omdat iemand een ander motief heeft dat project niet op codeberg te willen zien. Er zijn een miljoen manieren dat dit initiatief fout kan gaan, en met alle extra aandacht er op denk ik dat opvolgende stemrondes voor praktische uitvoering nog eens heel moeizaam kunnen gaan worden. Ik vind zelf het voornemen op dit moment wel positief voor Codeberg maar je hebt helemaal gelijk dat er allemaal pijnpunten, haken en ogen zullen zijn.

Niches zijn altijd minder relevant dan het grootste marktsegment. Of het onderhoudbaar is is lastig te zeggen. Ik denk dat fundamenteel veel niche projecten (niet alleen code hosting) op lossere schroeven staan dan voorheen omdat cloud billing door het dak kan gaan en vervangskosten van RAM en zelfs oudere datacentertier HDDs gewoon een continuiteitsrisico zijn. Ik denk dat kleinere resellers opgeslokt gaan worden of gaan stoppen en niet iedereen kan mee met de duurdere hostingvoorwaarden van een vervangende partij. Maargoed de vraag is dus is het belangerijker dat Codeberg in wat voor vorm dan ook bestaat, of is het prima als Codeberg een specifieke missie koos en door ongelukkige keuzes het werk later neer moet leggen? Ik snap dat met aandeelhouders het bestaan en verkoopwaarde van zo'n bedrijf wel voorgaan maar misschien voor Codeberg niet. En er zijn zat for profit bedrijven die met 20/20 hindsight onhandige keuzes hebben gemaakt en opgedoekt worden door zichzelf of een curator.

Als dit is wat Codeberg later de nek omdraait vind ik dat wel prima, ze hebben iets anders geprobeerd omdat mensen beweerde dat ze iets anders wouden. Als dan blijkt dat ze het toch niet zo graag willen of het niet kunnen subsidieren op die schaal is dat een droevige les maar weet je ook dat het een beetje 'gras is groener' verhaal was. Ik zat op een social media platform wat gewoon de handoek in de ring gooide: Cohost. Was heel pijnlijk ook met hoe kort de tijdlijn voor mij viel tenmidde van persoonlijke omstandigheden. Maar heb ook wel respect dat ze niet in een soort 'meer mainstream features, meer extern kapitaal' deathspiral belandde van enshittification. Tis jammer dat Cohost er niet meer is maar ze zijn teminste tenondergegaan op een positieve noot en waar ze zelf voor stonden. En dat klinkt natuurlijk weer verschrikkelijk voor mensen die zakelijk naar dingen kijken.
Er is geen programmeur meer die geen AI gebruikt. AI is gewoon heel handig en snel. Als je goed kan prompten en de resulterende code ook goed naleest is het tegenwoordig ook vaak beter dan een mens kan doen. Dat betekent niet dat een iedereen nu kan programmeren of dat een slechte programmeur nu ineens een top programmeur wordt. Ook prompten en stap voor stap een basiscode uitbreiden en controleren is immers een kunst.

De kans dat Codeberg de beslissing terugdraait of ten onder gaat is dus groot. De kans dat er massaal AI code door de controles glipt is natuurlijk veel groter.
Ik hou ook van hyperbool maar je snapt toch ook wel dat er genoeg mensen zijn die die tools niet gebruiken? Er zijn al decennia lang feuds over EMACS of VIM of linux distros of subysystemen in meerdere distros. Soms zie je mensen daar over de haren vliegen maar eigenlijk krijg je automatisch verzuiling. In het Engels heb je 'social media bubble' of 'filter bubble' maar vind 't Nederlandse verzuiling eigenlijk beter omvatten.

Ik geloof meteen dat het aantal mensen waar jij mee in aanraking komt dat het helemaal niet gebruikt nihiel is. Maar er zijn mensen die de eerste zin van jou comment lezen en meteen blocken of in iedergeval niet doorlezen laat staan reageren, het is zelf selecterend. (Verder zijn er mensen die gewend zijn om zonder AI te werken en niet snappen waarom je het wel/niet gebruik van de daken zou schreeuwen.) Het is heel duidelijk op de werkvloer welke type ontwikkelaar de voorkeur heeft dus ben het met je eens met het idee dat het een hele niche groep gaat worden. Maar net zoals jij zonder veel moeite AI gezinden kan vinden om ideeën uit te wisselen kunnen mensen kringen bouwen met omgekeerde insteek. Tweakers heeft zijn eigen voorselectie op AI interesse dus dan hoef je ook niet te veel interacteren met mensen die het liever links laten liggen.

Inderdaad dit is een van de grote beslissingen waarmee Codeberg gaat zinken of drijven. Ik denk inderdaad dat het meest zelfvernielende gaat zijn om de uitvoering in bedwang te houden. Moderatie is al lastig genoeg, moderators bij-trainen kan niet op schaal want value-drift. En user sourced reports kunnen ook misbruikt worden. Te agressief en het wordt zelf een witch-hunt wapen, te laks en je infra overstroomt nog steeds met LLM content, met als nadeel dat je geen schaalbare tools hebt gebouwd omdat je dacht dat het al uitgesloten was. Er is een gedeelte van Codeberg gebruikers die het prima vind dat Codeberg een missie kiest en kan falen maar er zullen ook wel andere zijn die continuïteit belangrijker vinden, de vraag is weten ze dit wel van elkaar en kunnen ze er beschaafd over praten? Kan nog een heel fork/resignation debakel worden.
Ik ben al gestopt met programmeren voordat AI in opmars raakte. Ik doe alleen nog wat privé voor een Arduino or Raspberry, al ontbreekt me daar zelfs de tijd meestal voor. Mensen die voor mij werken gebruiken allemaal wel AI tools, al is het soms maar voor kleine snippets of het opzetten van een basis.

Wie AI niet gebruikt is tegenwoordig gewoon een dief van zijn eigen tijd. Ik weet dat er nog steeds programmeurs zijn die het gebruik van AI vloeken in de kerk vinden, maar zeker voor eenvoudige routines bespaart het zoveel tijd. Desnoods gooi je er een routine in die door een klein tikfoutje niet werkt. AI lost dat veel sneller op dan dat een programmeur het überhaupt door kan lezen. Het gebruik van AI tools blijft wat mij betreft wel gewoon programmeren. Zonder kennis van programmeren lukt het je niet om in een prompt goed aan te geven wat je wilt, welke parameters je meegeeft en welke eruit moeten komen.
Ja dus dan is dat prima voor jou want je werkomstandigheden of persoonlijke interesses betekende al dat je niet wil programmeren of in ieder geval code schrijven toch? Als andere dingen belangerijker of prettiger voor je zijn dan is een aanpak waar je geen code schrijft prima. Je wordt niet gekrenkt omdat je niet aan het code schrijven bent zoals menig tekenaar of schilderaar wordt als ze niet aan hun passie toekomen. (En he er zijn zat mensen die dat alleen maar deden voor geld i.p.v. passie en toch betekent het niet dat de andere groep niet blijft voortbestaan.)

Maar als iemand als hobby van kalligrafie houd dan is het niet heel logisch om te zeggen doe maar op een typmachine. Misschien heeft die persoon zelfs al een typmachine voor iets anders maar dan is het niet logisch voor hun hobbytijd. Als je het heel leuk vind om je eigen deeg te maken en pizzas te beleggen en zelf op een pizzasteen bakken of zelfs een pizzaoven bouwen dan heb je ook niet zo veel aan iemand die je een abonnement op diepvries pizza aanbeveelt. Terwijl dat helemaal perfect klinkt voor iemand die alleen maar pizza wil eten. Gaat er om waar je blij van wordt in het proces. Er zijn borduur en breimachines maar mensen doen nog steeds handwerken voor naasten of verkoop aan mensen die daar weer blij van worden. En dat is ook allemaal niet even rationeel, sommige dingen 'op de oude manier gemaakt' zijn gewoon fungible met de fabrieksversie het is niet automatisch beter maar mensen vinden het idee/verhaal er omheen in hun hoofd fijn, het is onderdeel van hun beleving en de waarde die ze aan het (aanschaf)proces verbinden.

Als je blij wordt van wat een programma doet nadat het build/runt is het prima. Klinkt alsof je nog wel fijn vind om op hoger stategisch niveau problemen op te lossen, wat ook (voor LLM tools) aansluit bij bijvoorbeeld het idee van Wolfram producten. (voorbeeldje: dat het systeem zelf heuristieken had welk sorteer algoritme past bij je dataset/workflow. Of dat Wolfram Alpha probeerde met natuurlijke taal te werken in plaats van exacte query's of code statements. En natuurlijk andere producten die 'code free' spaghetti nodes verkochten. ) Helpt inderdaad enorm als je het '1 laag dieper kent' zodat als er wat mis gaat je er omheen kan werken, als je weet wat sorteer algoritmen zijn en dat je soms beter kan kiezen dan zo'n heuristiek. En dat klopt ook wel voor specificaties schrijven, naar mensen of naar LLM tools.

Maar er zijn ook mensen die blij worden van het code schrijven zelf. Dat je het niet zitten in een bedrijfssetting snap ik ook wel en iedereen heeft wel meer interesses dan vrijetijd dus je kan je er niet goed bij voelen anders te kiezen dan je nu al doet. Zo behaal je meer voldoening door een saai ding uit de tijd van de dag te knippen maar voor iemand anders is het leuk, waarom zou je het overslaan? Als je graag zelf kruiswoord puzzels oplost is het best saai om te zien hoe een computer het doet. Als je zelf graag logische problemen systematisch oplost is het misschien juist leuk als je ziet hoe een computer programma stapsgewijs een kruiswoord oplost. Als je alleen maar opgeloste kruiswoord puzzels wil dan is dat inderdaad zonde van je tijd en laat je iemand anders of iets anders zoals een tool het lekker doen. Net zoals dat jij prompten nu nog wel leuk vind zijn er ook andere mensen die het prompten ook te veel irritant werk vinden en manieren zoeken dat te automatiseren.

Dan komt het prompt op het niveau van iemand die niet weet wat algoritmes zijn (buiten dat facebook 'een algoritme' heeft) en niet echt weten wat werkgeheugen of een CPU is behalve dat het geld kost en nooit van variabelen, datastructuren, processen of threads in een programmeertaal hebben gehoord. En misschien werkt dat straks goed genoeg dat je het ook wel voor iets kan gebruiken maar kan ook zijn dat jij of andere mensen die graag technischer prompten daar weer niks aan vinden. Jij weet hoe je jezelf graag uit wil drukken en weet of dat door het medium van programmeren zal zijn of niet maar het is een rare stelling om te zeggen dat niemand anders zich hoort uit te drukken in code. Ik ga ook geen gekke dingen roepen naar iemand die zit te breien omdat ik mijn tijd anders gebruik en machinale sokken draag.
Ik kan me voorstellen dat mensen van het zelf code schrijven heel blij worden en dat het een voldaan gevoel geeft, maar het is niet meer van deze tijd.

Zelf ben ik lang datamanager en statisticus geweest en heb diverse modellen geschreven of daaraan meegewerkt. Ik weet dus wat algoritmes zijn. Ik heb nog geprogrammeerd voordat de eerste PC's (IBM) op de markt kwamen en toen moest je met een minimum aan geheugen dingen doen die eigenlijk niet konden met een processor die niet heel veel beter was dan die van een rekenmachine.

Wie gelukkig wordt van het zelf schrijven van code moet dat vooral blijven doen, maar het programmeren is aan verandering onderhevig. Er zijn diverse talen bij gekomen en nu AI als hulpmiddel.
Misschien dat m'n koffie niet zo goed werkt door slapen in het warme weer maar hoop dat ik met mijn vorige bericht niet de suggestie heb gemaakt dat je niet zou weten wat een algoritme is :+ excuus. Mijn speculatieve punt was eerder dat LLM ontwikkelingen zo door kunnen gaan dat mensen met onze achtergrond ook gewoon worden vervangen door een MBA, wealth manager, of wat dan ook die veel minder technisch hoeft te prompten.

Immers alle handjevast prompts, harnasses en workarounds voor (oudere zwakkere) LLMs op het spoor te houden kunnen weer opgezogen worden voor een nieuw LLM product om de mensen die nu nog brood op de plank brengen met prompten weer er uit te ellebogen. Daardoor zie ik voor mijzelf persoonlijk dus weer weinig impuls om nu beter leren te prompten of workflows rond LLMs te bouwen als daar bovenop de prijs zo onderhevig is aan willekeurige handelsconflicten of het energienet en DC buildouts zo rommelig of speculatief gaan worden. Als iemand voor een 100 euro per maand 1 of meer 'prompt engineer' (maar maakt niet uit welke titel je echt hebt) de laan uit kan sturen doen ze dat nu gewoon, zelfs als de LLM prijs later 300% kan stijgen.

Zelf wat te jong om die 16 of 640kb RAM tijden mee te maken maar had wel een ouder Basic boek van mijn ouders overgenomen.
Laten we het erop houden dat AI slechts een tool is die programmeurs kunnen gebruiken, maar dat het voor serieus programmeren geen vervanging is. Zelfs met AI is zeker nog kennis van programmeren nodig.

Voor hobby projectjes met een Raspberry of een Arduino werken AI tools als Claude best aardig, maar zodra het script voor een Arduino ingewikkelder wordt zit je al snel tegen geheugenbeperkingen aan te hikken en wordt het toch weer als vanouds programmeren.
Ben je erg skeptisch?
Alles in dit artikel schreeuwt toch gewoon anit-AI gevoel in een juridisch sausje?

Ze weigeren software 'die voornamelijk bestaan ​​uit code geschreven door generatieve AI-tools'
Dat is toch volkomen onhoudbaar? niet duidelijk en dus niet toepasbaar? Dat maakt direct duidelijk dat het een volledig niet-rationele beslissing is. En als slechts 1% van de code gejat zou zijn (het juridische argument), dan is dat voldoende om gedoe over te krijgen. Ofwel... allemaal bulls**t

Daarbij: hoeveel van de code van een project wordt zelf geschreven? Een gemiddeld python project? Hoeveel packes van derden worden gebruikt? Soms heb ik 1000 regels code geschreven... en maak ik gebruik van 10 packages met ieder 10k code. En al die packages zal AI worden verwerkt, omdat - zoals je zegt - AI inmiddels overal wordt gebruikt...

Al met al... een onzinnige keuze... Ik zou zeggen: good luck! (ze zullen het nodig hebben).
Overigens ben ik wel benieuwd hoe ze hier over een jaar in staan...
Ik word persoonlijk een beetje moe van hoe altijd per direct alle kritiek op AI of regels die AI inperken als "anti AI" gevoel worden weggezet. Open source projecten mogen toch nog altijd zelf beslissen of ze bepaalde tooling wel of niet toelaten? Net zoals we bij elke AI tool zelf beslissen of we willen dat het model getrained wordt met de data die je het geeft. Of valt het uitschakelen daarvan ook onder anti-AI, gezien het AI beperkt?

Ze stellen nu regels hiervoor op en daar zul je het toch mee moeten doen als je het wil gebruiken, net zoals de overige regels die ze al hadden. Ze zijn in ieder geval niet de eerste en ook zeker niet de laatste die AI weren uit hun project/community. Er zijn de laatste tijd al meer projecten gemoved van Github naar Codeberg omdat Github zwaar AI gebruik pushed.

Ze zijn dus ook zeker niet de eerste die de risico's van AI zien en niet alleen maar het positieve. Dat is gewoon kritisch nadenken en een standpunt innemen. Het is ook niet dat dit standpunt door één persoon of bedrijf is genomen. 358 stemmen, dus de community heeft besloten.

[Reactie gewijzigd door Powerblast op 25 juli 2026 16:23]

Ze mogen zeker zelf beslissen, maar wij mogen ook zelf onze mening daarover hebben. Mensen die klagen dat ze daar moe van worden word ik moe van.

Ik denk ook dat het gewoon anti ai gedrag is. Maar dat moeten ze zelf weten. Maakt ze voor mij irrelevant ik zal een ander alternatief voor GitHub moeten vinden. Want ik vind dat zij niet bepalen hoe ik code schrijf als hoster. Dat is aan mij. Zolang de code niets illegaals doet of zo.
thx voor je perspectief.
Persoonlijk wordt ik ongelofelijk moe van het anti-AI sentiment hier op Tweakers. Het woord 'bubbel' lees ik ongeveer 20x per week. 'Hype' zo'n 13x en 'circulaire investering' 12x per week.

Laatst schreef iemand dat de AI-hype jaren duurt. Daarop reageerde ik dat in de definitie van hype besloten ligt dat het kortdurend is. Maar ik was de enige die dat een slimme opmerking vond : (

Maar ik snap je punt. Ik schiet door in mijn anti-anti-AI. Ik reageer sowieso dwangmatig op anti-AI.

"Open source projecten mogen toch nog altijd zelf beslissen of ze bepaalde tooling wel of niet toelaten?"

Zeker! En ze mogen het wel toelaten. Of niet toelaten. Of een beetje toelaten. Of wel toelaten, tenzij je de tooling 'meestal' gebruikt. Want als je het 'meestal' gebruikt, is het niet goed. 'Soms'... is ok. Maar 'meestal' niet. Dus prima als 300 stemmers zeggen: 'soms' is okay, 'meestal' is niet okay. Ik ga daar niet echt over... Dus helemaal prima. Het klinkt ook heel doordacht....
Dat ze AI weren uit hun project, dat is hun keus.
Maar ze willen ook dat AI geweerd wordt uit projecten van anderen die bij hun gehost worden. Dat is toch wel een stap verder.
Als er over een jaar op meerdere plekken in de wereld meerdere juridische uitspraken zijn die zeggen dat het geen plagiaat is, dan zouden ze best wel weer terug kunnen gaan naar het oude model.

Anders is het wachten tot het fout gaat en jij de sjaak bent als kleine organisatie voor een juridisch gevecht. Als je 500 euro per maand te besteden hebt aan je legal afdeling bij wijze van, dan kun je het risico gewoon niet nemen.
nee joh...
Het juridische argument is een onzin argument.

Als je LLM's een juridisch probleem vindt... dan moet je LLM's verbieden... En niet een beetje verbieden en een beetje toestaan...
Als je LLM’s in zijn geheel verbiedt dan mag niemand nog een IDE gebruiken, want elke IDE verkoopt tegenwoordig basis code generatie zoals getters en setters en code line completion ook als AI aan, omdat het beter klinkt. Hiermee laten ze daarvoor alvast nog ruimte.

Ik zie persoonlijk het juridisch element wel steek houden. Je zou enkel over het woord mostly kunnen vallen, maar verder houdt het steek vanuit een non profit perspectief. Als je perse AI wil gebruiken mostly ;), dan is Github een betere plaats om dat te doen. Die raden het zelfs aan en geef je liefst ook je code weg om het model te trainen.

[Reactie gewijzigd door Powerblast op 25 juli 2026 17:58]

LLM != AI, ze kunnen rustig LLMs verbieden zonder dat dat impact heeft op een lokaal AI model die wat code completion doet. You n bij zaken als automatische getters en setters komt niet eens AI om de hoek kijken (tenzij je een AI first IDE gebruikt).
Heb je gelijk in :), maar omdat de comment boven met met LLM verder ging, ging ik er even in mee. Het gaat natuurlijk over veel meer dan dat alleen. Codeberg heeft het zoals ik zie ook over de ruimte verwoording AI.

Getters en setters zijn inderdaad een verkeerd voorbeeld. Maar dergelijke features worden wel vrolijk door IDE fabrikanten onder de noemer AI geplaatst. Zo loopt het percentage van de code die door AI wordt gemaakt vrolijk op, terwjil er natuurlijk niks speciaal aan is. Line completion is denk ik dan een beter voorbeeld, dat werd vroeger toch ook al een stukje context based opgelost volgens mij. Nu met AI natuurlijk betere voorspellingen, maar als je dan een lijn accepteert, is dit dan een lijn die door AI geschreven is of heb je dit manueel gedaan?
"Je zou enkel over het woord mostly kunnen vallen"

Juristen kunnen over elk woord vallen, daar zijn het juristen voor.
Maar het woord "mostly" is juridisch gezien natuurlijk een grap... wat alles vervolgens lachwekkend maakt.

Verdachte: "Maar rechter, ik heb me meestal prima aan de wet gehouden!"
Rechter: "oh, gelukkig... dan is alles goed!"
Die zijn er al. Een LLM is geen persoon en kan dus geen copyright houden. En leren van wat er voor is gekomen doen alle mensen ook en is dus geen plagiaat. Je mag iets niet verbatim overnemen, maar de implementatie van standaard algoritmes komen bij definitie vaak overeen. 1+1 is gewoon 2 dat is in code niet anders. Elke webserver software doet hetzelfde en de code lijkt op elkaar, want http is een standaard die ze implementeren. En iedereen mens of LLM leent van het internet. De LLM is er alleen beter in.
Ben je erg skeptisch?
Alles in dit artikel schreeuwt toch gewoon anit-AI gevoel in een juridisch sausje?
Ik weet het niet. Uiteraard is er angst voor verandering, en om de publieke opinie te sturen, worden heel veel zinnige en onzinnige dingen op een hoopje gegooid.

Ik denk dat velen momenteel aan het zoeken zijn hoe we hier nu best mee omgaan. Behalve de mensen die niet mee willen veranderen, is er eigenlijk geen grondige reden om tegen deze vooruitgang te zijn. Ik heb zelf de analoge fotografie-tijd niet meegemaakt, maar ik ben meegegroeid met de evolutie in Photoshop en de nieuwe AI functies zijn gewoon handig. Een muzikant zal dat misschien hebben met de evolutie van klassieke instrumenten naar synths, en nu naar AI tools. Geen idee of Pogacar dankzij AI nu sneller Alpe d’Huez op fietst, maar ik heb daar geen probleem mee.

Hetzelfde voor programmeurs. Mijn respect of vertrouwen verandert niet door de tools die ze gebruiken (heel eerlijk: ik heb nu ook al geen idee wat er gebruikt wordt, en van op een afstand lijkt het me alleen maar nuttig).

Wat al de bovenstaande mensen verbindt, is dat ze hun vak kennen/weten wat ze doen (de ene al wat beter dan de andere, maar steeds naar best vermogen).

Maar waar ik (en volgens mij ik niet alleen) over struikel, is hoe AI de volgende stap lijkt te zijn waar onze maatschappij overspoeld wordt door mensen die eigenlijk niets kunnen. De AI slop die je overal ziet verschijnen, is gewoon een evolutie van de crap die we daarvoor al kregen, maar heeft er wel een turbo op gezet. Al die andere dingen (plagiaat, etc.) zijn zeker ook relevant, maar zijn niet de kern van het probleem (namaak is niets nieuws).

Denk ik dat deze maatregel een goeie is? Meh, ik denk dat het verkeerd is uitgedrukt. Ik denk niet dat wat ze willen pure anti-AI is, het is anti-slop volgens mij. Waar de slop tot nu toe beheersbaar was, lijkt het dat met AI niet meer te zijn. En we weten niet hoe we daarmee om moeten, dus verbieden lijkt de makkelijkste oplossing.

Het probleem is dat het net bij de verkeerde mensen aankomt: wie competent is denkt “dit helpt mij vooruit, waarom mag ik het niet gebruiken?”, wie incompetent is, denkt niet en heeft hier dus geen last van.

Nog een anecdote: Onze global supply chain director ging een aantal maanden geleden op pensioen. Eén van zijn direct reports (dus ook een hoge directeur huppeldepup) gaf een speech waarin ze aangaf dat hij had gezegd “we moeten meer doen met AI”. Na een lange vergadering met het team, hadden ze dat gedaan: ze hadden voor hem een liedje gemaakt met AI. De beste man liet een traan, en ik ben er zeker van dat meer dan 80% dacht dat hij geëmotioneerd was.
"Ik denk dat velen momenteel aan het zoeken zijn hoe we hier nu best mee omgaan...."

Eens... En de techniek staat natuurlijk pas aan het begin. Dat maakt het extra lastig om een goede manier te vinden om ermee om te gaan.

"De AI slop die je overal ziet verschijnen, is gewoon een evolutie van de crap die we daarvoor al kregen, maar heeft er wel een turbo op gezet."

Tsja... dat deel zie ik niet. Ik zit niet op social media. Ik beschouw social media in zijn totaliteit - met en zonder ai - als 'slop'.

"Ik denk niet dat wat ze [codeberg] willen pure anti-AI is, het is anti-slop volgens mij."

Maar als ik een demo in elkaar zet met AI, om daarna aan een team te presenteren om te laten bouwen. Dan zou dat niet mogen. Voor mij is dat onbegrijpelijk. Volkomen irrationeel vanuit elk oogpunt.

"Maar waar ik (en volgens mij ik niet alleen) over struikel, is hoe AI de volgende stap lijkt te zijn waar onze maatschappij overspoeld wordt door mensen die eigenlijk niets kunnen."

Helemaal mee eens. En dat geldt vanaf de uitvinding van de boekdrukkunst.... die het 'monnikenwerk' overbodig maakte.
... En de kruisboog, die het schieten ook sterk vergemakkelijkte itt een reguliere boog. Jaren oefenen... werd een paar maanden oefenen.
... en ga zo maar door.

wat je zegt... ai zet het op turbo.

---

Waar ik zelf het meeste over struikel is het psychologische aspect. Nu al hoor je veel mensen die een AI vriendje of vriendinnetje hebben. Hoe gaat je brein hiermee om? Het is een soort psychologische porno. Bij visuele prikkels maakt het voor je brein ook nauwelijks uit of iemand in het echt voor je staat... of op een beeldscherm. De neurologische mechanismes zijn hetzelfde. Hoe gaat dat werken bij het chatten met AI? Geen idee. Wel weet ik dat het voor veel kwetsbare groepen een lastige tijd wordt mbt ai. Naast social media verslaving en porno verslaving... zou dit zomaar een derde bron van zorg kunnen zijn...

Maar goed... die discussie is ver verwijderd van CodeBerg....

---

p.s. leuke anecdote! die ga ik onthouden :)
Goed die demo die je even in mekaar gedraaid hebt hoeft dan ook niet op codeberg, zeg maar het is voor hun een net negative om dat voor je te hosten. Je kunt die net zo goed nog een keer prompten de volgende keer dat je wat nodig hebt. Daarbij GitHub lijdt ook gewoon onder de enorme hoeveelheid repos die er bijkomen, het is voor hun eigenlijk ook niet interessant natuurlijk om al die agent zooi te hosten.
"Goed die demo die je even in mekaar gedraaid hebt hoeft dan ook niet op codeberg"

Het hoeft idd niet... Je kunt ook alles op je harde schijf laten staan... dat werkte vroeger ook prima....
Maar wat nu, als we binnen ons bedrijf een iets andere werkwijze hebben dan jij voor ogen hebt? En wij - ook met demo's - git gebruiken?

"Je kunt die net zo goed nog een keer prompten de volgende keer dat je wat nodig hebt"

Huh? Jij weet wat voor demo's en POC's ik maak?
Je neemt aan dat die in 3 tellen met een paar prompts gereed zijn?

"het is voor hun eigenlijk ook niet interessant natuurlijk om al die agent zooi te hosten."

Kan zijn... het kan ook zijn dat ze wel dolgraag die code willen hebben, inclusief de interactie die een programmeur heeft met de llm, waarbij gemonitoord kan worden wie wat commit (met feedback loop).

Wat natuurlijik wel problematisch kan worden is dat het aantal commits met factor 10 hoger wordt. Van ongeveer 19 miljoen commits per week voor de opkomst van AI-agenten naar 275 miljoen per week in 2026.

Maar goed... dat is een heel ander probleem dan dat CodeBerg benoemd...
Wat het lastig maakt is dat niemand kan voorspellen welke kant dit op zal gaan juridisch gezien. Op dit moment is de halve wereld bij de vleet en op ongekende schaal elkaars huiswerk aan het kopiëren, en de huidige wetten en het huidige toezicht zijn er totaal niet op berekend om hiermee om te kunnen gaan. Daarom dat vooralsnog iedereen vrolijk z'n gang kan blijven gaan zonder grote consequenties.

Het kan haast niet anders dan dat de wetten omtrent auteursrecht op de schop moeten gaan. Hoe dat er precies uit moet komen te zien en wat de gevolgen op lange termijn gaan zijn, dat weet niemand. Dus is het niet zo vreemd dat sommige bedrijven voorzichtig zijn, vooral diegenen die er als eerste op aangesproken gaan worden zodra er wél gehandhaaft wordt.
Sorry maar dat deed de wereld al jaren, alleen het tempo was lager. Iedere persoon die een http server bouwde maakte code die leek op die van een ander. Http is nou eenmaal een standaard.
Goed punt. En dit werkt twee kanten op. Aan de ene kant loop je het risico dat een LLM werk gebruikt waar jij de rechten niet op hebt. Maar aan de andere kant zal het ook erg moeilijk zijn om je eigen werk te beschermen als dat gegenereerd is.

Dit geldt misschien ook wel voor patenten/octrooien en ander intellectueel eigendom, maar in ieder geval voor copyright. Je kunt gegenereerde code (verhalen, afbeeldingen, films, etc.) niet claimen als je eigen werk, denk ik. IANAL.
Aan de ene kant loop je het risico dat een LLM werk gebruikt waar jij de rechten niet op hebt.
Is niet hoe het werkt. De jurisprudentie is inmiddels dat de training fair use is. De LLM maker moet de input eenmalig kopen, dat is alles. En er is sowieso geen ketenaansprakelijkheid. Jij kunt niet zien op welke exacte input jouw output gebaseerd is, laat staan wat het auteursrecht daarop was.
Okee, dat is prima dan. Maar hoe zit dat de andere kant op? Ben ik copyright-wise de eigenaar van een codebase die door een LLM geschreven is? Zelfde vraag voor andere type werken.
Dat hangt af van het detail nivo van je instructies. Zijn je instructies gedetailleerd dan heb je copyright. Het LLM is dan net een compiler, en doet een vertaling van de ene taal naar een andere. Maar alleen high-level? Dan is er geen copyright en dus ook niet de vraag van wie dat is.
Je kunt er als bedrijf overigens beter vanuit gaan dat je copyright erg moeilijk te verdedigingen zal zijn, zodra het model een "beslissing" heeft gemaakt kun je al weer een moeilijkere casus hebben. En het aantonen dat het echt allemaal tot in detail geprompt is is sowieso heel erg lastig.
Rechtzaken werken anders, verdedigen is de makkelijke kant. De klager moet de aanklacht bewijzen.
Rechtzaken werken anders, verdedigen is de makkelijke kant. De klager moet de aanklacht bewijzen.
In mijn hypothetische geval heeft een derde partij "jouw" gegenereerde code gekopieerd en dus ben jij de klager die moet bewijzen dat je daadwerkelijk copyright hebt op het gekopieerde.
Die derde partij kan op z'n minst proberen te claimen dat zij toevallig dezelfde code gegenereerd hebben door het gebruik van soortgelijke prompts. Of in ieder geval dat er op dat moment geen copyright op de code kan rusten, zodra je aantoonbaar op (ongeveer) dezelfde code kunt uitkomen.
Daar kun je de jurisprudentie over source code en binary gebruiken. Heb jij je prompts netjes bewaard? Dan is dat net zoals source code bewijs van de oorsprong. En zijn die prompts gedetailleerd genoeg om onder copyright te vallen?
Nee, ik ga niet in je gedachtegang mee. Een prompt is een veel hoger niveau van abstractie. De kans dat jij en ik toevallig dezelfde prompt gebruiken "schrijf code dat XYZ doet" is veel groter dan de kans dat we dezelfde code schrijven.
Als je prompts inderdaad zó gedetailleerd zijn dan kun je bijna niet meer van abstractie spreken maar gewoon van programmeercode die getranspiled wordt. En dán is source code-binary een goede analogie. Ik ken niemand die op dat niveau prompts schrijft. Defeats the purpose een beetje.

Daarnaast, of een rechter meegaat met dat soort jurisprudentie betwijfel ik in elk geval. We leven in een nieuwe wereld met AI, dus oude jurisprudentie is de deur uit volgens mij.
"Schrijf code die XYZ doet" is inderdaad een goed voorbeeld van een niet-beschermde prompt. Die legt alleen een doel vast en is niet creatief. "Refactor deze loop body naar een aparte functie" is dan weer het andere uiterste. Dat kan een LLM prima, maar voor sommige talen waren er tools die dat al konden.

Ergens daartussen moet dus een grens liggen. En de jurisprudentie is dat de lat vrij laag ligt. Bij foto's is de keuze waar je de foto neemt bijvoorbeeld al voldoende.
Je doet nogal wat uitspraken die op z'n minst om een bron vragen en verkoopt ze als de waarheid. Ik heb sterke twijfels over de juridische kant van "mijn prompt was drie karakters te kort, nu kan ik geen copyright claimen". Over welke jurisprudentie hebben we het dan? En welke data moet er gekocht worden? Bij wie? Heb ik als particulier invloed op of ik in die data voorkom?
Dat heet dus een "strawman" argument. Je telt niet de letters in een prompt dus jouw "3 karakters te weinig" is geen argument.


Wat betreft trainingsdata, als jij erin voorkomt is dat vrijwel zeker een feit (jij bent geen fictief personage). Feiten vallen niet onder het auteursrecht.
Jij beweert dat copyright te maken heeft met de grootte van de prompt, zonder ook maar een bron of jurisprudentie te noemen en gaat vervolgens de discussie aan alsof het een debat is. Ik vroeg om die bronnen en hoopte met mijn "drie woorden" aan te geven dat dat gewoon onhoudbaar is en op geen enkele manier juridisch is te verdedigen. "Edelachtbare, mijn cliënt heeft echt goed nagedacht over de prompt, de code is van hem".

Als ik AI vraag naar de exacte broncode voor de fast inverse square root functie uit Quake, krijg ik dan automatisch de rechten op dat stuk software als ik de prompt maar uitgebreid genoeg maak? Wat nou als ik AI om de tuin leidt (en da's makkelijker dan je denkt) en ik uiteindelijk in de hele context uitkom op dat algoritme, is het dan toeval en vervalt het recht van ID op die code?

Daarom vroeg ik je juist naar bronnen, omdat je het als waarheid "verkoopt". Losse flodders over copyright en andere zaken daargelaten, kan ik namelijk niets terugvinden over jouw beweringen, dus ik laat me graag met bewijs overtuigen.
Toch is soms "voorkomen" beter dan achteraf genezen, dus niet verkeerd wat dit platform wil.

Hoop onkosten om te genezen, misschien zelfs rechtszaak en nog meer onkosten.
Je zou al kunnen scannen op het gebruik van libraries waarvan bekent is dat ze (deels) met AI zijn geschreven. Dan vang je nog niet alles, maar een hoop moderne software zal dan al snel afvallen.
Simpel, angst voor verandering. Niets anders
Wat je quote is net zo toe te passen op code die door mensen geschreven is, ook daar weet je niet of het schadelijke code bevat of mbt auteursrecht.
Het verschil is natuurlijk ook de snelheid waarmee dergelijke tools/projecten tegenwoordig met AI gemaakt kunnen worden. Zolang je een handjevol committers hebt die belabberde kwaliteit (kunnen) afleveren, dat is nog te overzien en te controleren/blokkeren/op aan te spreken. Nu zit je met 100+ die hetzelfde doen omdat AI wordt gebruikt en dus sneller potentieel slechte kwaliteit en kwetsbaarheden opgeleverd worden.

Ik zeg daarmee niet dat alle AI gebruik belabberd is van kwaliteit, maar de zondvloed die hierdoor ontstaat is mijn inziens het probleem. Je moet het als maintainer van een open source project ook nog zien te controleren.

Ik hoor dan dikwijls: ja maar daar heb je AI ook voor! Slecht plan mijn inziens. Dat is als de code van junior één door junior twee te laten controleren. Daar moet vind ik altijd een senior (de maintainers van het project) tussen zitten. Anders loop je het risico dat je binnen een paar maand je eigen project niet meer herkend.

[Reactie gewijzigd door Powerblast op 25 juli 2026 13:46]

Je omschrijft hoe menselijke programmeurs al jaren werken in veel gevallen. Het is allemaal niet nieuw. Het gaat alleen sneller.
En dat is natuurlijk ook niet hun enige argument. Ook oa het exernaliseren van de kosten voor gebruik van LLMs de bijkomende groeiende maatschappelijke ongelijkheid en de schade aan het milieu door de overvloed van datacentra zijn redenen om het niet toe te staan.
beetje meer offtopic maar paar jaar geleden veel respect verloren voor bepaalde project maintainers die lof hadden voor LLMs die Doom naar hun project konden porten. Dat is gewoon belachelijk want Doom is zovaak handmatig geport en getranspiled met handmatige validatie en automatische tests dat natuurlijk een groot gedeelte van de trainingsdata en dus het LLM gewoon Doom broncode bevat. Al helemaal als je project al in dezelfde taal is als veel van die ports. Sterker nog als je ipv de google samenvatting de echte google resultaten had gelezen (of gewoon direct op github had gezocht) vond je al 2 (krakkemikkige hobbyistische) ports van Doom naar een veel oude versie van diezelfde library.

LLMs plagiëren gewoon te pas en te onpas, mooi als het toepasselijk is, en dan zou je zelfs nog kunnen zeggen dat voor sommige problemen geen unieke oplossingen bestaan. Er zijn ook maar zoveel versies van Hello World die je voor een bepaald platform in een bepaalde taal gaat verzinnen, je hoeft niet altijd het wiel opnieuw uit te vinden. Maar LLMs plagiëren ook gewoon te onpas, hallucinaties kunnen ook gewoon geplagieerd zijn met het nadeel dat je code niet eens doet wat het moet doen. Prachtig. Cargo Cult programming maar infinitely scaling?

En dat is gewoon beargumenteerd op directe broncode maar we hebben natuurlijk ook bergen boeken en tutorials waar natuurlijke taal code beschrijft die vervolgens daar onder wordt vermeld. Super nuttig voor een LLM die stapsgewijs wordt handjevastgehouden om code onder comments te genereren maar zo creatief of origneel is het dus niet. Het is gewoon een randomized vertaling van iemands boek naar een verwante target taal. Lastig voor onafhankelijke programmeer projectjes om hun recht te halen maar grote uitgevers hebben misschien meer middelen als ze investeren in detectie. En zelfs de grote AI bedrijven willen niet een free for all. Ja ze willen jou data en compute gratis plunderen maar gaan huilen als DeepSeek output van GPT destilleert, of als je met een nieuw model de gelekte broncode van Claude gaat wassen met transpilation. Het is al erg genoeg wetgeving met ontwikkelingen gelijk te trekken en tis altijd lastig als verschillende groepen mensen verschillende dingen willen maar op dit moment nemen LLM bedrijven nieteens een oprechte positie in, ze zeggen gewoon wat hun het beste uitkomt per voorval.
De rewrite van Bun in Rust is anders wel een actie waar je wel respect voor kan hebben. (Misschien niet in de motivatie, maar dat is een ander onderwerp.) Daar kan de AI niet eens bestaande code afkijken, want dat is er niet. En is alles dus "nieuw" bedacht. Tuurlijk, de AI heeft de test suite gebruikt om te zorgen dat het foutloos werkt. Maar ergens moet er een controle op de output zijn, als is dat maar door de gebruiker die de app gebruikt, dus dat zorgt er alleen maar voor dat de AI maakt wat we willen.
Een progammeur kan natuurlijk ook (on)bewust "foute" code er in (ver)stoppen of een copy-paste van een andere bestaande code maken. Dat men dit expliciet aan AI toewijst vind ik eigenlijk maar een kul-argument.
Die auteursrechtelijke issues hebben we ook vaak gezien rondom open source software die iedereen vrolijk ging gebruiken in zijn projecten.
De auteursrecht situatie is misschien onzeker maar dat is irrelevant. Als er auteursrecht is, dan is dat eigendom van de menselijke co-auteur. Zoniet, dan is het public domain. Er is geen derde die copyright kan claimen.
bieden ze weinig garanties om te voorkomen dat projecten schadelijke code bevatten.
Die garanties heb je ook niet met mensen. Minder zelfs, naar mijn ervaring.
Volgens het platform is de auteursrechtelijke status van die tools onduidelijk
Vrij duidelijk toch?
Veel programmeurs hebben gebrekkig zicht op wat er daadwerkelijk in hun code gebeurt
Daar hebben ze geen AI voor nodig hoor
Handmatig reviewen van de enorme bergen aan code die nu geproduceerd wordt is ook onbegonnen werk
Ook dit heeft 0 met AI te maken, mensen hebben jaren lang bagger code geschreven. AI is prima in staat goede code te schrijven, beter dan een mens.
Dan is het niet zo vreemd dat een hosting platform zegt "hier gaan wij geen verantwoordelijkheid voor nemen", want het risico dat ze er op termijn hun vingers aan gaan branden is aanzienlijk.
Dat is wel vreemd. Het is gewoon ongegronde bangmakerij / angst voor nieuwe technologie.

AI code tools zijn gewoon een vergroter. In de handen van een capabele developer, krijg je goede code. In de handen van een pruter, krijg je meer prutswerk.
Handmatig reviewen van de enorme bergen aan code die nu geproduceerd wordt is ook onbegonnen werk.
Maar hier heb je toch ook gewoon tools voor? Zaken die al lang en breed bestaan en ook met “normale” code gewoon belangrijk zijn? Denk aan trivy, Sonar.

ik snap het auteursrechten aspect (maar ook daar heb ik mijn bedenkingen bij gezien de hoeveelheid stackoverflow copy paste er in de wereld is), maar het security aspect … hoe bied een tool die met de hand geschreven is die garanties nu? Dat kan ook niet een “trust me bro” zijn.

en laten we even eerlijk zijn. 99% van de security incidenten die we tot op heden hebben gehad kwam juist door handmatig geschreven code en processen. Niet dat AI beter hoeft te zijn (daar kun je ook prul mee maken). Maar ik heb wel mijn bedenkingen bij de redenen die ze nu aangeven.
Het verschil zit 'm vooral in ownership en verantwoordelijkheid. Als jij een stuk code met de hand schrijft, dan spreekt het voor zich dat het jouw code is, en dat jij verantwoordelijk bent voor de kwaliteit en de veiligheid daarvan. Of het bedrijf waar je voor werkt heeft het eigendom en de verantwoordelijkheid, dat is contractueel vastgelegd.

Met AI generated code ligt dat lastiger. Vooral met vibe coding is het niet ongebruikelijk dat de maker niet eens de code heeft bekeken, laat staan dat die kan uitleggen regel voor regel wat het doet en wat de achterliggende gedachte is. Dus wiens code is het dan? Je hoort nu al vaak het excuus "ja de AI heeft dat gedaan" om verantwoordelijkheid uit de weg te gaan. Misschien dat het gevoelsmatig obvious lijkt wie er verantwoordelijk zou moeten zijn als er iets mis gaat, maar of dat ook juridisch stand zou houden in een rechtzaak, dat is maar de vraag.

Het is nu nog één groot grijs gebied en dus niet zo vreemd dat sommige partijen voorzichtig om proberen te gaan met de situatie.
Met AI generated code ligt dat lastiger. Vooral met vibe coding is het niet ongebruikelijk dat de maker niet eens de code heeft bekeken, laat staan dat die kan uitleggen regel voor regel wat het doet en wat de achterliggende gedachte is. Dus wiens code is het dan? Je hoort nu al vaak het excuus "ja de AI heeft dat gedaan" om verantwoordelijkheid uit de weg te gaan. Misschien dat het gevoelsmatig obvious lijkt wie er verantwoordelijk zou moeten zijn als er iets mis gaat, maar of dat ook juridisch stand zou houden in een rechtzaak, dat is maar de vraag.
En er is stiekum best een hoop mis met die code. Primaire functionaliteit wordt er wel in geduwd door de vibe-coders, maar ik zie in AI gegenereerde code echt nul foutafhandeling. Inputvalidatie wordt nog wel gedaan als je roept dat het secure moet zijn, maar daadwerkelijk een try...catch block om een databasecall heen, dat gebeurt niet. En dan is het wachten tot een dergelijk vibecoded tool niet ergens de boel flink om zeep helpt. En wie wordt dan verantwoordelijk gehouden...
De code die ik schreef met AI bevat uit zichzelf try catch-blocks. Ik gebruik OpenAI Codex en Anthropic Opus. Misschien dat dit in de gratis variant via een webprompt anders is.
Misschien dat dit in de gratis variant via een webprompt anders is.
Geen lauw idee want ik gebruikte de vrij serieus betaalde variant....
Ik vind wat je zegt interessant, maar ik denk dat het een stuk informatiever wordt wanneer men bij dit soort dingen inderdaad wat meer informatie geeft over de gebruikte LLM. Dus de naam, versie, misschien ook de abonnementsvorm of tijdspanne als dit interessant is. Ik denk dat naam en versie het minimum is ("namen en rugnummers" om maar in voetbaltermen te spreken).
Claude Fable 5.0, extra effort, serieus betaald abbo
Maar even heel eerlijk. Ik ben dan oprecht benieuwd naar twee dingen.
  1. Hoezo heb ik dat dan niet? Waarom zie jij code die “altijd” (over hoe vaak het exact is, maakt me niet zoveel uit) expliciet geen try/catch blokken heeft en ik en @NoTechSupport wel?
  2. dat is toch kinderlijk eenvoudig te achterhalen met statische code analyse? Net als dat je dit normaal in je pijplijn zou hebben zitten? Codekwaliteit wil je toch gewoon altijd meten en verbeteren voor zover nuttig? Tools zoals sonarqube hebben bergen met regels over try-catch-finally blokken, juist rondom database calls.
Code schrijven dmv AI op professioneel niveau (waar het artikel echt wel om gaat) ontslaat je niet van alle andere checks die je met normale code ook zou doen. Hier heb je toch gewoon je standaard tool arsenaal voor? Een junior kan dit ook fout doen. Dat wil je ook absoluut ondervangen met geautomatiseerde tooling.
Was automatische tooling maar zo goed als jij denkt dat het is het zou m'n leven zo veel makkelijker maken. De gemiddelde static analyzer voegt vrij weinig toe boven de meest obvious fouten. Er zal toch echt iemand ECHT naar de code moeten kijken. En laat dat nou het probleem zijn met de hoeveelheid code die nu gegenereerd wordt. Het is gewoon een capaciteit probleem, dus gooi je er nog weer een LLM tegenaan die het dan weer moet reviewen en nog 1 die de review beoordeeld. Worden het ineens wel erg veel tokens...
De gemiddelde static analyzer voegt vrij weinig toe boven de meest obvious fouten
Ja dat zijn toch precies de zaken die @J_van_Ekris Hier benoemt? Een try-catch-finally die ontbreekt bij een DB call is een potentiële bug die iets als Sonar gewoon vangt.
Het is gewoon een capaciteit probleem, dus gooi je er nog weer een LLM tegenaan die het dan weer moet reviewen en nog 1 die de review beoordeeld. Worden het ineens wel erg veel tokens
Nouja. Met handmatige code heb je toch ook meerdere reviewers? In een team van programmeurs is 4-eye toch ook de standaard? En als het een beetje dieper gaat vraag je er twee of meer om goed te kijken? Ja ik heb daar ook verschillende modellen voor. Al was het alleen maar omdat verschillende modellen anders werken en anders kijken. Precies zoals je dat met mensen ook hebt. Iedereen let op andere dingen.

Iedere sprint retro is ook om die standaarden en processen verder te refinen, dat is met AI niet anders.
Er zal toch echt iemand ECHT naar de code moeten kijken
Ben ik het niet helemaal mee eens. IETS moet echt naar de code kijken, maar dat kan prima een LLM zijn met de juiste tools en instructies.

Zo heb ik bijvoorbeeld codesight in de repo om architecturele informatie te genereren waar een LLM over kan redeneren. Kijken naar abstracties en paden, kloppen de zaken logisch met wat best practises zijn? Even hoog over. De echte tooling gaat daar veel dieper op in en gaat die paden echt bewandelen en controleren. Wat j_van_Ekris zegt over abstracties en structuur, kun je prima verwerken met een LLM. Dat is ook niet “moeilijk” kost alleen tijd om in te regelen.

Maar nog steeds. AI is ondersteunend aan de uitvoer. Project scope, diepgang van security, wat is wel binnen scope en wat niet omdat het geen onderdeel is van de exposure? Moet je allemaal nog steeds bedenken.

Ik wordt zelf een beetje moe van al het “ja maar het doet dit slecht” en dan lijkt vervolgens eigenlijk dat die specifieke context gewoon niet is meegegeven in de instructies, of dat men probeert een one-shot te doen en dat dat dan niet werkt (ook een slechte marketing “belofte” eigenlijk). En dan dat zonder onderbouwing hier neerzetten. En dat ik dan denk, interessant punt, maar waarom zie ik dat dan niet?

Ik gebruik iedere week meerdere betaalde abonnementen helemaal tot het naadje. Ik snap wat er wordt bedoeld, maar ik zie ook dat er lang een breed oplossingen voor zijn die gewoon zijn oorsprong vinden in alle processen die ook normale software development gewoon kent.
En er is stiekum best een hoop mis met die code. Primaire functionaliteit wordt er wel in geduwd door de vibe-coders, maar ik zie in AI gegenereerde code echt nul foutafhandeling. Inputvalidatie wordt nog wel gedaan als je roept dat het secure moet zijn, maar daadwerkelijk een try...catch block om een databasecall heen, dat gebeurt niet. En dan is het wachten tot een dergelijk vibecoded tool niet ergens de boel flink om zeep helpt. En wie wordt dan verantwoordelijk gehouden...
Dan ben je dus nog niet ver genoeg gegaan met je prompts. Oo een gegeven moment kom je op het punt dat je langer bezig bent om he prompts te schrijven dan zelf de code te maken
Dan ben je dus nog niet ver genoeg gegaan met je prompts. Oo een gegeven moment kom je op het punt dat je langer bezig bent om he prompts te schrijven dan zelf de code te maken
Als je het punt bereikt dat het meer werk kost om een AI te overtuigen het werk goed te doen, dan het zelf te schrijven, dan vervalt de business case van AI.

Ik moet zeggen, op wat specieke zaken na (zoals high volume gluecode), heb ik dat punt wel bereikt dat het meer werk is de AI het echt goed te laten doen dan het gewoon zelf te schrijven. Zelfs met het meegeven van een architectuurdocument en een bijna identieke oplossing (open source project waar ik aan werk kent recorders, in a nutshell wilden we de filesystem write vervangen door een database optie) zie je dat het eigenlijk teveel werk is.
Grappig ik haal juist vaak try catches weg omdat het vaak puur om loggen gaat en dat handel je beter op een centrale plek af.

Uiteindelijk gaat het ook meer om de context dan het model hier. Als jij fout afhandeling op een specifieke manier wilt zul je dat aan je AI moeten uitleggen want zelf gaat die vaak beetje proberen te gokken.
Dus wiens code is het dan?
Dit is dus echt niet hoe auteursrecht werkt. Hetzelfde kan toch ook gezegd worden van een bedrijf? De copyright holder entiteit kán niet eens de code lezen en het bedrijf moet er maar vanuit gaan dat de ontwikkelaar weet wat ie doet.

Als ik een stuk code kopieer van stackoverflow, en dat werkt in een keer en ik kijk er verder niet naar (regel voor regel), omdat het al semi minified/onleesbare algoritmiek is, heb ik hier dan geen auteursrecht meer over?
Vooral met vibe coding is het niet ongebruikelijk dat de maker niet eens de code heeft bekeken, laat staan dat die kan uitleggen regel voor regel wat het doet en wat de achterliggende gedachte is.
Ik heb zoveel dingen gemaakt waar ik de achterliggende gedachte ook niet van begrijp. Ik vind dat geen goede reden om auteursrecht niet toe te mogen kennen. Bij heel veel kunst is er soms ook geen achterliggende gedachte. Het is gewoon wat het is. Gaan we dan die kunstenaar ook geen auteursrecht meer geven?
Inderdaad. Het probleem is als je geen enkele programmeerkennis hebt en alles door AI laat ontwikkelen je niet meer kunt beoordelen en oplossen als je eventueel bugs moet oplossen. De bugs door AI laten oplossen? Tja, wat als AI (zo slim wordt dat het) een backdoor introduceert die een vibe coder niet meer kan beoordelen...
Dat was voor ai ook al zo. Er is weinig nieuws onder de zon. Geen enkel project trok de code na van gebruikte libraries en frameworks. Iedereen gelooft dat het wel goed zit. Het is al jaren een jaren ondoenlijk voor 99% van de developers om de code van de volledige stack te auditen en dat bij elke versie van een externe library opnieuw te doen.

Het enige wat codeberg geregeld heeft is zichzelf nog meer irrelevant maken.

Ik overwoog ze als alternatief voor GitHub. Maar nu niet meer. Ik gebruik ai veel en ik begrijp wat ik er mee doe. Ik bepaal of ik de domme basis stappen door een ai laat maken en ik verberg dat ook niet.

Het copyright argument is ook onzin. Daar zijn al uitspraken over. De LLM is geen persoon en kan dus geen copyright houden. Het is een tool net als Photoshop. Een tool die net als mensen leert van andere en wat eerder gemaakt is. Dat is geen diefstal dat is hoe leren werkt.
Ik zit in de gekke situatie dat ik aan de ene kant alle begrip heb voor hun argumenten, maar tegelijkertijd wordt ik nu gedwongen een andere plek te zoeken. Ik ben net een complexe library aan het schrijven, en maar daarbij erg veel gebruik van Claude Code. Ik was van plan het onder de EPL op Codeberg te delen, omdat ik dat wel een sympathieke plek vond. Dat vind ik nog steeds, maar het is duidelijk niet de juiste plek voor deze library.

Ik zit nu naar CodeFloe te kijken. Ik weet er nog weinig van, maar het lijkt opgezet door iemand die uit Codeberg komt, maar iets net wat pragmatischer wou.
Dan is het niet zo vreemd dat een hosting platform zegt "hier gaan wij geen verantwoordelijkheid voor nemen"
Maar ze nemen toch geen verantwoordelijkheid over van het project? Hun bieden enkel de hosting van de code (en tooling daaromtrend) aan. Copyright en licenties is nog steeds een verantwoordelijkheid voor een project.

Ik vond Codeberg een platform die alleen voor specifieke Open Source projecten is. Deze beslissing versterkt dit alleen maar. Als jij als project wil versnellen door AI gebruik (binnen bepaalde condities) toe te staan, dan is dat de keus van het project. Niet iets dat bij de hosting partij hoort te liggen. Dit laat alleen merken dat ze bang zijn voor overdadig veel gebruik en dat hun daar niet de partij voor zijn. Dus kies voor GitHub, GitLab, SourceForce of zelfhosted.
Het is geen volledig verbod als je de voorwaarden leest:
7. You must not share projects that mostly consist of code written by "generative AI"-tools (including services such as Claude, OpenAI Codex). Such projects having an unclear copyright status (see requirements § 2 (1) 1 and § 2 (1) 3) and furthermore have little safeguards to ensure that they do not include harmful code (c.f. § 2 (1) 5).
Ik trigger hier op het woord "mostly". Dus volgens mij mag je nog steeds een project hosten daar dat met ondersteuning van AI tot stand is gekomen. Alleen hoe je dat aantoont of detecteert is mij een raadsel.
automatische detectie zal hem niet worden, maar je kan best makkelijk zien wanneer iemand 200 commits heeft per dag met duizenden lines aan code die allemaal willy-nilly worden aangepast.
Denk dat dit ook vooral zo verwoord wordt omdat alle soorten code generation tegenwoordig onder de noemen "AI" worden geklasseerd. Getters en setters die door je IDE gegenereerd zijn, hashing functies, compare, line completion die een lokale AI voor je doet, enzovoort. Ik vermoed om te vermijden dat ook dat niet meer toegestaan zou zijn, ze de verwoording "mostly" gebruiken. Waarschijnlijk om de vibe "coders" te weren. Want daar zit het grootste probleem natuurlijk.
Omdat de meeste developers tegenwoordig AI als hulpmiddel gebruiken. Ze willen vooral verbieden dat gehele codebases enkel door AI zijn gemaakt middels vibe coding.

AI in zijn geheel weigeren betekent het overgrote deel van de developers weigeren…
Ik trigger ook op het woord "mostly".

Daarmee vervalt ook het hele juridische argument over eigenaarschap en plagiaat. Als je daar bang voor bent... dan moet je niet het woord 'mostly' gebruiken... daar kom je niet mee weg bij de rechter.

Beste rechter: het meeste heb ik niet gejat maar zelf geschreven... Behalve deze code, die heb ik gejat...

Ofwel, het lijkt gewoon anti AI-sentiment die bij sommigen tot te veel irrationaliteit leidt.
Die mostly zouden ze inderdaad best nog even verder toelichten denk ik. Maar ik gok persoonlijk dat dit verwijst naar code completion en spul dat met je IDE is gegenereerd. Ik denk sowieso dat als je echt hard in wil zetten op AI als project, dat je dan beter bij Github blijft.

Met die mostly zal vermoedelijk het merendeel van de vibe coded toestanden wel gestopt worden, als ze actief gaan monitoren natuurlijk.

[Reactie gewijzigd door Powerblast op 25 juli 2026 16:25]

Die 'mostly' toont aan dat het een volledig irrationeel besluit is geweest, gebaseerd op anti AI sentiment..
ik denk dat het ook wel irritant is als je een vuln. hebt die gedetecteerd is door een LLM, en mogelijk een 1 line diff heeft als daadwerkelijke fiks (niet een bodge ofzo) dat als die oneline fix technisch gezien met een LLM is ingediend je hem dan op een andere manier zou moeten implementeren.
Dat Codeberg niet LLMs in de CI/CD wil hebben betekent niet dat er geen (onzinnige maar ook terechte) vulnerabilities gevonden gaan worden met LLMs. Die worden of dan verantwoordelijk aan een maintainer gemeld of ergens anders gepubliceerd omdat het niet op Codeberg moet, toch de vuln zit al in de broncode of de release dus je wil er aan het einde van de dag toch wat aan doen. Als de diff zo klein is dat de copyright status van de nieuwe code niet discutabel is denk ik dat het wel gepast kan zijn. Op een gegeven moment zit je gewoon op 'dat is hoe wiskunde werkt' of 'dat is hoe je dit doet in die ene programmeertaal' en is plagiaat niet zo zeer een factor of het nou een mens of LLM was.

Een 1000 file pull request klakkeloos mergen omdat een LLM dacht dat iets misschien niet zo hoorde zonden verificatie of onderbouwing brengt veel meer risicos voor CodeBerg qua infra en legal.
Dat Codeberg niet LLMs in de CI/CD wil hebben betekent niet
Is dit wel het geval? Dit lees ik er in elk geval niet in. Van wat ik ervan begrijp gaat het om codebases die hoofdzakelijk AI-gegenereerd zijn, maar issues/comments/CI vallen daar buiten. Het lijkt mij dat ze het express zo verwoord hebben om wel LLMs binnen een pipeline te hebben, maar de uiteindelijk geschreven code altijd aan een mens toe te kunnen schrijven.
Ja ik zie dezelfde loophole maar was mij ook niet duidelijk hoe intentioneel dat open werd gelaten of dat de volgende stemblokken dat weer gaan beperken. Lijkt me in ieder geval onverstandig veel energie in te investeren tot dat verduidelijkt wordt of überhaupt te kijken hoe dit huidige besluit uitgevoerd gaat worden.
Mensen die dit soort dingen roepen (“programmeren door LLM’s is zoveel sneller”) hebben blijkbaar hele lage kwaliteitseisen, want hoewel het je als tool zeker sneller kan maken, als je het inzet als vervanger van zelfbedachte code, is het gewoon niet onderhoudbare slop wat gemaakt wordt. Daarnaast is dat gerecyclede code die getraind is op met copyright beschermd werk, dus de kans is reëel dat je LLM code genereert wat copyrights schendt.
Wanneer heb jij het voor het laatst gebruikt dan? Is echt niet meer het geval anno 2026
Ik heb vorige week een prototype gemaakt met Claude Fable 5.0, tokens waren in de aanbieding dus maar gelijk op de meest grondige stand gezet. Na een hoop aandacht en heel veel correcties is er dan iets wat werkt, maar fundamentele zaken als grondige defensive programming zijn echt ver te zoeken. Structuur van de code is chaotisch, refactoren gebeurt niet, en als je er op stuurt gebeurt het slechts instrumenteel. Abstracties in de code zijn onlogisch. Ik heb behoorlijk moeten bijsturen op de verantwoordelijkheden van verschillende applicatielagen, en de bijbehorende validatiestappen. Vaak beschrijft het commentaar het onstaansproces, maar niet de daadwerkelijke afwijkende ontwerpkeuzes: dus commentaar is irrelevant en waar het echt nodig is ontbreek het juist.

Ik heb behoorlijke ervaring als code reviewer, en dit is het niveau wat je krijgt als een stagair of junior aan het werk zet. Leuk begin, maar op geen enkele wijze productierijp.

Het voordeel van de stagair is dat als ik een mens corrigeer, hij/zij de volgende keer aanzienlijk beter presteert. Bij een AI tool moet je dat maar echt afwachten.

[Reactie gewijzigd door J_van_Ekris op 25 juli 2026 17:13]

Na een hoop aandacht en heel veel correcties is er dan iets wat werkt, maar fundamentele zaken als grondige defensive programming zijn echt ver te zoeken. Structuur van de code is chaotisch, refactoren gebeurt niet, en als je er op stuurt gebeurt het slechts instrumenteel. Abstracties in de code zijn onlogisch. Ik heb behoorlijk moeten bijsturen op de verantwoordelijkheden van verschillende applicatielagen, en de bijbehorende validatiestappen. Vaak beschrijft het commentaar het onstaansproces, maar niet de daadwerkelijke afwijkende ontwerpkeuzes: dus commentaar is irrelevant en waar het echt nodig is ontbreek het juist.
Sorry maar dit leest echt alsof je dus precies een nieuwe tool hebt ontdekt en nog helemaal niet weet hoe je het moet gebruiken en dan de volledige tool afzaagt terwijl je het zelf verkeerd doet.

fundamentele zaken zoals defensive programming die ontbreken is een gebrek in jou prompting voor informatie. Structuur die ontbreekt is een gebrek aan prompting over hoe je denkt dat je een structuur zou moeten willen. Refactoren wat niet gebeurt is een gebrek aan kennis van hoe AI output geeft (namelijk append aan file of hele file opnieuw schrijven) en waar je dus op moet aansturen. Onlogische abstracties: niet zelf aangegeven wat voor extracties je wel wil zien. Behoorlijk moeten bijsturen op verantwoordelijkheid van lagen over verschillende zaken, helemaal prima, maar dit wil je dus vooraf doen in je ontwerp fase. Ook hoe je commentaar toevoegt aan je code, niet vooraf over gehad/vastgelegd.

AI kan echt heel veel, maar het ontslaat je niet van het nadenken over context en zaken die je wil hebben. Denk bijvoorbeeld aan dingen die jij nu al in je hoofd hebt zitten voor straks, die AI kan dat niet ruiken. Daar moet je het over hebben. Opus 5 kan geen wonderen verrichten en Fable 5 ook niet.

Wat ik nu lees is echt niet indicatief voor goed en verantwoord gebruik van AI. Zie AI als de code generator van je IDE, maar dan on steroids. De rest zul je echt zelf moeten doen, maar kan wel met AI worden besproken en vastgelegd.
dus maar gelijk op de meest grondige stand gezet.
Ultracode gebruiken met een “vaag ideetje” is gewoon niet hoe je het moet doen. Dat doe je hoogstens met implementatie werkzaamheden en daar is Fable oprecht overkill als je niet laat delegeren naar Opus en Sonnet. Fable en Sol zijn bijvoorbeeld ook orchestrator modellen. Modellen die je wil inzetten om groepen van andere modellen te orchestreren, niet om code te implementeren. De kwaliteit daarvan is niet heel veel beter dan Opus, maar dan wel drie keer zo duur. Zonde van je geld.
Het voordeel van de stagair is dat als ik een mens corrigeer, hij/zij de volgende keer aanzienlijk beter presteert. Bij een AI tool moet je dat maar echt afwachten.
Pertinent onwaar. Je legt het dan niet voldoende klaar.

Je verhaal klinkt leuk, maar als ik hem zo op de letter interpreteer dan heb je echt nog een aantal gaten in je informatievoorziening zitten die je prototype laat zijn wat het is. En ik geloof oprecht dat de kwaliteit daarvan niet zo heel best is, maar verbaasd ben ik daar niet echt over als ik dit zo lees.
Sorry maar dit leest echt alsof je dus precies een nieuwe tool hebt ontdekt en nog helemaal niet weet hoe je het moet gebruiken en dan de volledige tool afzaagt terwijl je het zelf verkeerd doet.
En jij doet wel hele wilde en onterechte aannames.
Heel eerlijk. Ja. Ik heb je bericht nu echt op de leter gevolgd. Als dat niet het geval is, leg het me uit en overtuig me. de dingen die jij aangeeft zie ik namelijk alleen nog terugkomen als ik zelf mijn context niet op orde heb. Ik herken er een aantal van hoor, maar die kwamen echt vooral doordat ik zelf die aanname deed “dattie dat wel zou doen”. En dat is gewoon niet zo.
jouw betoog lezende ben ik ervan overtuigd dat je nooit echt serieuze software hebt gebouwd. In elk geval niet met een LLM.
Ik ga volgende week naar productie met met een stuk software wat volledig is gebouwd met AI.

Daarnaast al jaren actief voor grote projecten. Ik weet 100% dat jij delen van mijn software en infra zaken hebt gebruikt. Iedere Nederlander heeft dat namelijk.
Dan houd ik mijn hart vast...

Ik denk overigens niet dat het iets is om trots op te zijn, overheid & IT zijn nou niet de kwaliteitsprojecten waar je over op kan scheppen op een forum ;-)
Dan houd ik mijn hart vast...
Hoeft niet hoor, je gaat het toch niet doorhebben ;)
misschien dat je wat minder belasting gaat betalen.

En wie zegt dat het overheid was?

En dan nog falen IT projecten bij de overheid vanwege management en verwachtingen. Heeft niks met de software kwaliteit te maken.

Maar als je een beetje met AI wat zaken gedaan zou hebben op een niveau wat wel serieus is, dan had je geweten dat er echt allang oplossingen zijn voor dit soort issues. Grounding, wiki, deep-research, harnassing, architecture decision logs.

En zelfs dat ontslaat je niet van zelf nadenken over wat belangrijk is. Men zegt vaak dat AI mensen lui maakt en kritisch denken verminderd, maar als je daadwerkelijk echt met AI aan de gang gaat en serieus met verschillende modellen gaat werken kom je er achter dat AI helemaal niet het denkwerk overneemt, maar de uitvoering. En ik denk oprecht dat mensen die met outsourcing gewerkt hebben naar bijvoorbeeld India, veel beter om kunnen gaan met AI. Ze zijn immers gewend om veel meer zaken expliciet te maken, abstracties zelf toe te voegen en specifiek te communiceren.
Als genoeg ontwikkelaars AI blijven trainen wordt het wel beter :+
Ik moet bekennen dat mijn ervaring eerlijk gezegd toch vrij gelijklopend is. Ik ben zelf perfectionistisch dat zeg ik maar alvast bij. Maar het voldoet in geen enkele mate aan de eisen die ik van mezelf stel voor productie code.

Ik gebruik het zelf meer om te brainstormen en voorbeelden samen te stellen van frameworks, libraries en andere zaken zodat ik het gemakkelijk kan opzoeken i.p.v. forums af te zoeken. Dat werkt heel goed. Code completion en dergelijke in IDE's bijvoorbeeld werkt dan ook wel weer een pak beter dan vroeger.

Probleem is meestal dat eens je de laatste nieuwe versies van een library wil gebruiken, het model er niet op getrained is en dus code weergeeft die soms zelfs niet meer compiled. Claude zoekt zover ik weet ook het internet af op zoek naar voorbeelden, maar ik gebruik soms libraries waar er enkel API docs van zijn. Geen voorbeelden. Het zou uit die API docs in staat moeten zijn, zoals een echte programmeur, om een werkend prototype te halen. Veel plezier zeg ik je dan :).

Spreek je het daar dan op aan, dan draai ik een uurtje in rondjes. Eindconclusie: Je bent niet de enige die met library X last heeft, laten we een andere gebruiken. Ja, daarvoor gebruik ik AI :/.

Blijkbaar werkt het voor sommige wel, maar voor de use cases waar ik het voor gebruik (Rust en C++), werkt het niet goed genoeg om blind op te vertrouwen. De basis lukt nog wel. Lifetimes met iets complexere setup, vergeet het maar. Dan is de Rust compiler nog nuttiger dan AI. Ik heb me die bedenking al meer gemaakt. Het lijkt alsof het met talen waar het erg veel voorbeelden van vind, heel gemakkelijk en heel goed werkt (Javascript, Java, C# enzovoort). Kom je in territorium waar het amper voorbeelden van heeft, dan zit je eigenlijk met een tool die eerder tegenwerkt.

Ik denk dat je het daarom ook is dat je twee strekkingen tegenkomt op forums en internet. Bij sommige werkt het fantastisch, bij sommige amper. Veel heeft volgens mij te maken met de use case en de programmeertaal waarin gewerkt wordt.

[Reactie gewijzigd door Powerblast op 25 juli 2026 20:07]

Valt toch wel mee hoor, en je kan het ook zien als niet willen dat grote autobedrijven alle traminfrastructuur opzuigen en afbreken. Maargoed metaforen zijn beperkt en die van mij veel krommer dan die van jou.

Ik zie het probleem niet echt dat een clubje met hun leden bepaald wat ze willen doen. Er zijn zoveel andere plekken waar je wel terechtkan met dit soort spul, zelfs als je niet GitHub, GitLab of een andere Forgejo instance wil gebruiken staat het je vrij Frogejo zelf te hosten. En als Forgejo je niet aanstaat kan je toch met Claude oid een nieuwe genereren?

Ik denk dat er zat projecten zijn waar zonder LLMs verder gaan prima is omdat de grootste overhead is om pullrq, commits en diffs te lezen is en zal zijn. Meer code genereren om te reviewen past daar niet in. Misschien dat over een paar jaar LLMs ook nuttiger gaan zijn voor reviews maar weet niet of we nog grote prestatiesprongen kunnen verwachten als de meeste bedrijven richting kostenoptimalisatie gaan. Dus misschien hoeven ze dan niet te verkassen.

Verder denk ik dat voor hobbyisten dat het wel relaxed is om een plek te hebben waar je zonder 999 upsale modals voor AI dit AI dat AI zus AI zo je leuke code te proppen. Als je het leuk vind zelf te schrijven is het niet zo logisch om een LLM abbo of dure hardware te kopen zodat de computer automatiseert wat je leuk vind en je als je pech hebt je als schoonmaker achter wat agents na moet rennen. En als je programmeren en code type saai vind en alleen het eindresultaat wil kan je voor je hobby interesse beter terecht bij iets wat helemaal een AI focus heeft.

Codeberg is nu nog super clunky voor 'traditionele' CI/CD en zou niet veel beter werken als je daar wat agents in had gepropt, zit ook allemaal in de opstartfase. Maar ze zeggen nu ondubbelzinnig dat ze geen zin hebben om een hele CI/CD omgeving gratis aan te bieden om dan geDDOSt te worden door slecht ingestelde bots. Ze zijn al veel tijd kwijt aan scrapers die servertijd verstoken en je wil niet dat je menselijke gebruikers weer in een captcha hell komen. (Kijk maar naar hoe sommig NPM js tools nu in captcha hell belanden ongeacht of er agents worden gebruikt). Elke keer dat je tijd inzet voor het toevoegen en tunen van API limits voor LLM scrapers en LLM agents ben je die tijd niet aan het inzetten voor je eindgebruikers. Dus wel logisch dat Codeberg in het bezit van leden andere prioriteiten stelt dan Microsoft met GitHub. Codeberg heeft geen cloud of turnkey LLMs om aan je te verkopen maar Microsoft wel, dus Microsoft kan dat integreren en het ene kostengat bij GitHub dichten met inkomsten uit Azure etc. het wordt dan meer een marketing expense terwijl voor Codeberg is het alsof ze hun eigen geld in de fik zouden zetten.
Valt toch wel mee hoor, en je kan het ook zien als niet willen dat grote autobedrijven alle traminfrastructuur opzuigen en afbreken. Maargoed metaforen zijn beperkt en die van mij veel krommer dan die van jou.
Eerlijk is eerlijk, die metafoor klopt beter dan het idee dat de trein, of de auto, paard en wagen zou hebben vervangen. Auto's hebben (vooral in de VS en bijna ook in Nederland) juist vooral het OV en dan met name trams, vervangen. Hele historische stadscentra zijn voor auto's platgewalst met alle infrastructuur erbij.
Eerder alsof je het graven van kanalen met kernbommen overslaat omdat we toch liever graafmachines gebruiken.
Ze proberen te voorkomen dat er teveel technical debt opgebouwd wordt door gebruik van AI. Ze kijken liever eerst de kat uit de boom, want alles ontwikkeld zich in een bloedsnelle tempo wat het lastig maakt om alles goed te kunnen overzien.
En alsof je een compiler verbiedt omdat de programmeur niet zelf de low level machine code schrijft :)

Een kwaliteitscriterium voor projecten is begrijpelijk, ik vraag me af of dit de juiste is.

[Reactie gewijzigd door JasperE op 25 juli 2026 11:49]

En alsof je een compiler verbiedt omdat de programmeur niet zelf de low level machine code schrijft :)
Het verschil met een compiler is dat eeen programmeertaal deterministisch is, en de compiler dat ook is. Dus indirect zit je als mens heel erg aan het stuur.

Ik ben package maintainer van een matig populair open source project, en we zien gewoon de belabberde code kwaliteit van een LLM terug in PR's. De intentie van de mens is goed, maar men heeft niet het geduld of de kennis om een LLM echt de goede kant op te sturen. En dan komt er gewoon bagger uit. Dit gebeurt bij menselijk gegenereerde PR's ook wel, maar echt veel minder snel.

Zelf ben ik nu bezig met een flinke modificatie, en als experiment wil ik de prototyping via Claude doen. Ik merk dat sommige zaken echt veel makkelijker zijn (lijmlaag tussen database en typescript met honderden entiteiten is echt veel sneller), maar zodra we het hebben of logica van opslagstrategie dan loopt het toch veel stroever, zelfs met een heel concreet voorbeeld ernaast. Daar was met de hand bouwen toch sneller geweest.
Toch maar wat meer nuance dan. Ik denk dat de truc dan is dat je je llm agent via bijv. .claude/rules/*.md aangeeft hoe je wil dat er gewerkt wordt m.b.t. de opslagstrategie. Zonder richtlijnen en architectureel overzicht dat jij moet bieden, gaat de llm agent nog rare afslagen nemen met de huidige stand der techniek. Het is mijn ervaring dat als je goed in instructies vastlegt hoe er gewerkt moet worden, dus wat de architectuur is (dat vind ik ook deterministisch), Claude beter in staat is om betere code te schrijven dan 80% van de devs dat kunnen.

Een LLM code agent is een tool die in de juiste handen enorm productief kan zijn en betere kwaliteit kan afleveren, mits de eindbeoordelaar in staat is de output te beoordelen. Het iteratietempo van verbetering is dan simpelweg veel hoger dan voorheen ooit mogelijk was. Een andere manier om te zitten aan dat stuur waar je het over hebt dus


Helaas is een groot deel van de GitHub publicerende vibecoders opgebouwd uit een populatie van mensen die de architectuur waar precies jij het over hebt (opslagstrategie e.d.) niet op enig hoger abstractieniveau weten te beheersen/beschrijven/bij te sturen voor de agent, waardoor er inderdaad veel projecten van slechte kwaliteit zijn. En dat beïnvloed de mening van de meute die je hier terugziet.

De primaire reactie als het niet in een one-shot prompt goed is, is dan "zie je wel, het werkt niet", zonder te realiseren dat het met wat bijsturing, iteraties, en guidelines veel sneller een kwalitatief project wordt dan wanneer je het met de hand gaat programmeren.

Vandaar m.i. ook de irrelevant moderaties op tweakers hier, en medestanders die hopen dat a.i. binnenkort zijn tijd gehad zal hebben.

Misschien dit eens lezen: https://www.theregister.com/ai-and-ml/2026/07/15/linus-torvalds-tells-ai-haters-to-fork-off/5271894

Een comment van de Linux kernel beheerder, waaruit blijkt hoe zijn eigen beeld op llm programmeerhulp is bijgesteld n.a.v. wat sinds kort mogelijk is.

Mijn opmerking over anti-compiler was overigens eens niet mijn eigen originele idee, maar die van Linus Torvalds, beheerder van de Linux kernel. Toch niet de minste in de open source wereld. Hier de quote: YouTube: Keynote: Linus Torvalds, Creator of Linux & Git with Dirk Hohndel, F...

[Reactie gewijzigd door JasperE op 25 juli 2026 21:30]

Achja, mijn ervaring is dat mensen ook enorm bagger code schrijft, dus om nu precies uiteindelijk het verschil te weten tussen wat nu door mens of AI geschreven is, is nogal moeilijk te zien, tenzij er duidelijk bij de commit of in code dit aangegeven staat.

Het is gewoon een feit dat binnen een paar jaar AI echt betere code schrijft als de meeste developers (handvol wonderkids daargelaten). Zelf developer zijnde vind ik dat ook erg jammer, want ik vind bedenken en schrijven van code erg leuk, maar ben me wel bewust dat dat een job is die niet lang meer zal bestaan, buiten hobby. Ben nog van de oude garde die nog steeds zelden AI gebruikt, maar meer omdat het nog steeds niet in mn nusclememory zit om te gebruiken, vraag gaat bij mij nog steeds op de zoek/url balk van de browser (en mijn dagelijks te gebruiken IDE heeft geen integratie met AI).
En alsof je een compiler verbiedt omdat de programmeur niet zelf de low level machine code schrijft :)
Een compiler is zo deterministisch als je maar kan krijgen. AI is het tegenovergestelde van determinisme. Voed het genoeg data om B te gaan geloven en je krijgt er vandaag A uit maar morgen B ookal is er eigenlijk geen enkel reden om B als beter te zien.

AI gestuurd door een ervaren programmeur zal op zich ook het probleem niet zijn. Het probleem is echter dat door AI er een hele hoop wannabe coders in het open source wereldje zijn terecht gekomen die eigenlijk niet kunnen controleren wat de AI als resultaat geeft. Ik hoor van meerdere open source projecten dat daar het grote probleem zit. Ze leveren PR's en issues af die nog altijd manueel gechecked moeten worden, maar op niks slaan.

Dus voor een organisatie zoals Codeberg die open source kwaliteit hoog in het vaandel draagt vind ik dit persoonlijk geen vreemde stap.

[Reactie gewijzigd door Powerblast op 25 juli 2026 13:34]

Alsof je trein en rails verbiedt omdat paard en wagen nog steeds voldoet.
Alsof je fatbikes verbiedt voor sommige leeftijden en gebieden omdat gewone fietsen nog steeds voldoen...
En we laten lekker in het midden welke leeftijden wel en niet mogen rijden. Wat precies een fatbike of gewone fiets is... En de gebieden worden ook vaag omschreven.

"You must not share projects that mostly consist of code written by "generative AI"-tools"

Dat gaat helemaal goedkomen met die beleidswijziging!
Je klinkt alsof je denkt dat zoiets nooit gebeurd.
Nee, alsof je een zelfrijdende auto verbiedt omdat daar nog doden mee vallen en mensen tóch nog zelf verantwoordelijk zijn achter het stuur. Het is een leuk nieuw iets maar nog totaal onnodig en enorm risicovol
Gelukkig zie ik staan "projecten mogen delen", dus voor persoonlijke projecten is het nog steeds "ga je gang", mooi.

Ik probeer serieus over te stappen naar Codeberg, heb inmiddels een aantal projecten daar nu een aantal maanden staan, maar ik vertrouw Codeberg nog niet heel erg. Zo vaak hebben ze problemen, zijn ze onbereikbaar of gewoon ooontzettend traaaaag (als in, simpele page load duurt 30+ sec).
Van wat ik mee krijg is dat ook gevolg van alle scrapers die maar training data proberen te vergaren. Dus ook daarvan kun je AI de schuld geven als je wil
Was het maar alleen traag. Codeberg vervangt je repo soms met adversorial crap als dit zie ook https://codeberg.org/Codeberg/Community/issues/2603) als het je useragent/browser/ip niet vertrouwd met geen enkele manier dat weg te krijgen en toegang tot de repo te krijgen, en het is "working as intended" volgens de beheerders, false positives zijn dus geen probleem voor codeberg.

Aan de ene kant wil ik weg bij github en was ik twee jaar terug naar codeberg verhuisd, maar nog belangrijker vind ik dat mijn repo ook daadwerkelijk toegankelijk is en dat ik niet reacties krijg als wtf is dit als ik mensen naar de repo verwijs. Voorlopig dus maar weer terug naar github. https://framagit.org lijkt het beter te doen, maar ik ben weer even klaar met alternatieven.

Gezien bovenstaande verbaasd deze stellingname van codeberg mij niet, ze maken zichzelf wel een onmogelijk principiële niche repo host (met name ai code verbieden in repos) op deze manier, maar dat is de keuze van de beheerders. Jammer, codeberg werkte erg prettig.

[Reactie gewijzigd door Norjee op 25 juli 2026 14:01]

Ik heb bij github hetzelfde probleem, en daar kun je niet naar een andere browser wisselen die het wel doet omdat de blokkade op netwerkniveau gebeurt. Hun support kan er niks aan doen; bij Codeberg spreek je altijd met iemand die wel korte lijntjes heeft met de systeembeheerders of dat zelf zijn
Waar zie je dat staan?
Daarin staat nu dat gebruikers geen projecten mogen delen 'die voornamelijk bestaan ​​uit code geschreven door generatieve-AI-tools'.
"Delen" is het sleutelwoord hier toch? Dus voor eigen gebruik is het prima maak ik hier uit op.
Ze gaan geen facebookpolitie spelen om te zien naar welke projecten je linkjes deelt. Die tekst slaat op het uploaden van slop naar Codeberg waardoor het met anderen gedeeld wordt
Blijft lastig om te bepalen waar de lijn dan ligt. Ik ben zelf software developer, maar ben voor een hobby projectje best veel bezig met agents.

Ik heb de basis ooit zelf opgezet, nu schijf ik issues. Die laat ik door de agent implementeren. Vervolgens review ik de code alsof het de code van een junior is totdat ik er tevreden mee ben. Het geeft me meer controle over de code dan als ik het volledig los zou laten. Maar echt helemaal zelf is het echt niet meer.
Veel developers werken zo. En straks - is mijn stellige overtuiging - bijna iedereen.

Daarbij zijn er projecten in soorten en maten.
Ik heb als test - om te kijken hoe goed tegenwoordig llm's zijn - ook een keer een project volledig met LLM gemaakt. Dat zou nu niet daar gehost mogen worden?

Ook een POC/Demo gemaakt met een LLM... Een simpele html UI volledig met een LLM.

Zo zijn er toch altijd diverse projecten en projectjes. Moet ik nu die LLM projecten naar Github sturen terwijl ik prima tevreden was met CodeBerg?
Nee... ik heb geen zin in 2 platforms...
En wat gaan ze doen met de code die nu al op hun platform bestaat, volledig gemaakt met AI? Ronduit een grappig idee om te denken dat je dit nog kan verbieden.
Het is hun platform dus het zijn hun regels. Kunnen ze prima toepassen als ze dat willen.

Zal vast gewoon lukken zolang je geen actief controle erop krijgt, beetje hetzelfde als dat er in hun voorwaarden ook staat dat private repo's (mits wat uitzonderingen) niet zijn toegelaten. Maar als ze je er uit plukken heb je in principe geen poot om op te staan als er een takedown gebeurd.

[Reactie gewijzigd door Powerblast op 25 juli 2026 14:02]

Die vraag kwam in hun ook pas achteraf op. We gaan het nog zien
Zeer goede zet om hier uitgesproken over te zijn. Het is echt om van te janken hoe weinig respect er meer is voor intellectuele werken (zie bijv het massaal opkopen van boeken om ze in Het Magische Orakel(tm) te voeren en dan te shredden). De last die dit levert op het internet in brede zin is ook groot. AI-crawlers die zich op steeds slinksere wijze vermommen als gewone users, en tegenmaatregelen van mensen die dit niet willen die ook steeds vervelender worden voor gewone users, daarom is codeberg vaak gewoon plat omdat ze effectief worden geDDoSt

Absurd hoeveel mensen dit ook als zoete koek slikken want och het is zo makkelijk…

[Reactie gewijzigd door SampleUser op 25 juli 2026 14:35]

Opkopen van boeken? Ze downloaden gewoon illegaal hoor. Kijk maar naar Meta.
Dr zijn nog steeds meer analoge boeken dan digitale. Wat er beschreven wordt gebeurt gewoon. AI heeft een datahonger en de digitale data is op.
Ik zou mensen die codeberg gebruiken aanraden heel snel een ander platform op te zoeken. Het artikel hier geeft je het idee dat codeberg een moraalridder rol speelt en er zegt voor gebruikers die code zelf schrijven te willen zijn.

Mooi verhaal maar het is eenzijdig en als je hun blog leest is het meer een "te verkopen" reden. Bij het lezen van hun blog komt het meer over als een bedrijf wat in nood begint te komen doordat AI hun servers zwaar belast en doordat de opkomst van AI ervoor zorgt dat hun hardware upgrades nu wel heel duur beginnen te worden.

En mensen met een iets langer geheugen dan de hype van de dag zullen zich nog wel herinneren dat Github (voor de overname door Microsoft) er ook niet al te best voor stond. Andere open code repository projecten zijn gestopt omdat de hardware voor dat type content (en onderhoud van de servers) best behoorlijk is. Inkomsten genereren met dit type content is bijzonder lastig en zo vallen die platforms dan ook om. Denk maar aan Codehaus, Gitorious (opgegaan in gitlab), CodePlex en zelfs Google Code.

Codeberg zit in een lastig pakket. Gaan ze het overleven? Ik denk het niet.
Om het dan op te geven met "ze gaan het niet redden want AI maakt alles duurder" is ook geen oplossing. Er is een reden dat ik lid ben geworden met een jaarlijkse donatie.

Codeberg speelt geen moraalridder of marketingpraatjes, het is een vereniging waarvan het bestuur een beslissing van de ALV uitvoert.
Voor wie het wil weten: Codeberg is een Duits/Europees alternatief voor Github, onder andere. Voor wie misschien zijn codebase wil migreren https://docs.codeberg.org/getting-started/what-is-codeberg/#what-is-codeberg-e.v.%3F
Ze gebruiken gewoon Forgejo hoor. Niets meer niets minder. Als dit al de standaard is om een “Europees alternatief” te zijn voor GitHub, dan kunnen we elke self hoster al een alternatief voor GitHub noemen.
Forgejo is juist een spinoff van Codeberg (valt onder Codebergorganisatie) :)
Forgejo is net zo van Codeberg als dat Linux van Microsoft is omdat het op github gehost wordt. Door lid te worden van Codeberg krijg je ook niks te zeggen over Forgejo. Zover ik kan zien (als lid van Codeberg) is het een losse organisatie. Natuurlijk is er vast overlap in wie bijdraagt aan de projecten maar dat is met andere opensourceprojecten ook die niet een spin-off van elkaar zijn
https://forgejo.org/2022-12-15-hello-forgejo/

Het gaat er niet om dat het op Codeberg gehost is: Forgejo is door Codeberg van Gitea geforkt en wordt door Codeberg onderhouden.
Oh, thanks voor de correctie!
Forgejo is gebaseerd op Gitea. En Gitea is van Gitea limited.

[Reactie gewijzigd door Exodai op 25 juli 2026 12:15]

Denk dat je nog eens zult moeten Googlen.
Wat bedoel je juist? Forgejo is inderdaad een hard fork van Gitea. Ik self host het op mijn homelab, zelfs de root folder van de docker container noemt bij de Forgejo install nog gewoon /gitea :).
Forgejo is met uitzondering van AI ondersteuning on par met de meeste Github functies die aan git gerelateerd zijn. Het is inderdaad geen verkapte sociale media zoals Github.
Ik zou persoonlijk wel twee keer nadenken voor ik mijn projecten naar een platform als Codeberg verhuis. Nieuws als dit toont aan dat ze zich inhoudelijk sterk bemoeien met wat je er wel of niet mag hosten.

Dat is hun goed recht natuurlijk, en hoeft geen probleem te zijn. Maar een één-op-één GitHub-alternatief is het (blijkbaar) niet.
GitHub bemoeit zich anders ook genoeg hoor, als je dat niet wil zul je zelf moeten hosten. (Wat met Forgejo natuurlijk perfect kan)
nog steeds van toepassing:
"A Fool with a Tool Is still a Fool" of
"A Fool with a Tool Is an Amplified Fool"
Ik ben niet tegen AI als hulpmiddel voor Software Dev..
Met AI zul je straks zien dat er meer ernstige ongelukken gaan gebeuren.
Mensen denken dat ze iets goed kunnen automatiseren . Je krijgt altijd antwoord (zoals dat met SQL ook begon), of het juist/zinnig is, is een 2de.

De kunst blijft je goed te verdiepen in de materie die je wilt automatiseren en vervolgens het zodanig op te zetten (architectuur) dat het robuust, betrouwbaar en aanpasbaar is. Iets overdenken een paar dagen laten berusten helpt daarbij ook heel goed.
Geldt voor een hele hoop zaken in het leven.

CodeBerg streef naar goede betrouwbare software en het is nog te vroeg om geheel AI gegenereerde software als robuust/betrouw/uitbreidbaar te zien. Als hulpmiddel is AI prima.

Op the bachelor-diploma uitreiking (2024) van mijn zoon op Technische Universiteit Eindhoven vroeg het nieuw "hoofd" van de (sub) faculteit "Data Science / AI" zich af , "moeten we de nieuwe lichting studenten nog programmeren (inc. Architectuur, etc..) leren"? Ik heb daar een paar weken over nagedacht en mijn antwoord is: JA (ook de basics). Het is net zo als rekenen en lezen/schrijven erg belangrijk dit goed te kunnen. Trouwens ook van de geschiedenis kun je een hoop leren om het in de toekomst beter (overdacht) te doen.
Er stond in het NRC een interessant artikel (achter de betaalmuur):
https://www.nrc.nl/nieuws...oed-gedaan-wordt-a4932479
De activist/schrijver Cory Doctorow waarover het NRC artikel gaat, publiceert veel op:
https://pluralistic.net/

[Reactie gewijzigd door Antonio di op 26 juli 2026 14:28]


Om te kunnen reageren moet je ingelogd zijn