Wenn ich eine freundliche AI frage, erhalte ich nach wenigen Prompts schon sowas, reicht Dir das nicht? So weit ich weiß, nimmt die "Aufmerksamkeit" für einzelne Details mit der Menge der Regeln ohnehin ab, die ganze API hineinzukippen, bringt also nichts.
Oder hab ich Dich und Dein Ziel falsch verstanden?
Ein Skill mit referenzierten Dokumenten wird nicht gesamt in den Kontext geladen - sondern nur die Skills (via Frontmatter) und Referenzen im SKILL.md die matchen. d.h. wenn man die *.md entsprechend strukturiert und den Inhalt kurz in der SKILL.md beschreibt, werden auch nur relevante Dokumente geladen. Da die Trainingsdaten zum Teil veraltete Versionen etc. enthalten ist eine solche Guideline nützlich. Ihre CLAUDE.md ist sehr gut gemacht, kann aber in eine Skill umgewandelt werden, die dann eben nur bei Bedarf geladen wird ohne den Kontext vollzuballern (die Claude.md wird hingegen immer geladen). Claude Opus 4.6 hat ein Kontextfenster von 1 Mio. Token - das wären ca. 1500 Seiten Manual ..... aber ja - einfach reinladen ist kontraproduktiv wegen Haystack Problemen. Aus Ihrem claude.md eine skill zu machen ist trivial (z.B. via superpowers skill-writer skill - eine skill zum erstellen von skills) - ziemlich meta, nicht wahr ? Denkbar ist statt referenzierten Dokumenten auch die Aufteilung in mehrere Skills nach Thema - z.B.
PBS, ceph,, etc. kann man in eigene Skills auslagern (oder eben als referenzierte Dokumente). der skill-writer skill unterstützt z.T. auch TDD für den Skill, d.h. vergleicht Antworten mit und ohne dem skill .... ziemlich krass. Der skill-writer skill ist zwar ein bisserl buggy, aber für mich funktionierts ganz gut.
Sie können das auch z.B. mit context7 MCP Server lösen, aber ich habe lieber eigene Skills lokal liegen - das ist deutlich schneller und die Dokumente sind unter meiner Kontrolle.
Bei den kritischen Stimmen, darf ich fragen mit welchen Modellen Ihr eure Annahmen und Aussagen validiert habt ? Es macht einen RIESEN Unterschied ob man freie Versionen, oder alte Modelle verwendet, im Vergleich zu z.B. Opus 4.6. Ich höre hier "muss mir einen Prompt überlegen" und "validieren ob die Antwort korrekt ist" - so läuft das schon lange (also im richtigen Leben seit Monaten) ;-) nicht mehr.
Eine LLM als Google Ersatz zu sehen ist nicht wirklich von großem Nutzen.
Beispiel: nach dem letzten PVE update in der letzten 14 Tagen hat ein Container nicht gestartet.
Prompt : Container 200 startet nicht, analysiere warum ?
Vorgang : Claude versucht den Container zu starten, analysiert die Logs, testet diverse mount Befehle, gibt einen verständlichen Fehlerbericht und einen Vorschlag wie das Problem zu beheben ist (es war eine Regression der neuen PVE Version mit einem am Host gemounteten NFS Share mit Root Squash) - das hätte ich mit Google sicher ebenfalls lösen können, aber ich hätte viel länger dafür benötigt.
Ich würde selbst bei genauester Formulierung einer solch stochastischen Maschine nie den produktiven Betrieb anvertrauen.
Ich bin auch eine stochastische Maschine. Insbesondere wenn etwas nicht geht und mir die User um 5 Uhr früh im Nacken sitzen. Und ich kann jeden Befehl ja rückbestätigen wenn ich das möchte. Oder auch nur invasive Befehle. Siehe oben das vorzügliche CLAUDE.md
Moderne LLM´s befolgen Befehle sehr gut.
Siehe den von mir verlinkten Post von uberspace. Ich halte da einen Hoster (dessen Geschäftsmodell immerhin darauf beruht möglichst viel Traffic für seine Kunden zu verarbeiten) da für glaubwürdiger, als unsere individuelle Erfahrung
Sie wollen also das gleichzeitige scrapen von claudebot mit 5000 IP Adressen die sich um robots.txt nicht scheren mit dem einmaligen scrapen von legitimen content vergleichen ? Das ist ein strawman argument.
Es gibt Studien wonach KI auch Entwickler nicht schneller macht (also messbar nicht schneller), sie glauben es halt nur, weil es halt ein schönes Spielzeug ist.
Es gibt auch Studien die behaupten das der Klimawandel nicht echt ist. Ich kann nur aus eigener Erfahrung anekdotisch sagen, das agentische Arbeitsweise meinen Output vervielfacht hat - und einige Software überhaupt erst ermöglicht hat. Beispielsweise habe ich grade die Firmware einer alten Canon IXUS 870 mit Ghidra deassembliert um daraus eine Webcam zu machen, weil war mir zu schade zum wegwerfen - ein Projekt das ich "zu Fuß" niemals gemacht hätte (zu Zeitaufwändig, und Wissen das ich sonst nirgends verwenden kann - Schreibe sonst keine Software für ARM noch verwende ich Ghidra täglich. Claude hat einen H.264 encoder dafür in C für ARM implementiert der funktioniert, selber den Framebuffer über Spies gefunden, das color mapping korrigiert, etc. etc. - mach das mal als Sideproject an drei Abenden ! Ich würde sagen Claude hat mich hier mindestens um den Faktor 500 schneller gemacht. Ich hätte mich in Ghidra, Ghidra Skripte, ARM, MJPEG, H.264 etc. einlesen müssen. Ich muss Dir aber zustimmen das man zumindest wissen muss was das alles bedeuted - und die Wissenslücken eben bei der LLM hinterfrägt. Das Weltwissen ist nur einen Prompt away, und die LLm kann es auch sofort umsetzen. Einfach phantastisch ! Im Moment dekompiliert Claude mit Ghidra weitere Teile der Firmware um den Hardware MJPEG Encoder endlich zum laufen zu bekommen - die vorhandene ARM CPU schafft per Software Encoder nur ca. 2FPS bei 640x480, a bisserl lahm das Teil.
Ein anderes Beispiel (selbst erlebt) war, wie sich jemand ein Skript von einen LLM hat erstellen lassen um ein Feature zu haben, was eines der vorhandenen Tools schon hatte (über eine entsprechende Option auf der Konsole) und auch in der Hilfe (--help) bzw. manual page dokumentiert war
Ja das kann passieren - weil man eben auch die LLM´s bedienen können muss. Wenn ich vorgebe "baue XY" so macht die LLM das. Wenn ich vorher frei mit der LLM diskutiere, ein Deep Research mache ob es bereits Lösungen für das Problem gibt, etc. dann wäre das vermutlich nicht passiert. Auch diese Fertigkeit muss erlernt werden - ich glaube das reine code monkeys aussterben und das ist auch gut so. Der selbe Student hätte das selbe nutzlose feature auch ohne LLM bauen können. Ich sehe hier nicht die Relevanz. Ich sehe es einfach als neue Abstraktionsebene - so wie wir von Maschinencode über Assembler zu C zu Fortran, Cobol zu whatever gekommen sind. Ich kann sinnvolle Software schreiben ohne Assembler zu beherrschen oder ? Ich mein, es schadet nicht, aber es muss auch nicht sein, Gut - es hilft den vollen Weg vom Transistor / Mosfet / Register / ALU / DMA / Interrupts bis rauf zu Objekten, Lambdas, Functional Programming etc. im Überblick zu kennen aber die Details muss man dann ohnehin nach Jobprofil auffüllen oder ?
Was der gute Mann nicht sieht, aber worauf ihn einer seiner Mitentwickler hingewiesen hat: KI macht es Leuten leichter, die ihren Lebenslauf mit einen Beitrag zum Linux-Kernel aufhübschen wollen, aber eigentlich keine Ahnung haben, irgendeinen Bullshit einzureichen, der dann erstmal aufwändig reviewt werden muss.
Welcher aufwändige Review ? Mein Review Prompt zu einem PR ist kurz und knackig: worum geht es in diesem PR, welche Probleme löst es, passt es ins Gesamtkonzept oder gibt es vorhandene oder bessere Lösungen. Roast the PR relentlessly --- Fertig Arbeit. Probieren Sie es einfach aus, sollten Sie den PR noch haben. - und bitte nicht in ChatGPT, sondern in Opus4.6 oder dem neuesten OpenAi Codex Modell. Im übrigen scheint es mittlerweile sinnvoll zu sein die verwendeten prompts im PR zu inkludieren, um den Entstehungsprozess der immer größer werdenden PR´s zu verstehen und zu redigieren.
Wäre ich ein Lehrender (ich glaube allerdings dazu bin ich gänzlich ungeeignet) würde ich genau das verlangen - weil ich davon ausgehen würde das der Code von LLM´s geschrieben wurde - ich würde das Log der verwendeten Prompts als Anforderung stellen und DIESE benoten. Nicht den Code.
Um zum Ursprung zurückzukommen - ich wäre dankbar wenn Ihr als Proxmox Spezialisten den Skill sobald er fertig ist dann mal ansehen könntet auf einem Testsystem - gerne auch mit kniffligen Fragen.
Auch die Linux-Foundation hat eigentlich kein Budget-Problem, warum setzen sie dann Tools ein, um Scraper rauszuhalten? An grundsätzlicher Apathie kann es doch kaum liegen, sind LLMs für Thorvalds doch "einfach nur ein weiteres Tool" (1)
