როგორ ვიმუშაოთ დეველოპერთან AI-ით აგებულ აპზე

AI-ით აგებულ აპზე დეველოპერთან კარგად სამუშაოდ, მიეცით მას კოდი Git რეპოზიტორიაში, ერთგვერდიანი აღწერა იმისა, რას აკეთებს აპი და რატომ, და მკაფიოდ განსაზღვრული დავალება დასრულების კრიტერიუმით. შეთანხმდით, ვინ რომელ ნაწილს ცვლის, რათა თქვენ და AI მის სამუშაოს არ გადააწეროთ, რეპოზიტორია და ჰოსტინგის ანგარიშები თქვენს სახელზე შეინახეთ, და საიდუმლოები პარამეტრებით გადასცეთ და არა შეტყობინებებით.

ბევრი ადამიანი პირველ ვერსიას AI-ით აკეთებს და შემდეგ დეველოპერს იწვევს — გადახდების დასამატებლად, იმის გასასწორებლად, რასაც AI მუდმივად ვერ ართმევს თავს, უსაფრთხოების გადასამოწმებლად, ან აპის ზრდასთან ერთად სრულად გადასაბარებლად. თუ ჯერ კიდევ წყვეტთ, დაიქირაოთ თუ არა, იხილეთ დაიქირავეთ დეველოპერი ან ააშენეთ AI-ით. ეს სახელმძღვანელო ვარაუდობს, რომ უკვე გადაწყვიტეთ და გსურთ თანამშრომლობა გლუვად წარიმართოს.

როდის ღირს დეველოპერი

ხშირი მიზეზები, რატომაც ვინმეს მოიწვევთ:

• პრობლემა, რომელსაც AI ვერ წყვეტს რამდენიმე მკაფიო ცდისა და გაუქმების შემდეგაც.
• სარისკო ადგილები: გადახდები, უფლებები, მგრძნობიარე მონაცემები, მონაცემთა ბაზის მიგრაციები.
• უსაფრთხოების ან კოდის მიმოხილვა გაშვებამდე ან უფრო დიდ კლიენტებამდე.
• წარმადობა, როცა რეალური ტრაფიკი მოდის.
• ზრდა: აპი ბიზნესად იქცა და მას კოდის საკუთრებაზე პასუხისმგებელი ადამიანი სჭირდება.

რომელი შემთხვევაა თქვენი, ამის სიცხადე ქვემოთ ყველაფერს განსაზღვრავს.

ნაბიჯი 1: მოათავსეთ კოდი გასაზიარებელ ადგილას

დეველოპერები Git რეპოზიტორიებით მუშაობენ. სანამ ვინმეს დაუკავშირდებით:

1. დააკავშირეთ პროექტი პირად GitHub-ის (ან მსგავს) რეპოზიტორიასთან, ან ექსპორტი გააკეთეთ.
2. დარწმუნდით, რომ კოდში და ისტორიაში საიდუმლოები არ არის. იხილეთ როგორ შევინახოთ API გასაღებები უსაფრთხოდ.
3. შეამოწმეთ, რომ პროექტი სუფთა ასლიდან მუშაობს — სთხოვეთ AI-ს დაწეროს დაყენების ნაბიჯები.

დაწერე README დეველოპერისთვის, რომელიც პროექტს შეუერთდება: რას აკეთებს აპი, რა სტეკი გამოიყენება, როგორ დაინსტალირდეს და გაეშვას ლოკალურად, რა გარემოს ცვლადები სჭირდება (მხოლოდ სახელები), საქაღალდეების სტრუქტურა და ყველაფერი, რაც მყიფე ან უჩვეულოა.

თუ Git ახალია, როგორ გამოვიყენოთ Git AI-ით აგებულ აპთან ძირითადს გიხსნით.

ნაბიჯი 2: დაწერეთ ერთგვერდიანი მოკლე აღწერა

დეველოპერი თქვენს ჩატის ისტორიას არ უსმენდა. კონტექსტი ერთ გვერდზე მიეცით:

• რას აკეთებს აპი, ვისთვის და რამდენი ადამიანი იყენებს.
• რა არის ყველაზე მნიშვნელოვანი — ნაკადები, რომლებიც არასდროს უნდა გაფუჭდეს.
• ცნობილი პრობლემები და ის, რაც უკვე სცადეთ.
• დავალება და როგორ გაიგებთ, რომ დასრულებულია.
• შეზღუდვები: ბიუჯეტი, ვადა, ის, რაც არ უნდა შეეხოს.

