Arbeitsplatz Bild apichap

Negar Layegh, Machine Learning Engineer bei APICHAP

Description

Machine Learning Engineer bei APICHAP Negar Layegh gibt im Interview Einblicke in ihren Werdegang bis hin zur aktuellen Arbeit, welche Herausforderungen im Machine Learning es gibt und gibt Tipps für Neueinsteiger.

Beim Videoaufruf stimmst Du der Datenübermittlung an YouTube und der Datenschutzerklärung zu.

Video Zusammenfassung

Im Talk "Negar Layegh, Machine Learning Engineer bei APICHAP" schildert Negar Layegh ihren Weg vom kurzen Start in der Elektrotechnik in Iran über einen C‑Programmierkurs und das Robotics‑Interesse bis zu einem Praktikum in Tel Aviv, dem Masterstudium und drei Jahren Arbeit in Machine Learning/Machine Vision. Als erste Mitarbeiterin bei APICHAP und in ihrem ersten Job nach der Uni entwickelt sie Services, die mit großen Sprachmodellen (GPT) APIs generieren; aktuell betreibt sie Prompt Engineering und plant Feintuning, wobei sie betont, dass LLMs gut Text erzeugen, aber bei Logik schwächeln. Ihr Rat: Mathe und Algorithmen als Basis, doch wirklicher Fortschritt entsteht durch Praxis, viele Beispiele und präzise Prompts.

Vom Aufnahmetest in Iran zur ersten Mitarbeiterin bei apichap: Negar Layeghs Weg in Machine Learning und Prompt Engineering

Unsere Perspektive auf die Session „Negar Layegh, Machine Learning Engineer bei APICHAP“

  • Title: Negar Layegh, Machine Learning Engineer bei APICHAP
  • Speaker: Negar Layegh
  • Company: apichap

Wir haben Negar Layeghs devstory mit besonderer Aufmerksamkeit verfolgt: eine Laufbahn, die in Iran beim großen Aufnahmeverfahren für die Universität begann, dann in einer ersten C-Programmierklasse einen radikalen Richtungswechsel nahm und sie schließlich als erste Mitarbeiterin eines jungen Startups in die Praxis von Large Language Models (LLMs) und Prompt Engineering führte. Diese Geschichte ist kein Hochglanz-Mythos über perfekte Karrierepläne, sondern ein geradliniger, bodenständiger Bericht aus dem Maschinenraum moderner Softwareentwicklung: Entscheidungen unter Unsicherheit treffen, sich von realen Ergebnissen motivieren lassen und durch Übung die eigene Handwerkskunst formen.

Ein früher Richtungswechsel: Vom Electrical Engineering zur Informatik – ausgelöst durch C

Negar beginnt ihre Geschichte dort, wo viele technologische Laufbahnen in Iran ihren Ausgang nehmen: bei der großen Aufnahmeprüfung für die Universität. Wer gute Noten hat, wählt oft Electrical Engineering – also tat sie es auch. Doch schon in der ersten Programmierveranstaltung, C, passierte etwas Entscheidendes. Sie erinnert sich:

„I was like, okay, I want to do that.“

Was folgt, ist bemerkenswert durch seine Entschiedenheit:

„I didn't even finish one semester as electrical engineering and I changed to computer engineering.“

In einer Welt, in der Studienrichtungen häufig als unumstößliche Pfade betrachtet werden, zeigt dieser Schritt: Das Erleben von unmittelbarer Wirksamkeit – Code schreiben, etwas läuft, Ergebnisse sehen – kann die beste Karriereberatung sein. Der Wechsel war nicht der einfache Weg, sondern der sinnvolle. Er markiert den Start einer Entwicklung, die von Neugier, Klarheit im Moment und der Fähigkeit geprägt ist, schnell Konsequenzen aus neuen Erkenntnissen zu ziehen.

Bachelorjahre: Klassische Machine Learning-Methoden, viel Praxis und Robotik als Magnet

In ihrem Bachelorstudium begann Negar, sich mit klassischem Machine Learning zu beschäftigen – nicht als Theorieexzess, sondern als praxisnahe Anwendung. Parallel zog sie Robotik an, ein Feld, das unmittelbares Feedback bietet: Sensoren, Aktoren, Wahrnehmung, Kontrolle. Auch wenn sie in der Rückschau betont, dass es „nicht viel“ klassisches ML war, ist gerade diese frühe Berührung bemerkenswert: Sie sah, wie Daten, Modelle und Code zusammenkommen.

Was wir daran schätzen: Ihre Motivation speist sich aus sichtbaren Ergebnissen und Lernfortschritt. Schon früh war klar, dass es nicht allein um Kurse geht, sondern um das Tun – ein Muster, das sich durch ihre gesamte Geschichte zieht.

