Abstracties voor implementatie zijn dood. Leve abstracties voor ontwerp
Nu AI het genereren van code goedkoper maakt, verliezen implementatiepatronen zoals het Strategy-patroon waarde, terwijl beslissingen op ontwerpniveau—zoals servicegrenzen, data-eigendom, consistentie en faalisolatie—nog belangrijker worden. Deze beslissingen, die lange feedbackcycli en hoge ommekeerkosten met zich meebrengen, kunnen niet aan AI worden gedelegeerd en vereisen een diepgaand zakelijk en operationeel begrip.
Het artikel betoogt dat met het vermogen van AI om code te genereren, de waarde van implementatiepatronen, zoals het Strategiepatroon in Java, afneemt. Deze patronen waren cognitieve hulpmiddelen om de complexiteit van code te beheren, maar AI kan dergelijke code nu direct schrijven. Echter, abstracties op ontwerpniveau—beslissingen over grenzen tussen domeinen, gegevenseigendom, consistentiemodellen, isolatie van storingen en schema-evolutie—blijven duur om te wijzigen en kunnen niet worden geautomatiseerd. Voorbeelden hiervan zijn het kiezen tussen synchrone en asynchrone orderverwerking, het definiëren van gegevenseigenaren en het stellen van consistentiegrenzen. AI kan code genereren voor elke gekozen aanpak, maar het kan deze architecturale beslissingen niet nemen, die afhangen van bedrijfslogica, verkeerspatronen, service-levelovereenkomsten en operationele realiteiten. Het artikel bekritiseert het idee dat AI om ontwerpadvies kan worden gevraagd, en merkt op dat iteratie op ontwerp kostbaar is en feedbackloops maanden duren. Het daagt ook het idee uit om alle storingsscenario's in prompts te specificeren, en benadrukt de rol van de ingenieur bij het anticiperen op mogelijke scenario's. Hoewel een samengestelde kennisbank van postmortems en architectuurbeslissingen helpt, blijft de laatste 10% van het ontwerpoordeel van onschatbare waarde, en ingenieurs zouden zich moeten richten op deze waardevolle vaardigheden in plaats van op het beheersen van frameworks die AI kan afhandelen.
Bron: Habr — хаб ИИ —
origineel