კარგი „დასრულების კრიტერიუმი“ ტესტირებადია: „დარეგისტრირებულ მომხმარებელს შეუძლია ყოველთვიური გეგმის შეძენა Stripe Checkout-ით, გეგმა გამოჩნდება მის ანგარიშის გვერდზე, ხოლო customer portal-ში გაუქმება გეგმას პერიოდის ბოლოს ამცირებს.“ და არა „მოაგვარე გადახდები“.

ნაბიჯი 3: მიეცით წვდომა უსაფრთხოდ

• კოდი: დაამატეთ როგორც თანამშრომელი რეპოზიტორიაში. სამუშაოს დაწყების შემდეგ ZIP ფაილები არ გადააგზავნოთ.
• ბილდერი: თუ თქვენი AI აპ-ბილდერი გუნდის წევრებს უჭერს მხარს, მოიწვიეთ სამუშაო სივრცეში, რომელიც მხოლოდ ამ პროექტს შეიცავს.
• საიდუმლოები: დაამატეთ ისინი თქვენი ჰოსტის პარამეტრებში ან გაუზიარეთ პაროლების მენეჯერით. გასაღებები არასდროს ჩასვათ ელფოსტაში ან ჩატში.
• სატესტო ანგარიშები: შექმენით ისინი სატესტო მონაცემებით, და არა თქვენი პირადი შესვლით.
• საწარმოო მონაცემები: მხოლოდ მაშინ, თუ მათ ნამდვილად სჭირდებათ, და მხოლოდ იმდენი, რამდენიც საჭიროა.

რეპოზიტორია, დომენი და ჰოსტინგის ანგარიშები თქვენს სახელზე დატოვეთ. ადამიანები დაამატეთ; ანგარიშებს არ გადასცეთ.

ნაბიჯი 4: შეთანხმდით, ვინ რას ცვლის

ყველაზე დიდი ხახუნი ისაა, როცა ორი მხარე — თქვენ AI-თან ერთად და დეველოპერი — ერთდროულად ერთსა და იმავე კოდს ცვლით. აირჩიეთ წესი:

რასაც არ უნდა აირჩიოთ: ყოველი მოთხოვნის სესიამდე წამოიღეთ უახლესი კოდი და დიდი ცვლილებები გააკეთეთ branch-ებზე, რომლებსაც მეორე მხარე გადახედავს.

ნაბიჯი 5: ურთიერთობა წერილობით

• შეცდომები აღწერეთ ნაბიჯებით, მოსალოდნელი და ფაქტობრივი შედეგით. იხილეთ როგორ დავწეროთ კარგი bug report.
• გადაწყვეტილებები ერთ ადგილას შეინახეთ: issue tracker-ში, გაზიარებულ დოკუმენტში ან pull request-ის კომენტარებში.
• სთხოვეთ, რომ ყოველ pull request-ში ცვლილებები უბრალო ენაზე ახსნას.
• შეთანხმდით, რამდენად ხშირად შეამოწმებთ ერთმანეთს.

ნაბიჯი 6: გადახედეთ მათ სამუშაოს

კოდის წაკითხვა არ გჭირდებათ, რომ სამუშაო გადახედოთ. შეამოწმეთ:

• აკეთებს თუ არა იმას, რაც დავალებაში იყო, preview-ზე ან სატესტო ასლზე.
• არაფერი სხვა არ გატყდა — გაუშვით თქვენი კრიტიკული ნაკადები.
• აუხსნეს თუ არა, რა შეცვალეს და რატომ.
• საიდუმლოები კოდში არ მოხვდა.

უფრო ახლოს რომ შეხედოთ, როგორ გადავხედოთ AI-ით გენერირებულ კოდს ჩეკლისტს გვთავაზობს, რომელიც ადამიანის მიერ დაწერილ კოდზეც მუშაობს. ასევე შეგიძლიათ AI ბილდერს სთხოვოთ, დეველოპერის pull request ჩემთვის მარტივი ენით ახსნას.

ნაბიჯი 7: საკუთრება მკაფიოდ დარჩეს