Tel Aviv als Praxislabor: Internship, Master, drei Jahre Machine Vision

Nach dem Bachelor trieb Negar die Suche nach Anwendung in ein neues Umfeld. Sie bewarb sich auf ein Praktikum in Tel Aviv, verbrachte dort einen Sommer, kam für den Master zurück – und blieb. Die Folge:

„I kind of stayed there and worked in machine learning, machine vision for three years.“

Drei Jahre sind in der Technologiewelt eine lange Zeit – vor allem, wenn man in einem Feld wie Machine Vision arbeitet. Auch ohne ins Detail zu gehen, was genau die Projekte waren, wird eines deutlich: Sie bewegte sich in einem Bereich, in dem Wahrnehmung, Datenqualität und algorithmische Robustheit täglich auf den Prüfstand kommen. Für uns ist das eine logische Brücke: Wer Robotik und klassische ML-Aufgaben mag, findet in Machine Vision die harte Schule des Anwendens – reale Signale, Rauschen, wackelige Inputs, knappe Latenzbudgets. Genau diese Erfahrung legt die Basis für das, was später in LLM-Workflows zählt: nicht nur „ob ein Modell funktioniert“, sondern „wie man es dazu bringt, in konkreten Services zuverlässig zu funktionieren“.

Erster Job nach der Uni, erste Mitarbeiterin: Verantwortung von Tag eins bei apichap

Zurück in die Gegenwart:

„I'm working as a machine learning engineer at APICHAP. I'm a first employee of the startup. It's also my first real job after university.“

Damit ist die Ausgangslage klar: kein großer Konzern, keine träge Struktur, sondern ein junges Setup mit viel Gestaltungsspielraum – und viel Verantwortung. Als erste Mitarbeiterin prägt man nicht nur Features, sondern Prozesse und Qualitätsmaßstäbe. Man trägt die frühe DNA des Unternehmens mit.

Die Produktidee: APIs generieren – nicht von Hand, sondern mit Modellen

Negar beschreibt das Ziel prägnant:

„That's the whole idea of the startup, to write the APIs or to generate the APIs using machine learning models instead of coding it, one person codes it.“

Es geht also darum, API-Generierung zu automatisieren – nicht als Magie, sondern als strukturierte Nutzung von Modellen, die textuelle und semantische Muster verarbeiten. APIs sind formal, aber sie sind auch Sprache: Endpunkte, Verträge, Beispiele, Fehlerfälle, Beschreibungen. Genau hier setzen Large Language Models heute an – je besser die Anleitung, desto stabiler das Ergebnis.

Large Language Models: stark im Text, begrenzt in Logik – und warum das den Prompt zum Hebel macht

Negar wählt eine nüchterne Beschreibung des Status quo:

„The machine learning models that are being used right now are large language models, which are a big hit right now. And the powerful part of them is that they have a window remembering all the stuff that they said so they can generate meaningful content.“

Dieses „Fenster“ – die Fähigkeit, in einem Kontext zu bleiben – ist der Grund, warum LLMs aus Beispielen, Spezifikationen und Anforderungen kohärente Artefakte generieren können. Zugleich benennt sie die Grenze:

„They are not very smart, so they are still a bit dumb when it comes to logical stuff, but they're very good generating text and based on the prompts you would give them.“

Das ist kein Widerspruch, sondern die zentrale Designprämisse für Entwicklerinnen und Entwickler: Wer LLMs sinnvoll für Entwicklungsaufgaben nutzen will, muss die Stärken (Text, Muster, Kohärenz) gegen die Schwächen (Logik, exakte Ketten von Schlussfolgerungen) abwägen – und die Prompts so gestalten, dass die Modelle in ihrer Komfortzone bleiben.

Tagesgeschäft: Services bauen, GPT-Modelle orchestrieren, erst nutzen – später feinjustieren

Negar beschreibt ihren aktuellen Fokus klar:

„As a machine learning engineer, right now what I do exactly is prompt engineering to use the existing models… And right now I also build services using the GPT models, but in the future we'll be also fine tuning the models to fit better the problem that we currently have instead of being a general to get a better result.“

Die Methodik dahinter ist typisch für reifes ML-Engineering:

  1. Mit bestehenden Modellen starten und prüfen, „wie weit man kommt“ – Zeit zur Value-Validierung ist wertvoller als zu frühe Modellbastelei.
  2. Prompt Engineering als Ersthebel nutzen – was will man, in welcher Reihenfolge, mit welchen Beispielen und welche Einschränkungen sind wichtig?
  3. Perspektivisch feinjustieren (Fine-Tuning) – wenn die Problemklasse klar ist, lassen sich Generalisten-Modelle besser auf das Ziel zuschneiden.

Besonders interessant ist ihr Hinweis zur Logikgrenze und wie Prompting sie abmildern kann:

