Video summary

ML Engineer сьогодні: задачі, технології та відповідальність — Олександр Корнієнко, випускник (2024)

Main summary

Key takeaways

Educational

Main ideas, concepts, and lessons

1) Purpose and structure of the talk

The speaker shares a personal career story to answer:

  • How trajectories in ML/engineering change over time
  • What different ML projects have in common
  • What employers and candidates should pay attention to

The talk is divided into three thematic blocks:

  • Personal ML engineering trajectory + projects
  • Miltech (military technology): what it is, what roles/skills matter, and opportunities
  • Superhuman (formerly Grammarly): what the ML Engineer role looks like, what the challenges are, and what to learn/aim for

2) How the speaker’s background shaped their ML path

  • Initial education: technical information protection (security).
  • Key connection: security work (e.g., analyzing data access and preventing unauthorized use) connects logically to later work where NLP and ML analyze language/information.
  • The speaker describes a progression of seemingly “different” domains that are actually grounded in similar fundamentals:
    • signal processing
    • math
    • feature engineering
    • modeling

3) Project history: “cool projects” across ML domains (common themes)

The speaker lists a chain of commercial projects, emphasizing shared foundations (math, signals, feature representations, pipelines):

  • Video analytics / person tracking
  • Music recognition / recommendation systems
  • Detection suit (“blows”)
    • Uses signal processing + spectral analysis and feature selection
  • Perception system for processing patient data
    • Described broadly as perception + processing pipelines
  • NLP / language models / agents (current direction)

Early inspiration

  • Learned about OpenCV and noticed similarity between “HAR” concepts and classic detector pipelines.
  • Early detector systems were built using:
    • cascades of feature functions
    • ensembles
      • analogy: a CNN as an ensemble element, where a shallow network feeds into ensemble structure

First job hiring story

  • A recruiter/interviewer recognized excitement about OpenCV and the similarity to known concepts.
  • The initial task involved an ML/POC system for:
    • searching for people
    • counting people
    • e-commerce analytics (“who comes, what products they’re interested in”)

4) Scale and “product thinking” in NLP at Grammarly/Superhuman

In the speaker’s first NLP role, they clarify that ML Engineering is not just model training.

Responsibilities

  • Help with data collection and annotation
  • Assess annotation quality (agreement/disagreement between annotators)
  • Train models
  • Deploy to production systems handling ~200,000 requests/sec

Early system approach

  • Rewriting text in a desired tone/style using GPT-2

Quality and evaluation challenge

  • Defining “style/tone” metrics is subjective.
  • They mention an “LM-as-a-judge” idea:
    • other LMs assess:
      • author knowledge / naturalness
      • task validity (does it solve the goal?)

Key pain point

  • Maintaining GPT-2 at high traffic is expensive.

Solution direction

  • Reduce cost via distillation and smaller specialized models.

Core lesson

  • ML engineers in product companies need a full-cycle, ownership mindset:
    • understand the problem
    • ship
    • diagnose failures
    • predict failure modes from experience
  • Also: learn why users dislike changes—not only when outputs are “technically correct.”

5) War-time/volunteer technology work: using ML for urgent real-world problems

Around Feb 24, the speaker describes a volunteer turning point and actions taken.

Initial efforts

  • Reconnaissance concepts using drones to locate threats (mines).
  • Attempts at deepfake detection
    • They deployed a classifier quickly after the Zelenskyy “surrender” video event.
    • Concluded it wasn’t useful—nobody needed it (in that form/time).

Shift: war damage assessment

  • Using satellite images to:
    • digitize damaged cities (Mariupol mentioned first)
    • align pixels into geospatial coordinates
    • build pipelines for large image processing

Long-term idea (~since 2017)

  • Demining: detect mines from UAVs
    • drone sensors (cameras + magnetic sensors)
    • mark mines on maps

Explicit lesson

  • Value and motivation come from working on problems with no ready-made answers.
  • Certain companies/products provided a framework:
    • First check whether someone already solved it (open-source/existing code).
    • Take responsibility for the result—not just for “doing tasks.”
    • “Execution” mindset: don’t wait for step-by-step instructions—own decisions and outcomes.

6) “UCU” / community and fundamentals: how they improved the speaker’s approach