• რეპოზიტორია, ჰოსტინგი, დომენი და მესამე მხარის ანგარიშები თქვენთან რჩება.
• დეველოპერის მიერ დაწერილ კოდზე საკუთრება დაწერილად დაადასტურეთ სამუშაოს დაწყებამდე. კონტრაქტის კითხვებისთვის შეამოწმეთ ადგილობრივი წესები ან მრჩეველი.
• სამუშაოს დასრულებისას მოხსენით მისი წვდომა და შეცვალეთ ყველა გასაღები, რომელიც მან ნახა.

მაგალითი მოთხოვნები

დეველოპერმა ბოლო pull-ში checkout-ის კოდი შეცვალა. ახსენი უბრალო ენაზე, რა შეცვალა და არის თუ არა აპის სხვა ნაწილი მასზე დამოკიდებული.

ჩამომითვალე ამ აპის ყველაზე რთული ან სარისკო ნაწილები, რომ დეველოპერს მივუთითო, სად გაამახვილოს ყურადღება.

გადაბარებ გადახდებს დეველოპერს. ამიერიდან src/payments-ის ფაილებს და /api/billing მარშრუტებს არ შეეხო. თუ რომელიმე ცვლილება მათ საჭიროებს, მითხარი და არ შეცვალო.

ხშირი შეცდომები

• არ არის მოკლე აღწერა. დეველოპერი ანაზღაურებად საათებს ხარჯავს იმის გასარკვევად, რაც გინდოდათ.
• ბუნდოვანი მოცულობა, როგორიცაა „გაასწორე ბაგები“ ან „გახადე საწარმოო-მზად“.
• ორივე ერთდროულად ცვლის წამოღების გარეშე და შემდეგ კონფლიქტებში კარგავს სამუშაოს.
• საკუთარი ანგარიშის გაზიარება ან გასაღებების ჩატში ჩასმა.
• ანგარიშები დეველოპერის სახელზე, რაც სხვა გზის გაყრას ართულებს.
• წვდომის მოხსნის დავიწყება და გასაღებების შეცვლა სამუშაოს დასრულების შემდეგ.

ჩეკლისტი

• კოდი პირად რეპოზიტორიაშია ჩემს სახელზე, საიდუმლოების გარეშე.
• README ხსნის დაყენებას; ერთგვერდიანი აღწერა ხსნის აპსა და დავალებას.
• დავალებას აქვს ტესტირებადი დასრულების კრიტერიუმი.
• წვდომა კოლაბორატორის მოწვევებით, საიდუმლოები პარამეტრებით ან პაროლების მენეჯერით.
• შეთანხმდით, ვინ რას ცვლის, და მოთხოვნამდე ვწევ ცვლილებებს.
• სამუშაო მიმოიხილება აღწერისა და კრიტიკული ნაკადების მიხედვით.
• საკუთრება დაწერილია; სამუშაოს დასრულებისას წვდომა მოიხსნება და გასაღებები იცვლება.

დეველოპერთან მუშაობა Mythex-ზე

• მოიწვიეთ სამუშაო სივრცეში. მფლობელებს შეუძლიათ შეუზღუდავი თანამშრომლის მოწვევა თანამშრომელზე დამატებითი გადასახადის გარეშე; წევრები სამუშაო სივრცის პროექტებზე მუშაობენ. გამოიყენეთ ცალკე სამუშაო სივრცე, რომ მხოლოდ ეს პროექტი ხედავდეს. გამოქვეყნებული აპების კრედიტები სამუშაო სივრცის მფლობელს ეწერება. იხილეთ Invites.
• GitHub sync და export (Pro). დააკავშირეთ რეპოზიტორია და გააკეთეთ push და pull, ან ექსპორტი გააკეთეთ საიდუმლოების გარეშე. იხილეთ GitHub, export, and import.
• გაუზიარეთ preview-ის ბმული მიმდინარე სამუშაოს საჩვენებლად ადამიანს Mythex-ის ანგარიშის გარეშე; წაშალეთ, როცა დაასრულებთ.
• Ask რეჟიმი პასუხობს კოდზე შეკითხვებს მის შეცვლის გარეშე — სასარგებლოა დეველოპერის ცვლილებების გასაგებად.

თუ დეველოპერი აპს სხვაგან გაუშვებს, იხილეთ როგორ ავაექსპორტოთ და დავაჰოსტოთ AI-ით აგებული აპი.

კითხვები