„With the correct prompt and explaining to them, you have to do this and that, then it will be a better result…“

Das ist mehr als ein Oberflächentipp. Es ist die Aufforderung, Modelle als kooperative, aber begrenzte Werkzeuge zu behandeln. Präzise Aufgabenanleitungen, klare Zwischenschritte, Beispiele und Abgrenzungen sind keine Zierde – sie sind der Motor reproduzierbarer Ergebnisse.

Lernen durch Ergebnisse: Spiele, klassische ML-Aufgaben – und warum Sichtbarkeit motiviert

Negar schildert, wie sie anfangs über spielerische Programmieraufgaben und klassische ML-Probleme in den Flow kam. Entscheidend war, dass sie schnell „sah, was passiert“. Ganz im Gegensatz zu ihrem kurzen Ausflug in Electrical Engineering, wo die Resultate nicht „very fast“ sichtbar wurden. Dieser Kontrast ist eine zentrale Lektion für Lernpfade in Tech:

  • Früh Ergebnisse sehen heilt Zögern.
  • Motivation wächst, wenn das eigene Tun Wirkung entfaltet.
  • Komplexität lässt sich besser tragen, wenn das Feedback kurzzyklisch bleibt.

Ihre Quintessenz:

„It's mostly by practicing… of course, reading some basics and mathematics would also help in the long term and algorithms, but at the end of the day, it's mostly programming and working on different examples… it's more like experience that you can gain from doing different stuff.“

Das ist keine Geringschätzung von Theorie – eher eine Einordnung. Mathe und Algorithmen schaffen Haltbarkeit. Doch die Kompetenz, ein Problem wirklich zu „drehen“, entsteht im Tun: verschiedene Beispiele, andere Daten, neue Domänen, unerwartete Kantenfälle.

Praktische Implikationen für Entwicklerinnen und Entwickler

Aus Negars Geschichte und Formulierungen lassen sich konkrete Handlungsempfehlungen ableiten – bodenständig, alltagstauglich, ohne Hype:

  • Starte mit existierenden Modellen: Baue zuerst Services um GPT-Modelle und LLMs, bevor du in aufwendige Eigenentwicklungen gehst. Das verschafft Tempo und Lernkurven.
  • Nimm die Logikgrenzen ernst: Plane Prozesse so, dass LLMs nicht lange, fragile logische Ketten alleine tragen müssen. Zerlege Aufgaben, gib klare Schritte vor.
  • Treat the prompt as code: Schreibe Prompts mit derselben Sorgfalt wie Produktivcode – mit klaren Zielen, Constraints, Beispielen und einer Begründungsstruktur.
  • Iteriere am Prompt, nicht nur am Code: Oft ist ein präziser formulierter Prompt der schnellste Qualitätshebel.
  • Halte Kontext greifbar: Nutze das „Fenster“ der Modelle effektiv, indem du relevante Vorgaben, Beispiele und bisherige Entscheidungen im Prompt führst.
  • Beweise Wert vor Fine-Tuning: Plane Fine-Tuning erst, wenn die Problemklasse stabil verstanden ist. So vermeidest du frühzeitige Spezialisierung in die falsche Richtung.
  • Lerne durch Projekte: Spiele, kleine Experimente, klassische ML-Aufgaben – alles, was schnelle Ergebnisse erzeugt, baut Intuition auf.
  • Theorie als Langzeitinvestition: Mathe und Algorithmen zahlen sich aus – aber sie entfalten ihren Wert am besten, wenn sie durch Praxis „geerdet“ sind.

Prompt Engineering: Konkrete Muster, die aus Negars Ansatz sprechen

Negars Aussagen legen nahe, worauf es im Prompting besonders ankommt. Einige Muster, die wir aus ihrer Beschreibung ableiten:

  • Zielorientierung: Formuliere explizit „you have to do this and that“ – also Ziele und Schritte, nicht nur vage Wünsche.
  • Schrittweises Vorgehen: Zerlege Aufgaben in Reihenfolgen, um logische Schwächen zu kompensieren.
  • Beispielgeleitet arbeiten: LLMs „lernen“ im Kontext – Beispiele schaffen Anker für Stil, Struktur und Grenzfälle.
  • Fehlervermeidung durch Constraints: Wenn eine Form strikt ist (z. B. API-Spezifikationen), schreibe die Constraints hinein und wiederhole sie im Prompt.
  • Output-Formate fixieren: Nenne klar, welches Format erwartet wird – das minimiert Rauschen und Nachbearbeitung.

Diese Punkte sind nicht exotisch – aber gerade deshalb wertvoll. In der Praxis gewinnt, wer sie konsistent anwendet.

Warum „erste Mitarbeiterin“ zählt: Ownership, Fokus und Pragmatismus

