Signal archive

Signal

Issue 6 · August 11, 2026 · 5 min read

Why Coding ML By Hand Still Beats AI Autocomplete

AI tools spit out sklearn scripts in seconds. Machine learning engineer jobs still pay for people who can write the training loop, catch leakage, and debug when the library path is lying.

"Students who implement the algorithms themselves understand them much better." - Andrew Ng

I keep seeing the same take: why learn machine learning by hand when an AI tool can spit out a scikit-learn script in ten seconds?

This week I'm going to argue the opposite. Coding machine learning algorithms yourself is still one of the highest-ROI things you can do for machine learning engineer jobs, and yes, this can get you a very comfortable job.

Here's the idea: "machine learning vs AI" is a search query. In hiring, the split is uglier. AI tools are great at producing code that looks like python machine learning. Machine learning engineering is what happens when that code is wrong in a more discrete way. Wrong split. Wrong metric. Learning rate that "works" until it doesn't. A model that reports 94% accuracy because every row leaked the label. Copilots do not catch that for you. People who have written the training loop by hand usually do.

I am not anti-tools. You should use libraries. Ship with them. But if you have never coded gradient descent, never written a split criterion, never watched a loss refuse to move because your features are on different scales, you are renting intuition. That shows up fast in machine learning interview questions. Interviewers still ask you to implement logistic regression, explain bias-variance on a concrete model, or debug why a "perfect" validation score collapses in production. Indeed Hiring Lab still has machine learning engineer postings well above their early-2020 baseline while general software postings are underwater. Those roles pay like it (Robert Half's 2026 AI/ML midpoint sits around $170K) because somebody on the team has to own the failure modes.

To see why hand-coding still matters, think about what a library call actually hides. When you call `LogisticRegression.fit()`, you skip the part where the gradient is a matrix multiply, the learning rate is a knife edge, and L2 regularization is just adding weight magnitude to the loss. When you implement that same model in NumPy, those knobs stop being folklore. Same story for trees: once you write the information gain yourself, you stop treating `max_depth` like a magic dial. Netflix can spend a fortune on ranking machine learning models because the people on those teams can reason about the objective, the sampling, and the serving constraints. That reasoning does not come from watching someone else's notebook.

So my statement is simple: if you want machine learning engineer jobs in a market flooded with AI demos, learn to code machine learning by hand first. Then use the libraries to go faster on top of that understanding.

Now I'm going to explain what this means for you:

The Skill Employers EXPECT

Learn core machine learning algorithms in Python the slow way. Employers assume you can:

  • Write a training loop without copy-pasting a tutorial
  • Implement at least one linear model and one tree-based idea from scratch
  • Plot loss / error and explain what the curve is telling you
  • Catch leakage, class imbalance, and bad metrics before you blame the model
  • Read a library's defaults and know what they are doing to your objective

If sklearn feels like a black box, you are not ready to debug production models.

The Skill That Separates You

Learn to debug machine learning models from first principles.

When a model misbehaves, strong candidates can isolate the cause:

  • Is the loss stuck because of scale, step size, or a bad objective?
  • Is the metric lying (accuracy on imbalanced labels, AUC with leakage)?
  • Is the algorithm the wrong tool for the data geometry?
  • Would a simpler hand-built baseline already beat the fancy pipeline?

That skill turns machine learning interview questions into conversations instead of panic.

The Project To Learn These Skills This Week

Rebuild a real algorithm by hand, then prove you understand the library version.

Dataset: Breast Cancer Wisconsin, or any clean binary classification set you already know

Requirements:

  • Implement logistic regression in NumPy only: sigmoid, binary cross-entropy, gradient descent (batch or mini-batch), and L2 regularization.
  • Train it yourself. Log loss each epoch. Tune learning rate and regularization until validation loss is stable.
  • Match scikit-learn's `LogisticRegression` on the same split within 1% absolute accuracy and within 0.02 ROC-AUC. If you miss, write exactly which assumption differed (solver, penalty, feature scaling, intercept handling).
  • Add one intentional bug (shuffle leak, unscaled features, or label imbalance with accuracy-only reporting), show the fake "win," then fix it.
  • Write a one-page note: what coding this by hand taught you that the library call had been hiding.
  • No pretrained models, no AutoML, no "AI wrote my training loop." Your code.

This project teaches a practical lesson for machine learning engineering:

Libraries make you fast. Hand-coded machine learning makes you dangerous in the useful way: you can tell when the fast path is lying.

If you want to sharpen your machine learning skills even more, I also selected a challenge problem for you this week:

If you learned something from this newsletter, make sure to forward it to a friend.

Binary Cross-Entropy Loss

Medium · ~15 min

Concept: logistic regression

Ready to practice?

Turn weekly insights into hands-on ML skills on GRADuateML.