Oordeelsvermogen in engineering wordt de meest schaarse hulpbron
Implementatie wordt goedkoper. Dit maakt oordeelsvorming duur.
Oordeelsvermogen is geen intuïtie of mening. Het is het vermogen om beslissingen te nemen onder onzekerheid. AI maakt deze vaardigheid zichtbaarder dan ooit.
Twee engineers kunnen dezelfde taak krijgen: bouw een API voor factuurreconciliatie. AI kan de code voor beiden schrijven. De syntaxis en frameworks zullen hetzelfde lijken.
De uiteindelijke systemen zullen verschillen. De ene engineer bouwt misschien een rommelige service die moeilijk te onderhouden is. Een ander scheidt bedrijfsregels en logica in onafhankelijke componenten.
De AI heeft die keuze niet gemaakt. De engineer wel.
Architectuur doet er nog steeds toe, omdat implementatie niet langer het onderscheidende vermogen is. De beslissingen achter de code zijn dat wel.
Complexiteit verdwijnt niet met AI. Het verplaatst zich.
In het verleden besteedden engineers tijd aan het vertalen van ideeën naar code. Nu doet AI die vertaling. Het zware werk vindt plaats voordat je ook maar één regel schrijft.
Je moet vragen beantwoorden zoals:
- Welk probleem lossen we op?
- Welke data is de bron van waarheid?
- Waar moeten bedrijfsregels worden ondergebracht?
- Hoe meten we succes?
Autocomplete kan deze niet beantwoorden. Ze vereisen context.
Softwareontwikkeling lijkt nu op informatie-engineering. De bottleneck is niet de code. De bottleneck is informatie.
Je krijgt te maken met:
- Ontbrekende vereisten.
- Onvolledige documentatie.
- Tegenstrijdige bedrijfsregels.
- Onduidelijk eigenaarschap.
De engineer die informatie organiseert, creëert meer waarde dan degene die snel code schrijft.
De workflow is verschoven. Het was voorheen: Requirement -> Design -> Code -> Debug -> Deploy.
Nu is het: Bedrijfsprobleem -> Context -> Architectuur -> AI-implementatie -> Menselijke beoordeling -> Beveiliging -> Evaluatie -> Productie.
Programmeren is nu een klein onderdeel van het proces. De omliggende activiteiten hebben de prioriteit.
Beslissingen met een grote impact vinden plaats buiten de code-editor. Ze vinden plaats wanneer je jezelf afvraagt:
- Moet dit een aparte service zijn?
- Kunnen we deze beslissing auditen?
- Wat gebeurt er als de AI het fout heeft?
- Kan deze architectuur evolueren?
AI-engineering is meer dan prompts of modelselectie. Dat is slechts één laag.
De echte uitdagingen zijn architecturaal:
- Hoe modelleren we bedrijfsmatige kennis?
- Hoe lossen we ambiguïteit op?
- Hoe behouden we vertrouwen?
Modellen veranderen elke paar maanden. Architecturen gaan jaren mee. Een slechte architectuur wordt heel snel duur.
De beste teams bouwen systemen die meerdere generaties modellen overleven. Ze optimaliseren voor aanpassingsvermogen.
AI is slechts een extra abstractielaag. Hogere abstractie vereist sterker redeneervermogen, niet zwakker.
De sterkste engineers zijn niet de snelste programmeurs. Het zijn degenen die helderheid creëren. Ze definiëren architecturen, standaardiseren data en verminderen ambiguïteit.
Een goed systeem helpt mensen en AI-agenten om samen te werken. Een slecht systeem zorgt er alleen maar voor dat fouten sneller worden gemaakt.
De engineer die helderheid creëert, creëert een hefboomeffect.
Bron: https://dev.to/uigerhana/engineering-judgment-is-becoming-the-scarcest-resource-1a5l
Optionele leercommunity: https://t.me/GyaanSetuAi