Negars Hinweis, die erste Mitarbeiterin zu sein, ist mehr als ein Detail. Es heißt:

  • breite Zuständigkeit vom Tag eins,
  • Entscheidungen unter Unsicherheit treffen,
  • Services bauen, die heute Mehrwert liefern – nicht nur in sechs Monaten.

In solchen Umgebungen ist „erst nutzen, dann feinjustieren“ keine Notlösung, sondern Disziplin. Der Wert liegt in funktionierenden Services – und in der Fähigkeit, aus ihnen zu lernen.

Zitate, die haften bleiben

Einige Aussagen, die wir aus der Session mitgenommen haben:

„I was like, okay, I want to do that.“

– über den Moment, in dem Programmieren „klick“ machte

„I didn't even finish one semester as electrical engineering and I changed to computer engineering.“

– über entschlossenes Umlenken, sobald Klarheit da ist

„I'm a first employee of the startup. It's also my first real job after university.“

– über Verantwortung und Lernkurve im Startup-Kontext

„They are not very smart… but they're very good generating text…“

– über die realistische Einschätzung von LLMs

„With the correct prompt… then it will be a better result.“

– über den Prompt als zentrales Werkzeug

„It's mostly by practicing…“

– über Lernen, das aus Erfahrung entsteht

Für wen diese devstory besonders relevant ist

  • Studierende und Umsteiger, die überlegen, von einer technischen Disziplin in die Informatik zu wechseln – Negars Beispiel zeigt, dass frühe Klarheit und mutige Schritte sich lohnen.
  • ML-Einsteigerinnen und -Einsteiger, die verstehen wollen, warum LLM-Arbeit heute so häufig bei Prompt Engineering beginnt.
  • Startup-Builder, die wissen, dass Zeit zu Wert zählt: erst Services mit Generalisten-Modellen bauen, dann Spezialisierung.

Konkrete erste Schritte, inspiriert von Negar Layegh

  • Nimm eine Aufgabe, die textuell gut beschreibbar ist (z. B. API-Spezifikation aus Beispielen), und baue einen minimal funktionierenden Service mit einem GPT-Modell.
  • Schreibe Prompts iterativ: Ausgangsformulierung, Ergebnis prüfen, Lücken identifizieren, Constraints ergänzen.
  • Sammle repräsentative Beispiele und Gegenbeispiele – und führe sie im Prompt.
  • Dokumentiere Prompt-Änderungen wie Code-Änderungen – welche Anpassung brachte welchen Effekt?
  • Wenn die Zielklasse klarer wird, evaluiere, ob Fine-Tuning Mehrwert gegenüber weiterem Prompting bringt.

Diese Schritte sind nicht komplex, aber sie verlangen Disziplin. Das ist die Art Pragmatismus, die aus Negars Arbeitsweise spricht.

Was uns besonders überzeugt hat

Negars Ton ist sachlich, fast nüchtern – und gerade deshalb glaubwürdig. Keine Wunderversprechen für LLMs, sondern klare Worte zu Stärken und Schwächen. Keine überzogenen Claims zur eigenen Laufbahn, sondern ein sauberer Faden: entdecken, entscheiden, üben, anwenden.

Ihr Weg von der ersten C-Klasse über Robotik und Machine Vision hin zu LLM-basierten Services ist ein stringentes Muster für moderne ML-Karrieren: Man beginnt nicht mit dem „perfekten“ Modell, sondern mit einer Aufgabe, die Wert stiftet. Man lernt dort, wo Feedback schnell kommt. Und man beherrscht die Werkzeuge, indem man sie benutzt – immer wieder, an echten Beispielen.

Fazit: Eine moderne ML-Karriere ohne Mythos – mit viel Praxis

Negar Layeghs Geschichte zeigt, wie lebendig und bodenständig ein Weg in Machine Learning heute sein kann. Vom iranischen Aufnahmeverfahren zum entschlossenen Studienwechsel. Von spielerischen Programmieraufgaben zu klassischem ML. Von einem Sommerpraktikum in Tel Aviv zu drei Jahren Machine Vision. Und schließlich: erste Mitarbeiterin bei apichap, Services mit GPT-Modellen bauen, Prompt Engineering als tägliches Handwerk, Fine-Tuning als nächster Schritt.

Was wir mitnehmen: Sichtbare Ergebnisse schlagen abstrakte Pläne. LLMs liefern starken Text unter klarer Anleitung – aber keine Wunder in Logik. Übung, Beispiele und Erfahrung entkoppeln Fortschritt von Perfektion. Für Entwicklerinnen und Entwickler ist das eine beruhigende Botschaft: Gute Arbeit entsteht nicht aus Mythos, sondern aus Methode. Genau das hat diese Session – „Negar Layegh, Machine Learning Engineer bei APICHAP“ – eindrucksvoll vor Augen geführt.

Weitere Tech Lead Stories