ნულიდან Senior-მდე — სასწავლო გზის ჭეშმარიტი ვერსია
ააგებულია 4 ტრეკისა და 5 დონის გარშემო, რეალისტური ვადებით, კონკრეტული პროექტებითა და ყველა მიერ დაშვებული შეცდომებით. ყოველი ნაბიჯი უკავშირდება კურსებსა და სტატიებს, რომლებიც ამ კვირაშივე გამოგადგებათ.
ჯერ არ იცი, რომელი გზა აირჩიო?
აირჩიე ორი საწყისი წერტილიდან ერთი, სანამ ტრეკზე გადახვალ.
აირჩიე შენი ტრეკი
ოთხი ძალიან განსხვავებული სამუშაო. აირჩიე ის, რომელიც შეესაბამება როგორ გინდა გაატარო სამუშაო დღე. შეცვლა შესაძლებელია — ინჟინერების უმეტესობა ერთხელ-ორჯერ ამას მაინც აკეთებს.
ფრონტენდის განვითარება
~2.5–4 წელი (დამწყები → Senior)
ბექენდის განვითარება
~3–5 წელი (დამწყები → Senior)
მონაცემთა მეცნიერება / ML
~3–5 წელი (Junior → Senior — Data იშვიათად იწყება Beginner-დან)
DevOps / SRE
~4–6 წელი ჯამში (DevOps-ში ჩვეულებრივ მიდიან 1–2 წლის backend-ის ან sysadmin-ის შემდეგ)
ფრონტენდის განვითარება
~2.5–4 წელი (დამწყები → Senior)
დამწყები
ჩვეულებრივ: 4–8 კვირა წყარო: Stack Overflow Developer Survey →
დამწყები
ჩვეულებრივ: 4–8 კვირა წყარო: Stack Overflow Developer Survey →
რა უნარებს ისწავლი
- HTML და CSS-ის საფუძვლები
- JavaScript-ის საფუძვლები
- DOM-თან მუშაობა
- Responsive დიზაინი
მზად ხარ შემდეგი დონისთვის, როდესაც
- ნულიდან ააგე 1–2 გვერდიანი პორტფოლიო და deploy-ი გააკეთე (Vercel / Netlify გამოდგება)
- თავისუფლად კითხულობ და ცვლი HTML/CSS-ს ბრაუზერის DevTools-ში
- შეგიძლია vanilla JS-ში ღილაკის click handler-ის დაწერა copy-paste-ის გარეშე
- საიტი მობილურზე ნორმალურად გამოიყურება — გესმის box model და flexbox
- კოდი ატვირთე GitHub-ზე და repo სამარცხვინო არ არის
რა ააშენო
კონკრეტული პროექტები — და რას გასწავლით ისინი.
- პირადი პორტფოლიო ვებ-გვერდი (სწავლის: deploy, responsive, საბაზო JS)
- პატარა landing-გვერდი, რომელიც API-დან ერთ მონაცემს იღებს და აჩვენებს (სწავლის: fetch, async, DOM-ის რენდერინგი)
გაიარე ეს კურსები
შესავალი HTML & CSS-ში
ისწავლეთ HTML და CSS-ის საფუძვლები და შექმენით თანამედროვე, რეზპონსიული ვებგვერდები ნულიდან.
შესავალი HTML5 და CSS3-ში
ისწავლეთ HTML5 და CSS3-ის თანამედროვე სტანდარტები: სემანტიკური მარკაპი, Canvas, მულტიმედია, WebSockets, WebStorage, ანიმაციები და რეზპონსიული დიზაინი.
შესავალი JavaScript-ში
ისწავლეთ JavaScript ნულიდან: სინტაქსი, ლოგიკა, მასივები, ფუნქციები, ობიექტები, אירועები, DOM, AJAX და მონაცემების შენახვა კლიენტის მხარეს. მყარი საფუძველი frontend დეველოპმენტისთვის.
წაიკითხე
ამ დონისთვის სიღრმისეული სტატია ჯერ არ გვაქვს. გახსენი მთელი ბლოგი →
გავრცელებული შეცდომები ამ ეტაპზე
- 6 თვის გატარება tutorial-ებში, არაფრის რეალურად აშენების გარეშე — tutorial hell ამ დონეზე №1 მკვლელია
- CSS-ის საფუძვლების გამოტოვება, „Tailwind ყველაფერს გაიგებს“ — ნანობ პირველივე არატრივიალურ layout-ზე
- React tutorial-ების ყურება, სანამ vanilla JS-ში click handler-ის დაწერა არ გასწავლია
- პორტფოლიოს საიტისადმი ერთჯერად ნივთად მოპყრობა — ეს არის არტეფაქტი, რომლითაც დაგქირავებენ
რას ელიან კომპანიები ამ დონეზე
- 2–3 პროექტიანი პორტფოლიო, რომელიც თქვენი GitHub-დან კლონირდება და გაიშვება
- HTML/CSS, screen-share-ის ინტერვიუზე StackOverflow-ის გარეშე დაწერილი
- DevTools-ში კომფორტი — inspect element, console, network tab
- საბაზო Git: clone, branch, commit, push. მოწინავე ცოდნას სამუშაოზე მიიღებ.
უმცროსი
ჩვეულებრივ: 3–6 თვე წყარო: Stack Overflow Developer Survey →
უმცროსი
ჩვეულებრივ: 3–6 თვე წყარო: Stack Overflow Developer Survey →
რა უნარებს ისწავლი
- React-ის საფუძვლები
- კომპონენტის სიცოცხლის ციკლი
- State management-ის საფუძვლები
- API ინტეგრაცია
მზად ხარ შემდეგი დონისთვის, როდესაც
- გაუშვი React აპი 3+ კომპონენტით, რეალური API ინტეგრაციით და ცოცხალი deploy-ის URL-ით
- შეგიძლია useState-სა და useEffect-ის სხვაობის ახსნა საკუთარი სიტყვებით — ჟარგონის გარეშე
- თავისუფლად კითხულობ ბიბლიოთეკის source-ს GitHub-ზე, თუნდაც ყველაფერი ბოლომდე არ გესმოდეს
- ერთხელ მაინც იმუშავე გუნდურ Git-flow-ში: branch, PR, review-ზე პასუხი
- წაიკითხე ერთი "როდის არ ღირს AI-ის გამოყენება" ტიპის სტატია და გაქვს დასაბუთებული პოზიცია
რა ააშენო
კონკრეტული პროექტები — და რას გასწავლით ისინი.
- პატარა React აპი, რომელიც რეალურ საჯარო API-სთან ურთიერთობს (სწავლის: კომპონენტები, state, fetch, error handling)
- შაბათ-კვირაში გადააკეთე შენი დამწყები პორტფოლიო React + TypeScript-ზე (სწავლის: refactoring, ტიპები, რატომ მნიშვნელოვანია JSX)
გაიარე ეს კურსები
React.js-ის საფუძვლები
შექმენით თანამედროვე, ინტერაქტიული UI React-ით. ისწავლეთ კომპონენტები, hooks, state management, routing, API ინტეგრაცია და რეალური პროექტების deploy. JavaScript-ის შემდეგ ბუნებრივი ნაბიჯი.
TypeScript Mastery
JavaScript-იდან production-კლასის TypeScript-მდე. Type system, generics, decorators, strict mode, advanced utility types და TypeScript-ის ინტეგრაცია რეალურ პროექტებში.
გავრცელებული შეცდომები ამ ეტაპზე
- ყოველ 2 კვირაში framework-ის შეცვლა (Vue → React → Svelte → Solid → ...) — აირჩიე ერთი და რამე დაასრულე
- TypeScript-ის აღქმა „უბრალოდ JS ტიპებით“ — რეალური ღირებულება დიზაინის დისციპლინაშია
- პლატფორმის ბაზის არცოდნა (event loop, event delegation, ბრაუზერის რენდერინგი)
- მხოლოდ TODO-აპების აშენება. ააშენე რამე, რასაც სერვერული მონაცემები და სხვისი API სჭირდება.
რას ელიან კომპანიები ამ დონეზე
- მინიმუმ 1 deploy-ი React აპი, რომელიც თავიდან ბოლომდე გესმის — და ინტერვიუზე ახსნა შეგიძლია
- მინიმუმ ერთ CSS მიდგომაში (Tailwind / CSS modules / styled-components) კომფორტი
- დოკუმენტაციის წაკითხვა — შენი დეფოლტ მოქმედებაა გაჭედვისას, არა გუნდისთვის კითხვა
- შეგიძლია ახსნა, რატომ აირჩიე ბიბლიოთეკა, არა უბრალოდ "გამოვიყენე"
საშუალო დონე
ჩვეულებრივ: 6–12 თვე წყარო: Stack Overflow Developer Survey →
საშუალო დონე
ჩვეულებრივ: 6–12 თვე წყარო: Stack Overflow Developer Survey →
რა უნარებს ისწავლი
- გაგრძელებული React პატერნები
- წარმადობის ოპტიმიზაცია
- ტესტირება (Jest, React Testing Library)
- Build ინსტრუმენტები (Webpack, Vite)
მზად ხარ შემდეგი დონისთვის, როდესაც
- სამსახურში ან რეალურ პროექტში ფიჩერი ნულიდან გაატარე: requirements → design → ship → bugfix
- სხვისი React კომპონენტი გადააკეთე ისე, რომ არაფერი გაგიფუჭდა (და გუნდმა მადლობა გითხრა)
- შეგიძლია performance-ის დებაგი Chrome DevTools-ში — Profiler, Network, Coverage
- რევიუ გაუკეთე PR-ებს რეალურ გუნდში და შენი რევიუ მხოლოდ nitpick-ი არ არის
- გაქვს state management-ზე აზრი, რომლის დაცვაც კოდით შეგიძლია, არა შთაბეჭდილებით
რა ააშენო
კონკრეტული პროექტები — და რას გასწავლით ისინი.
- სრულფასოვანი SPA auth-ით, routing-ით, optimistic UI-ით და რეალური ტესტირების პირამიდით (სწავლის: production-დონეზე ship)
- პატარა ხელახლა გამოყენებადი კომპონენტების ბიბლიოთეკა + Storybook (სწავლის: API დიზაინი, accessibility, დოკუმენტაცია)
წაიკითხე
-
AI ინსტრუმენტები, რომლებიც ყველა დეველოპერმა უნდა გამოიყენოს 2025-ში
არა hype-სია. პრაქტიკული ანალიზი — რომელი AI ინსტრუმენტები რეალურად ზოგავს დროს, რომელი ხარჯავს, და როგორ ააწყოთ workflow, რომელიც გხდით აზომვადად სწრაფს.
-
Claude Code production-ში: რა ვისწავლე 6 თვეში
ექვსი თვე Claude Code როგორც ძირითადი ინსტრუმენტი — რომელი workflows-ი რეალურად დაზოგავს დროს, რომელი მას ჩუმად ჭამს, და რა კონფიგურაცია არ ეყენება გუნდების უმეტესობას.
-
კონტექსტ-ინჟინერია: დისციპლინა, რომელიც 2026-ში ცვლის prompt engineering-ს
Prompt engineering არასოდეს ყოფილა რეალური უნარი. პროდუქშენში AI-ფიჩების ორწლიანი მიწოდების შემდეგ პირდაპირ ვიტყვი: შედეგზე სხვა გავლენას ახდენს — კონტექსტ-ინჟინერია. მდგომარეობა, ხელსაწყოები, ძიება, ისტორია და შეზღუდვები, რომელიც ზუსტ მომენტში მოდელის ფანჯარაში ერთმანეთს უხამდება. არქიტექტორის ხედვა.
-
C#-დან AI აგენტებამდე: .NET დეველოპერის გზა Claude-ზე განვითარებისკენ
თქვენ უკვე იცით C#, ASP.NET Core და როგორ გაუშვათ production ბექენდები. აი როგორ გამოიყენოთ ეს უნარები სერიოზული AI აგენტების შესაქმნელად Claude-ზე — თქვენი სტეკის გადაგდების გარეშე.
გავრცელებული შეცდომები ამ ეტაპზე
- Over-engineering: Redux store + saga middleware 3-გვერდიანი აპლიკაციისთვის
- ახალი ბიბლიოთეკის წამოღება, ნაცვლად 30 ხაზიანი მარტივი კოდის დაწერისა
- ტესტების არ წერა, რადგან "ეს მხოლოდ frontend-ია" — frontend-ის ბაგები ყველაზე თვალსაჩინოა მომხმარებლისთვის
- მხოლოდ React-ისად ქცევა — stack-ები იცვლება, ისწავლე პლატფორმა, HTTP, ბრაუზერი
რას ელიან კომპანიები ამ დონეზე
- ძლიერი React + TypeScript, მაგრამ React-ის კერპი არ ხარ — შეგიძლია framework-ის შეცვლა, თუ გუნდს სჭირდება
- მყარი ინსტინქტი ტესტირებაში: unit + integration, იდეალში — რამდენიმე e2e კრიტიკულ ფლოუებზე
- შეგიძლია პატარა ფიჩერის დაპროექტება senior-ის გვერდით ყოფნის გარეშე
- ადეკვატური code review — კონსტრუქციულად აბრუნებ ცუდ PR-ებს
უფროსი
ჩვეულებრივ: 1–2 წელი
უფროსი
ჩვეულებრივ: 1–2 წელი
რა უნარებს ისწავლი
- Frontend არქიტექტურის დიზაინი
- წარმადობის მასშტაბირება
- გუნდის ლიდერობა
- სისტემების დიზაინზე გადაწყვეტილებები
მზად ხარ შემდეგი დონისთვის, როდესაც
- დაპროექტდი არატრივიალური პროდუქტის frontend-არქიტექტურა (3+ ინჟინერი მასზე დამოკიდებული)
- მიიღე ტექნოლოგიური გადაწყვეტილება, რომელსაც გუნდი ერთი წლის შემდეგაც იყენებს — და შეგიძლია ახსნა, რატომ
- junior ან mid ინჟინერი რეალური ზრდის პლატოდან გადაიყვანე
- შეწყვიტე ბილეთების წერა „რადგან მინდა“ — წერ, რადგან ეს სწორი შემდეგი ნაბიჯია
- კომფორტული ხარ უთხრა PM-ს ან დიზაინერს „ეს იდეა არასწორია“, დასაბუთებით
რა ააშენო
კონკრეტული პროექტები — და რას გასწავლით ისინი.
- მასშტაბირებადი frontend არქიტექტურის დიზაინი მრავალგუნდიანი პროდუქტისთვის (სწავლის: მოდულის ზღვრები, build pipeline-ები, design system-ის მფლობელობა)
- frontend გუნდის წაყვანა კრიტიკულ მიგრაციაში (სწავლის: დაგეგმვა, trade-offs, mentoring წნეხის ქვეშ)
წაიკითხე
-
კონტექსტ-ინჟინერია: დისციპლინა, რომელიც 2026-ში ცვლის prompt engineering-ს
Prompt engineering არასოდეს ყოფილა რეალური უნარი. პროდუქშენში AI-ფიჩების ორწლიანი მიწოდების შემდეგ პირდაპირ ვიტყვი: შედეგზე სხვა გავლენას ახდენს — კონტექსტ-ინჟინერია. მდგომარეობა, ხელსაწყოები, ძიება, ისტორია და შეზღუდვები, რომელიც ზუსტ მომენტში მოდელის ფანჯარაში ერთმანეთს უხამდება. არქიტექტორის ხედვა.
-
Evals 2026-ში: ტესტ-სიუტი სისტემებისთვის, რომლებიც დეტერმინირებული არ არიან
თქვენი AI-ფიჩა გუშინ მუშაობდა და დღეს იშლება. არც კოდი შეცვლილა, არც პრომპტი, არც მოდელი. ასე გამოიყურება ცხოვრება evals-ის გარეშე. ეს არის spec → context → evals ტრიადის მესამე საყრდენი — და დისციპლინა, რომელსაც გუნდების უმეტესობა გამოტოვებს.
-
OpenSpec 2026-ში: spec-driven development-ის ოპერაციული სისტემა
ექვსი კვირის წინ დავაყენე @fission-ai/openspec. გუშინ ჩავაბარე თოთხმეტ-ფაილიანი ცვლილება ოთხმოცდაათ წუთში ორას-ხაზიანი სპეციფიკაციიდან, brownfield-კოდბაზაში, რომელსაც სამი ინჟინერი ორი წელია ასწორებს — მერჯ-კონფლიქტების გარეშე, რევიუს ესკალაციის გარეშე. ეს არის სენიორ-არქიტექტორის ღრმა გარჩევა იმისა, თუ რატომ OpenSpec არის პირველი SDD-ხელსაწყო, რომელიც პროდაქშენ-რეალობის ქვეშ არ იშლება.
-
როგორ გავიაროთ System Design ინტერვიუ: senior ინჟინრის სახელმძღვანელო
System design რჩევების უმეტესობა თეორიული ხმაურია. ეს არის გამეორებადი ფრეიმვორკი, რომელსაც კანდიდატების შესაფასებლად ვიყენებ — და რომელიც შეგიძლიათ გამოიყენოთ ნებისმიერი system design ინტერვიუს mid ან senior დონეზე გასავლელად.
გავრცელებული შეცდომები ამ ეტაპზე
- რწმენა, რომ შენი ტიტული შენს აზრს სწორს ხდის — არა. სწორს მას დასაბუთება ხდის.
- ზედმეტად ჩადება იმ stack-ში, რომლითაც დაიწყე — Senior არის stack-ის გაფართოება და არა შევიწროება
- „ადამიანური“ პრობლემების თავიდან აცილება — ეს senior-ის სამუშაოს 80%-ია
- junior-ების არ კოუჩინგი. შენი გუნდის ხარისხის პლატო — შენი პლატოა.
რას ელიან კომპანიები ამ დონეზე
- შეგიძლია frontend არქიტექტურის დიზაინი და მფლობელობა რამდენიმე repo / გუნდის გასწვრივ
- მყარი ტექნიკური კომუნიკაცია: დოკუმენტები, RFC-ები, ასინქრონული წერა — არა მხოლოდ ლაპარაკი
- აძლიერებ გუნდს — junior-ები მჩვენებლად იზრდებიან, როცა შენ უერთდები
- კომფორტული ხარ გაურკვევლობასთან — პროდუქტები იცვლება, მოთხოვნები იცვლება, ადაპტირდები პანიკის გარეშე
ექსპერტი
ჩვეულებრივ: 2+ წელი
ექსპერტი
ჩვეულებრივ: 2+ წელი
რა უნარებს ისწავლი
- ფრემვორკების ინოვაცია
- ტექნიკური სტრატეგია
- ღრმა დომენის ექსპერტიზა
- ინდუსტრიის სტანდარტებზე გავლენა
მზად ხარ შემდეგი დონისთვის, როდესაც
- მართე ტექნიკური მიმართულება 2+ გუნდის (ან საკუთარი მასშტაბირებული გუნდის) გასწვრივ კვარტალი ან მეტი
- შეგიძლია სარწმუნო 1-საათიანი ტექნიკური საუბრის გამართვა სხვა senior-თან peer-კომპანიიდან
- გაქვს საჯარო არტეფაქტი, რომელზეც სხვები მიუთითებენ — open-source, კონფერენციის გამოსვლა, ტექნიკური წერა
- რამდენიმე Senior-ს დაეხმარე მათი senior-ის წინსვლის გავლაში
- კომფორტული ხარ ოთახში „ყველაზე ნაკლებად ტექნიკურ“ ადამიანად ყოფნა, როცა ეს სწორია
რა ააშენო
კონკრეტული პროექტები — და რას გასწავლით ისინი.
- წვლილი დიდ frontend framework-ში ან მის ეკოსისტემაში (სწავლის: open-source code-review მსოფლიო დონეზე)
- შენი კომპანიის შემდეგი თაობის pattern-ის საჯარო სპეციფიკაციის დიზაინი და დაწერა (სწავლის: ინდუსტრიის დონის ტექნიკური კომუნიკაცია)
წაიკითხე
-
კონტექსტ-ინჟინერია: დისციპლინა, რომელიც 2026-ში ცვლის prompt engineering-ს
Prompt engineering არასოდეს ყოფილა რეალური უნარი. პროდუქშენში AI-ფიჩების ორწლიანი მიწოდების შემდეგ პირდაპირ ვიტყვი: შედეგზე სხვა გავლენას ახდენს — კონტექსტ-ინჟინერია. მდგომარეობა, ხელსაწყოები, ძიება, ისტორია და შეზღუდვები, რომელიც ზუსტ მომენტში მოდელის ფანჯარაში ერთმანეთს უხამდება. არქიტექტორის ხედვა.
-
Evals 2026-ში: ტესტ-სიუტი სისტემებისთვის, რომლებიც დეტერმინირებული არ არიან
თქვენი AI-ფიჩა გუშინ მუშაობდა და დღეს იშლება. არც კოდი შეცვლილა, არც პრომპტი, არც მოდელი. ასე გამოიყურება ცხოვრება evals-ის გარეშე. ეს არის spec → context → evals ტრიადის მესამე საყრდენი — და დისციპლინა, რომელსაც გუნდების უმეტესობა გამოტოვებს.
-
OpenSpec 2026-ში: spec-driven development-ის ოპერაციული სისტემა
ექვსი კვირის წინ დავაყენე @fission-ai/openspec. გუშინ ჩავაბარე თოთხმეტ-ფაილიანი ცვლილება ოთხმოცდაათ წუთში ორას-ხაზიანი სპეციფიკაციიდან, brownfield-კოდბაზაში, რომელსაც სამი ინჟინერი ორი წელია ასწორებს — მერჯ-კონფლიქტების გარეშე, რევიუს ესკალაციის გარეშე. ეს არის სენიორ-არქიტექტორის ღრმა გარჩევა იმისა, თუ რატომ OpenSpec არის პირველი SDD-ხელსაწყო, რომელიც პროდაქშენ-რეალობის ქვეშ არ იშლება.
-
როგორ გავიაროთ System Design ინტერვიუ: senior ინჟინრის სახელმძღვანელო
System design რჩევების უმეტესობა თეორიული ხმაურია. ეს არის გამეორებადი ფრეიმვორკი, რომელსაც კანდიდატების შესაფასებლად ვიყენებ — და რომელიც შეგიძლიათ გამოიყენოთ ნებისმიერი system design ინტერვიუს mid ან senior დონეზე გასავლელად.
გავრცელებული შეცდომები ამ ეტაპზე
- IC-ის სრულიად თავიდან აცილება — ტექნიკური სანდოობა ამ დონეზე სწრაფად იშლება
- კოდის წერაზე უარის თქმა, „რადგან Expert ვარ“ — უნდა დაწერო, კარგად
- საკუთარი გზის ერთადერთ სწორად მიჩნევა — ინდუსტრია უკვე ორჯერ წინ გასცდა შენ
- ხილული სამუშაოს ოპტიმიზაცია მაღალი leverage-ის მქონე სამუშაოს ნაცვლად
რას ელიან კომპანიები ამ დონეზე
- ადგენს და იცავს ფუნქციის ტექნიკურ სტრატეგიას
- ენდობიან გადაწყვეტილებების მიღებაში, რომლებიც roadmap-ის 6+ თვეზე ახდენს გავლენას
- გარე ყოფნა (წერა, გამოსვლები, OSS) ან ეკვივალენტური შიდა გავლენა
- აღიარებული ინდუსტრიული ექსპერტიზა მინიმუმ ერთ ვიწრო სფეროში
ბექენდის განვითარება
~3–5 წელი (დამწყები → Senior)
დამწყები
ჩვეულებრივ: 4–8 კვირა წყარო: Stack Overflow Developer Survey →
დამწყები
ჩვეულებრივ: 4–8 კვირა წყარო: Stack Overflow Developer Survey →
რა უნარებს ისწავლი
- HTTP და REST-ის საფუძვლები
- C# და .NET-ის საფუძვლები
- ობიექტზე ორინეტირებული პროგრამირების საფუძვლები (OOP)
- მონაცემთა ბაზების საფუძვლები (SQL)
- ვერსიების კონტროლი (Git)
მზად ხარ შემდეგი დონისთვის, როდესაც
- ააშენე და deploy-ი გააკეთე პატარა CRUD აპი ნულიდან — წიგნების სია, დავალებების ტრეკერი, რამაც მონაცემთა ბაზას ხებებს
- თავისუფლად წერ საბაზო SQL-ს: SELECT, JOIN, WHERE, GROUP BY copy-paste-ის გარეშე
- შეგიძლია ახსნა, რა არის HTTP request — method, headers, body, status code
- Git-ით იმუშავე რეალურ flow-ში: branch, commit, push საჯარო repo-ში
- იცი value და reference ტიპების სხვაობა C#-ში (და რატომ აქვს მნიშვნელობა)
რა ააშენო
კონკრეტული პროექტები — და რას გასწავლით ისინი.
- მარტივი C# კონსოლური აპი, რომელიც რამე სასარგებლოს აკეთებს (სწავლის: ტიპები, control flow, error handling)
- პატარა CRUD აპი SQL ბაზით — წიგნები / კონტაქტები / დავალებები (სწავლის: ORM-ის საფუძვლები, სქემის დიზაინი, საბაზო queries)
გაიარე ეს კურსები
შესავალი პროგრამირებაში C#-ზე
დაიწყეთ ნულიდან და ისწავლეთ C# etapobrivad: ენის საფუძვლებიდან მთავარ ტიპებამდე, ობიექტურ პროგრამირებამდე, კოლექციებამდე,_Generic_ ტიპებამდე, დელეგატებსა და მოვლენებამდე, გამონაკლისების დამუშავებამდე. მყარი საფუძველი .NET ბექენდ-დეველოპმენტისთვის.
SQL-ში შესავალი
ისწავლეთ SQL ნულიდან: შეკითხვები, მონაცემთა ბაზის დიზაინი, ინდექსები, JOIN-ები, ქვეშეკითხვები და შენახული პროცედურები.
Git და ვერსიების კონტროლი
დაეუფლეთ Git-ს ნულიდან: commits, branching, merging, rebasing, კონფლიქტების გადაჭრა, GitHub workflows და CI/CD საფუძვლები. ყველა დეველოპერს ეს სჭირდება.
წაიკითხე
-
C#-დან AI აგენტებამდე: .NET დეველოპერის გზა Claude-ზე განვითარებისკენ
თქვენ უკვე იცით C#, ASP.NET Core და როგორ გაუშვათ production ბექენდები. აი როგორ გამოიყენოთ ეს უნარები სერიოზული AI აგენტების შესაქმნელად Claude-ზე — თქვენი სტეკის გადაგდების გარეშე.
-
C# თუ Python 2025-ში: რომელი ვისწავლოთ ჯერ?
Senior ინჟინრის გულახდილი შეფასება: როგორ ავირჩიოთ C#-სა და Python-ს შორის როგორც პირველი სერიოზული ენა — შრომის ბაზრის მონაცემების, სასწავლო მრუდისა და კარიერაზე ხანგრძლივი გავლენის საფუძველზე.
-
როგორ გავიაროთ System Design ინტერვიუ: senior ინჟინრის სახელმძღვანელო
System design რჩევების უმეტესობა თეორიული ხმაურია. ეს არის გამეორებადი ფრეიმვორკი, რომელსაც კანდიდატების შესაფასებლად ვიყენებ — და რომელიც შეგიძლიათ გამოიყენოთ ნებისმიერი system design ინტერვიუს mid ან senior დონეზე გასავლელად.
გავრცელებული შეცდომები ამ ეტაპზე
- მიკროსერვისების არქიტექტურის აშენების მცდელობა, სანამ ერთი მუშა endpoint-ის დაწერა გასწავლია
- SQL-ის გამოტოვება, რადგან „ORM ყველაფერს თავად აკეთებს“ — როცა ORM ნელ query-ს მალავს, გასწორება SQL-ში მოგიწევს
- Git-ის აღქმა როგორც „შენახვის ღილაკი“ — branching და diff-ების კითხვა ისწავლე ადრე, მომავალი PR-ები ამაზეა დამოკიდებული
- სინტაქსის დამახსოვრება flow-ის გაგების ნაცვლად — კოდი ქვემოდან ზემოთ იკითხება, არა ზემოდან ქვემოთ
რას ელიან კომპანიები ამ დონეზე
- 2–3 პროექტიანი პორტფოლიო, რომელიც კლონირდება და გაიშვება — მინიმუმ ერთი ნამდვილი ბაზით
- საბაზო SQL-ის თავისუფალი წერა screen-share ინტერვიუზე, StackOverflow-ის გარეშე
- საბაზო Git workflow — clone, branch, commit, push, PR კომენტარებზე პასუხი
- შეგიძლია stack trace-ის წაკითხვა და მტყუნებული ხაზის პოვნა — ნახვაზე არ პანიკდები
უმცროსი
ჩვეულებრივ: 3–6 თვე წყარო: Stack Overflow Developer Survey →
უმცროსი
ჩვეულებრივ: 3–6 თვე წყარო: Stack Overflow Developer Survey →
რა უნარებს ისწავლი
- ASP.NET Core Web API-ის საფუძვლები
- როუტინგი, კონტროლერები, DTO-ები
- Entity Framework Core-ის საფუძვლები
- ავთენტიკაცია და ავტორიზაცია (JWT)
- Async/await და task-ებზე დაფუძნებული პროგრამირება
მზად ხარ შემდეგი დონისთვის, როდესაც
- გაუშვი REST API auth-ით, რეალური DB persistence-ით და მინიმუმ ერთი integration ტესტით
- თავისუფლად წერ async/await-ს, თავი არ გეშლება შესრულების რიგში
- შეგიძლია Web API მოთხოვნის დებაგი: კონტროლერიდან service-ით repository-მდე, breakpoint-ებით
- რევიუ გაუკეთე სხვის PR-ს და მინიმუმ ერთი სასარგებლო კომენტარი დაწერე, არა კოსმეტიკური
- საკმარისად გესმის DI, რომ ახალი service დაამატო სხვა ფაილიდან კოპირების გარეშე
რა ააშენო
კონკრეტული პროექტები — და რას გასწავლით ისინი.
- REST API ASP.NET Core + EF Core-ზე, JWT auth-ით, რეალურად სადმე deploy-ით (სწავლის: ერთი ადამიანის სრული stack, რეალური auth, რეალური DB, რეალური deploy)
- მომხმარებელთა ან დავალებების მართვის სერვისი მინიმუმ ერთი foreign-key კავშირით და სამი დაცული endpoint-ით (სწავლის: სქემის დიზაინი, route-ების დაცვა, error response-ები)
გაიარე ეს კურსები
შესავალი Entity Framework-ში
ისწავლეთ Entity Framework-ის საფუძვლები, მონაცემთა მოდელირება და პრაქტიკული მაგალითები .NET აპლიკაციებისთვის.
შესავალი ASP.NET Core-ში
ისწავლეთ ASP.NET Core-ის საფუძვლები: თანამედროვე backend დეველოპმენტი, DI, როუტინგი, კონტროლერები, REST API და გაშვება.
შესავალი MongoDB-ში
ისწავლეთ MongoDB ნულიდან: NoSQL კონცეფციები, დოკუმენტები და კოლექციები, შეკითხვები, ინდექსები, აგრეგაცია და ტრანზაქციები. პრაქტიკული დასაწყისი backend-სა და data engineering-ისთვის.
Node.js და REST API-ები
შექმენით production-მზა REST APIs Node.js-ით და Express-ით. ასინქრონული patterns, middleware, JWT ავტენტიფიკაცია, მონაცემთა ბაზის ინტეგრაცია, შეცდომების დამუშავება.
წაიკითხე
-
C#-დან AI აგენტებამდე: .NET დეველოპერის გზა Claude-ზე განვითარებისკენ
თქვენ უკვე იცით C#, ASP.NET Core და როგორ გაუშვათ production ბექენდები. აი როგორ გამოიყენოთ ეს უნარები სერიოზული AI აგენტების შესაქმნელად Claude-ზე — თქვენი სტეკის გადაგდების გარეშე.
-
C# თუ Python 2025-ში: რომელი ვისწავლოთ ჯერ?
Senior ინჟინრის გულახდილი შეფასება: როგორ ავირჩიოთ C#-სა და Python-ს შორის როგორც პირველი სერიოზული ენა — შრომის ბაზრის მონაცემების, სასწავლო მრუდისა და კარიერაზე ხანგრძლივი გავლენის საფუძველზე.
-
როგორ გავიაროთ System Design ინტერვიუ: senior ინჟინრის სახელმძღვანელო
System design რჩევების უმეტესობა თეორიული ხმაურია. ეს არის გამეორებადი ფრეიმვორკი, რომელსაც კანდიდატების შესაფასებლად ვიყენებ — და რომელიც შეგიძლიათ გამოიყენოთ ნებისმიერი system design ინტერვიუს mid ან senior დონეზე გასავლელად.
გავრცელებული შეცდომები ამ ეტაპზე
- ბიზნეს-ლოგიკის ჩასმა კონტროლერებში — კონტროლერები მარშრუტიზებენ, service-ები მუშაობას ასრულებენ, repository-ები ბაზასთან საუბრობენ
- ყოველი გამონაკლისის დაჭერა ზოგადი try/catch-ით — დაუშვი, რომ exception იქამდე მიაღწიოს, სადაც მისი დამუშავება იციან
- ტესტების არ წერა, რადგან „გუნდი მერე დაწერს“ — არ დაწერს. დაამატე მინიმუმ ერთი integration ტესტი თითოეულ endpoint-ზე.
- EF Core-ის აღქმა მაგიად — როცა query ნელია, სჭირდება მის მიერ გენერირებული SQL-ის წაკითხვა
რას ელიან კომპანიები ამ დონეზე
- მინიმუმ 1 deploy-ი REST API ASP.NET Core-ზე, რომელშიც ინტერვიუზე კოდით გასეირნება შეგიძლია
- OOP-ისა და async-ის მყარი საფუძვლები — Task და Task<T>-ს სხვაობას, value vs reference ტიპებს ხსნი
- დოკუმენტაციის წაკითხვა — შენი დეფოლტ ნაბიჯია გაჭედვისას, არა გუნდისთვის შეკითხვა
- request pipeline-ის საბაზო გაგება: middleware, filters, model binding
საშუალო დონე
ჩვეულებრივ: 6–12 თვე წყარო: Stack Overflow Developer Survey →
საშუალო დონე
ჩვეულებრივ: 6–12 თვე წყარო: Stack Overflow Developer Survey →
რა უნარებს ისწავლი
- Clean Architecture და შრეობრივი დიზაინი
- EF Core-ის წარმადობა და მიგრაციები
- ქეშირება (Redis / Valkey)
- მესიჯ ქიუები (RabbitMQ, Kafka-ის საფუძვლები)
- ერთეულური და ინტეგრაციის ტესტირება (xUnit, NUnit)
- CI/CD პაიპლაინები .NET სერვისებისთვის
მზად ხარ შემდეგი დონისთვის, როდესაც
- სამსახურში ან რეალურ OSS პროექტში ფიჩერი ნულიდან გაატარე: requirements → design → ship → on-call როცა გაფუჭდა
- სხვისი კოდის არატრივიალური ნაწილი ისე გადააკეთე, რომ უარესი არ გახდა — გუნდმა შენიშნა
- შეგიძლია ნელი EF Core query-ის დებაგი მისი გენერირებული SQL-ის წაკითხვითა და სწორი ინდექსის დამატებით
- PR-ებს რევიუ გაუკეთე რეალურ გუნდში და შენი რევიუ ფასობს — გვერდს არ უვლიან
- გაქვს Clean Architecture / DDD-ზე აზრი, რომელსაც კოდით იცავ, არა ბლოგებით
რა ააშენო
კონკრეტული პროექტები — და რას გასწავლით ისინი.
- მიკროსერვისი .NET-ზე ბაზით, ქეშით, message queue-ით, observability-ით და CI/CD-ით (სწავლის: production-ფორმის აზროვნება — რა იცვლება, როცა service-ები 3+-ია, არა 1)
- არსებული monolith-ის ფიჩერის რეფაქტორინგი სუფთა მოდულურ slice-ად ტესტებით (სწავლის: ინკრემენტული რეფაქტორინგი წნეხის ქვეშ — რეალურ გუნდებში მხოლოდ ეს ტიპი მნიშვნელოვანია)
გაიარე ეს კურსები
C# Pro: მაღალი დონის პროგრამირება და სისტემური დიზაინი
ისწავლეთ C# და .NET-ის მოწინავე შესაძლებლობები: კოლექციები, რეფლექცია, ასინქრონობა, ნაკადები, GC, სერიალიზაცია, TPL, ფუნქციური პროგრამირება და Windows ბირთვის სინქრონიზაცია.
დიზაინის შაბლონები C#-ში: თეორიიდან პრაქტიკამდე
ისწავლეთ GoF-ის კლასიკური დიზაინის შაბლონები C#-ში. გამოიყენეთ პოროჟდაიანი, სტრუქტურული და ქცევითი შაბლონები სუფთა და მოქნილი არქიტექტურის შესაქმნელად.
Backend არქიტექტურის საფუძვლები
პრაქტიკული კურსი backend არქიტექტურული აზროვნებისთვის. ისწავლით მასშტაბირებადი სისტემების დიზაინს, მონოლითსა და მიკროსერვისებს შორის არჩევანს, სუფთა API-ების შექმნას და production აზროვნებას.
AI-ზე დაფუძნებული .NET განვითარება
ინტეგრირეთ AI .NET აპლიკაციებში OpenAI და Azure OpenAI API-ების გამოყენებით. შექმენით ინტელექტუალური ფუნქციები: chat, summarization, embeddings, semantic search, RAG pipelines — C# და ASP.NET Core-ში.
წაიკითხე
-
კონტექსტ-ინჟინერია: დისციპლინა, რომელიც 2026-ში ცვლის prompt engineering-ს
Prompt engineering არასოდეს ყოფილა რეალური უნარი. პროდუქშენში AI-ფიჩების ორწლიანი მიწოდების შემდეგ პირდაპირ ვიტყვი: შედეგზე სხვა გავლენას ახდენს — კონტექსტ-ინჟინერია. მდგომარეობა, ხელსაწყოები, ძიება, ისტორია და შეზღუდვები, რომელიც ზუსტ მომენტში მოდელის ფანჯარაში ერთმანეთს უხამდება. არქიტექტორის ხედვა.
-
C#-დან AI აგენტებამდე: .NET დეველოპერის გზა Claude-ზე განვითარებისკენ
თქვენ უკვე იცით C#, ASP.NET Core და როგორ გაუშვათ production ბექენდები. აი როგორ გამოიყენოთ ეს უნარები სერიოზული AI აგენტების შესაქმნელად Claude-ზე — თქვენი სტეკის გადაგდების გარეშე.
-
C# თუ Python 2025-ში: რომელი ვისწავლოთ ჯერ?
Senior ინჟინრის გულახდილი შეფასება: როგორ ავირჩიოთ C#-სა და Python-ს შორის როგორც პირველი სერიოზული ენა — შრომის ბაზრის მონაცემების, სასწავლო მრუდისა და კარიერაზე ხანგრძლივი გავლენის საფუძველზე.
-
Evals 2026-ში: ტესტ-სიუტი სისტემებისთვის, რომლებიც დეტერმინირებული არ არიან
თქვენი AI-ფიჩა გუშინ მუშაობდა და დღეს იშლება. არც კოდი შეცვლილა, არც პრომპტი, არც მოდელი. ასე გამოიყურება ცხოვრება evals-ის გარეშე. ეს არის spec → context → evals ტრიადის მესამე საყრდენი — და დისციპლინა, რომელსაც გუნდების უმეტესობა გამოტოვებს.
გავრცელებული შეცდომები ამ ეტაპზე
- Clean Architecture-ის cargo-cult 3-endpoint-იან service-ში — შრეები სირთულის სამართავად არსებობს, არა მის დასამატებლად
- ყველაფრის microservice-ად ქცევა — გუნდების უმეტესობა უკეთ აგზავნის სუფთა მოდულურ monolith-ზე, ვიდრე ცუდად შემოსაზღვრულ მიკრო-ზოოპარკზე
- ყველგან ქეშირება — cache = invalidation = მზად პრობლემა, უბრალოდ ელოდება
- observability-ის გამოტოვება „სანამ დაგვჭირდება“ — იმ დროისთვის სიბნელეში დებაგ-ი logs.txt-ით და იმედით
რას ელიან კომპანიები ამ დონეზე
- ძლიერი .NET + EF Core, clean architecture-ისა და design patterns-ის რეალური გაგებით — არა მხოლოდ სახელმძღვანელოდან
- მყარი ინსტინქტი ტესტირებაში: unit + integration, საბაზო contract testing inter-service ზარებისთვის
- შეგიძლია პატარა ფიჩერის დაპროექტება senior-ის გვერდით ყოფნის გარეშე, DB სქემის და rollback გეგმის ჩათვლით
- ადეკვატური code review — კონსტრუქციულად აბრუნებ ცუდ PR-ებს, junior-ებს კოუჩინგი უტარდები რევიუს დროს
უფროსი
ჩვეულებრივ: 1–2 წელი
უფროსი
ჩვეულებრივ: 1–2 წელი
რა უნარებს ისწავლი
- .NET სისტემების არქიტექტურის დიზაინი
- მაღალ დატვირთვებზე ოპტიმიზაცია და პროფილინგი
- Observability (ლოგირება, ტრეისინგი, მეტრიკები)
- Domain-Driven Design (DDD), CQRS, ივენტ-დრივენ სისტემები
- ბექენდ გუნდის ლიდერობა და კოდის ხარისხის მართვა
მზად ხარ შემდეგი დონისთვის, როდესაც
- დაპროექტდი არატრივიალური პროდუქტის backend არქიტექტურა (3+ service ან 5+ ინჟინერი მასზე დამოკიდებული)
- მიიღე ტექნოლოგიური გადაწყვეტილება, რომელსაც გუნდი ერთი წლის შემდეგაც იყენებს — და შეგიძლია trade-off-ების ახსნა
- junior ან mid ინჟინერი რეალური პლატოდან გადაიყვანე — მათ გააგზავნეს ის, რასაც ადრე ვერ ახერხებდნენ
- შეწყვიტე ბილეთების წერა „რადგან მინდა“ — წერ, რადგან ეს სისტემისთვის სწორი შემდეგი ნაბიჯია
- კომფორტული ხარ უთხრა PM-ს, დიზაინერს ან სხვა senior-ს „ეს იდეა არასწორია“ — დასაბუთებით, არა სტატუსით
რა ააშენო
კონკრეტული პროექტები — და რას გასწავლით ისინი.
- მრავალ-სერვისიანი პროდუქტის backend არქიტექტურის დიზაინი, DB სტრატეგიის, observability-ის, deploy გეგმის ჩათვლით (სწავლის: failure mode-ებში აზროვნება, არა happy path-ებში)
- კრიტიკული მიგრაციის წაყვანა — DB engine-ის შეცვლა, framework-ის განახლება, monolith-დან გამოყოფა — გასაზომი rollback გეგმით (სწავლის: დაგეგმვა, კომუნიკაცია, mentoring წნეხის ქვეშ)
გაიარე ეს კურსები
1:1 Backend და არქიტექტურის განხილვა
პირადი 1:1 სესია არქიტექტურაზე ფოკუსით: რისკების გამოვლენა, trade-off-ების განხილვა და კონკრეტული შემდეგი ნაბიჯების განსაზღვრა. განვიხილავთ backend არქიტექტურას, კოდს და production მზადყოფნას.
LLM-ზე დაფუძნებული აპების შექმნა: RAG & Agents
შექმენით production-კლასის AI აპლიკაციები დიდი სასწავლო მოდელების გამოყენებით. Vector databases, RAG, autonomous agents, tool use, evaluation და deployment patterns.
Claude API-ით აპლიკაციების შექმნა: production AI Anthropic SDK-ით
დაეუფლეთ Anthropic-ის Claude API-ს: messages API, prompt caching, tool use, extended thinking, streaming, batch processing, files, citations და vision. შექმენით ეკონომიური production AI ფუნქციები ნებისმიერ backend-ში.
Agents-ის შექმნა Claude Agent SDK-ით
შექმენით საკუთარი AI აგენტები Claude Agent SDK-ით. ააწყვეთ agent loops, განსაზღვრეთ tools, მართეთ memory და sub-agents, შეაფასეთ behavior და deploy multi-agent სისტემები, რომლებიც რეალურ საინჟინრო ამოცანებს ავტონომიურად ხსნიან.
წაიკითხე
-
Claude Code production-ში: რა ვისწავლე 6 თვეში
ექვსი თვე Claude Code როგორც ძირითადი ინსტრუმენტი — რომელი workflows-ი რეალურად დაზოგავს დროს, რომელი მას ჩუმად ჭამს, და რა კონფიგურაცია არ ეყენება გუნდების უმეტესობას.
-
კონტექსტ-ინჟინერია: დისციპლინა, რომელიც 2026-ში ცვლის prompt engineering-ს
Prompt engineering არასოდეს ყოფილა რეალური უნარი. პროდუქშენში AI-ფიჩების ორწლიანი მიწოდების შემდეგ პირდაპირ ვიტყვი: შედეგზე სხვა გავლენას ახდენს — კონტექსტ-ინჟინერია. მდგომარეობა, ხელსაწყოები, ძიება, ისტორია და შეზღუდვები, რომელიც ზუსტ მომენტში მოდელის ფანჯარაში ერთმანეთს უხამდება. არქიტექტორის ხედვა.
-
Evals 2026-ში: ტესტ-სიუტი სისტემებისთვის, რომლებიც დეტერმინირებული არ არიან
თქვენი AI-ფიჩა გუშინ მუშაობდა და დღეს იშლება. არც კოდი შეცვლილა, არც პრომპტი, არც მოდელი. ასე გამოიყურება ცხოვრება evals-ის გარეშე. ეს არის spec → context → evals ტრიადის მესამე საყრდენი — და დისციპლინა, რომელსაც გუნდების უმეტესობა გამოტოვებს.
-
OpenSpec 2026-ში: spec-driven development-ის ოპერაციული სისტემა
ექვსი კვირის წინ დავაყენე @fission-ai/openspec. გუშინ ჩავაბარე თოთხმეტ-ფაილიანი ცვლილება ოთხმოცდაათ წუთში ორას-ხაზიანი სპეციფიკაციიდან, brownfield-კოდბაზაში, რომელსაც სამი ინჟინერი ორი წელია ასწორებს — მერჯ-კონფლიქტების გარეშე, რევიუს ესკალაციის გარეშე. ეს არის სენიორ-არქიტექტორის ღრმა გარჩევა იმისა, თუ რატომ OpenSpec არის პირველი SDD-ხელსაწყო, რომელიც პროდაქშენ-რეალობის ქვეშ არ იშლება.
გავრცელებული შეცდომები ამ ეტაპზე
- system design-ის აღქმა ტროფეად — არქიტექტურა გუნდის რეალური პრობლემების გადასაჭრელად არსებობს, არა შენი რეზიუმეს მოსართავად
- ზედმეტი ჩადება იმ stack-ში, რომლითაც დაიწყე — Senior არის გაფართოება (სხვა ენები, სხვა პარადიგმები), არა შევიწროება
- „ადამიანური“ პრობლემების თავიდან აცილება — ეს senior-ის სამუშაოს 70%-ია და ის ნაწილი, რომელიც განსაზღვრავს Staff-ად გახდები თუ არა
- junior-ების არ კოუჩინგი რეალურ PR-ებზე. გუნდის ხარისხის პლატო — შენი პლატოა.
რას ელიან კომპანიები ამ დონეზე
- შეგიძლია backend არქიტექტურის დაპროექტება და მფლობელობა რამდენიმე service-ზე, სარწმუნო failure mode ისტორიით
- მყარი ტექნიკური კომუნიკაცია: დოკუმენტები, RFC-ები, ასინქრონული წერა — გუნდი მოქმედებს შენი ტექსტის მიხედვით შენი ოთახში ყოფნის გარეშე
- აძლიერებ გუნდს — junior-ები მჩვენებლად იზრდებიან, როცა შენ უერთდები, mid-level-ები უფრო სწრაფად მიდიან წინ
- კომფორტული ხარ გაურკვევლობასთან: პროდუქტები და მოთხოვნები იცვლება, ხარისხის დაკარგვის გარეშე ადაპტირდები
ექსპერტი
ჩვეულებრივ: 2+ წელი
ექსპერტი
ჩვეულებრივ: 2+ წელი
რა უნარებს ისწავლი
- .NET ეკოსისტემის პლატფორმისა და არქიტექტურის სტრატეგია
- დიდი მასშტაბის განაწილებული სისტემები .NET-ზე
- ტექნიკური ლიდერობა რამდენიმე გუნდის დონეზე
- ინჟინერინგული სტანდარტებისა და საუკეთესო პრაქტიკის დადგენა
- ქომუნიტიზე ზეგავლენა: open-source, პრეზენტაციები, მენტორობა
მზად ხარ შემდეგი დონისთვის, როდესაც
- მართე ტექნიკური მიმართულება 2+ გუნდის (ან საკუთარი მასშტაბირებული გუნდის) გასწვრივ კვარტალი ან მეტი
- შეგიძლია სარწმუნო 1-საათიანი ტექნიკური საუბრის გამართვა sister-კომპანიის senior-თან — და წახვიდე რაიმე ახალი ცოდნით
- გაქვს საჯარო არტეფაქტი, რომელზეც სხვები მიუთითებენ: OSS, კონფერენციის გამოსვლა ან ფართოდ ციტირებული შიდა RFC
- რამდენიმე Senior-ს დაეხმარე წინსვლაში — ისინი შენ აცხადებენ მიზეზად
- კომფორტული ხარ ოთახში „ყველაზე ნაკლებად ტექნიკურ“ ადამიანად ყოფნა, როცა ეს სწორია — და ყველაზე ტექნიკურად 30 წუთში
რა ააშენო
კონკრეტული პროექტები — და რას გასწავლით ისინი.
- კომპანიისთვის .NET პლატფორმის ხედვის განსაზღვრა — რომელი service რომელ pattern-ებს იყენებს, რატომ და როგორ ერთვებიან გუნდები (სწავლის: სტანდარტები როგორც multiplier, არა constraint)
- ძირითადი OSS ან შიდა framework-ის განვითარება, რომელსაც რამდენიმე გუნდი იყენებს — არტეფაქტი, რომელიც კომპანიაში შენს როლს გადაცილდება (სწავლის: API დიზაინი მასშტაბურად, deprecation დისციპლინა)
გაიარე ეს კურსები
MCP სერვერების და AI Tool Integrations-ის შექმნა
დაეუფლეთ Model Context Protocol (MCP) — Anthropic-ის ღია სტანდარტს AI მოდელების გარე ინსტრუმენტებთან და მონაცემებთან დასაკავშირებლად. შექმენით MCP სერვერები, გაუმართეთ API Claude-ს.
Spec-Driven Development-ის საფუძვლები: ფილოსოფიიდან ოპერაციულ მოდელამდე
ისწავლე იმ specs-ის წერა, რომელსაც agents-ი მართლა ემორჩილება, კოდი როგორც durable spec-ის ქეში გაუშვი და გამართე spec→context→evals ტრიადა რეალურ კოდბაზებზე. Vendor-agnostic, tool-agnostic, brownfield-ready — მეთოდოლოგიური კურსი, რომელიც ნებისმიერ agentic stack-თან ერთად მუშაობს.
OpenSpec-ის დაუფლება: production spec-driven workflows AI coding agents-ისთვის
გადააქციე SDD ოპერაციულად OpenSpec-ით — open-source spec framework, რომელიც specs-ს ისე ეპყრობა, როგორც Git კოდს. დაეუფლე /opsx:propose, /opsx:apply და /opsx:archive ბრძანებებს რეალურ brownfield კოდბაზაზე. CI gates, multi-engineer collaboration, legacy specs-ის retrofitting და workflow რიტუალები, რომლებიც რჩება.
წაიკითხე
-
კონტექსტ-ინჟინერია: დისციპლინა, რომელიც 2026-ში ცვლის prompt engineering-ს
Prompt engineering არასოდეს ყოფილა რეალური უნარი. პროდუქშენში AI-ფიჩების ორწლიანი მიწოდების შემდეგ პირდაპირ ვიტყვი: შედეგზე სხვა გავლენას ახდენს — კონტექსტ-ინჟინერია. მდგომარეობა, ხელსაწყოები, ძიება, ისტორია და შეზღუდვები, რომელიც ზუსტ მომენტში მოდელის ფანჯარაში ერთმანეთს უხამდება. არქიტექტორის ხედვა.
-
Evals 2026-ში: ტესტ-სიუტი სისტემებისთვის, რომლებიც დეტერმინირებული არ არიან
თქვენი AI-ფიჩა გუშინ მუშაობდა და დღეს იშლება. არც კოდი შეცვლილა, არც პრომპტი, არც მოდელი. ასე გამოიყურება ცხოვრება evals-ის გარეშე. ეს არის spec → context → evals ტრიადის მესამე საყრდენი — და დისციპლინა, რომელსაც გუნდების უმეტესობა გამოტოვებს.
-
OpenSpec 2026-ში: spec-driven development-ის ოპერაციული სისტემა
ექვსი კვირის წინ დავაყენე @fission-ai/openspec. გუშინ ჩავაბარე თოთხმეტ-ფაილიანი ცვლილება ოთხმოცდაათ წუთში ორას-ხაზიანი სპეციფიკაციიდან, brownfield-კოდბაზაში, რომელსაც სამი ინჟინერი ორი წელია ასწორებს — მერჯ-კონფლიქტების გარეშე, რევიუს ესკალაციის გარეშე. ეს არის სენიორ-არქიტექტორის ღრმა გარჩევა იმისა, თუ რატომ OpenSpec არის პირველი SDD-ხელსაწყო, რომელიც პროდაქშენ-რეალობის ქვეშ არ იშლება.
-
როგორ გავიაროთ System Design ინტერვიუ: senior ინჟინრის სახელმძღვანელო
System design რჩევების უმეტესობა თეორიული ხმაურია. ეს არის გამეორებადი ფრეიმვორკი, რომელსაც კანდიდატების შესაფასებლად ვიყენებ — და რომელიც შეგიძლიათ გამოიყენოთ ნებისმიერი system design ინტერვიუს mid ან senior დონეზე გასავლელად.
გავრცელებული შეცდომები ამ ეტაპზე
- IC-ის სრულიად თავიდან აცილება — ტექნიკური სანდოობა ამ დონეზე სწრაფად იშლება. კოდი დაწერე, კარგად, ყოველთვიურად.
- კოდის წერაზე უარის თქმა „რადგან Expert ვარ“ — როგორც კი ვერ გააკეთებ prototype-ს, შენი design feedback ბუნდოვანი ხდება
- საკუთარი stack-ის უნივერსალურ პასუხად მიჩნევა — ინდუსტრია მინიმუმ ერთხელ უკვე წინ გასცდა შენს საყვარელ პარადიგმას
- ხილული სამუშაოს ოპტიმიზაცია მაღალი leverage-ის სამუშაოს ნაცვლად — სამუშაო release note-ის გარეშე ხშირად უფრო მნიშვნელოვანია
რას ელიან კომპანიები ამ დონეზე
- ადგენს და იცავს backend ფუნქციის ტექნიკურ სტრატეგიას
- ენდობიან გადაწყვეტილებების მიღებაში, რომლებიც roadmap-ის 6+ თვეზე ახდენს გავლენას და უძლებენ VP-ების და სხვა Expert-ების შემოწმებას
- გარე ყოფნა (წერა, გამოსვლები, OSS) ან ეკვივალენტური შიდა გავლენა (architecture council, hiring bar, mentor pool)
- აღიარებული ინდუსტრიული ექსპერტიზა მინიმუმ ერთ ვიწრო სფეროში — განაწილებული სისტემები, performance, security და სხვა
მონაცემთა მეცნიერება / ML
~3–5 წელი (Junior → Senior — Data იშვიათად იწყება Beginner-დან)
უმცროსი
ჩვეულებრივ: 3–6 თვე წყარო: Stack Overflow Developer Survey →
უმცროსი
ჩვეულებრივ: 3–6 თვე წყარო: Stack Overflow Developer Survey →
რა უნარებს ისწავლი
- Python მონაცემების ანალიზისთვის
- Pandas და NumPy
- მონაცემების ვიზუალიზაცია
- SQL მოთხოვნები
- სტატისტიკის საფუძვლები
მზად ხარ შემდეგი დონისთვის, როდესაც
- საჯარო dataset-ი თავიდან ბოლომდე გაასუფთავე და გააანალიზე — CSV-დან გრაფიკამდე, რომელსაც სხვა ადამიანი გაიგებს
- თავისუფლად წერ SQL-ს SELECT-ის მიღმა — joins, window functions, საბაზო ოპტიმიზაცია
- დაწერე Python-სკრიპტი, რომელიც კითხულობს, ცვლის და წერს მონაცემებს StackOverflow-დან copy-paste-ის გარეშე
- შეგიძლია ახსნა mean-ის, median-ის და mode-ის სხვაობის Wikipedia-ის გარეშე
- შენი ანალიზი GitHub-ზე ატვირთე README-ით, რომელიც სხვა ადამიანმა შეიძლება გაიაროს
რა ააშენო
კონკრეტული პროექტები — და რას გასწავლით ისინი.
- მონაცემების ანალიზის პროექტი საჯარო dataset-ზე (Kaggle, ღია მონაცემები) — გასუფთავება, ანალიზი, ვიზუალიზაცია, დასკვნები (სწავლის: pandas, matplotlib, ანალიზის რეალური ციკლი)
- პატარა dashboard, რომელიც API-დან live მონაცემებს იღებს და ახლდება (სწავლის: ETL-ის საფუძვლები, დაგეგმვა, მონაცემების პრეზენტაცია notebook-ის გარეშე)
გაიარე ეს კურსები
Python-ის საფუძვლები
ისწავლეთ Python ნულიდან: ცვლადები, მონაცემთა ტიპები, ფუნქციები, OOP, ფაილებთან მუშაობა, მოდულები და პრაქტიკული სკრიპტები. იდეალური პირველი ნაბიჯი backend, data და AI კარიერისთვის.
SQL-ში შესავალი
ისწავლეთ SQL ნულიდან: შეკითხვები, მონაცემთა ბაზის დიზაინი, ინდექსები, JOIN-ები, ქვეშეკითხვები და შენახული პროცედურები.
გავრცელებული შეცდომები ამ ეტაპზე
- SQL-ის გამოტოვება, რადგან „pandas-ს გამოვიყენებ“ — როცა dataset 50GB-ია, pandas იშლება და SQL ერთადერთი ვარიანტია
- Streamlit dashboard-ის აშენება, სანამ გაიაზრებდი რა ინსაითს იძლევი
- Jupyter notebook-ის აღქმა production კოდად — ეს sandbox-ია, არა deliverable
- სტატისტიკის გამოტოვება, რადგან „მოდელი თავად გაარკვევს“ — მოდელის ყოველი შეცდომა სტატისტიკის შენიღბული შეცდომაა
რას ელიან კომპანიები ამ დონეზე
- 1–2 პროექტიანი პორტფოლიო GitHub-ზე რეალური data-სამუშაოთი — Kaggle საწყისია, არა ფინიში
- თავისუფალი SQL screen-share ინტერვიუზე, არა მხოლოდ notebook-ის ერთხაზიანი ფრაზები
- შეგიძლია ახსნა, რატომ ასე გაასუფთავე მონაცემები — არა მხოლოდ რომ გაასუფთავე
- საბაზო git workflow, შეგიძლია სხვისი notebook-ის წაკითხვა და სკრიპტად ქცევა
საშუალო დონე
ჩვეულებრივ: 6–12 თვე წყარო: Stack Overflow Developer Survey →
საშუალო დონე
ჩვეულებრივ: 6–12 თვე წყარო: Stack Overflow Developer Survey →
რა უნარებს ისწავლი
- მანქანური სწავლების საფუძვლები
- Scikit-learn
- მოდელის შეფასება
- ფიჩერების ინჟინერია
- მონაცემების პაიპლაინები
მზად ხარ შემდეგი დონისთვის, როდესაც
- სამსახურში ან რეალურ პროექტში ML-ფიჩერი ნულიდან გაატარე: data → model → deploy → monitoring
- შეგიძლია მოდელის დებაგი, რომელიც „production-ში გაუარესდა“, მონაცემების კითხვით — არა ბრმად ხელახალი ვარჯიშით
- ააშენე მინიმუმ ერთი ETL/ELT pipeline, რომელიც განრიგით მუშაობს და failure-ებიდან აღდგება
- რევიუ გაუკეთე სხვის data-სამუშაოს და feedback კოსმეტიკური არ იყო
- გაქვს აზრი კლასიკურ ML vs LLM-ამ-დავალებისთვის, რომელსაც კოდით იცავ
რა ააშენო
კონკრეტული პროექტები — და რას გასწავლით ისინი.
- ML მოდელის ვარჯიში, შეფასება და deploy HTTP API-ის უკან — /predict endpoint-ის ჩათვლით retry/timeout-ით (სწავლის: რომ „ML deploy“ ძირითადად ჩვეულებრივი backend სამუშაოა)
- RAG-prototype: corpus-ის ჩატვირთვა, embedd-ი, შენახვა, retrieval, პასუხი (სწავლის: vector DB-ები, prompt-ის კონსტრუირება, evaluation)
გაიარე ეს კურსები
Prompt Engineering და AI Workflow ავტომატიზაცია
ისწავლეთ AI მოდელებთან ეფექტური მუშაობა: დაწერეთ მაღალხარისხიანი prompts, შექმენით ავტომატიზებული workflows Cursor, Copilot და API ინსტრუმენტებით.
AI-ზე დაფუძნებული .NET განვითარება
ინტეგრირეთ AI .NET აპლიკაციებში OpenAI და Azure OpenAI API-ების გამოყენებით. შექმენით ინტელექტუალური ფუნქციები: chat, summarization, embeddings, semantic search, RAG pipelines — C# და ASP.NET Core-ში.
წაიკითხე
-
AI ინსტრუმენტები, რომლებიც ყველა დეველოპერმა უნდა გამოიყენოს 2025-ში
არა hype-სია. პრაქტიკული ანალიზი — რომელი AI ინსტრუმენტები რეალურად ზოგავს დროს, რომელი ხარჯავს, და როგორ ააწყოთ workflow, რომელიც გხდით აზომვადად სწრაფს.
-
Claude Code production-ში: რა ვისწავლე 6 თვეში
ექვსი თვე Claude Code როგორც ძირითადი ინსტრუმენტი — რომელი workflows-ი რეალურად დაზოგავს დროს, რომელი მას ჩუმად ჭამს, და რა კონფიგურაცია არ ეყენება გუნდების უმეტესობას.
-
კონტექსტ-ინჟინერია: დისციპლინა, რომელიც 2026-ში ცვლის prompt engineering-ს
Prompt engineering არასოდეს ყოფილა რეალური უნარი. პროდუქშენში AI-ფიჩების ორწლიანი მიწოდების შემდეგ პირდაპირ ვიტყვი: შედეგზე სხვა გავლენას ახდენს — კონტექსტ-ინჟინერია. მდგომარეობა, ხელსაწყოები, ძიება, ისტორია და შეზღუდვები, რომელიც ზუსტ მომენტში მოდელის ფანჯარაში ერთმანეთს უხამდება. არქიტექტორის ხედვა.
-
C#-დან AI აგენტებამდე: .NET დეველოპერის გზა Claude-ზე განვითარებისკენ
თქვენ უკვე იცით C#, ASP.NET Core და როგორ გაუშვათ production ბექენდები. აი როგორ გამოიყენოთ ეს უნარები სერიოზული AI აგენტების შესაქმნელად Claude-ზე — თქვენი სტეკის გადაგდების გარეშე.
გავრცელებული შეცდომები ამ ეტაპზე
- LLM-ისკენ ხელის გაწვდენა იქ, სადაც 50 ხაზიანი scikit-learn სკრიპტი უფრო იაფად, სწრაფად და სანდოდ იმუშავებდა
- accuracy-ს ერთადერთ მეტრიკად მიჩნევა — production ML ცოცხლობს ან კვდება latency-ზე, cost-ზე და failure mode-ებზე
- eval-set დისციპლინის გამოტოვება — ყოველი „მოდელი მშვენიერია“ განცხადება eval-set-ის გარეშე მარკეტინგია
- მონაცემების არ ვერსიონირება — როცა მოდელი ფუჭდება, უნდა იცოდე, რა მონაცემებზე ვარჯიშობდა
რას ელიან კომპანიები ამ დონეზე
- ძლიერი Python + SQL ML lifecycle-ის რეალური გაგებით (არა „ნოთბუქი → PowerPoint“)
- მყარი საფუძვლები evaluation-ში: train/val/test, leakage, საბაზო შედარებები
- შეგიძლია პატარა ML-ფიჩერის დაპროექტება senior-ის გვერდით ყოფნის გარეშე — data-ის, model-ის და serving-ის ჩათვლით
- ადეკვატური code review — ცუდ data-სამუშაოზე ისევე აპროტესტებ, როგორც ცუდ კოდზე
უფროსი
ჩვეულებრივ: 1–2 წელი
უფროსი
ჩვეულებრივ: 1–2 წელი
რა უნარებს ისწავლი
- გაუმჯობესებული ML ალგორითმები
- ღრმა სწავლება (Deep Learning)
- მოდელების ოპტიმიზაცია
- დიდი მონაცემების ტექნოლოგიები
- კვლევითი სამუშაო
რა ააშენო
კონკრეტული პროექტები — და რას გასწავლით ისინი.
- რთული ML სისტემა
- data science გუნდის ლიდერობა
ექსპერტი
ჩვეულებრივ: 2+ წელი
ექსპერტი
ჩვეულებრივ: 2+ წელი
რა უნარებს ისწავლი
- AI ინოვაციები
- კვლევითი მიმართულების ლიდერობა
- ალგორითმების დიზაინი
- ინდუსტრიული კვლევები
- ტექნიკური სტრატეგია
მზად ხარ შემდეგი დონისთვის, როდესაც
- მართე data/ML ტექნიკური მიმართულება 2+ გუნდის გასწვრივ კვარტალი ან მეტი
- შეგიძლია სარწმუნო 1-საათიანი ტექნიკური საუბარი sister-კომპანიის senior data-ადამიანთან
- საჯარო არტეფაქტი: სტატია, OSS, კონფერენციის გამოსვლა ან ფართოდ ციტირებული შიდა RFC
- რამდენიმე Senior-ს დაეხმარე წინსვლაში data ორგანიზაციაში
- კომფორტული ხარ უთხრა „ეს არ უნდა ავაშენოთ“, როცა მონაცემები პროდუქტს არ უჭერს მხარს
რა ააშენო
კონკრეტული პროექტები — და რას გასწავლით ისინი.
- research-სტატიის, ტექნიკური პოსტის ან OSS-წვლილის გამოქვეყნება, რომელზეც სხვა პრაქტიკოსები მიუთითებენ (სწავლის: სიცხადე იმ დონეზე, სადაც ინდუსტრია მოძრაობს)
- კომპანიის AI/data-პლატფორმის სტრატეგიის განსაზღვრა — რომელი stack, რომელი კონტროლი, რომელი eval-დისციპლინა (სწავლის: სტანდარტები როგორც multiplier)
გაიარე ეს კურსები
MCP სერვერების და AI Tool Integrations-ის შექმნა
დაეუფლეთ Model Context Protocol (MCP) — Anthropic-ის ღია სტანდარტს AI მოდელების გარე ინსტრუმენტებთან და მონაცემებთან დასაკავშირებლად. შექმენით MCP სერვერები, გაუმართეთ API Claude-ს.
Agents-ის შექმნა Claude Agent SDK-ით
შექმენით საკუთარი AI აგენტები Claude Agent SDK-ით. ააწყვეთ agent loops, განსაზღვრეთ tools, მართეთ memory და sub-agents, შეაფასეთ behavior და deploy multi-agent სისტემები, რომლებიც რეალურ საინჟინრო ამოცანებს ავტონომიურად ხსნიან.
წაიკითხე
-
AI ინსტრუმენტები, რომლებიც ყველა დეველოპერმა უნდა გამოიყენოს 2025-ში
არა hype-სია. პრაქტიკული ანალიზი — რომელი AI ინსტრუმენტები რეალურად ზოგავს დროს, რომელი ხარჯავს, და როგორ ააწყოთ workflow, რომელიც გხდით აზომვადად სწრაფს.
-
Claude Code production-ში: რა ვისწავლე 6 თვეში
ექვსი თვე Claude Code როგორც ძირითადი ინსტრუმენტი — რომელი workflows-ი რეალურად დაზოგავს დროს, რომელი მას ჩუმად ჭამს, და რა კონფიგურაცია არ ეყენება გუნდების უმეტესობას.
-
კონტექსტ-ინჟინერია: დისციპლინა, რომელიც 2026-ში ცვლის prompt engineering-ს
Prompt engineering არასოდეს ყოფილა რეალური უნარი. პროდუქშენში AI-ფიჩების ორწლიანი მიწოდების შემდეგ პირდაპირ ვიტყვი: შედეგზე სხვა გავლენას ახდენს — კონტექსტ-ინჟინერია. მდგომარეობა, ხელსაწყოები, ძიება, ისტორია და შეზღუდვები, რომელიც ზუსტ მომენტში მოდელის ფანჯარაში ერთმანეთს უხამდება. არქიტექტორის ხედვა.
-
C#-დან AI აგენტებამდე: .NET დეველოპერის გზა Claude-ზე განვითარებისკენ
თქვენ უკვე იცით C#, ASP.NET Core და როგორ გაუშვათ production ბექენდები. აი როგორ გამოიყენოთ ეს უნარები სერიოზული AI აგენტების შესაქმნელად Claude-ზე — თქვენი სტეკის გადაგდების გარეშე.
გავრცელებული შეცდომები ამ ეტაპზე
- ხელსაწყოების არჩევა hype-ით, არა იმით, რაც გუნდს სჭირდება და შეუძლია შენარჩუნება
- ბიზნეს-საუბრების თავიდან აცილება — ამ დონეზე „მოდელი მშვენიერია“ ცარიელი ბგერაა business impact-ის გარეშე
- საკუთარი გზის ერთადერთ სწორად მიჩნევა — ინდუსტრია მინიმუმ ერთხელ უკვე წინ გასცდა
- ხილული სამუშაოს ოპტიმიზაცია leverage-სამუშაოს ნაცვლად (eval pipeline-ები > flashy ახალი მოდელი)
რას ელიან კომპანიები ამ დონეზე
- ადგენს და იცავს data/ML ტექნიკურ სტრატეგიას ფუნქციისთვის
- ენდობიან 6+ თვის roadmap-ის გადაწყვეტილებებს, VP-ების შემოწმებას უძლებენ
- გარე ყოფნა (სტატიები, გამოსვლები, OSS) ან ეკვივალენტური შიდა გავლენა
- აღიარებული ინდუსტრიული ექსპერტიზა მინიმუმ ერთ სფეროში — recsys, LLM-აგენტები, time series
DevOps / SRE
~4–6 წელი ჯამში (DevOps-ში ჩვეულებრივ მიდიან 1–2 წლის backend-ის ან sysadmin-ის შემდეგ)
საშუალო დონე
ჩვეულებრივ: 6–12 თვე წყარო: CNCF Annual Survey →
საშუალო დონე
ჩვეულებრივ: 6–12 თვე წყარო: CNCF Annual Survey →
რა უნარებს ისწავლი
- Docker კონტეინერიზაცია
- Kubernetes-ის საფუძვლები
- CI/CD პაიპლაინები
- Linux ადმინისტრირება
- ქსელების საფუძვლები
მზად ხარ შემდეგი დონისთვის, როდესაც
- რეალური service local dev-დან production-მდე გაიარე: Dockerfile, CI, deploy, monitoring — tutorial-დან copy-paste-ის გარეშე
- თავისუფლად კითხულობ container-ის log-ებს და kubectl describe output-ს CrashLoopBackOff-ის დიაგნოზისთვის
- მინიმუმ ერთი CI pipeline თავად დაწერე, არა მხოლოდ არსებული გადააკეთე
- გესმის sxvaoba liveness და readiness probe-ებს შორის, და როდის რა გამოიყენება
- გაქვს აზრი Helm vs Kustomize-ზე, რომელსაც იცავ რეალური config-ით, რომელიც დაწერე
რა ააშენო
კონკრეტული პროექტები — და რას გასწავლით ისინი.
- აიღე ნამდვილი backend service და გაატარე სრული pipeline-ით: Dockerfile → CI build → push → deploy → health check (სწავლის: რეალური production ციკლი, არა იზოლირებული ნაჭრები)
- მცირე კლასტერზე monitoring-ისა და alerting-ის დაყენება — ერთი ნამდვილი alert-ის გამოწვევა, შემდეგ tune-ი (სწავლის: alert fatigue რეალურია; ხარისხი > რაოდენობა)
წაიკითხე
-
Claude Code production-ში: რა ვისწავლე 6 თვეში
ექვსი თვე Claude Code როგორც ძირითადი ინსტრუმენტი — რომელი workflows-ი რეალურად დაზოგავს დროს, რომელი მას ჩუმად ჭამს, და რა კონფიგურაცია არ ეყენება გუნდების უმეტესობას.
-
Spec-Driven Development: როცა სპეციფიკაცია კოდბაზად იქცევა
უკვე ორი თვეა, ხელით ერთი ფუნქცია არ დამიწერია — და კოდბაზა არასოდეს ყოფილა უფრო ჯანმრთელი. აი, როგორ შეცვალა spec-driven development-მა ის, რასაც 2026-ში «საინჟინრო სამუშაო» ერქმევა, წესები, რომლებიც დისციპლინას პატიოსნებას უნარჩუნებენ, და ადგილები, სადაც ის ჯერ კიდევ იშლება.
გავრცელებული შეცდომები ამ ეტაპზე
- Kubernetes-ისკენ ხელის გაწვდენა, სადაც ჩვეულებრივი VM systemd-ით ამოცანას 1/10 ოპერაციული ფასით გადაჭრიდა
- CI/CD-ის აღქმა „დააყენე და დაივიწყე“ — pipeline-ებს მოვლა სჭირდება, როგორც ნებისმიერ კოდს
- CI log-ებში env-ცვლადებში secret-ების შენახვა — failure mode-ი = „შენი AWS-გასაღებები Pastebin-ზე“
- on-call გამოცდილების გამოტოვება — DevOps on-call-ის გარეშე თეორიაა; on-call არის სადაც გაიგებ, რა ფუჭდება სინამდვილეში
რას ელიან კომპანიები ამ დონეზე
- რეალურად ahead production-ში — არა „Kubernetes-ი ვისწავლე home cluster-ზე“
- თავისუფლად მუშაობ მინიმუმ ერთ cloud provider-თან ღრმად (AWS, GCP ან Azure) — არა სამივესთან ზედაპირულად
- მყარი Linux საფუძვლები: ssh, ფაილის უფლებები, systemd, საბაზო ქსელები
- ჯერ docs, მერე გუნდი — არ ცხოვრობ #help-devops chat-ში
უფროსი
ჩვეულებრივ: 1–2 წელი
უფროსი
ჩვეულებრივ: 1–2 წელი
რა უნარებს ისწავლი
- გაგრძელებული Kubernetes
- Infrastructure as Code (Terraform, Ansible)
- მონიტორინგი და ლოგირება
- უსაფრთხოება და შესაბამისობა
- მასშტაბირების სტრატეგიები
მზად ხარ შემდეგი დონისთვის, როდესაც
- დაპროექტდი და ექსპლუატაციაში ჩაატარე infra, რომელზეც 3+ ინჟინერი დამოკიდებულია, სარწმუნო failure mode ისტორიით
- მიიღე infra-არჩევანი, რომელსაც გუნდი ერთი წლის შემდეგაც იყენებს — Terraform layout, K8s topology, deploy strategy
- junior ან mid DevOps ინჟინერი რეალური პლატოდან გადაიყვანე — ახლა მათ infra-ს ნაჭერი ეკუთვნით
- დაწერე მინიმუმ ერთი runbook, რომელითაც ღამის 3-ზე სხვა ადამიანმა სისტემა აღადგინა შენი ზარის გარეშე
- კომფორტული ხარ უთხრა „ეს გადაწერა სჭირდება, არა plaster“ მზა cost-benefit ანალიზით
რა ააშენო
კონკრეტული პროექტები — და რას გასწავლით ისინი.
- multi-cluster setup-ის დიზაინი და გაშვება სათანადო IaC-ით, secret-ების როტაციით და incident playbook-ებით (სწავლის: 3-AM-pager-ის კატეგორიებში აზროვნება; failure case-ისთვის დიზაინი)
- კრიტიკული infra-მიგრაციის წაყვანა — cloud-ში გადასვლა, K8s განახლება, monitoring-ის გადაკეთება — გასაზომი rollback გეგმით (სწავლის: დაგეგმვა, mentoring, კომუნიკაცია, როცა სისტემები რისკშია)
წაიკითხე
-
Claude Code production-ში: რა ვისწავლე 6 თვეში
ექვსი თვე Claude Code როგორც ძირითადი ინსტრუმენტი — რომელი workflows-ი რეალურად დაზოგავს დროს, რომელი მას ჩუმად ჭამს, და რა კონფიგურაცია არ ეყენება გუნდების უმეტესობას.
-
კონტექსტ-ინჟინერია: დისციპლინა, რომელიც 2026-ში ცვლის prompt engineering-ს
Prompt engineering არასოდეს ყოფილა რეალური უნარი. პროდუქშენში AI-ფიჩების ორწლიანი მიწოდების შემდეგ პირდაპირ ვიტყვი: შედეგზე სხვა გავლენას ახდენს — კონტექსტ-ინჟინერია. მდგომარეობა, ხელსაწყოები, ძიება, ისტორია და შეზღუდვები, რომელიც ზუსტ მომენტში მოდელის ფანჯარაში ერთმანეთს უხამდება. არქიტექტორის ხედვა.
-
Evals 2026-ში: ტესტ-სიუტი სისტემებისთვის, რომლებიც დეტერმინირებული არ არიან
თქვენი AI-ფიჩა გუშინ მუშაობდა და დღეს იშლება. არც კოდი შეცვლილა, არც პრომპტი, არც მოდელი. ასე გამოიყურება ცხოვრება evals-ის გარეშე. ეს არის spec → context → evals ტრიადის მესამე საყრდენი — და დისციპლინა, რომელსაც გუნდების უმეტესობა გამოტოვებს.
-
OpenSpec 2026-ში: spec-driven development-ის ოპერაციული სისტემა
ექვსი კვირის წინ დავაყენე @fission-ai/openspec. გუშინ ჩავაბარე თოთხმეტ-ფაილიანი ცვლილება ოთხმოცდაათ წუთში ორას-ხაზიანი სპეციფიკაციიდან, brownfield-კოდბაზაში, რომელსაც სამი ინჟინერი ორი წელია ასწორებს — მერჯ-კონფლიქტების გარეშე, რევიუს ესკალაციის გარეშე. ეს არის სენიორ-არქიტექტორის ღრმა გარჩევა იმისა, თუ რატომ OpenSpec არის პირველი SDD-ხელსაწყო, რომელიც პროდაქშენ-რეალობის ქვეშ არ იშლება.
გავრცელებული შეცდომები ამ ეტაპზე
- „best practice“-ების cargo-cult-ი იმის გაგების გარეშე, რატომ აირჩია გუნდმა წინა ვარიანტი
- observability tooling-ში ზედმეტი ჩადება იმ კითხვის უგულებელყოფით: რომელ alert-ებზე უნდა იღვიძებდეს გუნდი რეალურად
- developer experience-ის მხარის თავიდან აცილება — DevOps, რომელიც დეველოპერებს აშფოთებს, გვერდს უვლიან, არ იღებენ
- cost-ის სხვის პრობლემად აღქმა — Senior DevOps, რომელიც დოლარებში ვერ ლაპარაკობს, Senior-ზე ჭედება
რას ელიან კომპანიები ამ დონეზე
- შეგიძლია infra-ის დაპროექტება და მფლობელობა რამდენიმე service-სა და cluster-ზე, სარწმუნო disaster-recovery გეგმით
- ძლიერი ტექნიკური კომუნიკაცია: docs, RFC-ები, runbook-ები — გუნდი ღამის 3-ზე მოქმედებს შენი ტექსტის მიხედვით
- აძლიერებ გუნდს — junior DevOps ინჟინრები მჩვენებლად იზრდებიან, როცა შენ უერთდები
- კომფორტული ხარ leadership-თან დოლარებში და reliability-ში ლაპარაკი, არა მხოლოდ YAML-ში ინჟინრებთან
ექსპერტი
ჩვეულებრივ: 2+ წელი
ექსპერტი
ჩვეულებრივ: 2+ წელი
რა უნარებს ისწავლი
- ღრუბლოვანი არქიტექტურა
- ინფრასტრუქტურის ინოვაციები
- გუნდის ლიდერობა
- ხარჯების ოპტიმიზაცია
- ავარიული აღდგენის სტრატეგიები
მზად ხარ შემდეგი დონისთვის, როდესაც
- მართე ინფრასტრუქტურის სტრატეგია 2+ გუნდის (ან საკუთარი მასშტაბირებული გუნდის) გასწვრივ კვარტალი ან მეტი
- შეგიძლია სარწმუნო 1-საათიანი ტექნიკური საუბარი sister-კომპანიის senior platform-ადამიანთან
- საჯარო არტეფაქტი, რომელზეც სხვები მიუთითებენ: OSS, გამოსვლა ან ფართოდ ციტირებული შიდა RFC platform/infra design-ზე
- რამდენიმე Senior-ს დაეხმარე წინსვლაში platform ორგანიზაციაში
- კომფორტული ხარ ოთახში „ყველაზე ნაკლებად ტექნიკურ“ ადამიანად, როცა ეს სწორია — და ყველაზე ტექნიკურად, როცა საჭიროა
რა ააშენო
კონკრეტული პროექტები — და რას გასწავლით ისინი.
- კომპანიისთვის cloud/platform სტრატეგიის განსაზღვრა — რომელი service-ები, რომელი კონტროლი, რომელი cost ceiling, რომელი failure budget (სწავლის: სტანდარტები როგორც multiplier რამდენიმე გუნდის გასწვრივ)
- infra-გუნდის წაყვანა დიდ ცვლილებაში — multi-cloud, FinOps-რეფაქტორინგი, security-overhaul — რომელიც leadership-ის ცვლილებას უძლებს (სწავლის: მდგრადი design; რა იცავს თავს, როცა stakeholder-ები იცვლებიან)
წაიკითხე
-
კონტექსტ-ინჟინერია: დისციპლინა, რომელიც 2026-ში ცვლის prompt engineering-ს
Prompt engineering არასოდეს ყოფილა რეალური უნარი. პროდუქშენში AI-ფიჩების ორწლიანი მიწოდების შემდეგ პირდაპირ ვიტყვი: შედეგზე სხვა გავლენას ახდენს — კონტექსტ-ინჟინერია. მდგომარეობა, ხელსაწყოები, ძიება, ისტორია და შეზღუდვები, რომელიც ზუსტ მომენტში მოდელის ფანჯარაში ერთმანეთს უხამდება. არქიტექტორის ხედვა.
-
Evals 2026-ში: ტესტ-სიუტი სისტემებისთვის, რომლებიც დეტერმინირებული არ არიან
თქვენი AI-ფიჩა გუშინ მუშაობდა და დღეს იშლება. არც კოდი შეცვლილა, არც პრომპტი, არც მოდელი. ასე გამოიყურება ცხოვრება evals-ის გარეშე. ეს არის spec → context → evals ტრიადის მესამე საყრდენი — და დისციპლინა, რომელსაც გუნდების უმეტესობა გამოტოვებს.
-
OpenSpec 2026-ში: spec-driven development-ის ოპერაციული სისტემა
ექვსი კვირის წინ დავაყენე @fission-ai/openspec. გუშინ ჩავაბარე თოთხმეტ-ფაილიანი ცვლილება ოთხმოცდაათ წუთში ორას-ხაზიანი სპეციფიკაციიდან, brownfield-კოდბაზაში, რომელსაც სამი ინჟინერი ორი წელია ასწორებს — მერჯ-კონფლიქტების გარეშე, რევიუს ესკალაციის გარეშე. ეს არის სენიორ-არქიტექტორის ღრმა გარჩევა იმისა, თუ რატომ OpenSpec არის პირველი SDD-ხელსაწყო, რომელიც პროდაქშენ-რეალობის ქვეშ არ იშლება.
-
როგორ გავიაროთ System Design ინტერვიუ: senior ინჟინრის სახელმძღვანელო
System design რჩევების უმეტესობა თეორიული ხმაურია. ეს არის გამეორებადი ფრეიმვორკი, რომელსაც კანდიდატების შესაფასებლად ვიყენებ — და რომელიც შეგიძლიათ გამოიყენოთ ნებისმიერი system design ინტერვიუს mid ან senior დონეზე გასავლელად.
გავრცელებული შეცდომები ამ ეტაპზე
- hands-on მუშაობის სრულიად თავიდან აცილება — Expert platform ინჟინრები, რომლებიც ვერ აკეთებენ prototype-ს, ერთ წელში კარგავენ ავტორიტეტს
- IaC-ის წერაზე უარის თქმა „რადგან Expert ვარ“ — შენი design feedback ბუნდოვანი ხდება იმ მომენტიდან, როცა შეწყვიტე
- საკუთარი stack-ის უნივერსალურ პასუხად მიჩნევა — რაც 50 ინჟინერზე მუშაობდა, არ მუშაობს 5-ზე ან 500-ზე
- ხილული სამუშაოს ოპტიმიზაცია უხილავი-მაგრამ-leverage-ულის ნაცვლად (deprecation cleanup, რომელიც 3 incident-ს ხდის თავიდან)
რას ელიან კომპანიები ამ დონეზე
- ადგენს და იცავს platform/infra ტექნიკურ სტრატეგიას ფუნქციისთვის
- ენდობიან გადაწყვეტილებებში, რომლებიც platform roadmap-ის 6+ თვეზე ახდენს გავლენას და უძლებენ VP-ების შემოწმებას
- გარე ყოფნა (გამოსვლები, OSS, წერა) ან ეკვივალენტური შიდა გავლენა (architecture council, SRE bar, platform RFC-ები)
- აღიარებული ინდუსტრიული ექსპერტიზა მინიმუმ ერთ სფეროში — networking, observability, FinOps, security და სხვა
რეალისტური საერთო ვადები
რამდენ დროს იღებს რეალურად IT-ში გადასვლა? გულახდილი პასუხი: დამოკიდებულია. აი ტიპური დიაპაზონი საჯარო გამოკითხვებისა და ჩვენი დაკვირვებების მიხედვით თვითნასწავლებზე.
ფრონტენდის განვითარება
~2.5–4 წელი (დამწყები → Senior)
ბექენდის განვითარება
~3–5 წელი (დამწყები → Senior)
მონაცემთა მეცნიერება / ML
~3–5 წელი (Junior → Senior — Data იშვიათად იწყება Beginner-დან)
DevOps / SRE
~4–6 წელი ჯამში (DevOps-ში ჩვეულებრივ მიდიან 1–2 წლის backend-ის ან sysadmin-ის შემდეგ)
შეცდომები, რომლებსაც ყველა უშვებს
ტრეკისგან დამოუკიდებელი. თუ ამ ხუთს თავიდან აიცილებ, ისწავლი უფრო სწრაფად, ვიდრე ხალხის 80%-ი, რომელსაც mit-up-ებზე შეხვდები.
-
Tutorial hell
100 საათი tutorial-ის ყურება საკუთარი ხელით არაფრის აშენების გარეშე. ყოველი კურსის შედეგი უნდა იყოს პროექტი, რომლის ჩვენებაც შეგიძლია. თუ კურსი დაასრულე არტეფაქტის გარეშე — კურსი არ მომხდარა, ფილმი ნახე.
-
Framework-ების დევნა
React-დან Vue-ზე, Svelte-ზე, Solid-ზე გადახტომა ყოველ ორ კვირაში „სწორის საპოვნელად“. სწორი ის არის, რომელზეც რამე გაუშვი. აირჩიე პოპულარული დეფოლტი, ააშენე 6 თვე, მერე გქონდეს აზრი. არა ადრე.
-
ყველაფრის ფარულად შენება
შენი პორტფოლიო 2026-ში არის შენი GitHub, არა CV. რეკრუტერები და hiring manager-ები ჯერ „GitHub-ზე ნახვას“ აჭერენ, მერე კითხულობენ ბულეტებს. თუ შენი პროექტები საჯარო არ არის — თუნდაც უხეშები — ისინი არ ითვლება. საჯარო > გაპრიალებული.
-
საფუძვლების გამოტოვება მოდურის დევნისას
LLM-აგენტებში ჩახტომა სუფთა ფუნქციის დაწერის შესაძლებლობის გარეშე. მიკროსერვისების mesh-ის აშენება ერთი HTTP მოთხოვნის გაგების გარეშე. მოწყენილი საფუძვლები (HTTP, SQL, event loop, მონაცემთა საბაზო სტრუქტურები) 30 წელს იზრდება. ტრენდებს 2 წლის ნახევარგანცდის ვადა აქვთ.
-
მარტო სწავლა
ყველაზე სწრაფად სწავლობენ ისინი, ვინც pair-program-ს აკეთებს, საჯაროდ პოსტავს პროგრესს, „სულელურ“ კითხვებს სვამს Discord-ში და code review-ს იღებს მათგან, ვინც ცოტათი წინ არის. მარტო სწავლა დაახლოებით ორჯერ ნელია, ვიდრე იგივე საათები ერთ ადამიანთან, რომელსაც კითხვა შეგიძლია.