Notes on working with AI
Not everything needs a language model
Many AI projects are classic prediction problems with a table of past data. A language model is the wrong tool for them, and Claude is most useful as the analyst who builds the right one.
Most prediction problems in a business are a table
A company has two years of customer records and a column that says who left. The question is who is likely to leave next. People call this an AI project and reach for a chatbot. It is a classic prediction problem, and it was solved long before language models existed.
The shape to look for is simple: rows of past cases, columns describing each case, and one column with the outcome you want to predict. That is supervised learning. Four methods cover most of what a business needs.
The four methods in plain words
Linear regression fits the best straight line through past points and uses it to predict a number. Delivery time from distance is the standard example. If the question is how much or how long, start here.
Logistic regression, despite the name, answers yes or no. It turns the inputs into a probability between 0 and 1, and you pick the threshold where a case counts as high risk. It sits behind churn scores, fraud flags and spam filters.
A decision tree asks a chain of yes or no questions until it reaches an answer. Its strength is that a person can read the chain. When someone has to defend the decision to a manager, a regulator or a customer, this is often the right choice.
Nearest neighbors labels a new case by the most similar cases it has seen. It is intuitive, but it keeps all the data and compares against it at prediction time, so it slows down as the data grows.
Why a language model is the wrong tool here
Paste the same spreadsheet into a chatbot and ask for a churn prediction, and four things go wrong. It is slower, because a table of numbers runs through a system built for text. It costs more for every answer. It can return a different answer on the same row tomorrow, because generation is sampled. And it cannot show how it decided, so there is nothing to audit.
A logistic regression on the same table is fast, nearly free to run, gives the same answer every time, and reports which factors pushed the score. That consistency and traceability is most of what a business decision needs.
Where Claude belongs
The useful role for Claude is analyst, not predictor. It looks at your table, picks the simplest method that fits, writes the code, holds back some rows to test on, and reports how often the method was right on cases it had not seen. Then it explains the result in plain words.
The held-back test matters. A method that is judged only on the rows it learned from will look better than it is. Ask for the test every time.
The cheat sheet fits in four lines. A number: regression. Yes or no with a probability: logistic. Need to explain why: a tree. Similar past cases: nearest neighbors.
Where this breaks
Classic methods need a decent table. If you have forty rows, or the column you want to predict is filled in inconsistently, no method will rescue it. They also learn only from the columns you give them, so a factor that is not in the table cannot matter. And when the input is free text, such as complaint emails, a language model is the right tool again. The skill is telling the two kinds of problem apart.
What to do tomorrow
Find one table of past cases with an outcome column. Upload it to Claude with code execution enabled and paste this:
The file has past cases and one outcome column. Pick the simplest suitable method from linear regression, logistic regression, a decision tree or nearest neighbors, and explain in plain words why you chose it. Train it on part of the rows, test it on rows you held back, and tell me how often it was right. List the three strongest factors.
Check whether the three factors match what you already suspected. If they do, you have a baseline. If they do not, you have your next question.