Ingenieursbeslissingen gebeuren niet in IDE-zijdebalken.Ze gebeuren in Slack-draden, op dezelfde plaats waar uw team al praat, debuggt, al samen aan problemen werkt. That disconnect is a problem. Het gesprek over Om te bouwen gebeurt op één plek, en het werkelijke gebouw gebeurt ergens anders volledig. Context wordt verloren. Beslissingen worden opnieuw uitgelegd. Iemand kopieert onvermijdelijk een probleem in een AI-chat ergens en past het antwoord terug, en iedereen doet alsof het een normale workflow is. Wat Ik heb net iets verzonden dat dit eigenlijk aanpakt: Het team achter het heeft de bot al maanden intern gebruikt, en het heeft fundamenteel veranderd hoe ze bouwen en verzenden. Kilo Slack integratie Kilo voor Slack stelt u in staat om een AI-coderingsagent rechtstreeks in de gesprekken van uw team @ te vermelden. Het leest de volledige threadcontext, verbindt zich met uw GitHub-repos en kan vragen beantwoorden of PR's openen zonder dat iemand Slack verlaat. H en dr: Kilo voor Slack . H en dr: Try Kilo for Slack Kilo voor Slack . De contextwisselende belasting Hier is een scenario dat waarschijnlijk bekend is. Iemand meldt een bug in een team Slack-kanaal. Drie ingenieurs schudden in met theorieën. Een ontwikkelaar scrollt door de draad, absorbeert de context, vervolgens alt-tabs naar hun IDE. Ze openen hun AI-codering agent van keuze en beginnen de situatie opnieuw uit te leggen vanaf nul. Ze plakken de fout. Ze beschrijven wat is geprobeerd. Ze verstrekken de context die al in die Slack-draad was, behalve nu ze het opnieuw typen. De oplossing wordt geïmplementeerd. Een PR gaat omhoog. Dan is het terug naar Slack om de link te delen en samen te vatten wat er is veranderd. Dit gebeurt tientallen keren per week op actieve engineering teams.En elke keer, er is een wrijvingsbelasting.De contextoverdracht, de herverklaring, de mentale verschuiving tussen "discussie modus" en "implementatie modus." Het is niet een enorme belasting voor een enkele instantie, maar het voegt toe.En nog belangrijker, het creëert een kunstmatige grens tussen waar beslissingen worden genomen, en waar werk wordt gedaan. Wat Kilo voor Slack eigenlijk doet Neem dezelfde Slack-draad: de bug is besproken, theorieën zijn overstroomd en er is ruwe consensus over wat er moet gebeuren. @Kilo based on this thread, can you implement the fix for the null pointer exception in the Authentication service? De bot leest de hele draad, en aangezien het is verbonden met de GitHub repos van het team via het Kilo-platform, draait het een Een paar minuten later is er een PR-link daar in Slack. Cloud Agenten Geen kopiëren. geen alt-tabbing. geen twee keer hetzelfde uitleggen. de context die al bestond in het gesprek wordt de input voor de implementatie. Voor eenvoudige vragen werkt het op dezelfde manier: @Kilo how is error handling implemented in the payment module? Het leest uw codebase en reageert in de draad. teamgenoten kunnen het antwoord zien, en u kunt opvolgingen vragen en implementatieinstructies geven. Hoe het Kilo-team dit eigenlijk gebruikt Het team heeft Kilo voor Slack intern gebruikt sinds vóór de publieke lancering, en het is de standaard manier geworden waarop veel veranderingen worden gemaakt. De opkomende patronen zijn meer gevarieerd dan verwacht: Real-time bugfixes Waarschijnlijk de meest voor de hand liggende gebruikssituatie, en degene die voortdurend wordt geraakt. Een fout verschijnt in de productie. Iemand vlaggen het in Slack. Het team bespreekt wat het zou kunnen veroorzaken. En dan in plaats van iemand vrijwilligerswerk om "het te bekijken," ze gewoon tag @Kilo. Het belangrijkste ding: de bot begint niet vanaf nul wanneer het dat probleem leest. Het heeft de volledige context van het gesprek en toegang tot de hele codebasis. Het kan lezen wat het team vermoedt en wat is uitgesloten. Het weet wat het verwachte gedrag zou moeten zijn. Het werkt met dezelfde informatie die een menselijke ontwikkelaar zou hebben na het lezen van de draad: @Kilo I'm seeing this error in production: [stack trace]. Based on what we discussed above, can you create a PR with a fix? De PR landt in de draad. Iemand beoordeelt het. Als het er goed uitziet, wordt het samengevoegd. De hele cyclus gebeurt zonder dat iemand de taak formeel "opneemt". Snelle codewijzigingen van discussies Dit is iets dat een dagelijkse ervaring is geworden voor veel mensen bij Kilo. Een gesprek gebeurt over een functie of gedrag. Iemand zegt "we zouden waarschijnlijk X naar Y moeten veranderen." In een traditionele workflow, dat wordt een mentale notitie, of een ticket, of iets dat wordt behandeld "later." Met de Slack-bot wordt "later" "nu precies".De persoon die het idee had, labelt Kilo en beschrijft wat moet veranderen. @Kilo please change "2025" to "2026" through all of the announcement files in our kilo-org/kilocode repo Voor een team dat snel beweegt, is dit belangrijk.De wrijving op kleine veranderingen is wat ervoor zorgt dat ze zich ophopen.Het verwijderen van die wrijving betekent dat de codebase schoner en actueler blijft. Documentatie en content-updates Dit geldt voor mensen in minder-technische of niet-technische rollen. Het Kilo-team gebruikt de bot voor allerlei wijzigingen over het hele Kilo-platform voortdurend. landingspagina-copie, handleidingsaanwijzingen, documentatie-updates, README-verbeteringen. Het patroon is hetzelfde: er vindt in Slack een discussie plaats over wat moet veranderen, en dan implementeert de bot het. @Kilo the getting started guide is missing the new authentication flow. Can you update it based on what we discussed in this thread? Voor content die in een repo leeft (die, als je docs-as-code doet, het grootste deel van je inhoud is), is deze workflow een enorme tijdbesparing. Vooral voor mensen die zich overweldigd voelen door te duiken in een ontwikkelingsworkflow om een eenvoudige landingspagina-verandering te maken. Het PR-proces geeft je hetzelfde beoordelingsmechanisme dat wordt gebruikt voor code, en de Slack-draad biedt de gemak van toegang. Implementatie van functies uit Spec Discussions Soms evolueert een thread van "doen we dit?" naar "hier is ongeveer hoe het zou moeten werken" naar "okay, laten we het eigenlijk bouwen." @Kilo please implement the caching improvements we discussed in this thread Dit werkt het beste wanneer de draad voldoende specificiteit bevat. De bot is goed in het infereren van intenties, maar duidelijker context leidt tot een betere output. Cross-Repo coördinatie Echte technische werkzaamheden bestrijken meestal meerdere repositories. Frontend, backend, gedeelde bibliotheken, infrastructuurconfiguraties. In tegenstelling tot sommige andere Slack-integraties geeft Kilo automatisch aan welke repo wordt verwezen. @Kilo the API change we discussed needs updates in both the backend service and the frontend client. Can you create PRs for both? Geen handmatige configuratie per kanaal. geen schakeling context om te specificeren welke repo te gebruiken. Het leest de draad, begrijpt wat wordt verwezen en handelt dienovereenkomstig. Waarom dit anders is dan andere Slack-bots Veel AI Slack-integraties voelen zich als nieuwigheden - ze zijn algemeen bedoeld door AI's die proberen zich te maskeren als een specialist in elke categorie. ze beantwoorden vragen, misschien genereren ze wat code-snippets, maar op het moment dat er iets niet-triviaals opkomt, is het terug naar het kopiëren in een IDE. De aanpak van Kilo is architectonisch verschillend op manieren die van belang zijn. Multifunctionele gesprekken De meeste AI Slack bots zijn ontworpen voor one-shot interacties. Stel een vraag, krijg een antwoord. Follow-ups beginnen in wezen een nieuw gesprek. Kilo bouwt op de hele draad. Het onderhoudt de context over meerdere uitwisselingen. Een back-and-forth discussie kan plaatsvinden, de aanpak kan worden verfijnd, verduidelijkende vragen kunnen worden gesteld, en vervolgens implementatie kan worden geactiveerd. Dit weerspiegelt hoe menselijke gesprekken werken. niemand legt de hele situatie opnieuw uit elke keer dat ze aan een discussie toevoegen. Multi-Repository door de standaard Cursor's Slack-integratie vereist het configureren van één repository per werkruimte of kanaal. Dat is prima voor eenvoudige setups, maar het breekt snel af wanneer engineeringwerk meerdere repos overspant. Kilo verwijst het relevante repository uit de conversatie. Als bestanden of diensten die in verschillende repos worden genoemd, wordt dat behandeld. geen voorlopige configuratie. geen schakelen tussen kanalen om met verschillende codebasen te werken. Dit lijkt een klein ding totdat je hebt gewerkt aan een project waar de frontend, backend en infrastructuur allemaal in een afzonderlijke repos leven. Echte uitvoering, niet alleen chatten Dit is het fundamentele verschil. Kilo voor Slack is geen Q&A-bot. Wanneer gevraagd wordt om iets te implementeren, draait het een cloudagent op, creëert een tak, maakt de wijzigingen en opent een PR. Het doet het werk, niet alleen praten over het werk. En omdat het de cloudagenten van Kilo gebruikt, is er geen lokale machine betrokken. De repo hoeft niet lokaal te worden gekloond. De implementatie vindt plaats in de cloud en het resultaat verschijnt als een PR klaar voor beoordeling. Context met PRs Zodra er een PR bestaat, kan de bot er verder aan werken.Als feedback komt, kan Kilo gevraagd worden om het in dezelfde draad aan te pakken.Het gesprek over de PR en de implementatie van veranderingen vindt plaats op dezelfde plaats: @Kilo the reviewer asked for better error handling in the auth flow. Can you update the PR? Er is een voortdurend gesprek over wat er wordt gebouwd, en de code evolueert in reactie op dat gesprek. De technische details Voor degenen die nieuwsgierig zijn hoe dit eigenlijk werkt onder de hoed: Wanneer @Kilo wordt genoemd in een kanaal of DM, leest de bot de draadcontext. Het heeft toegang tot verbonden GitHub repositories (eenmaal ingesteld in het Kilo-dashboard). Op basis van het verzoek reageert het ofwel met informatie of schakelt een cloudagent uit om wijzigingen te maken. De zijn dezelfde die beschikbaar zijn van de Kilo CLI of dashboard. Ze lopen in de infrastructuur van Kilo, creëren takken, maken commits en open PR's tegen repos. Cloud Agenten Prijzen zijn gebaseerd op gebruik, met dezelfde kosten per token als het gebruik van het model rechtstreeks via Kilo - wat betekent dat u alleen wordt gefactureerd tegen precies de prijzen die door de modelproviders zijn vastgesteld. Het opzetten van De installatie duurt ongeveer twee minuten: Kilo account aanmaken (gratis om te beginnen) Connect GitHub repos in het tabblad Integraties op app.kilo.ai Voeg de Slack-integratie toe van dezelfde pagina Integraties Begin met vermelden of DM-ing @Kilo in de werkruimte Kilo rekening Integratie tab Slack integratie De bot kan direct worden DM-ed voor privé vragen, of vermeld in elk kanaal waar het is toegevoegd voor team zichtbare interacties. De GitHub-verbinding is het belangrijkste onderdeel - en duurt ongeveer 10 seconden en 2 klikken.De bot heeft toegang nodig om te herstellen om vragen over de codebase te beantwoorden en om PR's te maken. Wat te gebruiken voor Sommige patronen zijn ontstaan voor waar dit schijnt: De overhead van het openen van een IDE, het vinden van het juiste bestand, het maken van een verandering en het duwen van een PR is hoog in relatie tot het werk zelf. Wanneer de "wat" en "waarom" al zijn vastgelegd in een draad, voelt het natuurlijk om gewoon de "do it" aan het einde toe te voegen. Documentatie en inhoud. Alles wat in een repo leeft, maar niet strikt codeert. READMEs, gidsen, configuratiebestanden, landingspagina kopie. Wanneer een wijziging meerdere repositories moet aanraken, is het beheren van dat van een enkele Slack-draad schoner dan bouncing tussen IDE-vensters. Mobiele en asynchrone situaties Een PR kan vanaf een telefoon worden gestart. Het werk gebeurt in de cloud. Wanneer het idee nog steeds wint Dit is geen vervanging voor een ontwikkelomgeving, het is een aanvulling. Snelle iteratie, lokale testen en real-time verfijning willen nog steeds de IDE of Kilo CLI. Stappen door middel van code, inspecteren van de staat en begrijpen van gedrag vereist volledige tooling. Grote architecturale veranderingen profiteren van de volledige context die een IDE biedt. Kilo CLI Het mentale model: Slack-first voor veranderingen die voortkomen uit gesprekken, IDE-first voor veranderingen die diepe engineering vereisen. Het breder platform Kilo for Slack maakt deel uit van Kilo's grotere, end-to-end agentschapstechnische platform. - het De En de kilo’s De Hetzelfde platform, dezelfde 500+ modelkeuzes, en dezelfde kwaliteit, alleen toegankelijk vanaf een ander oppervlak. VS Code JetBrains Kilo CLI Cloud Agenten Slack integratie Wanneer u klaar bent met bouwen in Kilo, kunt u ook AI-aangedreven Een klik , en zelfs delen van uw sessies in uw team met . Code beoordelingen Deployment Kilo sessies Het gaat niet alleen om welke tool de beste code genereert - wat onbetwistbaar belangrijk is - maar het gaat ook om welke tool past in de werkelijke workflow met de minste wrijving. De plaats waar teams de code bespreken kan nu de plaats zijn waar de code wordt geschreven. De discussie en de implementatie gebeuren samen. Dat is het soort workflow-verbetering dat na verloop van tijd samenvoegt. > > Kilo proberen voor Slack nu Kilo proberen voor Slack nu Kilo is een open source AI codering agent met meer dan 1 miljoen gebruikers. Het is verkrijgbaar in VS Code, JetBrains en CLI, Cloud Agents, live preview App Builder, one-click deployments, geautomatiseerde code reviews en nu Slack integratie. Kilo.nl . Kilo.nl
