GitHub CoPilot

Hi, nachdem es hier ja ev. ein paar Wissende gibt wie die AIs so aufgebaut sind.

Ich arbeite mittlerweile recht viel mit ChatGPT & CoPilot weil sie viele Tasks extrem vereinfachen, besonders wenn es darum geht mal schnell Scripte für irgendwelche komplexeren Tasks zu generieren.
Das funktioniert prinzipiell recht gut, bleibt natürlich immer die Frage des Datenschutzes (und vermutlich kann die in Wahrheit niemand tatsächlich prüfen außer z.B. Microsoft selbst).

Mich würde das Prinzip von den Code-Vorschlägen vom GitHub CoPilot der z.B. in VS Code eingebettet ist interessieren.
Der schlägt ja automatisch weiteren Code oder Kommentare vor, d.h. der hat ja automatisch Zugriff auf alle Dateien die ich offen habe.

Jetzt lese ich z.B.: https://github.com/orgs/community/discussions/133245

Zitat

How can Copilot provide responses that seem to know my code?
Copilot generates code suggestions based on the context provided within your current file or the prompt you've given it. It uses a language model trained on a vast amount of publicly available code and text, but it does not have the ability to access or read your specific codebase. This means that while it can generate code that looks like it fits within the context of what you're working on, it does not actually see your code.

Hä? Wie kann das Sinn machen? Um ähnlichen Code vorzuschlagen muss ja mein aktueller gelesen werden auf irgendeine Art und Weise?
Wie kann der Code dann NICHT zu Microsoft wandern?
Technisch würde mich das interessieren wie das funktionieren soll (aber vermutlich tut es das eh nicht - wenn doch erleuchtet mich bitte )

Kanns im Detail auch nicht sagen - vermute VS Code hat natürlich auf deinen Code Zugriff und wird bevor der zu Copilot geschickt wird diesen bereits in Vectoren abbilden (oder wie auch immer).

Glaub die Grundaussage ist, dass MS nicht deinen Code zum Training von Copilot verwendet. Alles andere ist zumindest für mich irrelevant.

"but it does not have the ability to access or read your specific codebase"

So wie ichs verstanden hab: Github Copilot (Cloud) keinen direkten Zugriff auf deine Codebase. Copilot (lokal) hat natürlich Zugriff, und erstellt aufgrund deiner Codebasis einen Index, der dann für die weitere Kommunikation verwendet wird.

Aber wie genau das abläuft, wenn man explizit mehrere Files zum Prompt für Chat/Agent hinzufügt, frag ich mich auch.

Gibt einen Artikel dazu, der sehr detailliert ausschaut:

Bei auto-suggest wird "Code" mitgeschickt, das ist der "context", ohne geht's schwer.

Ich verwende seit ca. halbem Jahr ausschliesslich OpenCode as Agent (hab mir die anderen nie naeher angeschaut). Wir verwenden aber schon ein gut angepasstes setup (laeuft in docker [kleine sandbox], pre-konfigurierete mcp, skills, commands, etc.).

Zitat

z.B. konnte Copilot mir durch füttern eines Jira Tickets (Atlassian MCP), Figma Designs und API Sample Response recht gut neue Componenten mit der selben Struktur wie im bisherigen Projekt erstellen, allerdings waren Types dann nicht 100% korrekt und ein paar andere Krankheiten, die ich manuell gefixed habe, aber als Kickstarter spart sowas schon Zeit.

Bei uns in der Praxis hat sich gezeigt dass ein AGENTS.md hier extrem viel hilft. Das ordentlich aufgesetzt was die Details betrifft (wie tests ausfuehren, wie der ueberblick uber die API, dieses sub-modul), das hat extrem viel boost gebracht dass der agent besseren code liefert. Also je nach komplexitaet bis zu code, den ich gar nicht angreifen muss. Und das .md auch warten: sobald ich seh der Agent macht was, was ich nicht erwarten wuerde -> sofort im agents.md erweitern, fuers naechste mal.

Insofern wuerd ich zu dem Website problem sagen, ja gib ihm die docs. Aehnlich Ballmer damals: "context context context!".

Andererseits das grosse Problem ist der Context

Man muss such Github Copilot vorstellen wie "models fuer Masse": cheap, aber nicht das beste Service. Hauptsaechlich beudeutet: kleinere Token-Context und geringere rate limits bei den Premium modellen.

Opus ist das beste Modell mit dem ich gearbeitet habe, aber extrem teuer. Das Problem bei Github: auch bei diesem Modell hat du "nur" 120k oder so context und sehr hohes (globales!?) rate limit.

Das selbe Modell bei AWS Bedrock hat > 200k context. Das macht dann bei komplexeren / laengeren Tasks "den unterschied". Aber Bedrock ist NOCHMAL teurer als github. Hier kannst du mit ein paar heavy tasks in ein paar stunden bis zu 100 USD verbraten.

Context managen ist das "a und o", sobald dir wichtig facts auslaufen, derailed das teil schon mal leichter.

Aus der Praxis wie ich context "spare":
- sub-agents: die haben ihren eigenen context, nehmen weniger vom haupcontext weg, geben schon vorgekaute infos zurueck
- mcp als sub-agents tarnen: das problem bei manchen MCPs ist, dass sie so viel context bieten, dass sie viele Tokens fressen. Wir haben in unserem Team 5 default MCPs und wenn die alle geladen werden, sind 50k schon weg. Der Trick hier, in dem sub-agent zu beschreiben wann welche MCPs zu verwenden sind und der agent laedt sich den ganzen context des jeweiligen MCP dann nur, wenn er (wie im markdown definiert) gebraucht wird. Da warens dann by default nur mehr 10-15k token weg. Der technische Kniff im opencode ist: der haupt-agent darf nicht auf MCP zugreifen (sieht sie nicht, contex wird nicht polluted) und fuer jeden MCP gibt einen sub-agent der aber nur Permissions auf den jeweiligen mcp hat ("sieht" die anderen nicht). Und die laufen auch meist mit dem kleinsten modell weils fuer summaries ausreicht (z.b. haiku).

HTH!

Agents.md Files lokal laden und lesen hat bei unseren Tests auch besser geklappt.
Ich hab mir vor Weihnachten spec-kit angesehen (von Github / Microsoft ein KI Framework zum erstellen von Tickets)

Kontext ist immer wichtig - das Wissen zu transportieren und in verdauliche Häppchen bereitzustellen habe ich noch nicht gelöst. Die Kontextgrenzen der aktuellen KI sind auch für kleine Projekte zu bescheiden.

Ich bin aber aktuell wieder mehr mit lovable dran an Prototypen zu werkln