Het artikel bespreekt het risico dat engineers hun kritisch denkvermogen uitschakelen bij het gebruik van AI, een fenomeen dat ook wel de 'Meat Proxy' wordt genoemd. Om dit te voorkomen, introduceert de auteur de Brain Sandwich, een driestappenplan voor een effectieve workflow:
- Je brein (De eerste laag): Voordat AI wordt ingezet, moet de engineer het probleem eerst zelf analyseren en een ruw plan maken om te voorkomen dat de AI de verkeerde richting op gaat.
- AI (De vulling): De AI wordt gebruikt voor de daadwerkelijke uitvoering en implementatie van het werk.
- Je brein (De laatste laag): De engineer reviewt het resultaat, controleert de complexiteit en zorgt dat de wijzigingen volledig uitlegbaar zijn voordat ze worden ingediend.
Het doel van deze methode is om de productiviteit van AI te benutten zonder dat de eigen expertise van de ontwikkelaar verloren gaat.
De Brain Sandwich
(Trouwens, ik heb gehoord dat de 'hippe kids' dit een Meat Proxy noemen.)
De reden dat ik besloot hierover te posten, is dat Emily een heel eenvoudig raamwerk gebruikt voor het werken met AI, dat ze de "Brain Sandwich" noemt, wat dit probleem oplost. Het gaat erom dat je optimaal gebruikmaakt van AI zonder dat je engineering-vaardigheden atrofiëren (verslappen).
Het idee is zeer simpel en kan als volgt worden samengevat: wanneer je aan iets werkt, zou je het volgende moeten gebruiken:
- Je brein, en dan
- AI, en dan
- Je brein
Een verdere toelichting...
De eerste laag: Je brein Voordat je de agent opdracht geeft om iets te bouwen, ga je er eerst zelf in zitten om het te lezen en te begrijpen. Je hebt geen compleet implementatieplan nodig, maar je hebt wel een ruw idee nodig van waar je naartoe gaat. Anders kan AI je in de verkeerde richting sturen. Of erger nog: het kan je aanzetten tot het bouwen van iets dat überhaupt geen probleem was dat opgelost moest worden!
De vulling: AI Nu je al deze context hebt, is het tijd om AI in te zetten. Doe dat gerust. Delegeer dit deel volledig en zonder schaamte! Omdat je de context hebt, weet je wanneer de agent met de oplossing komt of het correct is, of het te veel is, of dat het volledig het verkeerde probleem oplost, enzovoort.
De laatste laag: Je brein Aan het einde komt je brein weer terug. Want voordat je je werk naar andere mensen stuurt voor review, moet je het werk reviewbaar maken. Lees de diff, controleer of de complexiteit in dit geval gerechtvaardigd is, verbeter de beschrijving van de Pull Request (PR), etc.
De vuistregel is: als je niet kunt uitleggen wat er verandert en waarom, is het niet klaar om door iemand anders bekeken te worden.
De Brain Sandwich
(Trouwens, ik heb gehoord dat de 'hippe kids' dit een Meat Proxy noemen.)
De reden dat ik besloot hierover te posten, is dat Emily een heel eenvoudig raamwerk gebruikt voor het werken met AI, dat ze de "Brain Sandwich" noemt, wat dit probleem oplost. Het gaat erom dat je optimaal gebruikmaakt van AI zonder dat je engineering-vaardigheden atrofiëren (verslappen).
Het idee is zeer simpel en kan als volgt worden samengevat: wanneer je aan iets werkt, zou je het volgende moeten gebruiken:
- Je brein, en dan
- AI, en dan
- Je brein
Een verdere toelichting...
De eerste laag: Je brein Voordat je de agent opdracht geeft om iets te bouwen, ga je er eerst zelf in zitten om het te lezen en te begrijpen. Je hebt geen compleet implementatieplan nodig, maar je hebt wel een ruw idee nodig van waar je naartoe gaat. Anders kan AI je in de verkeerde richting sturen. Of erger nog: het kan je aanzetten tot het bouwen van iets dat überhaupt geen probleem was dat opgelost moest worden!
De vulling: AI Nu je al deze context hebt, is het tijd om AI in te zetten. Doe dat gerust. Delegeer dit deel volledig en zonder schaamte! Omdat je de context hebt, weet je wanneer de agent met de oplossing komt of het correct is, of het te veel is, of dat het volledig het verkeerde probleem oplost, enzovoort.
De laatste laag: Je brein Aan het einde komt je brein weer terug. Want voordat je je werk naar andere mensen stuurt voor review, moet je het werk reviewbaar maken. Lees de diff, controleer of de complexiteit in dit geval gerechtvaardigd is, verbeter de beschrijving van de Pull Request (PR), etc.
De vuistregel is: als je niet kunt uitleggen wat er verandert en waarom, is het niet klaar om door iemand anders bekeken te worden.
Groetjes,