Populaire onderwerpen
#
Bonk Eco continues to show strength amid $USELESS rally
#
Pump.fun to raise $1B token sale, traders speculating on airdrop
#
Boop.Fun leading the way with a new launchpad on Solana.
> De kosten van het uitleggen van de bedrijfslogica aan AI > de kosten van coderen, daarom gebruik ik Vibe Coding niet aan de achterkant.
In mijn ogen is het niet gebruiken van AI voor het schrijven aan de achterkant ook een gevolg van padafhankelijkheid; men is te vertrouwd en wil liever in de eigen comfortzone blijven, en is nog niet bereid om prompts te gebruiken om code te genereren. Aan de voorkant is men juist minder vertrouwd en durft men daardoor meer.
Een ander probleem dat je zelf al goed begrijpt: het is moeilijk om je behoeften duidelijk te beschrijven met prompts.
Het vermogen om op een begrijpelijke manier in natuurlijke taal te communiceren is op zich al een vereiste voor ervaren programmeurs, omdat je in de praktijk mensen moet aansteken en anderen moet overtuigen om jouw ontwerp te gebruiken, wat altijd een natuurlijke uitdrukking en communicatie vereist.
Achterkantcode kan geprobeerd worden met pseudocode als prompts, probeer TDD, schrijf eerst testcode en implementeer dan, maar ik raad aan om AI veel te gebruiken.
12 uur geleden
Ik ben het volledig eens met wat leraar Baoyu zegt, en ik kan enkele andere perspectieven aanvullen (Vb van backend en frontend).
Wanneer ik backend Java schrijf, gebruik ik nooit Vb-programmering, alles is handmatig gecodeerd, omdat het Java-ecosysteem extreem volwassen is, en de frameworks hebben de onderliggende technische details al sterk verpakt, zodat ik me alleen hoef te concentreren op de implementatie van de bedrijfslogica.
De kosten van het uitleggen van bedrijfslogica aan AI > de kosten van coderen, dus gebruik ik geen Vb-programmering in de backend.
Maar wanneer ik frontend schrijf, gebruik ik vaak een Agent voor volledige automatisering + een editor om kleine aanpassingen te doen, 99% van de code is door de Agent voor mij geschreven, ik hoef alleen maar enkele kleine aanpassingen te doen op basis van de resultaten, vaak in één keer goed.
Waarom gebruik ik een Agent voor volledige automatisering bij het schrijven van frontend? Een grote reden is dat de herhalingen in frontend-code niet te vermijden zijn, ongeacht hoe hooggekwalificeerd je bent als engineer, elke component, elke knop moet nog steeds op de juiste plaats worden geïntroduceerd en gecombineerd om het gewenste effect te bereiken.
Elke validatie, pop-up, melding en formulierindiening in de frontend kan niet door een framework voor je worden voltooid, je moet het nog steeds handmatig schrijven, en op dat moment komen de voordelen van een volledig geautomatiseerde Agent naar voren; zolang je de taak duidelijk schrijft, kan het huidige model je helpen om 99% van de herhaling te doen.
Tegenwoordig is er in de full-stack ontwikkeling een volwassen Monorepo-model, waarbij een groot model in hetzelfde repository het hele project met al zijn API's en objectdefinities kan begrijpen, dus ik denk dat full-stack ontwikkeling met Monorepo + volledig geautomatiseerde Agent gewoon explosieve efficiëntie oplevert.
Samenvattend: of je een volledig geautomatiseerde Agent gebruikt, hangt af van of het me tijd kan besparen en de efficiëntie kan verhogen, en voor een ervaren engineer zou het gemakkelijk moeten zijn om te beoordelen welke code-scenario's de Agent kan gebruiken om de efficiëntie te verbeteren.
Natuurlijk raad ik ook niet aan om alles aan AI over te laten. Sommige repetitieve taken moeten op de een of andere manier door AI worden uitgevoerd, maar voor sommige ontwerptaken is het het beste om AI slechts als ondersteuning te gebruiken. Daarnaast moet je regelmatig bewust wat code handmatig schrijven om ervoor te zorgen dat je vaardigheden niet achteruitgaan.
Het is net als nu, mensen hoeven geen fysiek werk meer te doen, maar gaan nog steeds naar de sportschool!
4,1K
Boven
Positie
Favorieten