AI engineer
AI engineer membangun produk yang komponen terpentingnya adalah model yang tidak mereka latih sendiri. Pekerjaannya adalah retrieval dan grounding, desain context, evaluation harness, guardrail, serta menjaga latensi dan pengeluaran tetap di dalam anggaran sementara model di bawahnya terus berubah. Panduan ini menguraikan cakupan perannya, kapan peran ini benar-benar tepat, dan bagaimana membedakan substansi dari kefasihan bicara.
Apa yang dikerjakan seorang AI engineer?
AI engineer membangun produk perangkat lunak yang perilakunya bergantung pada sebuah foundation model â biasanya large language model yang diakses lewat API penyedia atau dijalankan sebagai model open-weight yang di-hosting sendiri. Cakupannya meliputi mengambil context yang tepat dan menambatkan output padanya, merancang dan memberi versi pada instruksi yang dikirim ke model, membangun evaluation harness yang memperlihatkan apakah sebuah perubahan benar-benar memperbaiki sesuatu, memasang guardrail terhadap respons yang dimanipulasi atau tidak aman, serta mengendalikan waktu respons dan pengeluaran begitu trafik sungguhan datang. Ini software engineering yang diterapkan pada komponen yang bersifat probabilistik alih-alih deterministik, dan jarang melibatkan pelatihan model.
Yang menentukan peran ini adalah adanya dependency yang tidak sepenuhnya bisa diperiksa engineer-nya. Model punya versi, harga, rate limit, dan sekumpulan perilaku yang bergeser ketika penyedianya merilis pembaruan. Karena itu hampir seluruh upaya engineering tercurah pada apa yang mengelilinginya: apa yang diletakkan di dalam context window, apa yang dilakukan terhadap hasil yang kembali, apa yang dilakukan sistem ketika responsnya keliru, dan dari mana semua itu bisa diketahui.
Pengukuran adalah tempat kesulitannya menumpuk. Demo mudah dirakit, karena sekumpulan input yang dikurasi akan membuat hampir semua konfigurasi tampak kompeten. Membuktikan bahwa versi kedua lebih baik daripada versi pertama jauh lebih sulit, karena dua respons bisa sepenuhnya berbeda kata-katanya namun sama-sama benar, atau nyaris identik namun berbeda pada satu fakta yang justru menentukan. Regression set, rubrik penilaian, judge otomatis yang dikalibrasi terhadap label manusia, dan skor terpisah untuk retrieval dan generation adalah instrumen yang biasa dipakai, dan tim yang tidak memilikinya sedang merilis berdasarkan kesan.
Ragam kegagalannya berbeda dari perangkat lunak konvensional. Pernyataan muncul tanpa dukungan dari sumber mana pun. Retrieval mengembalikan paragraf yang terbaca relevan padahal bukan. Instruksi menyusup ke model di dalam konten yang dikirim pengguna. Kualitas melorot setelah perubahan di sisi penyedia yang tidak menghasilkan error dan tidak memicu alert satu pun. Biaya membengkak seiring panjang percakapan dengan cara yang tidak muncul dalam load test. Masing-masing entah dirancang lebih dulu, atau ditemukan oleh pelanggan.
Kapan tim membutuhkan kapabilitas ini
Fitur berbasis foundation model biasanya bermula dari sesuatu yang dirakit seseorang dalam satu akhir pekan, dan versi akhir pekan itu memang mengesankan. Jarak antara versi tersebut dan sesuatu yang bisa diandalkan pelanggan adalah tempat peran ini membuktikan nilainya.
Sebuah prototipe harus menjadi produk
Demonya menangani input yang memang menjadi acuan pembuatannya dan melempem pada segala hal lain. Membuatnya bisa diandalkan berarti membatasi ruang input, memutuskan apa yang terjadi di luar batas itu, dan menaruh angka pada kualitas yang tetap bertahan ketika ada yang menyanggahnya.
Jawaban harus bertumpu pada materi milik Anda sendiri
Respons harus berasal dari dokumen internal, tiket, kontrak, atau data produk, bukan dari apa pun yang diserap model selama pelatihan. Itu membawa serta strategi chunking, pemilihan embedding, hybrid search, reranking, kesegaran data, dan keharusan bahwa seorang pengguna tidak pernah menarik dokumen yang tidak berhak ia baca.
Tidak ada yang bisa memastikan sistemnya membaik atau tidak
Perubahan dirilis karena terasa lebih baik pada segelintir pemeriksaan manual. Ini keadaan yang paling umum pada fitur foundation model di production, dan itu membuat setiap keputusan berikutnya menjadi tebakan, termasuk keputusan apakah fitur itu layak dipertahankan.
Teks yang tidak tepercaya masuk ke model
File yang diunggah, email masuk, pesan pelanggan, halaman hasil scraping. Begitu konten yang diambil bisa membawa instruksi, pertanyaannya berhenti menjadi apa yang diperintahkan kepada model dan berubah menjadi apa yang diizinkan untuk model lakukan.
Pengeluaran naik lebih cepat daripada pemakaian
Retry, riwayat percakapan yang terus bertambah, context yang kebesaran, tidak ada caching, dan setiap request diarahkan ke model terbesar yang tersedia. Kurva biaya sebuah fitur probabilistik bukan kurva biaya yang biasa diproyeksikan tim.
Penyedia mendeprecate versi yang menjadi fondasi Anda
Tenggat migrasi tiba untuk sebuah komponen yang perilakunya tidak dispesifikasikan di mana pun. Tanpa regression suite, satu-satunya cara mengetahui apa yang berubah pada versi baru adalah dengan merilisnya.
Kapabilitas inti
Desain retrieval
Batas chunk, pemilihan embedding, hybrid search yang menggabungkan leksikal dan vektor, reranking, dan penyaringan berbasis metadata. Sebagian besar laporan yang dibuka dengan kalimat modelnya salah sebenarnya adalah kegagalan retrieval, dan memisahkan keduanya adalah langkah diagnosis yang pertama.
Grounding dan atribusi
Membuat sebuah jawaban bisa ditelusuri ke paragraf yang mendukungnya, dan merancang apa yang terjadi ketika tidak ada paragraf yang mendukungnya. Sistem yang menolak menjawab umumnya lebih berharga daripada sistem yang berimprovisasi, dan perilaku itu harus dibangun, bukan sekadar diminta.
Penyusunan context
Memutuskan apa yang menempati jendela yang terbatas: instruksi, bukti hasil retrieval, riwayat percakapan, hasil pemanggilan tool, skema output. Merumuskan kalimat instruksi adalah bagian yang terlihat; menganggarkan dan mengurutkan isi jendelanya adalah bagian yang substansial.
Evaluation harness
Kumpulan kasus terkurasi yang mencerminkan input sesungguhnya, rubrik yang akan dinilai sama oleh orang kedua, judge otomatis yang diperiksa terhadap label manusia, dan sebuah regression run yang berdiri di antara perubahan prompt dan sebuah rilis.
Penggunaan tool dan orkestrasi
Function calling, loop berlangkah banyak, kondisi berhenti, perilaku retry, dan idempotensi di setiap langkah yang punya efek keluar. Loop yang tidak bisa berhenti dan aksi yang terulang adalah cacat khas di wilayah ini.
Guardrail dan ketahanan terhadap penyalahgunaan
Memperlakukan output model sebagai input yang tidak tepercaya, memvalidasinya terhadap sebuah skema sebelum ia menyentuh apa pun yang berkonsekuensi, dan membatasi tool mana yang bisa dijangkau alih-alih bergantung pada model untuk menolak.
Pengendalian latensi dan biaya
Streaming, caching, mengarahkan permintaan yang sederhana ke model yang lebih kecil, memangkas context, dan menghitung biaya per tugas yang tuntas alih-alih per panggilan â angka yang kedua itulah yang mengikuti tagihan.
Output terstruktur
Generasi yang dibatasi skema, validasi, perbaikan saat gagal, dan parsing deterministik di batas sistem, agar kode di hilir tidak pernah diminta menafsirkan prosa yang besok mungkin ia tafsirkan berbeda.
Pemantauan di production
Trace lengkap termasuk context yang diambil, review manusia terjadwal atas respons yang disampel, alert atas pergerakan kualitas dan bukan hanya atas error, serta jalur yang membawa kegagalan yang dilaporkan pengguna kembali ke dalam evaluation set.
Penanganan data di batas sistem
Tahu persis apa yang keluar dari lingkungan Anda, apa yang disimpan penyedia, apa yang disamarkan sebelum dikirim, dan bagaimana isolasi antar tenant ditegakkan di dalam index yang dipakai bersama beberapa pelanggan.
Ekosistem teknologi
Berikut teknologi yang umum dipakai dalam AI engineering. Daftar ini menggambarkan lanskap disiplin tersebut sebagaimana dipraktikkan secara umum di industri, dan bukan klaim tentang perkakas engineer mana pun. Framework di bidang ini berganti nyaris tiap tahun, sehingga cara seorang kandidat menalar soal retrieval, context, dan pengukuran adalah sinyal yang jauh lebih baik daripada nama yang muncul di proyek terakhirnya.
Bahasa dan runtime
- Python
- TypeScript
- Go
Akses dan hosting model
- OpenAI API
- Anthropic API
- Google Vertex AI
- Amazon Bedrock
- vLLM
- Ollama
Framework orkestrasi
- LangChain
- LlamaIndex
- Semantic Kernel
- Haystack
- DSPy
Retrieval dan search
- pgvector
- Pinecone
- Qdrant
- Weaviate
- Elasticsearch
- OpenSearch
Evaluasi dan tracing
- Ragas
- DeepEval
- promptfoo
- LangSmith
- Langfuse
- OpenTelemetry
Validasi dan guardrail
- Pydantic
- Instructor
- Guardrails AI
- NeMo Guardrails
- JSON Schema
Lapisan aplikasi
- FastAPI
- Next.js
- Vercel AI SDK
- Redis
- Celery
How this role works with your team
Engineers work inside your team, on your priorities, to your standards. You direct the work; Talent.ID carries the employment. The division below is the whole arrangement.
You keep
- Produk
- Prioritas bisnis
- Roadmap
- Arsitektur
- Prioritas sprint
- Standar engineering
- Kolaborasi teknis sehari-hari
Talent.ID handles
- Hubungan kerja
- Payroll
- Benefit karyawan
- Administrasi talenta
- Hubungan karyawan berkelanjutan
Apa yang perlu dinilai saat memilih kandidat
Pekerjaan berbasis foundation model mengundang penjelasan yang fasih. Kosakatanya terbuka untuk umum, demonya cepat dibuat, dan seorang kandidat bisa berbicara penuh percaya diri soal retrieval dan agent tanpa pernah sekali pun mengoperasikan sistem yang jawaban salahnya sampai ke pelanggan yang membayar. Evaluasi adalah cara tercepat memisahkan kedua kelompok itu, karena hanya bagian itulah yang tidak bisa dihafalkan.
Disiplin evaluasi
Alur pertanyaan paling informatif yang tersedia adalah bagaimana kandidat tahu sebuah perubahan benar-benar membantu. Minta datasetnya, dari mana contoh-contohnya berasal, berapa banyak jumlahnya, siapa yang menilainya, dan dengan rubrik apa. Jawaban yang kabur di sini bukan soal cara berkomunikasi; biasanya itu berarti pengukurannya memang tidak pernah ada.
- Menyusun evaluation set sebelum mengubah apa pun, bukan setelah ada keluhan
- Bisa menjelaskan bagaimana judge otomatisnya diperiksa terhadap penilaian manusia
- Menilai retrieval dan generation secara terpisah, bukan sebagai satu angka
- Menjalankan regression set sebelum perubahan prompt atau versi model dirilis
Kualitas retrieval
Tanyakan bagaimana mereka memastikan bukti yang benar memang ditemukan sejak awal. Engineer yang pernah men-debug sistem semacam ini akan menjangkau paragraf hasil retrieval sebelum menyentuh instruksinya; engineer yang hanya pernah membuat demo akan menulis ulang instruksinya lebih dulu, lalu terus menulis ulang.
- Mengukur apakah sumber yang benar muncul di dalam hasil yang dikembalikan
- Mengubah chunking atau menambah reranking berdasarkan bukti, bukan firasat
- Menegakkan hak akses pada saat retrieval, bukan pada saat menyusun respons
- Bisa menceritakan kasus ketika retrieval memang bukan arsitektur yang tepat sama sekali
Grounding dan kegagalan yang jujur
Apa yang dilakukan sistem ketika ia tidak punya bukti untuk menjawab lebih banyak bercerita daripada apa yang dilakukannya ketika semuanya tersedia. Karangan yang disampaikan penuh keyakinan lebih buruk daripada penolakan pada hampir semua konteks komersial, dan kandidat berbeda tajam dalam hal apakah mereka sudah benar-benar menghayatinya.
- Merancang jalur eksplisit untuk kondisi informasinya tidak cukup untuk menjawab
- Kutipan yang diberikan benar-benar merujuk paragraf yang mendukung klaimnya
- Pernah mengukur tingkat groundedness, bukan sekadar menyatakannya
- Memperlakukan jawaban yang tak berdasar tetapi terdengar masuk akal sebagai cacat yang layak jadi insiden
Cara berpikir adversarial
Setiap sistem yang membaca konten yang bukan tulisannya sendiri memiliki permukaan injection. Jawaban yang lemah berupa instruksi yang lebih panjang, yang menyuruh model mengabaikan instruksi yang ia temui. Jawaban yang kuat membatasi apa yang mampu dilakukan model, sehingga bujukan tidak memberi keuntungan apa pun bagi penyerang.
- Memperlakukan teks hasil retrieval dan teks kiriman pengguna sebagai bermusuhan secara default
- Memisahkan kemampuan yang hanya membaca dari apa pun yang punya efek keluar
- Memvalidasi output sebelum ia sampai ke sebuah tool, query, atau kotak surat
- Tidak menyandarkan kontrol keamanan pada susunan kata dalam instruksi
Latensi dan biaya pada trafik sesungguhnya
Tanyakan berapa biaya fitur itu per tugas yang tuntas dan seperti apa waktu respons pada persentil sembilan puluh lima, termasuk retrieval dan reranking. Kandidat yang pernah menjalankan sesuatu di production tahu kedua angka itu secara kasar; yang belum pernah cenderung menyebut harga per token.
- Menalar dalam biaya per hasil yang berhasil, bukan biaya per panggilan
- Pernah mengalihkan sebagian pipeline ke jalur yang lebih kecil atau ter-cache
- Mengukur latensi ujung ke ujung, bukan hanya waktu sampai token pertama
- Menurunkan pengeluaran dan membuktikan kualitasnya tetap bertahan
Pemantauan setelah rilis
Pertanyaan yang menarik adalah bagaimana mereka mengetahui adanya masalah yang tidak mereka antisipasi. Cari review manusia atas sampel yang berjalan terjadwal, trace yang merekam context yang benar-benar dikirim, dan satu kasus ketika perubahan di sisi penyedia mengubah perilaku tanpa ada yang gagal.
- Mencatat seluruh context yang dikirim, bukan hanya respons akhirnya
- Meninjau sampel output langsung dengan irama yang teratur
- Pernah menangkap kemunduran kualitas yang tidak menghasilkan error apa pun
- Mengalirkan kegagalan yang dilaporkan kembali ke dalam evaluation set
Menahan diri soal di mana model layak dipakai
Kandidat yang kuat sudah sesering menghapus panggilan model seperti mereka menambahkannya. Tanyakan di titik mana mereka menyimpulkan bahwa sebuah aturan, classifier, atau kode biasa adalah instrumen yang lebih tepat, dan apa faktor penentunya.
- Pernah mengganti langkah yang dihasilkan model dengan kode deterministik
- Bisa menyebut tugas yang ongkos kesalahannya menggugurkan pendekatan tersebut
- Mempertimbangkan model khusus yang lebih kecil bila itu sudah memadai
- Menanyakan keputusan apa yang akan disuapi output itu sebelum mengusulkan arsitektur
Pertanyaan wawancara yang layak diajukan
Pakai sesuai yang cocok dengan percakapan seleksi Anda sendiri. Penilaiannya milik Anda, begitu pula kesimpulannya; yang berikut ini sekadar menunjukkan di mana jawaban yang informatif biasanya berada â dan dalam disiplin ini, jawaban itu ada pada orang yang pernah menjaga sistem semacam ini tetap berjalan, bukan pada orang yang banyak membacanya.
Bagaimana Anda tahu perubahan terakhir Anda membuat sistemnya lebih baik?
What a strong answer shows
Pertanyaan tunggal dengan daya prediksi tertinggi di disiplin ini. Dengarkan asal-usul datasetnya, ukurannya, rubrik penilaiannya, siapa yang menerapkannya, dan apakah hasilnya pernah membuat mereka membatalkan perubahan yang sebenarnya mereka sukai.
Seorang pelanggan melaporkan jawaban yang salah tetapi disampaikan dengan yakin. Tuntun saya melalui diagnosisnya secara berurutan.
What a strong answer shows
Apakah mereka mengurai pipeline-nya. Jawaban yang kuat menarik trace dan memeriksa apa yang diambil sebelum menyentuh instruksinya, lalu memastikan apakah buktinya memang tidak ada, ada tetapi tidak terambil, terambil tetapi diabaikan, atau terambil dan salah dibaca.
Produk Anda menerima dokumen yang diunggah pengguna. Salah satunya memuat teks yang ditujukan kepada model. Apa yang terjadi?
What a strong answer shows
Kesadaran soal injection dan, yang lebih penting, apakah pertahanan mereka berupa batas kapabilitas atau berupa instruksi yang membujuk. Hanya yang pertama yang bertahan menghadapi penyerang yang mau mencoba berulang kali.
Retrieval mengembalikan paragraf yang tampak relevan, tetapi jawabannya tetap salah. Anda memeriksa dari mana?
What a strong answer shows
Kedalaman di luar konfigurasi bawaan. Harapkan pembahasan soal batas chunk yang memotong jawabannya, kemiripan semantik tanpa irisan leksikal, reranking yang tidak ada, dokumen yang basi, atau korpus yang memang tidak memuat jawabannya.
Pengeluaran melonjak tiga kali lipat setelah peluncuran sementara pemakaian hanya dua kali lipat. Bagaimana Anda menyelidikinya?
What a strong answer shows
Kefasihan soal biaya. Cari pembahasan tentang riwayat percakapan yang menumpuk, retry yang tidak bersuara, context yang membesar di tiap rilis, loop tool yang tak berbatas, serta model penghitungan per tugas alih-alih per token.
Versi model yang Anda gunakan akan dipensiunkan. Apa rencana migrasi Anda?
What a strong answer shows
Apakah regression suite-nya ada. Jawaban yang meyakinkan menjalankan versi baru terhadap kumpulan kasus yang disisihkan, membandingkan skor per kategori, dan mengidentifikasi instruksi mana yang sensitif terhadap perubahan itu sebelum trafik apa pun dipindahkan.
Kapan Anda pernah mengatakan kepada stakeholder bahwa language model adalah alat yang keliru?
What a strong answer shows
Pertimbangan dan kemandirian sikap. Jawaban yang kuat menyebut tugas konkret yang ongkos kegagalannya, anggaran latensinya, tuntutan auditabilitasnya, atau kebutuhan determinismenya membuat pendekatan konvensional menjadi yang benar.
Semuanya tampak relevan dan jendelanya terbatas. Bagaimana Anda memutuskan apa yang masuk?
What a strong answer shows
Apakah context diperlakukan sebagai anggaran dengan kebijakan alokasi. Cari kesadaran soal efek urutan, pemadatan riwayat, bukti bahwa context yang lebih banyak pernah diuji dan tidak selalu menolong, serta dasar terukur bagi pembagian yang dipakai sekarang.
What this looks like in practice
A hypothetical scenario, written to show how the working model applies. It does not describe a Talent.ID client or a completed project.
- Challenge
- Sebuah tim produk telah merilis asisten yang menjawab pertanyaan dari dokumen perusahaan. Ia bekerja baik saat didemokan dan tidak menentu pada materi pelanggan yang sesungguhnya, tim support mulai meneruskan jawaban-jawaban yang keliru, dan tak seorang pun di tim bisa menyatakan apakah perubahan bulan lalu menolong atau justru merusak, karena tidak ada yang diukur.
- Approach
- Kapasitas engineering tambahan masuk mengikuti cara kerja tim yang sudah berjalan: konvensi repositori mereka, code review mereka, proses rilis mereka, dan arah arsitektur yang sudah mereka tetapkan. Keputusan produk dan kewenangan teknis tetap pada engineer internal, dan kapasitas tambahan mengambil pekerjaan evaluasi, retrieval, dan pemantauan di dalam sprint yang sama.
- What this adds to the team
- Tim memperoleh kapasitas pengiriman sambil tetap memegang kepemilikan atas produk dan arsitekturnya. Apa yang seharusnya dilakukan asisten itu, dan standar apa yang harus ia penuhi sebelum dirilis, tetap menjadi keputusan orang-orang yang bertanggung jawab atasnya.
Related disciplines
Frequently asked questions
- Apa beda AI engineer dan machine learning engineer?
- AI engineer membangun di sekeliling model yang dihasilkan pihak lain; machine learning engineer menghasilkan dan memelihara modelnya sendiri. Yang pertama menghabiskan waktunya pada retrieval, context, evaluasi, guardrail, dan perilaku produk yang sedang berjalan; yang kedua pada feature, pipeline pelatihan, infrastruktur serving, drift, dan pelatihan ulang. Tim yang mengintegrasikan foundation model milik penyedia membutuhkan yang pertama. Tim yang posisi kompetitifnya bergantung pada model yang dilatih atas datanya sendiri membutuhkan yang kedua.
- Apakah AI engineer perlu melatih model?
- Umumnya tidak. Fine-tuning muncul sesekali, paling sering untuk membetulkan format atau nada output alih-alih menambahkan pengetahuan, dan biasanya baru dijangkau setelah retrieval dan desain context sudah habis dieksplorasi. Jika kebutuhan yang sebenarnya adalah model yang dilatih atas data milik sendiri, itu disiplin berbeda dengan perkakas berbeda, dan mencari orangnya dengan judul peran ini berujung pada ketidakcocokan yang tidak menyenangkan bagi kedua pihak.
- Apakah prompt engineering merupakan peran tersendiri?
- Sebagai peran yang berdiri sendiri, ia jarang bertahan begitu bersentuhan dengan production. Susunan kata instruksi hanyalah satu artefak di antara retrieval, penyusunan context, evaluasi, guardrail, pemantauan, dan pengendalian biaya, dan justru artefak itulah yang paling mungkin ditulis ulang ketika salah satu yang lain diperbaiki dengan benar. Orang yang seluruh praktiknya adalah merangkai kalimat akan kesulitan di titik ketika masalah yang menarik ternyata bersifat arsitektural.
- Mengapa evaluasi begitu menentukan bagi peran ini?
- Karena tanpanya tidak ada cara membedakan perbaikan dari sekadar perubahan. Perangkat lunak konvensional memberi Anda test yang lulus atau gagal; komponen probabilistik memberi Anda respons yang berbeda, dan berbeda bukanlah arah. Tim tanpa evaluation harness menumpuk penyesuaian yang tak seorang pun bisa membenarkannya, dan pada akhirnya tidak sanggup menjawab apakah fiturnya lebih baik daripada enam bulan lalu.
- Bisakah seorang backend engineer berpindah ke pekerjaan ini?
- Sering, dan ini termasuk salah satu perpindahan yang paling berhasil. Bagian yang bisa dibawa besar: desain API, anggaran latensi, caching, queueing, observability, dan penanganan kegagalan adalah sebagian besar dari sistemnya. Yang harus dipelajari adalah toleransi yang sungguh-sungguh terhadap dependency yang tidak bisa direproduksi, serta kebiasaan mengukur perilaku secara statistik alih-alih menyatakannya lewat sebuah test.
- Apakah retrieval masih perlu sekarang setelah context window menjadi sangat besar?
- Untuk sebagian besar produk, ya. Jendela yang besar tidak menjawab dokumen mana yang mendukung sebuah klaim, tidak menegakkan siapa boleh melihat apa, dan tidak menghentikan biaya serta latensi yang membesar seiring segala hal yang Anda putuskan untuk disertakan. Retrieval tetap menjadi mekanisme untuk provenance, hak akses, dan penghematan, dan ketiga kebutuhan itu tidak lenyap seiring membesarnya jendela.
- Bagaimana AI engineer bekerja bersama tim engineering yang sudah ada?
- Di dalam model penambahan kapasitas tim engineering, arahnya milik Anda: arsitektur Anda, code review Anda, standar rilis Anda, dan apa pun yang menjadi sasaran sprint. Kolaborasi teknis sehari-hari berlangsung dengan engineer Anda sendiri. Talent.ID memegang sisi kepegawaiannya â payroll, benefit karyawan, administrasi talenta, dan hubungan kerja yang berkelanjutan.
Tell us what your team needs
Describe the gap â the work, the stack, the way your team runs â and we will tell you what we can support. If it is not something we can help with, we will say so.