The speaker explains why they later pursued UCU-related education.

  • Belief: knowing “how” vs understanding “why” matters.
  • They wanted to strengthen foundational gaps, especially mathematics.
  • UCU is described as providing:
    • a strong community of capable peers/teachers
    • pillars:
      • linear algebra (practical)
      • ethics (including multi-context understanding)
      • “computerized corporate finance” framed through opportunity cost and compound interest as investing in knowledge/health/projects

7) Building ML systems at Miltech: what makes it different

The speaker emphasizes Miltech is fundamentally different from standard commercial ML.

Core characterization

  • Not “weapon/romance,” but engineering under extreme constraints.

Main enemies

  • time and error
    • in Miltech, saving quality has a cost measured in lives/health

System expectations

  • reliably and quickly
  • under uncertainty
  • “right the first time”
    • no “turn it on later,” no “turn off and forget”

Miltech is more than an algorithm

  • Hardware + application methodology
    • algorithm doesn’t matter if devices fail in cold/heat/discharge constraints
  • User reality
    • defenders may use devices with gloves, in darkness, under fire—often with minimal instructions
    • usability should be “one button” (conceptually)
  • Field testing from day one
    • overheating, antenna failures, battery behavior, and other practical issues
    • anticipating these at design time is highly valued

Example constraints

  • Thick connectors because devices may be dropped into swamp/snow; must remain functional after cleanup in cold.

Data problem and “synthetics” (simulation)

  • Miltech-relevant data is extremely valuable.
  • Danger: relying on open general datasets (e.g., speech recognition datasets) can cause hallucinations/model degradation.
  • Therefore:
    • collect field-relevant data
    • but when data is scarce, use synthetics/simulation to cover edge cases

Example

  • Camera view geometry / small targets
    • if a tiny target occupies only a few pixels, a model may miss it
    • simulation generates more visible training scenarios for rare events like mines

Quick Miltech market notes

  • Roles distribution mentioned: roughly a “third” are software engineers
  • Pay: more competitive than earlier volunteer-stage work
  • Growth expectation: increasing demand for additional features

8) Technologies Miltech recruiters look for (as stated)

The speaker lists key technology areas:

  • Computer vision
    • object detection
    • feature tracking
    • deployment to single-board devices (e.g., Raspberry Pi) with adequate FPS
  • Protection
    • code suppression / encrypting model weights to prevent reuse by enemies
  • ROS (Robot Operating System)
    • build robots using consumer/toy platforms to learn:
      • data connectivity problems
      • stability
      • combining data + decision algorithms
      • machine/robot control aspects

9) Superhuman: the ML Engineer role and agent-focused engineering

The speaker explains Superhuman’s mission and their ML work.

Company/product context

  • Superhuman is a multi-product company for AI assistants in communication/knowledge.
  • Products mentioned:
    • Koda
    • Grammarly
    • Superhuman Mail

Speaker’s role

  • in-house LMs
  • text improvement and generation
  • recommendation systems for production agents operating across millions of emails daily

Key implication

  • model changes directly affect how millions communicate

Why not “just connect GPT” for proofreading

  • Cost at scale
    • tens of millions daily users; even sentence-by-sentence checking becomes extremely expensive
  • Latency
    • GPT-style services may take seconds vs ~milliseconds for specialized pipelines
  • Meaning change risk
    • models can alter meaning (e.g., “insist” vs “leave”)

Approach to quality

  • Tune a large model into a smaller one:
    • teach it the specific task
    • avoid changing unnecessary text
  • Evaluate with task-specific metrics
    • mentions “F05” / precision-like emphasis (precision reportedly more important than recall)
  • If needed:
    • ensembles of specialized models can improve quality, but increase cost

How agents work (described)

  • Agents run multi-step loops:
    • receive task
    • plan steps
    • call tools
    • check result
    • adjust
    • repeat before completing
  • Tradeoff:
    • more autonomy, but often slower and more expensive than direct models
    • especially costly for long email/document checking

10) Engineering challenges when building/using agents

The speaker enumerates engineering problems before and when building agents:

  • Non-determinism
    • LLMs can fail in unpredictable steps (especially if temperature > 0)
  • Quality assessment requirement
    • because outputs aren’t reliably predictable:
      • prefer deterministic solutions where possible
      • implement strong quality control
      • use:
        • human annotation
        • LLM-as-judge evaluation (“language as judge”)
  • Versioning and model replacement risk
    • backend model swaps can unexpectedly reduce quality
  • Security and control
    • “responsible AI” emphasis: models shouldn’t generate risky/harmful content

