Від сапорту — до ролі промпт-інженера. Історія фахівця Readdle про стереотипи і шлях початківця
Микиті Гавриленку — 23 роки. В IT він прийшов у 18. Спочатку працював у техпідтримці, потім — на позиції Support QA Engineer. Майже рік тому став Prompt Engineer у Readdle.
Ми дізналися в Микити про його світчинг, типові задачі, проблеми та необхідні навички для роботи. Також він розповів, чому Prompt Engineer — позиція не для новачків та які перспективи розвитку цієї посади.
Микита Гавриленко, фото надане спікером
Мрія про вступ до вишу США: «Я — людина, яка любить ставити собі високі планки»
Я з Миколаєва. Після школи в мене були великі плани, які, на жаль, не змогли реалізуватись — я хотів вступити на навчання до США. Це дало б мені нове середовище, більше челенджів. А я — людина, яка любить ставити собі «високі планки».
У мене була вибірка з п’яти закладів, проте здебільшого орієнтувався на Berea College. Я не з багатої сім’ї, тому міг пройти туди тільки на бюджет. Готувався максимально, але, на жаль, не вдалося. Проте той період і підхід до досягнення цілей, дуже допомогли мені надалі.
Я почав шукати першу роботу. Розглядав різні варіанти: від McDonalds до сфери логістики. А потім знайома порекомендувала податися на техпідтримку в доволі відому в Миколаєві аутсорс-компанію — GeeksForLess. І мене взяли з першої спроби як Technical Support Specialist. Це було через декілька місяців після того, як мені виповнилось 18 років.
Я не планував працювати саме в IT, хоча з дитинства завжди цікавився цією сферою. Але на тій роботі побачив, як зможу застосовувати уже набуті скіли. Скажімо, робота з технологіями потребує повного заглиблення в процес, який може затягнутися надовго. А я саме мав досвід приділяти конкретній задачі велику кількість часу, допоки не досягну успіху.
Прогрес у компанії відбувся доволі швидко. Спочатку мене поставили на першу лінію підтримки. Три місяці був онбординг, а ще через три місяці я склав іспит на другу лінію підтримки — став Tier2 Technical Support Specialist.
Розробка власного стартапу: «Я був тоді „зеленим“, не розумів, що таке взагалі інвестиції»
У той час мій фокус повністю змістився на роботу, реалізацію цілей, які «перескакують» етап навчання, тому я залишив ідею вступу до вишу США. Виникло бажання створити власний стартап, це був такий собі підлітковий максималізм.
Десь через рік роботи в GeeksForLess я вирішив сконцентруватися на цих планах. Знайшов партайм-підробіток, який дозволяв залишати час на розвиток власної справи, але при цьому давав заробіток на тому ж рівні, що й фултайм у техпідтримці. Раніше я професійно займався жимом штанги лежачі, моєю тренеркою була Ганна Куркуріна, найсильніша жінка світу. Вона залишається й зараз у Миколаєві, дуже активно допомагає дітям, тваринам, бездомним. Тоді я брав участь у запусках її проєктів. Був таким собі Project Manager, але це умовна назва — я виконував доволі різну роботу.
Паралельно займався власним стартапом: застосунком, який би допомагав у онлайн-заняттях спортом. Користувачі мали поставити телефон на відстані, а застосунок за допомогою Machine Learning аналізував зображення з камери: чи правильно людина виконує вправу — і корегував за потреби. Оскільки тоді був карантин через ковід, люди не могли ходити в тренажерні зали та займатися під наглядом тренера.
Я продумав концепцію, почав самостійно розробляти застосунок. У мене був Android, тож я писав на Kotlin. До речі, саме у той період я напрактикував навичку вивчення мов програмування. Через деякий час я побачив, що з’являються більш «мажорні» гравці, але все одно жив ідеєю. Я був тоді дуже молодим, «зеленим», не розумів, як працює IT-сфера, що потрібно, для реалізації стартапів, що таке взагалі інвестиції та де їх шукати. А потім почалася повномасштабна війна, яка повністю змінила всі плани та проєкти.
Пошук роботи: «Я нарахував 13 відмов»
Щоб знайти наступну роботу, я витратив десь 7 місяців. Спочатку хотів трохи змінити напрям і писати застосунки для iOS і macOS. Отже, шукав позиції Swift-розробника рівнів трейні або джуніор, паралельно намагався підтягувати знання. Але ситуація з грошима ставала дедалі проблематичнішою, тож повернувся до пошуку у техпідтримці, де мав принаймні рік досвіду.
Загалом я нарахував 13 відмов (10 з них — на вакансії розробника). І на
Тут я працював приблизно рік. Буквально через два місяці після початку роботи я вже придумав застосунок для автоматизації процесів Customer Support і почав самостійно його розвивати. Щоб цим займатися, я продовжував вивчати Swift-розробку, мови програмування. Через деякий час я пішов до менеджменту, щоб спробувати просувати застосунок на рівень компанії. Керівництво зацікавилося, ми почали обговорення, але потім наші бачення розійшлися. Тож улітку 2023 року я вирішив рухатися далі та піти з аутсорсу в продукт.
Перше фото після переїзду до Києва після довгих пошуків роботи, 2022 рік
Перехід до Readdle: «Мої очікування від роботи в продуктовій компанії справдилися»
На DOU є табличка найкращих роботодавців. Я вибрав для себе дві компанії й цілеспрямовано подавався лише туди — у Solidgate і Readdle. Перша мені відмовила. А ось до Readdle мені вдалося потрапити на позицію Support QA Engineer — це QA інженер, який сфокусований саме на дослідженні проблем користувачів.
Умови щодо обов’язкового переїзду не було, але буквально на другий тиждень онбордингу мене запросили до Одеси, де був розташований основний офіс Readdle. Мені сподобалося місто, до офісу ходило багато людей, тож було цікаво тут соціалізуватися. І так через два тижні я вже повністю переїхав з Києва до Одеси.
Мої очікування від роботи в продуктовій компанії справдилися. На мою думку, в аутсорсі наймають людей, щоб казати їм, яку роботу потрібно виконувати. А продуктові — наймають, щоб люди казали, що робити компанії для розвитку. Я відчуваю легку взаємодію як з колегами, так і менеджментом різного рівня.
Першій рік у Readdle був наповнений. Я зміг доповнити процеси QA-інженерії, створив тулу для автоматизованої символізації краш-логів, якою активно користується поточний QA Support. Також провів декілька презентацій — як внутрішніх, так і зовнішніх — з користі читання QA інженерами краш-логів до macOS та iOS застосунків. Ще намагався автоматизувати процеси, пов’язані з підтримкою.
Внутрішня QA конференція в Readdle, 2024 рік
Для себе я отримав знання, як робити QA-тестування саме в Reactive Testing Approach, тобто коли застосунок у релізі та потрібно реагувати на проблеми в моменті. За цей час я дуже прокачав різні скіли, особливо комунікативні навички. Як QA Engineer я мав доступ до кодової бази проєктів, тож міг вивчати технічні особливості роботи застосунків для дослідження проблем користувачів і відтворення багів. Ще я дуже класно навчився пояснювати технічні речі простими словами для команди підтримки, і навпаки — передавати слова відділу підтримки розробникам так, щоб розв’язувати проблеми на проєкті.
Перехід на іншу позицію: «Через рік я прийшов до Head of QA зі словами: «Я зробив усе, що міг на цій посаді»
На посаді QA Support у мене не було Team Lead, оскільки я був одним інженером на два продукти. Тож вийшло, що моїм менеджером був Head of QA. І через рік я прийшов до нього зі словами: «Я зробив усе, що міг на цій посаді. Я хочу розвиватися далі, виконувати цікавіші задачі». На що він мені відповів: «Чувак, як ти вчасно прийшов: зараз з’являється потреба на іншому продукті в посаді AI QA Engineer». Отже, початково я йшов на позицію QA Engineer, який сфокусований на тестуванні AI-функціональності поштового клієнта Spark.
Процес переходу зайняв пів року, тому що потрібно було знайти людину на мою посаду. Я брав участь у процесах найму, паралельно оформлював у документацію весь досвід, що набув за рік. Я допоміг покращити онбординг-план, написав доволі велику knowledge-base. Через три місяці ми знайшли людину — і наступні три місяці я проводив їй онбординг.
За пів року змінилася потреба в фахівці, тож замість AI QA Engineer я став Prompt Engineer. У процесі роботи трансформувалося розуміння і цієї позиції. Перший job description з’явився, коли вже були конкретні реквести та потреби в проєкті.
Я працюю у підкоманди в Spark, яка займається лише розробкою фіч з використанням штучного інтелекту. Нас шестеро: чотири розробники, один QA й один промпт-інженер. Я підпорядковуюсь нашому Team Lead і водночас активно співпрацюю з Head of Engineering застосунку Spark. Якщо порівнювати з двома попередніми компаніями, там чітко відчувалася ієрархія, що є менеджер. У Readdle — інакше, питання вирішуються дуже легко. Я також роблю колаборації з іншими Head of Engineering або VP of Product.
Взагалі я обожнюю ділитися інформацією з нашими командами, ходити по різних продуктах, допомагати. Наприклад, створити презентацію для Support-команди, що таке промпт-інжиніринг, піти в інший продукт, створити промпт для конкретної фічі, провалідувати, поділитися досвідом з нашого продукту, як ми вибудовували процеси. Це те, що допомагає й мені розвиватися як спеціалісту.
Задачі Prompt Engineer: «Одна справа — написати промпт, а інша — довести, що він працює»
Промпт-інженери в різних компаніях можуть виконувати різні обов’язки. Я розкажу саме про свій досвід у Readdle. Конкретна функціональність має розв’язувати певну задачу — я відповідальний за ту частину роботи, яка залежить від мовної моделі. Працюю саме з LLM (Large Language Models) — не з генерацією картинок або іншими типами AI-моделей.
Prompt Engineer — людина, яка займається не тільки промптами, а ще й може побудувати тестовий workflow. Одна справа — написати промпт, а інша — довести, що він працює, є ефективним, корелює з фідбеком користувачів. Тут необхідними є навички дослідження, тестування, написання коду (для написання тестів я використовую Python), знання того, як будується промпт, розуміння тенденцій ринку тощо.
Якщо говорити про типові задачі, які я виконував з початку роботи на позиції Prompt Engineer, то це поетапне покращення інструкцій для мовних моделей. Спочатку відбувається дослідження. Я аналізую фідбек користувачів, співробітників, дивлюся на задачі, колаборую з Team Lead, визначаю, що саме потрібно виконувати для того, щоб покращити промпти. Дослідження займає чимало часу. Наприклад, потрібно проаналізувати, як користувачі складають листи, щоб визначити їх стиль написання. Спочатку я вивчаю актуальні тенденції на ринку, підходи, метрики, щоб визначити, чи ефективно зроблений аналіз попередніх листів, які аналізуються за допомогою штучного інтелекту. Після цього вже відбувається реалізація самого промпта, його покращення та валідація.
Я роблю до200–300 ітерацій
Дивлюся, як зміни в інструкції впливають на роботу мовної моделі саме в цій фічі. Важливо, щоб не створювалося регресій та інші юзкейси не постраждали. Тому необхідно постійно валідувати, проганяти тести. Виходить багато ітерацій для того, щоб розв’язати конкретну задачу, не погіршивши роботу попередньої версії промпта.
На кількість також впливає складність задачі. Наприклад, у Spark є самаризація дзвінків — робиться запис розмови, потім транскрипт, підсумовується зміст бесіди. Щоб досягти класної самаризації, потрібно було провести
Окрім цього, потрібно гратися з параметрами моделі, тестувати, можливо, на інших моделях, особливо коли функціональність розробляється з нуля. У нас є датасети, на яких ми проганяємо тести для валідації, і їхній розмір визначається особливостями конкретної фічі — в середньому кілька сотень записів. Інколи я доповнюю датасети, на яких відбувається тестування. Якщо мені бракує знань, то повертаюся до етапу дослідження. Іноді також коригую внутрішню інфраструктуру, яка використовується для тестування.
Оскільки все це робиться на різних моделях, з різними параметрами, з різними промптами, я вже «намотав» більше сотні мільйонів токенів.
Про побудову процесів і проблеми: «Є частина роботи, яка від мене не залежить»
У компанії багато часу та ресурсів приділяється LLM Evaluation. Задача Prompt Engineer — побудувати та налаштувати якісний пайплайн для оцінки якості роботи фічі перед тим як почати працювати над покращенням промпта. Цей процес передбачає:
- визначення, як саме буде проводитися автоматизований evaluation (research, тестування підходів),
- збір та організацію тестових даних,
- валідацію зі стейк-холдерами кінцевого результату роботи мовних моделей (Golden Standard output, якого потрібно досягти),
- написання коду для автоматизації,
- останній етап — подальша оптимізація тестів і промптів.
Звісно, побудова процесів є критично важливою для будь-якої роботи, але промпт-інжиніринг — доволі нова галузь, тож потрібно коригувати процеси під потребу конкретного бізнесу. Варто приділяти увагу фундаменту для праці промпт-інженера: пошук потрібних тулів, стеку для ефективного виконання задач, тестових даних. Можливо, знайти датасет, визначити, де брати складові, які потім будуть пришвидшувати роботу Prompt Engineer. Ще мені здається важливим занадто довго не зациклюватися на чомусь. Тому що АІ — це про швидкий темп, швидкий розвиток. А значить варто також бути готовим до того, що процеси будуть змінюватися, тож треба робити їх модульними, прибирати bottlenecks, які затримують роботу промпт-інженера.
Проблема, з якою стикається Prompt Engineer — це в першу чергу хаотичність
Ти намагаєшся написати інструкцію, потім змінюєш іншу. Потрібно швидко та дуже багато ітерувати, розуміти, що на що впливає, щоб нічого не поламати. При цьому ще перечитувати великий обсяг тексту, передивлятися кейси, робити мінорні зміни в промпти, дивитися, який вплив вони мають загалом і на попередні кейси.
До того ж, моделі дуже непередбачувані. Ти можеш написати найкращий промпт, він буде наслідувати те, що ти прочитав у guidebooks від провайдерів OpenAI, Anthropic, Google. Проте все одно трапляються історії, коли модель веде себе не так, як очікувалося. І тобі може здаватися, що ти зробив щось не так, недогледів, недовивчив, недотестував. На мене особисто це сильно впливає, я все приймаю на свій рахунок, а інколи це просто обмеження в моделях.
Підготовка до внутрішнього воркшопу з промптингу для QA, 2025
Опанування нових навичок: «Мені дуже допомогли інженери з відділу R&D»
Деяких навичок для роботи Prompt Engineer мені бракувало. Наприклад, як правильно, структуровано виконувати дослідження. Коли я тільки почав працювати на цій позиції, то часто бувало таке: я бачив якусь релевантну статтю, вона мені подобалося — й одразу починав застосувати знахідки з цього дослідження у власній роботі, а вони не спрацьовували. Виходить, я втрачав час, оскільки не робив додатковий аналіз і не бачив картини повністю. Тож тепер я раджуся з відділом R&D.
Потім мені довелося більше вивчити Python. Коли я переходив на цю роль, то ми з менеджером думали, що я будуватиму тестові пайплайни на окремій платформі, яка не потребує знань програмування. Але потім я зрозумів, що за допомогою коду можна вирішувати задачі набагато швидше, ефективніше. Загалом мені дуже знадобився досвід з вивчення мов програмування. Коли вже подивився дві-три, то бачиш, що концепт — доволі схожий, а відмінності — в синтаксисі.
Плюс треба було вивчати все, що пов’язано зі штучним інтелектом (і я продовжую це робити). Тому що в мене було лише поверхневе розуміння, як працюють мовні моделі, як на них впливають різні параметри, що від чого залежить. Тобто я повернувся до інтенсивного самонавчання, яке було в мене, коли я хотів вступити до вишу США. Взагалі для Prompt Engineer важлива постійна самоосвіта, треба спостерігати за ринком AI, читати різні новини, документацію, дивитися, як працює функціональність у конкурентів, вивчати досвід інших людей.
Про цінність позиції: «Readdle планує наймати Prompt Engineers в майбутньому»
Вважаю, що для компанії Prompt Engineer приносить велику цінність. Особливо для Spark, оскільки там багато функціональності, де використовуються різні промпти. Наприклад, коли виходить нова мовна модель потрібно провести тестування фіч, подивитися, краще чи гірше на ній все працює, потім зробити репорти, показати їх стейкхолдерам і Head of Engineering.
Зараз є один Prompt Engineer на всю компанію з 300+ людей. Можна сказати, що це була «пілотна» посада. Тепер уже є розуміння, що має виконувати людина на цій позиції, що можна виключити з тієї першої версії job description, а що — дописати. Однозначно посада — ефективна, якщо інтегрувати її в роботу команди та правильно організувати процеси.
Знаю, що Readdle збирається наймати Prompt Engineers в майбутньому — з розвитком різних продуктів та AI-функціональності в них. Наразі відкритих вакансій поки немає, проте плани є.
Якщо говорити про мій найбільший результат за ці пів року, то мені здається, він якраз пов’язаний з розумінням сутті посади Prompt Engineer: що він не тільки робить промпти, але й досліджує, валідує, не закриває очі на особливості роботи моделей, опановує нові технології. Наприклад, я вивчав файн-тюнінг моделей — може здатися, що для Prompt Engineer це не потрібно, але воно також дуже допомагає. Сподіваюся, я в позитивному ключі вплинув на розвиток процесів, які зараз є в нашій команді.
Якщо говорити про конкретну фічу, у яку я зробив внесок — це вже згадана самаризація дзвінків. Я більше двох місяців провів над тим, щоб зрозуміти, що потрібно для покращення функціональності. Не можу сказати, що повністю задоволений результатом, але мені здається, він досить суттєвий.
За пів року мої задачі сильно змінилися. Зараз я вже буду розвиватися в трохи іншому напрямку — я би сказав, на планку вище. Наступна моя посада, найімовірніше, називатиметься AI Prototype Engineer та буде пов’язана з прототипуванням.
Ми готуємо в Spark нову функціональність — на жаль, поки не можу розповідати деталі. І зараз я визначаю, як зробити її ефективною: перейти до налаштувань, промптів, створити MVP повноцінної великої функціональності, що потім буде використовуватися в продакшні. Я проводжу дослідження, ставлю питання стейкходерам, виконую додаткові дослідження, роблю прототип. Тоді потрібно протестувати його на реальних даних, які мені надали стейкходери — або якщо мені їх не вистачить, створити синтетичні дані, щоб врешті-решт створити повноцінний солюшен, який я зможу передати на наступний етап до розробників. Можна сказати, що це такий міні R&D.
Для кого ця позиція: «Якщо хочеться більше працювати з AI і ML-інженерією, то це гарний старт»
Є стереотип, що промпт-інженерія — це просто написання інструкцій. Я особисто не чув прямо таке формулювання. Але коли знайомлюся з колегами з інших застосунків, наприклад на WAWTech 2025, то подібне розуміння інколи випливає з певних слів і реакцій. Мені здається, що сама по собі назва позиції не зовсім описує те, чим насправді займається Prompt Engineer. Можливо, так правильніше називати фахівців, які ще декілька років тому займалися тільки інструктажем мовних моделей у таких великих корпораціях, як OpenAI, Anthropic, Google. Тепер ця посада еволюціонувала, і писати промпти — це одна зі складових роботи.
Із командою на WAWTech 2025
Я не впевнений, що Prompt Engineer може бути entry-посадою
Бачив, що зазвичай у вимогах до таких вакансій потребується досвід в ІТ. Але якщо хочеться більше працювати з AI і
Отже, промпт-інжиніринг — класний напрямок, щоб зрозуміти, чи подобається тобі AI, ML. А головне скіли з промптингу, досвід роботи з мовними моделями, проведення досліджень можна використовувати і в інших задачах. Ця посада дозволяє вивчити продуктову складову бізнесу, прокачати навички комунікації, оскільки потребує трансляції запитів стейкхолдерів у промпти.
Саме по собі вміння писати промпти ймовірніше скоро стане просто базовою грамотністю. Інструкції потрібні, вони вирішують конкретні задачі. У майбутньому моделі стануть ще потужніше, розумніше, тому важливо буде правильно надавати їм інформацію для ефективної роботи.
Щодо перспектив посади Prompt Engineer, мені здається, актуальнішим стане «контекст-інжиніринг» — поняття, яке активно просуває Anthropic. Це не просто написання інструкцій, а якісна підготовка контексту, інформації, яка потрібна для розв’язання конкретної задачі.
Наприклад, ми пробували згенерувати тест-кейси для QA-інженерів. Щоб зробити їх дійсно якісними, потрібно спочатку зібрати інформацію: Slack переписки, Jira-тікети, транскрипт дзвінків, на яких обговорювався вигляд фіч, можливо, дизайн—скриншоти з Figma. Але цей контекст — «сирий», треба понизити рівень «шуму», зробити вибірку або організувати дані, щоб модель могла з ними ефективно працювати та зменшити вірогідність неочікуваної або неякісної відповіді. Ми знаємо: коли модель працює з даними, навіть банальне зміщення їхнього порядку може впливати на її роботу. Так, ШІ розвивається, цей вплив зменшується. Тим не менше, потрібне буде розуміння, що таке взагалі контекст, як його зібрати, де знайти інформацію, як оформити дані та протестувати, як модель з ними працює.
Взагалі важко сказати, як буде розвиватися професія, тому що сфера AI-інженерії стрімко змінюється, є залежність від тенденцій, які задають інші компанії — OpenAI, Google, Microsoft тощо. Ті задачі, які, наприклад, виконувались пів року тому, через рік можуть зникнути. Проте, на мою думку, промпт-інженерія однозначно буде частиною повноцінної посади, яка займається розробкою AI-функціональності.
