80/20 Ingenieurswese: Hoe ek my webwerf in 'n naweek herbou het

Laat ek vir jou 'n geheim vertel: ek het my persoonlike webwerf nie in 'n naweek herskryf omdat ek besonder vinnig kodeer nie. Ek het dit gedoen omdat ek feitlik glad nie gekodeer het nie.

In plaas daarvan het ek die meeste van my tyd spandeer aan wat die meeste ontwikkelaars soos die pes vermy—voorbereiding. Dokumentasie. Dinge neerskryf. En toe ek uiteindelik my editor oopmaak en met OpenAI se Codex begin werk het, het die werklike implementering verbygevlieg soos 'n goed geoefende towertryk.

Dit is 'n storie oor hoe ek 80% van die werk gedoen het voordat ek 'n enkele reël kode geskryf het, en hoe dit alles verander het.

Waarom die webwerf herskryf?

My webwerf het op Qwik v3 geloop. Soliede tegnologie, goeie vibe, maar ek wou meer buigsaamheid hê—veral met routering. Ek het oorgeskakel na React Router in raamwerkgemoed. 'n Volledige herbou, nie 'n refaktor nie. Nuwe argitektuur, skoon lêerstruktuur, opgedateerde styl (hallo Tailwind v4), en 'n skoon lei.

Maar dit wat my verras het: die werklike kodering het omtrent 2–3 ure geneem. Van begin tot einde. En dit het al die eerste keer gewerk.

Wat het dan gebeur in die ander 5 ure?

Die 80%: Codex voorberei soos 'n konsultant 'n aanbiedingsdeksel voorberei

Die meeste van die moeite het gegaan in die bou van 'n "mega prompt-stelsel"—nie in 'n gesofistikeerde gebruikerskoppelvlak nie, maar reg in my projekgids. Dit is wat ek gedoen het voordat ek Codex gevra het om selfs 'n enkele komponent te skryf:

• Ek het die hele React Router dokumentasie afgelaai en dit in 'n /guides gids gestoor.

• Ek het dieselfde gedoen vir Tailwind CSS v4, en die mees relevante bladsye na Markdown omgeskakel met Firecrawl.

• Ek het 'n PROMPT.md lêer geskryf met 'n projekoorzicht:

  • "Erfeniskode leef by /, nuwe kode gaan in /app."
  • "Slegs minimale gebruikerskoppelvlak, fokus op sake-logika."
  • "Gebruik Tailwind v4. Bly in raamwerkgemoed met React Router."
  • En so aan.

Dit was nie blote woorde nie. Dit was operasionele konteks—die soort gedetailleerde inligting wat jy vir 'n nuwe spanlid op dag een gee. Codex het nie net geraai wat ek wou hê nie. Dit het dokumentasie in die repo gehad. Dit het presiese reëls in eenvoudige Engels gehad. Dit het beperkings gehad.

Toe ek uiteindelik getik het:

"Lees PROMPT.md. Migrasie eers al die roetes na die nuwe app."

Het Codex soosof dit sy hele lewe lank op hierdie opdrag gewag het, reageer.

Mega Prompts, minimale hallusinasies

Die resultate was ongelooflik. Codex het by die instruksies gehou. Dit het nie gehallusineer nie. Dit het nie probeer om dinge uit te vind nie. Dit het die "moet nie op UI fokus nie" riglyn gerespekteer. Die bedienerlogika is met presisie gemigreer. Die roetekonfigurasie het gelyk asof ek dit self geskryf het—indien ek die geduld van 'n samesteller gehad het.

Dit was nie net "prompt ingenieurswese" nie. Dit was oor om Codex te grondves in die werklike en huidige spesifikasies. Nie 'n vae lys van take nie. Nie 'n wenslys van funksies nie. Maar gestruktureerde insette, duidelike voorbeelde, en plaaslike toegang tot die werklike dokumentasie wat dit nodig gehad het.

Wat het tyd geneem? Nie die kode nie

Sodra die fondament gelê was, is die werk in twee duidelike fases verdeel:

1. Codex-modus – Vinnig, gestruktureerd, herhalend uitvoering. Dit het deur migrasie, logika, en selfs sommige uitlegraamwerke met amper perfekte akkuraatheid gewerk.
2. Ontwerp-verkenningsmodus – Stadig, handmatig, en oop einde. Dit was die menslike deel: 'n voorkoms kies, uitleg probeer, met komponente eksperimenteer. Sodra ek 'n werkende visuele styl gehad het, het Codex weer aangetas om die ontwerp-patrone te versprei.

Die enigste ware vertragings het gekom omdat ek nie geweet het hoe ek iets moes laat lyk nie—nie hoe dit moes werk nie.

Die werklike insig: Codex is net so goed soos jou voorbereiding

Hierdie naweek het 'n skuif beklemtoon wat ek in my werk sien:

Kodering word die maklike deel. Beplanning is die moeilike deel—en die belangrikste.

Vir klein tot medium projekte behandel ek nou die implementering as 'n 20% taak. Die 80% is voorlê: die dokumentasie bymekaar maak, gespesifiseerde take skryf, kontekstuele prompts bou.

Codex floreer met hierdie tipe struktuur. As jy dit ambiguïteit voer, gee dit jou ambiguïteit. Maar as jy jou omgewing met bedoeling bou—dokumente, beperkings, duidelike beskrywings—presteer dit soos 'n senior ontwikkelaar met perfekte geheue en geen ego nie.

Vooruit: Behandel KI soos 'n spanmaat, nie 'n gees nie

Die boodskap is eenvoudig: behandel jou KI-kodeerinstrumente soos medewerkers. Gee hulle dieselfde materiaal wat jy 'n regte ingenieur sou gee. Berei die konteks voor. Wees spesifiek. Wees deeglik.

Volgende keer, vir 'n groter projek, gaan ek nog verder:

• Een meesterplan-dokument om die volle projekomvang te definieer.
• Individuele taakspesifikasies per subsisteem of komponent.
• 'n Werkende stel Markdown-dokumente en voorbeeldlêers as plaaslike verwysingsbasis.

Codex het nie towerwoorde nodig nie—dit benodig struktuur.

Wil jy vinniger bou? Begin deur nie te bou nie. Beplan eers. Prompt dan soos jy dit meen.

Die evolusie van ontwerp: 'n Visuele reis

Mettertyd het my webwerf verskeie transformasies deurmaak—elkeen 'n weerspieëling van nuwe idees, gereedskap, en geleerde lesse. Hier is 'n vinnige visuele toer van hoe dinge ontwikkel het:

Weergawe 1: Die beginpunt

Weergawe 2: 'n Meer gedefinieerde stem

Weergawe 2.1: Aanpassings en verfyning

Weergawe 3: Die Qwik-era

Weergawe 4: Gefokusde eenvoud met Remix

Elke weergawe het nuwe insigte gebring oor wat 'n webwerf effektief maak—nie net in estetika nie, maar in duidelikheid, bruikbaarheid, en instandhouding. Die ontwerpreis het die ontwikkelingsreis gespog: doelbewus, iteratief, en altyd vorentoe gekyk.