11) What the speaker says MLEs do day-to-day

Workstreams described:

  • working with data
  • building models/classifiers
  • building LM agent systems
  • deployment engineering

Systems integration and operations:

  • choose architecture/backends based on cost and latency
  • integrate into products (multi-microservice design, protocols, load balancing)

Operational reality:

  • incidents can occur at ~3am; engineers must diagnose and fix quickly.

12) What agents changed in the speaker’s working style

  • “Code review” habit
    • agents can make changes that are hard to control
    • code review assistants help prevent breaking changes
  • Codebase analysis
    • hidden documentation and unknown stacks require asking people
    • agent assistants act as quick guides to integrate safely
  • Faster routine development
    • previously: days to build boilerplate for tricky integration/breaking-model issues
    • now: near minutes to half an hour to connect services and test
  • LLM tooling for research engineering
    • logs, experiment tracking, analysis
    • assistant can help train/improve models from model + data
    • “downtime” automation idea: wake up and the job is done

13) What employers look for (explicit interview guidance)

The speaker provides structured recruiting signals.

What to demonstrate

  • Values fit
    • not “cultural vibe,” but mission understanding
  • Technical thinking
    • solve from the task statement, not just know tools
    • be willing to inspect references/approaches (e.g., Face/Hub-style resources)
  • Impact
    • explain what you did and how you measured outcomes
  • Responsibility and explainability
    • justify decisions
    • explain alternatives and why you chose your approach

Red flags / negatives

  • Cannot explain why decisions were made
  • Proposes technology without understanding it
  • Doesn’t describe teamwork (focuses only on self)
  • Cannot analyze mistakes or reflect on what went wrong and what was learned

How to prepare (practical suggestions)

  • Build pedagogical projects (achievable, routine problems) and mention them in interviews
  • Use:
    • volunteering
    • internships
    • open problems as course/diploma projects
  • Learn from people around you (company culture and mentorship matter)
  • Even without commercial experience:
    • show projects
    • measurable outcomes
    • reflection and learning

Methodologies / instruction-like lists (as presented)

Miltech “how to think” (implied checklist + steps)

  • Treat Miltech as engineering under extreme consequence
  • Anticipate constraints early:
    • environment (cold/heat)
    • power/battery behavior
    • physical failure modes (connectors, cables, field damage)
  • Iterate with field testing from day one
  • Collect relevant data:
    • rely on field-specific data (avoid generic datasets that degrade quality)
  • When data is insufficient:
    • use synthetics/simulation to generate coverage of rare/small targets
  • Ensure usability for real users:
    • minimal training
    • robust interaction assumptions (gloves, darkness, stress)

Career/employment preparation steps (explicit-ish)

  • Build at least one:
    • pedagogical project (practical, solvable)
    • volunteer work or internship experience
    • team-based projects (course/diploma) showing collaboration
  • In interviews, be ready to provide:
    • the problem
    • your decisions
    • alternative reasoning
    • metrics/impact
    • lessons learned

“Agents vs direct models” decision framing

  • If you can solve with targeted tuned models:
    • do it (cheaper, faster, more controllable)
  • If tasks require multi-step tool use and autonomous loops:
    • use agents, but plan for:
      • non-determinism
      • quality assessment gates
      • security controls
      • versioning risks

Speakers / sources featured

  • Primary speaker: Олександр Корнієнко (Alexander Korniienko) — ML engineer / lecturer
  • Mentioned person (brief): Руслан (referenced in the opening anecdote)
  • Mentioned people (brief):
    • Олександр “Andrey Kurorychkin” (invited the speaker to teach/lecture)
    • Ярік Гермило (Yarik Hermilo) (credited for a talk about code review/control)
    • Назарій Друщук (Nazariy Drushchuk) (responsible AI)
  • Companies/products mentioned as sources/contexts:
    • OpenAI (GPT-2 mentioned; GPT-4 mentioned)
    • OpenCV
    • Grammarly (spelled in subtitles “Gramerly/Gramrly,” later referred to as rebranded “Superhuman”)
    • Superhuman
    • UCU (education/community; exact full org name unclear in subtitles)
    • ROS (Robot Operating System)
    • Raspberry Pi
    • Claude (mentioned as an assistant in the agent/tooling discussion)
    • Face/Hugging Face-style resource (referenced as “hface” in subtitles; likely Hugging Face)

Original video