github copilot's routekeuze
Categories:
copilot was van afgelopen februari tot juli onbeperkt te gebruiken in vscode insider, ik heb in deze periode gezien hoe de agent-capaciteiten van copilot geleidelijk achteruitgingen. Het is moeilijk voor te stellen dat de eerste maand preview-versie van copilot eigenlijk het beste werkte, waarna de agent-capaciteiten geleidelijk daalden. Wat is er precies veranderd? Het is dat de ontwikkelings- en evolutierichting van copilot in het afgelopen jaar meer was gericht op “token besparen”. Vroeger lazen de agents van iedereen bestanden in één keer volledig, qwen cli/claudecode/gemini/copilot deden dat allemaal vroeg, met zeer goed resultaat, alleen was het tokenverbruik waarschijnlijk behoorlijk groot, en raakte de context ook snel vol; als je de context opnieuw opbouwde, daalde de cache-hitrate. Later stapten ze allemaal over op gefragmenteerd lezen: sommigen lazen tientallen regels rondom een grep, en lazen meer als het niet genoeg was; anderen gebruikten gestructureerde codetools zoals LSP om te lezen. De agent van copilot las bestanden van boven naar beneden, 50 regels per keer, soms 200 regels, maar bleef van boven naar beneden lezen. Gecombineerd met de standaardlimiet van 50 tool-aanroepen en een invoercontext van minder dan 200k, was het werk dat het kon voltooien vrij beperkt. Vroeger maakten alle aanbieders verlies, met de verwachting de ecosysteempositie tegen lage prijs te veroveren en later de kosten te verlagen, maar in dit meer dan jaar durende traject bleek eindelijk dat de kosten niet omlaag konden; door kosten met geweld te verlagen zou je eigen product een derderangs product worden. Dus bekritiseer copilot niet te veel, alle agents die aan tafel zitten rekenen al per token, en copilot is er al een die achterloopt. Nu het historische juk van per-keer afrekenen is afgeworpen, hoop ik dat copilot zijn agent goed verbetert en de grote groep volgt, want het is nog steeds het best geïntegreerd met vscode. AI-tools mogen duur zijn, maar ze mogen niet te slecht zijn.
