Part 1 of the “Applied AI: A Practical Guide for Developers” series

By: Austin Reid

Who this guide is for

Software developers who can ship Application Programming Interfaces (APIs) or apps, but are new to applied Artificial Intelligence (AI) or are looking for a fast refresher. If you already train models weekly, treat this as a concise review. We’ll favour practical mental models, tiny examples, and “what to use when,” not formal proofs.

What to expect

• A clean map of AI → Machine Learning (ML) → Deep Learning (DL) with emphasis on what matters for shipping features.
• How models learn (supervised vs. unsupervised) explained in developer terms.
• Generative vs. discriminative models and when to pick each family.
• The must-do building blocks before training (data, features, evaluation).
• A short list of common models and where they shine.

AI, ML, and DL—what actually matters for developers

Think of AI as the umbrella term (anything that looks “intelligent”). Machine Learning (ML) is the set of methods that learn patterns from data. Deep Learning (DL) is a subset of ML that uses deep neural networks and tends to win when you have lots of unstructured data (images, audio, language) or scale.

• Modern products mostly use Artificial Narrow Intelligence (ANI), systems trained for a specific task (e.g., speech-to-text, recommendations).
• Artificial General Intelligence (AGI) and Artificial Superintelligence (ASI) are useful to know conceptually, but you won’t ship them this quarter. Focus on narrow, high-leverage tasks.

Developer’s take: Start with “What user problem? What data do we have?” Then pick the simplest method that can work. If your input is tabular and labelled, Deep Learning (DL) is rarely the first step.

How models learn: supervised vs. unsupervised (developer edition)

Supervised learning (labelled data)

You provide inputs plus correct outputs (labels). The model learns to predict the label from the input.

• Typical uses: fraud detection, churn prediction, spam filtering, price prediction.
• Minimum viable dataset: a table (features) and a target column.

Tiny example:

• Input: email text and metadata.
• Label: is_spam (0/1).
• Output: a classifier that flags future spam.

Ship‑it checklist: Split data (train/validation/test), pick metrics that match risk (precision/recall/F1-score for imbalanced problems), and watch for data leakage.

Unsupervised learning (no labels)

You only provide inputs; the model finds structure without explicit labels.

• Typical uses: customer segmentation, anomaly detection, topic discovery.
• Output: clusters or outlier scores you use to trigger workflows.

Developer’s take: Use unsupervised methods to understand or triage first (segments, anomalies), then bring in supervised learning once you establish useful labels.

Generative vs. discriminative models—choose by outcome

Discriminative models

These models separate classes or predict a continuous value. They are ideal for “is this X or not?” decisions or numeric predictions.

• Examples: Logistic Regression, Random Forest, Gradient Boosted Trees (e.g., XGBoost, LightGBM), Support Vector Machine (SVM), standard neural networks for classification/regression.
• Use when: you need reliable decisions, rankings, or scores.

Generative models

These models create data (text, images, audio) or model the underlying data distribution.

• Examples: Large Language Models (LLMs, e.g., GPT-style models), diffusion models, Variational Autoencoders (VAEs).
• Use when: you need content generation, summarisation, translation, code assistance, data augmentation, or you want zero/few-shot behaviour with prompts.

Developer’s take: If your output is a label or score, reach for discriminative first. If your output is content, go generative. When in doubt, prototype both: a classifier baseline versus an LLM prompt with guardrails.

Building blocks: what every AI developer must do

1) Data preprocessing

• Clean missing or invalid values, normalise formats and encode categorical variables.
• For time columns: extract useful fields (hour, day of week, month).

2) Feature engineering (for tabular problems)

• Turn raw fields into signals: ratios, rolling aggregates, and flags.
• Aim for features a human could defend in a design review.

3) Train/validation/test split and metrics

• Keep a hold‑out test set until the end.
• Choose metrics that reflect impact: balanced classes → accuracy; imbalanced classes → precision, recall, F1‑score; Receiver Operating Characteristic – Area Under the Curve (ROC‑AUC) and Precision‑Recall Area Under Curve (PR‑AUC); ranking/recommendations → Normalised Discounted Cumulative Gain (NDCG), Mean Average Precision (MAP), HitRate@K.

4) Overfitting control

• Traditional ML: regularisation, early stopping, cross‑validation.
• Deep Learning: dropout, weight decay, and data augmentation.
• Always compare to a simple baseline (e.g., majority class or linear model).

5) Evaluation that survives production

• Simulate data drift: train on older data, test on newer data.
• Record performance by segment (e.g., country, channel) to catch blind spots.

Developer’s take: A good evaluation plan beats a fancy model with a shaky test.

In case you missed it: How Enterprise APIs Bridge the Gap from Agent Conversation to Action

Common models (and when to use them)

• Linear Regression – Fast baseline for numeric prediction (e.g., prices, demand). Use when relationships are roughly linear and features are well engineered.
• Logistic Regression – Baseline binary classifier (e.g., fraud, churn, conversion). Use when you want interpretability and speed; start here before tree‑based methods.
• Decision Trees / Random Forests / Gradient Boosted Trees – Strong tabular learners with minimal preprocessing. Use when data are tabular, relationships are non‑linear, and you want quick wins.
• Support Vector Machine (SVM) – Works well on smaller, high‑dimensional datasets. Use when you need a strong margin classifier and scale is manageable.
• Convolutional Neural Networks (CNNs) – Best for images and video frames. Use when you need spatial understanding with consistent input sizes.
• Recurrent Neural Networks (RNNs) / Long Short‑Term Memory (LSTM) – Legacy sequence models; still useful in some time‑series niches.
• Transformers / Large Language Models (LLMs) – Handle text and code tasks, long‑range dependencies, and few‑shot learning. Use for generation, summarization, retrieval‑augmented question answering (QA), or flexible text interfaces.

Rule of thumb: For tabular data, try tree‑based models first. For language, start with a small prompt‑engineered LLM with guardrails and retrieval‑augmented generation (RAG), then consider fine‑tuning if return on investment (ROI) is clear.

Quick practical pathways

If you have labelled tabular data

1) Clean and encode data → 2) Train Gradient Boosted Trees → 3) Tune with cross‑validation → 4) Compare against Logistic Regression baseline → 5) Segment evaluation.

If you have text and no labels (yet)

1) Start with a Large Language Model (LLM) to prototype behaviour via prompts. 2) Add retrieval (RAG) for accuracy and grounding. 3) Log prompts/completions; label tricky cases; graduate to a small discriminative model if consistent labels emerge.

If you have unstructured images

1) Try a pretrained Convolutional Neural Network (CNN) or Vision Transformer (ViT) with transfer learning. 2) Freeze most layers and fine‑tune the final head on your data. 3) Augment images to reduce overfitting.

Common pitfalls (so you don’t hit them later)

• Mismatched metrics: optimising accuracy on a heavily imbalanced problem. Prefer precision, recall, and F1‑score.
• Data leakage: accidentally letting future information into training. Keep strict temporal splits for time‑dependent data.
• No baseline: always beat a simple model before celebrating.
• Ignoring drift: set up periodic re‑evaluation and monitoring from day one.

Putting it together

Start from the user problem and the data you actually have. Pick the simplest path that can work, choose metrics that reflect the real‑world cost of errors, and keep a clean test set until the end. You’ll ship faster, spend less, and earn the right to add complexity later.

Up next (Part 2): tools and deployment paths—from notebooks to Continuous Integration/Continuous Delivery (CI/CD) and lightweight Machine Learning Operations (MLOps).