Ask a coding assistant for a random forest and inspect the four lines it gives you: the imports are correct, the estimator fits, and predictions come back in the expected shape. Now look at the arguments nobody specified, because those four lines have settled more questions than your prompt asked.
How many features should each tree consider? How much regularization should the model apply? How should validation folds reflect the structure of your data? That is what defaults do: they let an underspecified request become an executable program.
Language models learn patterns of code through next-token prediction, which makes familiar implementations a natural starting point for generation. When an implementation leaves an argument out, the library supplies its value, allowing a statistical choice to pass from convention into your pipeline without ever becoming part of the conversation.
An assistant can examine those choices when prompted, but receiving working code is no evidence that they have been examined. The omission is easy to miss precisely because nothing needs to break.
The five defaults below are ones I’ve encountered in my own production work and in colleagues’ projects, where they caused debugging headaches because we had overlooked what the code was doing. Each deserves the same question: what did leaving this argument out decide for me?
1. RandomForestRegressor(max_features=1.0)
If you learned random forests as “bootstrap the rows, subsample the features, average the trees,” the default regressor comes with a surprise: RandomForestClassifier uses max_features="sqrt", while RandomForestRegressor uses max_features=1.0, making every feature available at every split!
That difference switches off the feature subsampling that distinguishes the usual random forest recipe from plain bagging. Bootstrap sampling is still there, so the trees remain random through the rows they receive, but the second layer of randomness (deliberately restricting which features each split can consider) is absent.
Why does that matter? Imagine a dataset with one particularly strong predictor, such as price or discount in a sales model. Even when each tree receives a different bootstrap sample, price may keep winning the early splits because its predictive signal survives those changes in the training rows. The trees can therefore develop similar structures and respond similarly to fluctuations in the training data, limiting how much averaging reduces their shared variability.
Feature subsampling interrupts that repetition by occasionally excluding the dominant predictor from consideration, forcing trees to explore alternative splits. I unpacked the mathematics and a controlled experiment in Why Random Forest Needs to Be This Random TDS article, where the central point is that adding more trees cannot eliminate the variance component associated with their correlation.
With max_features=1.0, you are leaving that additional decorrelation mechanism unused, even though the estimator’s name may have led you to assume it was already operating. Setting max_features=0.33, for example, makes roughly a third of the features available at each split and restores that part of the random forest recipe.
The question to ask your assistant is simple: if we chose a random forest partly for feature-level randomness, why have we left that randomness switched off?
2. LogisticRegression(C=1.0)
Ask for a logistic regression and you might expect a model that finds the coefficients that best explain the observed outcomes. What LogisticRegression() actually fits is a regularized version, with an L2 penalty that discourages large coefficients and a default C=1.0 that determines how strongly that penalty competes with fitting the data.
Regularization is often useful, especially when the data is noisy or the predictors overlap, but the number 1.0 has no special knowledge of your problem. Smaller values of C impose stronger regularization, while larger values give the coefficients more freedom, and leaving the argument out accepts one particular setting without examining it.
Apart from that an even more subtle issue is that “large coefficient” depends on how you measured the feature. Suppose income is recorded in euros and its coefficient is 0.0001. Express the same income in thousands of euros and the coefficient must become 0.1 to preserve exactly the same penalty-contribution to the prediction:
50,000 × 0.0001 = 50 × 0.1 = 5
The information has not changed, but the coefficient is now a thousand times larger, so its contribution to the L2 penalty, which squares coefficients, is a million times larger. When you refit the model with the same C, the optimizer faces a different trade-off simply because you changed the units.
A practical starting point is to standardize continuous features inside a Pipeline, so preprocessing is fitted within each training fold, and then tune C using appropriate validation. Otherwise, your choice of euros versus thousands of euros is quietly helping decide how much regularization each feature receives.
3. cross_val_score(model, X, y, cv=5)
Five-fold cross-validation sounds like a reassuringly thorough check: train on four parts of the data, evaluate on the fifth, and repeat until every observation has been held out once. But cv=5 specifies the number of folds while quietly leaving another decision to scikit-learn: how those folds are constructed.
For regression, it uses KFold with shuffle=False, meaning the validation folds are consecutive blocks of rows in their existing order. If your dataframe is sorted by date, customer, or region, that ordering becomes part of your evaluation design, whether you intended it or not.
Consider 100 weeks of sales, arranged chronologically. The first fold evaluates on weeks 1–20 after training on weeks 21–100, so the model is using later observations to predict earlier ones. The code runs perfectly, but the experiment does not represent forecasting, where only the past is available when predicting the future.
Simply adding shuffle=True would still mix past and future across training and validation, which is why the right splitter depends on what “unseen data” means for your problem. For independent observations whose row order is arbitrary, shuffled KFold is a reasonable choice; for forecasting, use a time-based scheme that trains on earlier observations and evaluates on later ones; for predictions about new customers, use a grouped splitter that keeps each customer entirely within one side of the train–validation boundary.
For ordinary binary or multiclass classification, scikit-learn uses StratifiedKFold instead, preserving class proportions approximately, but still without shuffling by default and without automatically respecting customer groups or time.
By passing cv=5, you have chosen how many times to evaluate the model, while leaving the structure of that evaluation implicit. Your assistant can supply a valid cross-validation call, but you still need to define what the model should be able to generalize to.
4. KMeans(n_init="auto")
The word "auto" sounds reassuring, especially for a parameter controlling how many times an algorithm tries to find a good solution. You might reasonably leave it alone, assuming the library takes care of that decision, but with the default init="k-means++", n_init="auto" means exactly one complete run.
To see why that matters, remember how KMeans works: it starts with an initial set of cluster centers, assigns each observation to its nearest center, and repeatedly updates those centers until convergence. Where the centers start can affect where they finish, because the algorithm can settle into a local minimum that further iterations will not escape.
Multiple initializations address this by repeating the entire procedure from different starting positions. With n_init=10, KMeans performs ten runs and keeps the one with the lowest inertia, the sum of squared distances between observations and their assigned cluster centers.
The default k-means++ initialization chooses starting centers more carefully than simple random selection, which makes a single run a more reasonable computational shortcut, but it does not guarantee that another initialization would not produce a better solution. The "auto" setting follows a fixed rule based on the initialization method; it does not examine your results and keep restarting until they appear stable.
Increasing max_iter will not restore those missing restarts, because it only allows more updates within each run. Similarly, setting random_state=42 makes the initialization reproducible, so you can consistently return to the same solution without learning whether another starting point would improve it.
If you want multiple attempts, request them explicitly with a value such as n_init=10, accepting the additional computation. Otherwise, the automatic choice you have inherited is to accept the result of one initialization, without comparing it against alternative starts.
5. SimpleImputer(keep_empty_features=False)
You add SimpleImputer() to a pipeline expecting it to fill missing values, but its defaults also allow it to remove entire columns. With the default mean strategy, any feature that contains only missing values during fitting has no mean to compute, so the imputer drops it from the transformed output.
Imagine a training dataset with 20 features, including a measurement that was never recorded for any of the training observations. The imputer removes that column, and the downstream model trains on the remaining 19 features, even though you may still be thinking of your pipeline as a 20-feature model.
Now new data arrives with actual values in that previously empty column. The fitted imputer still removes it, because the decision was established during training; the new measurements never reach the model.
You might expect a feature-count error, but a consistent pipeline produces none: the model received 19 features during training and receives the same 19 during prediction. Everything runs normally, which makes the change easy to miss if you only inspect the data before preprocessing.
This can also happen inside cross-validation, where a sparsely populated column may be entirely missing in one training fold despite containing values elsewhere in the dataset.
Setting keep_empty_features=True preserves those columns, filling their missing values with zero under the default mean strategy. That preserves the feature structure, but it cannot teach the model a relationship that was absent from the training data, so retaining the column does not automatically make its future values useful.
The point is to inspect what your preprocessing actually passes downstream, including the output feature names and shape. A step introduced to fill missing entries can also decide which features survive, and a successful .predict() call will not tell you that one disappeared.
The Point
None of these are bugs, and there are good reasons for the defaults to exist, from computational efficiency to making common workflows easier to run. The trouble begins when we accept them without noticing the choices they make, especially when the code executes cleanly and the output looks entirely plausible.
These are all behaviors I’ve encountered in production work, either in my own pipelines or in colleagues’ projects, and they have caused more debugging headaches than their small footprint in the code would suggest. An omitted argument is easy to overlook when you are investigating the data, the model, and everything else that could explain an unexpected result.
Coding assistants make it easier to carry those omissions forward, because a familiar implementation can arrive fully formed before we have discussed the assumptions behind it. An assistant can help examine those assumptions, but a request to “write the code” does not guarantee a conversation about row ordering, initialization, or what survives preprocessing.
That is where experience still matters: recognizing which apparently routine choices deserve a second look, and asking for an explanation of the defaults alongside the implementation. Sometimes the right outcome is to keep the default, with a clear understanding of why it fits.
The job was never just typing the four lines; it was knowing which questions those four lines left unanswered.
Instagram Engineering
Shopify Engineering