Machine Learning Guide

Latest Episodes:

MLA 023 Inside a Coding Agent: Context, Instructions, Hooks, Skills, MCP Apr 13, 2025

Show notes

A coding agent is a loop appending to a context window, and the window is what runs out. Instruction files, permissions, hooks, skills, MCP, subagents and memory explained as one mechanism, mapped across Claude Code, Codex and OpenCode.

Links

Try a walking desk - stay healthy & sharp while you learn & code
More OCDevel shows - this one has siblings, each on its own subject and produced the same way

Second of three episodes on coding agents: how Claude Code, Codex, OpenCode and pi handle context, instruction files, permissions, hooks, skills, MCP, subagents and memory. Claude Code is the running example; each section maps the same concept to the other three.

The loop and why context is the scarce resource

A coding agent is a short program: send the conversation to the model, run whatever tool it asks for, append the result, repeat until the model answers with text alone. Every appended file and test log stays in the window for the life of the session, so the context window, not the model, is what runs out. Every mechanism below is a way of deciding what enters the window and when. Compaction summarizes the history when the window fills; Claude Code's auto-compact window and /compact are configurable, and /compact is itself an expensive request while /clear is free. Thinking is dialed by effort level in Claude Code and by model_reasoning_effort in the Codex configuration reference.

Instruction files: CLAUDE.md and AGENTS.md

AGENTS.md has become the cross-vendor instruction file, stewarded by the Agentic AI Foundation under the Linux Foundation and read by Codex, OpenCode, Cursor, Gemini CLI, GitHub Copilot, Jules, Aider, Zed and more. Claude Code reads only CLAUDE.md, bridged with an @AGENTS.md import; the Claude Code memory docs describe the managed, user, project and local layers, lazy subdirectory loading, @ imports up to four hops, path-scoped .claude/rules/, and re-injection after compaction. Codex's AGENTS.md guide walks from the git root down with a 32 KiB default cap; OpenCode rules read AGENTS.md with a CLAUDE.md fallback plus an instructions array in opencode.json; pi concatenates AGENTS.md from home, parents and cwd. What belongs: commands, conventions and boundaries the model cannot derive from the code, under a couple hundred lines. Instruction files are context, not enforcement.

Permissions and sandboxing

Claude Code permissions use Tool(pattern) rules with deny over ask over allow, and the docs list how allowlists leak: absolute paths, sh -c, and unstripped wrappers like devbox run. Permission modes are default, acceptEdits, plan, the classifier-backed auto mode, and bypassPermissions. Codex separates sandbox modes (read-only, workspace-write, danger-full-access) from an approval policy. OpenCode permissions map globs to allow, ask or deny with last-match-wins. pi ships no permission system by design. Claude Code sandboxing uses Seatbelt on macOS and bubblewrap on Linux, with filesystem and network-domain allowlists. The cautionary case is PocketOS, April 2026, where a Cursor agent found an unscoped hosting token and deleted the production volume and its backups in seconds, reported by The Register and Fast Company.

Hooks: deterministic guardrails at tool events

A hook runs a program at a fixed point in the loop and its exit code or JSON decides what happens next; unlike an instruction, it fires every time. Claude Code hooks cover more than thirty events; exit code 2 always blocks on blockable events, PreToolUse can stop a call, Stop can refuse to end a turn, PostToolUse cannot block. Codex hooks mirror the event set and require trusting each hook definition by hash. OpenCode plugins expose tool.execute.before, permission.asked and session events; Gemini CLI hooks and Copilot CLI hooks exist too. The three worth having: a PreToolUse block on destructive commands and secret files, a post-edit formatter and typecheck that feeds errors back, and a Stop hook that holds the turn open while tests are red.

Skills and slash commands

A skill is a folder with a SKILL.md whose name and description load at startup, whose body loads when a task matches, and whose bundled files load on demand. The format is the open Agent Skills standard, adopted by Codex, OpenCode, Cursor, Gemini CLI, GitHub Copilot and dozens more. Claude Code skills absorbed custom slash commands; frontmatter flags decide whether a skill is user-invoked, model-invoked or both, and side-effecting skills like deploy should be user-invoked only. A loaded skill body persists in the window, and load-time shell commands can splice live state into a procedure.

MCP: what it solves and what it costs

The Model Context Protocol standardizes tools, resources and prompts over JSON-RPC, via stdio or streamable HTTP with OAuth; Anthropic donated it to the Linux Foundation and the current revision adds stateless per-request negotiation, Tasks and MCP Apps extensions. Tool definitions traditionally loaded into context for every server every session. Anthropic's Code execution with MCP named the two costs and reported 150,000 tokens down to 2,000. The fix that shipped is deferred loading: Claude Code defers MCP tool definitions by default via tool search, also available at the API level; Codex MCP config offers per-server enabled_tools and disabled_tools; OpenCode MCP servers filter tools by glob with no lazy loading documented. Claude Code's cost guidance: prefer CLI tools over MCP servers, scope servers per project, disable what you have not used, and watch the 25,000-token output cap.

Subagents and worktrees as the answer to context rot

A subagent is a second loop with a fresh window; the parent sees only its result. Claude Code subagents are Markdown files with frontmatter for model, tools, permission mode, memory and worktree isolation, started without conversation history unless forked; agent teams add messaging between named teammates at roughly seven times the tokens of a plain session. Codex subagents are TOML files with developer instructions, model, effort and sandbox mode. OpenCode agents split into primary agents and @mention subagents, each with its own permission block. Recommended cast: a read-only scout on a cheap model, a fresh reviewer per diff, one writer per task. Claude Code worktrees create isolated checkouts with --worktree, EnterWorktree, subagent isolation: worktree, .worktreeinclude for gitignored files, and enforcement that blocks edits reaching back into the main checkout; Codex and OpenCode leave worktree management to git.

Memory across sessions

Memory is files. Claude Code auto memory is on by default: a per-repository directory shared across worktrees with a MEMORY.md index (first 200 lines loaded) and topic files read on demand, recording preferences, feedback and learned project facts. Codex memories are an opt-in local store controlled per session. OpenCode has no first-party memory beyond snapshots. Both vendors frame memory as a recall layer: rules that must always apply belong in the instruction file, prohibitions in hooks.

Concept map across tools

Instruction file: CLAUDE.md (Claude Code); AGENTS.md (Codex, OpenCode, pi, most others)
Permissions: modes and rules (Claude Code); sandbox mode plus approval policy (Codex); per-tool allow/ask/deny (OpenCode); none by design (pi)
Hooks: settings hooks (Claude Code); trusted hooks file (Codex); plugins (OpenCode); extensions (pi)
Skills: shared open format everywhere; slash commands folded in (Claude Code)
MCP: deferred by default (Claude Code); per-server tool filters (Codex); glob filters (OpenCode)
Subagents: Markdown (Claude Code, OpenCode); TOML (Codex)
Worktrees: first-party (Claude Code); do it yourself (Codex, OpenCode)
Memory: auto memory (Claude Code); memories (Codex); files or an MCP server (OpenCode)

Related episodes

The Gnothi companion show on Claude Code goes from a first change in the terminal to a repeatable delivery workflow: OCDevel Claude Code Podcast.

MLA 022 Vibe Coding: Codex vs Claude Code vs Antigravity vs Grok Feb 09, 2025

Show notes

What a coding agent actually is, and how Claude Code, OpenAI Codex, Google Antigravity and xAI's Grok Build differ in philosophy rather than features. Plus open harnesses pi and OpenCode, the open-weight coders, and a decision rule by constraint.

Links

Try a walking desk - stay healthy & sharp while you learn & code
More OCDevel shows - this one has siblings, each on its own subject and produced the same way

First of three episodes on vibe coding: the field of coding agents (Claude Code, OpenAI Codex, Google Antigravity, Grok Build, pi, OpenCode) as of late 2026 and how to choose one. The next two cover the mechanics (Inside a Coding Agent) and the engineering practice (Agentic Software Engineering).

Vibe coding then and now

Andrej Karpathy's February 2025 post named "vibe coding": accept all, don't read the diffs, paste errors back in, and, the caveat everyone dropped, "not too bad for throwaway weekend projects." Collins made it Word of the Year 2025. The arc since is autocomplete, then chat, then agents that read, edit, run and iterate; the engineers who stayed with it moved from vibing to agentic engineering, which is the through line for the sequence.

Anatomy of a coding agent

The model and the harness are separate things, and most tool arguments are about one without noticing which. The harness is the loop around the model, and there are five parts worth naming: the model, the tools (read, write, shell, search, browser), the permission model and sandbox, the context strategy (what to keep, summarize, offload to files, or hand to a fresh subagent), and the surface (terminal, IDE, desktop, web, chat). Ask those five questions of any product; they matter more than the feature grid. The mechanics get their own episode.

Claude Code: terminal-first and composable

Anthropic's stated design is Unix-style composability: pipe logs into it, run it in CI, chain it with other tools. The terminal is the primary surface; the IDE extension, desktop app, web and mobile clients all connect to the same engine and share CLAUDE.md, settings and MCP servers, with handoffs between local, cloud and desktop. Headless -p mode, GitHub Actions and GitLab integrations, and the Claude Agent SDK make it embeddable. Subagents and worktrees are its answer to the context problem. Model tiers (Sonnet, Opus, Fable) sit behind one harness with 1M-context variants and an effort dial; usage is included in Claude subscriptions or billed via the API.

OpenAI Codex: cloud-first and parallel

Codex CLI and Codex cloud are one product under one ChatGPT login, with an IDE extension and a desktop app; codex cloud pushes local work into a sandboxed cloud environment and applies the result back. OpenAI's framing is isolated environments, parallel tasks, and comparing multiple solution attempts, with tasks launchable from the web, GitHub, GitLab, Linear or Slack. Codex-tuned models are trained for long-running agentic work, and the newest generation keeps notes across context windows instead of repeatedly compressing a session. The CLI is Apache-2.0 open source; the Agents API brings the same harness to your own cloud agents.

Google Antigravity: the agent manager

Antigravity still ships under that name, and it absorbed Gemini CLI: Google retired Gemini CLI into Antigravity CLI in June 2026, and Antigravity 2.0 spans IDE, desktop app, CLI and SDK. The philosophy is supervision: "manage higher-level tasks for the Agent, not individual tool calls," with agents working across editor, terminal and browser and producing artifacts you review. The model menu is multi-vendor on consumer tiers (several Gemini tiers plus Claude Sonnet and Opus and GPT-OSS); enterprise is Gemini only.

Grok Build: the cost-first bet

xAI's coding story flipped in 2026 from a fast model in other people's harnesses (grok-code-fast-1, since deprecated from GitHub Copilot) to a first-party open-source terminal agent, Grok Build: interactive TUI, headless -p, Agent Client Protocol for editors, plan-review-approve, hooks, plugins, MCP and parallel subagents. xAI's own positioning for its coding model is fastest and cheapest for agentic coding; the premium model above it is the agent's default. Benchmark numbers and the subagent-count and price claims circulating in blogs are not on xAI's pages.

Open harnesses: pi and OpenCode

Both are open source, model-agnostic and very active, and they're opposites in philosophy. pi is a toolkit: small core, unified API over 15+ providers, TUI, print/RPC/SDK modes, TypeScript extensions, branchable sessions, a package system, and deliberately no built-in permission system (containerize instead; the author ships the Gondolin micro-VM). OpenCode is a product: TUI, web, desktop and IDE surfaces, a ~50-entry provider list including local runtimes, permission config, and the optional Zen gateway of verified models. OpenCode's docs note Anthropic prohibits driving Claude subscription models through third-party harnesses and those plugins were removed. Also: Crush, Kilo Code, Cline, and DeepSeek's own harness.

Special mentions: open-weight coders and the second tier

Every lab with a model now ships a harness. Qwen has a coder line, an Apache-licensed open series and the Qwen Code CLI. Z.ai's GLM is pitched as the most capable open-weights model for coding, sold as a Coding Plan documented for Claude Code, Cline and OpenCode. DeepSeek serves 1M-context models with an Anthropic-format endpoint, so Claude-shaped harnesses can point at it. Moonshot's Kimi K3 is a very large open-weight multimodal model under a bespoke license, with the Kimi Code CLI. All coding claims are vendor-reported, now headlining SWE-bench Pro and Terminal Bench rather than SWE-bench Verified. Second tier: Copilot coding agent (cloud, inside Actions), Cursor (editor-first, adding cloud agents and a coordinator), Windsurf (folded into Devin), Cline (active), Aider (no commits since May 2026).

Decision rule by constraint

Already paying a lab: take that lab's agent (Claude Code, Codex, Antigravity) and stop shopping. Cloud vs local: Codex cloud or Copilot's agent for sandboxed parallel PRs; a harness plus a local or self-hosted model if everything has to stay behind your firewall. Cost: Grok Build or an open harness with a cheap open-weight model for mechanical work. Open weights: pi or OpenCode with Qwen, GLM, DeepSeek or Kimi. Test on a real bug you already understand, and budget for a primary agent plus a cheaper second one.

Related episodes

Companion show: the Gnothi Claude Code series goes from your first terminal change to a repeatable delivery workflow.

MLG 033 Transformers Feb 09, 2025

Show notes

Links:

Notes and resources at ocdevel.com/mlg/33
3Blue1Brown videos: https://3blue1brown.com/
Try a walking desk stay healthy & sharp while you learn & code
Try Descript audio/video editing with AI power-tools

Background & Motivation

RNN Limitations: Sequential processing prevents full parallelization—even with attention tweaks—making them inefficient on modern hardware.
Breakthrough: "Attention Is All You Need" replaced recurrence with self-attention, unlocking massive parallelism and scalability.

Core Architecture

Layer Stack: Consists of alternating self-attention and feed-forward (MLP) layers, each wrapped in residual connections and layer normalization.
Positional Encodings: Since self-attention is permutation invariant, add sinusoidal or learned positional embeddings to inject sequence order.

Self-Attention Mechanism

Q, K, V Explained:
- Query (Q): The representation of the token seeking contextual info.
- Key (K): The representation of tokens being compared against.
- Value (V): The information to be aggregated based on the attention scores.
Multi-Head Attention: Splits Q, K, V into multiple "heads" to capture diverse relationships and nuances across different subspaces.
Dot-Product & Scaling: Computes similarity between Q and K (scaled to avoid large gradients), then applies softmax to weigh V accordingly.

Masking

Causal Masking: In autoregressive models, prevents a token from "seeing" future tokens, ensuring proper generation.
Padding Masks: Ignore padded (non-informative) parts of sequences to maintain meaningful attention distributions.

Feed-Forward Networks (MLPs)

Transformation & Storage: Post-attention MLPs apply non-linear transformations; many argue they're where the "facts" or learned knowledge really get stored.
Depth & Expressivity: Their layered nature deepens the model's capacity to represent complex patterns.

Residual Connections & Normalization

Residual Links: Crucial for gradient flow in deep architectures, preventing vanishing/exploding gradients.
Layer Normalization: Stabilizes training by normalizing across features, enhancing convergence.

Scalability & Efficiency Considerations

Parallelization Advantage: Entire architecture is designed to exploit modern parallel hardware, a huge win over RNNs.
Complexity Trade-offs: Self-attention's quadratic complexity with sequence length remains a challenge; spurred innovations like sparse or linearized attention.

Training Paradigms & Emergent Properties

Pretraining & Fine-Tuning: Massive self-supervised pretraining on diverse data, followed by task-specific fine-tuning, is the norm.
Emergent Behavior: With scale comes abilities like in-context learning and few-shot adaptation, aspects that are still being unpacked.

Interpretability & Knowledge Distribution

Distributed Representation: "Facts" aren't stored in a single layer but are embedded throughout both attention heads and MLP layers.
Debate on Attention: While some see attention weights as interpretable, a growing view is that real "knowledge" is diffused across the network's parameters.

MLA 021 Databricks: Cloud Analytics and MLOps Jun 22, 2022

Show notes

Databricks is a cloud-based platform for data analytics and machine learning operations, integrating features such as a hosted Spark cluster, Python notebook execution, Delta Lake for data management, and seamless IDE connectivity. Raybeam utilizes Databricks and other ML Ops tools according to client infrastructure, scaling needs, and project goals, favoring Databricks for its balanced feature set, ease of use, and support for both startups and enterprises.

Links

Notes and resources at ocdevel.com/mlg/mla-21
Try a walking desk stay healthy & sharp while you learn & code

Raybeam and Databricks

Raybeam is a data science and analytics company, recently acquired by Dept Agency.
While Raybeam focuses on data analytics, its acquisition has expanded its expertise into ML Ops and AI.
The company recommends tools based on client requirements, frequently utilizing Databricks for its comprehensive nature.

Understanding Databricks

Databricks is not merely an analytics platform; it is a competitor in the ML Ops space alongside tools like SageMaker and Kubeflow.
It provides interactive notebooks, Python code execution, and runs on a hosted Apache Spark cluster.
Databricks includes Delta Lake, which acts as a storage and data management layer.

Choosing the Right MLOps Tool

Raybeam evaluates each client's needs, existing expertise, and infrastructure before recommending a platform.
Databricks, SageMaker, Kubeflow, and Snowflake are common alternatives, with the final selection dependent on current pipelines and operational challenges.
Maintaining existing workflows is prioritized unless scalability or feature limitations necessitate migration.

Databricks Features

Databricks is accessible via a web interface similar to Jupyter Hub and can be integrated with local IDEs (e.g., VS Code, PyCharm) using Databricks Connect.
Notebooks on Databricks can be version-controlled with Git repositories, enhancing collaboration and preventing data loss.
The platform supports configuration of computing resources to match model size and complexity.
Databricks clusters are hosted on AWS, Azure, or GCP, with users selecting the underlying cloud provider at sign-up.

Parquet and Delta Lake

Parquet files store data in a columnar format, which improves efficiency for aggregation and analytics tasks.
Delta Lake provides transactional operations on top of Parquet files by maintaining a version history, enabling row edits and deletions.
This approach offers a database-like experience for handling large datasets, simplifying both analytics and machine learning workflows.

Pricing and Usage

Pricing for Databricks depends on the chosen cloud provider (AWS, Azure, or GCP) with an additional fee for Databricks' services.
The added cost is described as relatively small, and the platform is accessible to both individual developers and large enterprises.
Databricks is recommended for newcomers to data science and ML for its breadth of features and straightforward setup.

Databricks, MLflow, and Other Integrations

Databricks provides a hosted MLflow solution, offering experiment tracking and model management.
The platform can access data stored in services like S3, Snowflake, and other cloud provider storage options.
Integration with tools such as PyArrow is supported, facilitating efficient data access and manipulation.

Example Use Cases and Decision Process

Migration to Databricks is recommended when a client's existing infrastructure (e.g., on-premises Spark clusters) cannot scale effectively.
The selection process involves an in-depth exploration of a client's operational challenges and goals.
Databricks is chosen for clients lacking feature-specific needs but requiring a unified data analytics and ML platform.

Personal Projects by Ming Chang

Ming Chang has explored automated stock trading using APIs such as Alpaca, focusing on downloading and analyzing market data.
He has also developed drone-related projects with Raspberry Pi, emphasizing real-world applications of programming and physical computing.

Additional Resources

MLA 020 Kubeflow and ML Pipeline Orchestration on Kubernetes Jan 29, 2022

Show notes

Machine learning pipeline orchestration tools, such as SageMaker and Kubeflow, streamline the end-to-end process of data ingestion, model training, deployment, and monitoring, with Kubeflow providing an open-source, cross-cloud platform built atop Kubernetes. Organizations typically choose between cloud-native managed services and open-source solutions based on required flexibility, scalability, integration with existing cloud environments, and vendor lock-in considerations.

Links

Notes and resources at ocdevel.com/mlg/mla-20
Try a walking desk stay healthy & sharp while you learn & code

Dirk-Jan Verdoorn - Data Scientist at Dept Agency

Managed vs. Open-Source ML Pipeline Orchestration

Cloud providers such as AWS, Google Cloud, and Azure offer managed machine learning orchestration solutions, including SageMaker (AWS) and Vertex AI (GCP).
Managed services provide integrated environments that are easier to set up and operate but often result in vendor lock-in, limiting portability across cloud platforms.
Open-source tools like Kubeflow extend Kubernetes to support end-to-end machine learning pipelines, enabling portability across AWS, GCP, Azure, or on-premises environments.

Introduction to Kubeflow

Kubeflow is an open-source project aimed at making machine learning workflow deployment on Kubernetes simple, portable, and scalable.
Kubeflow enables data scientists and ML engineers to build, orchestrate, and monitor pipelines using popular frameworks such as TensorFlow, scikit-learn, and PyTorch.
Kubeflow can integrate with TensorFlow Extended (TFX) for complete end-to-end ML pipelines, covering data ingestion, preprocessing, model training, evaluation, and deployment.

Machine Learning Pipelines: Concepts and Motivation

Production machine learning systems involve not just model training but also complex pipelines for data ingestion, feature engineering, validation, retraining, and monitoring.
Pipelines automate retraining based on model performance drift or updated data, supporting continuous improvement and adaptation to changing data patterns.
Scalable, orchestrated pipelines reduce manual overhead, improve reproducibility, and ensure that models remain accurate as underlying business conditions evolve.

Pipeline Orchestration Analogies and Advantages

ML pipeline orchestration tools in machine learning fulfill a role similar to continuous integration and continuous deployment (CI/CD) in traditional software engineering.
Pipelines enable automated retraining, modularization of pipeline steps (such as ingestion, feature transformation, and deployment), and robust monitoring.
Adopting pipeline orchestrators, rather than maintaining standalone models, helps organizations handle multiple models and varied business use cases efficiently.

Choosing Between Managed and Open-Source Solutions

Managed services (e.g., SageMaker, Vertex AI) offer streamlined user experiences and seamless integration but restrict cross-cloud flexibility.
Kubeflow, as an open-source platform on Kubernetes, enables cross-platform deployment, integration with multiple ML frameworks, and minimizes dependency on a single cloud provider.
The complexity of Kubernetes and Kubeflow setup is offset by significant flexibility and community-driven improvements.

Cross-Cloud and Local Development

Kubeflow operates on any Kubernetes environment including AWS EKS, GCP GKE, and Azure AKS, as well as on-premises or local clusters.
Local and cross-cloud development are facilitated in Kubeflow, while managed services like SageMaker and Vertex AI are better suited to cloud-native workflows.
Debugging and development workflows can be challenging in highly secured cloud environments; Kubeflow's local deployment flexibility addresses these hurdles.

Relationship to TensorFlow Extended (TFX) and Machine Learning Frameworks

TensorFlow Extended (TFX) is an end-to-end platform for creating production ML pipelines, tightly integrated with Kubeflow for deployment and execution.
While Kubeflow originally focused on TensorFlow, it has grown to support PyTorch, scikit-learn, and other major ML frameworks, offering wider applicability.
TFX provides modular pipeline components (data ingestion, transformation, validation, model training, evaluation, and deployment) that execute within Kubeflow's orchestration platform.

Alternative Pipeline Orchestration Tools

Airflow is a general-purpose workflow orchestrator using DAGs, suited for data engineering and automation, but less resource-capable for heavy ML training within the pipeline.
- Airflow often submits jobs to external compute resources (e.g., AI Platform) for resource-intensive workloads.
- In organizations using both Kubeflow and Airflow, Airflow may handle data workflows, while Kubeflow is reserved for ML pipelines.
MLflow and other solutions also exist, each with unique integrations and strengths; their adoption depends on use case requirements.

Selecting a Cloud Platform and Orchestration Approach

The optimal choice of cloud platform and orchestration tool is typically guided by client needs, existing integrations (e.g., organizational use of Google or Microsoft solutions), and team expertise.
Agencies with diverse client portfolios often benefit from open-source, cross-cloud tools like Kubeflow to maximize flexibility and knowledge sharing across projects.
Users entrenched in a single cloud provider may prefer managed offerings for ease of use and integration, while those prioritizing portability and flexibility often choose open-source solutions.

Cost Optimization in Model Training

Both AWS and GCP offer cost-saving compute options for training, such as spot instances (AWS) and preemptible instances (GCP), which are suitable for non-production, batch training jobs.
Production workloads that require high uptime and reliability do not typically utilize cost-saving transient compute resources, as these can be interrupted.

Machine Learning Project Lifecycle Overview

Project initiation begins with data discovery and validation of the client's requirements against available data.
Cloud environment selection is influenced by client infrastructure, business applications, and platform integrations rather than solely by technical features.
Data cleaning, exploratory analysis, model prototyping, advanced model refinement, and deployment are handled collaboratively with data engineering and machine learning teams.
The pipeline is gradually constructed in modular steps, facilitating scalable, automated retraining and integration with business applications.

Educational Pathways for Data Science and Machine Learning Careers

Advanced mathematics or statistics education provides a strong foundation for work in data science and machine learning.
Master's degrees in data science add the most value for candidates from non-technical undergraduate backgrounds; those with backgrounds in statistics, mathematics, or computer science may benefit more from self-study or targeted upskilling.
When evaluating online or accelerated degree programs, candidates should scrutinize the curriculum, instructor engagement, and peer interaction to ensure comprehensive learning.

MLA 019 Cloud, DevOps & Architecture Jan 13, 2022

Show notes

The deployment of machine learning models for real-world use involves a sequence of cloud services and architectural choices, where machine learning expertise must be complemented by DevOps and architecture skills, often requiring collaboration with professionals. Key concepts discussed include infrastructure as code, cloud container orchestration, and the distinction between DevOps and architecture, as well as practical advice for machine learning engineers wanting to deploy products securely and efficiently.

Links

Notes and resources at ocdevel.com/mlg/mla-19
Try a walking desk stay healthy & sharp while you learn & code

;## Translating Machine Learning Models to Production

After developing and training a machine learning model locally or using cloud tools like AWS SageMaker, it must be deployed to reach end users.
A typical deployment stack involves the trained model exposed via a SageMaker endpoint, a backend server (e.g., Python FastAPI on AWS ECS with Fargate), a managed database (such as AWS RDS Postgres), an application load balancer (ALB), and a public-facing frontend (e.g., React app hosted on S3 with CloudFront and Route 53).

Infrastructure as Code and Automation Tools

Infrastructure as code (IaC) manages deployment and maintenance of cloud resources using tools like Terraform, allowing environments to be version-controlled and reproducible.
Terraform is favored for its structured approach and cross-cloud compatibility, while other tools like Cloud Formation (AWS-specific) and Pulumi offer alternative paradigms.
Configuration management tools such as Ansible, Chef, and Puppet automate setup and software installation on compute instances but are increasingly replaced by containerization and Dockerfiles.
Continuous Integration and Continuous Deployment (CI/CD) pipelines (with tools like AWS CodePipeline or CircleCI) automate builds, testing, and code deployment to infrastructure.

Containers, Orchestration, and Cloud Choices

Containers, enabled by Docker, allow developers to encapsulate applications and dependencies, facilitating consistency across environments from local development to production.
Deployment options include AWS ECS/Fargate for managed orchestration, Kubernetes for large-scale or multi-cloud scenarios, and simpler services like AWS App Runner and Elastic Beanstalk for small-scale applications.
Kubernetes provides robust flexibility and cross-provider support but brings high complexity, making it best suited for organizations with substantial infrastructure needs and experienced staff.
Use of cloud services versus open-source alternatives on Kubernetes (e.g., RDS vs. Postgres containers) affects manageability, vendor lock-in, and required expertise.

DevOps and Architecture: Roles and Collaboration

DevOps unites development and operations through common processes and tooling to accelerate safe production deployments and improve coordination.
Architecture focuses on the holistic design of systems, establishing how different technical components fit together and serve overall business or product goals.
There is significant overlap, but architecture plans and outlines systems, while DevOps engineers implement, automate, and monitor deployment and operations.
Cross-functional collaboration is essential, as machine learning engineers, DevOps, and architects must communicate requirements, constraints, and changes, especially regarding production-readiness and security.

Security, Scale, and When to Seek Help

Security is a primary concern when moving to production, especially if handling sensitive data or personally identifiable information (PII); professional DevOps involvement is strongly advised in such cases.
Common cloud security pitfalls include publicly accessible networks, insecure S3 buckets, and improper handling of secrets and credentials.
For experimentation or small-scale safe projects, machine learning engineers can use tools like Terraform, Docker, and AWS managed services, but should employ cloud cost monitoring to avoid unexpected bills.

Cloud Providers and Service Considerations

AWS dominates the cloud market, followed by Azure (strong in enterprise/Microsoft-integrated environments) and Google Cloud Platform (GCP), which offers a strong user interface but has a record of sunsetting products.
Managed cloud machine learning services, such as AWS SageMaker and GCP Vertex AI, streamline model training, deployment, and monitoring.
Vendor-specific tools simplify management but limit portability, while Kubernetes and its ML pipelines (e.g., Kubeflow, Apache Airflow) provide open-source, cross-cloud options with greater complexity.

Recommended Learning Paths and Community Resources

Learning and prototyping with Terraform, Docker, and basic cloud services is encouraged to understand deployment pipelines, but professional security review is critical before handling production-sensitive data.
For those entering DevOps, structured learning with platforms like aCloudGuru or AWS's own curricula can provide certification-ready paths.
Continual learning is necessary, as tooling and best practices evolve rapidly.

Reference Links

Expert coworkers at Dept

Matt Merrill - Principal Software Developer
Jirawat Uttayaya - DevOps Lead
The Ship It Podcast (frequent discussions on DevOps and architecture)

DevOps Tools

Visual Guides and Comparisons

Learning Resources

aCloudGuru AWS curriculum

MLA 017 AWS Local Development Environment Nov 06, 2021

Show notes

AWS development environments for local and cloud deployment can differ significantly, leading to extra complexity and setup during cloud migration. By developing directly within AWS environments, using tools such as Lambda, Cloud9, SageMaker Studio, client VPN connections, or LocalStack, developers can streamline transitions to production and leverage AWS-managed services from the start. This episode outlines three primary strategies for treating AWS as your development environment, details the benefits and tradeoffs of each, and explains the role of infrastructure-as-code tools such as Terraform and CDK in maintaining replicable, trackable cloud infrastructure.

Links

Notes and resources at ocdevel.com/mlg/mla-17
Try a walking desk stay healthy & sharp while you learn & code

Docker Fundamentals for Development

Docker containers encapsulate operating systems, packages, and code, which simplifies dependency management and deployment.
Files are added to containers using either the COPY command for one-time inclusion during a build or the volume directive for live synchronization during development.
Docker Compose orchestrates multiple containers on a local environment, while Kubernetes is used at larger scale for container orchestration in the cloud.

Docker and AWS Integration

Docker is frequently used in AWS, including for packaging and deploying Lambda functions, SageMaker jobs, and ECS/Fargate containers.
Deploying complex applications like web servers and databases on AWS involves using services such as ECR for image storage, ECS/Fargate for container management, RDS for databases, and requires configuration of networking components such as VPCs, subnets, and security groups.

Challenges in Migrating from Localhost to AWS

Local Docker Compose setups differ considerably from AWS managed services architecture.
Migrating to AWS involves extra steps such as pushing images to ECR, establishing networking with VPCs, configuring load balancers or API Gateway, setting up domain names with Route 53, and integrating SSL certificates via ACM.
Configuring internal communication between services and securing databases adds complexity compared to local development.

Strategy 1: Developing Entirely in the AWS Cloud

Developers can use AWS Lambda's built-in code editor, Cloud9 IDE, and SageMaker Studio to edit, run, and deploy code directly in the AWS console.
Cloud-based development is not tied to a single machine and eliminates local environment setup.
While convenient, in-browser IDEs like Cloud9 and SageMaker Studio are less powerful than established local tools like PyCharm or DataGrip.

Strategy 2: Local Development Connected to AWS via Client VPN

The AWS Client VPN enables local machines to securely access AWS VPC resources, such as RDS databases or Lambda endpoints, as if they were on the same network.
This approach allows developers to continue using their preferred local IDEs while testing code against actual cloud services.
Storing sensitive credentials is handled by AWS Secrets Manager instead of local files or environment variables.
Example tutorials and instructions:

Strategy 3: Local Emulation of AWS Using LocalStack

LocalStack provides local, Docker-based emulation of AWS services, allowing development and testing without incurring cloud costs or latency.
The project offers a free tier supporting core serverless services and a paid tier covering more advanced features like RDS, ACM, and Route 53.
LocalStack supports mounting local source files into Lambda functions, enabling direct development on the local machine with changes immediately reflected in the emulated AWS environment.
This approach brings rapid iteration and cost savings, but coverage of AWS features may vary, especially for advanced or new AWS services.

Infrastructure as Code: Managing AWS Environments

Managing AWS resources through the web console is not sustainable for tracking or reproducing environments.
Infrastructure as code (IaC) tools such as Terraform, AWS CDK, and Serverless enable declarative, version-controlled description and deployment of AWS services.
Terraform offers broad multi-cloud compatibility and support for both managed and cloud-native services, whereas CDK is AWS-specific and typically more streamlined but supports fewer services.
Changes made via IaC tools are automatically propagated to dependent resources, reducing manual error and ensuring consistency across environments.

Benefits of AWS-First Development

Developing directly in AWS or with local emulation ensures alignment between development, staging, and production environments, reducing last-minute deployment issues.
Early use of AWS services can reveal managed solutions—such as Cognito for authentication or Data Wrangler for feature transformation—that are more scalable and secure than homegrown implementations.
Infrastructure as code provides reproducibility, easier team onboarding, and disaster recovery.

Alternatives and Kubernetes

Kubernetes represents a different model of orchestrating containers and services, generally leveraging open source components inside Docker containers, independent of managed AWS services.
While Kubernetes can manage deployments to AWS (via EKS), GCP, or Azure, its architecture and operational concerns differ from AWS-native development patterns.

Additional AWS IDEs and Services

Conclusion

Choosing between developing in the AWS cloud, connecting local environments via VPN, or using tools like LocalStack depends on team needs, budget, and workflow preferences.
Emphasizing infrastructure as code ensures environments remain consistent, maintainable, and easily reproducible.

MLA 016 AWS SageMaker MLOps 2 Nov 05, 2021

Show notes

SageMaker streamlines machine learning workflows by enabling integrated model training, tuning, deployment, monitoring, and pipeline automation within the AWS ecosystem, offering scalable compute options and flexible development environments. Cloud-native AWS machine learning services such as Comprehend and Poly provide off-the-shelf solutions for NLP, time series, recommendations, and more, reducing the need for custom model implementation and deployment.

Links

Notes and resources at ocdevel.com/mlg/mla-16
Try a walking desk stay healthy & sharp while you learn & code

Model Training and Tuning with SageMaker

SageMaker enables model training within integrated data and ML pipelines, drawing from components such as Data Wrangler and Feature Store for a seamless workflow.
Using SageMaker for training eliminates the need for manual transitions from local environments to the cloud, as models remain deployable within the AWS stack.
SageMaker Studio offers a browser-based IDE environment with iPython notebook support, providing collaborative editing, sharing, and development without the need for complex local setup.
Distributed, parallel training is supported with scalable EC2 instances, including AWS-proprietary chips for optimized model training and inference.
SageMaker's Model Debugger and monitoring tools aid in tracking performance metrics, model drift, and bias, offering alerts via CloudWatch and accessible graphical interfaces.

Flexible Development and Training Environments

SageMaker supports various model creation approaches, including default AWS environments with pre-installed data science libraries, bring-your-own Docker containers, and hybrid customizations via requirements files.
SageMaker JumpStart provides quick-start options for common ML tasks, such as computer vision or NLP, with curated pre-trained models and environment setups optimized for SageMaker hardware and operations.
Users can leverage Autopilot for end-to-end model training and deployment with minimal manual configuration or start from JumpStart templates to streamline typical workflows.

Hyperparameter Optimization and Experimentation

SageMaker Experiments supports automated hyperparameter search and optimization, using Bayesian optimization to evaluate and select the best performing configurations.
Experiments and training runs are tracked, logged, and stored for future reference, allowing efficient continuation of experimentation and reuse of successful configurations as new data is incorporated.

Model Deployment and Inference Options

Trained models can be deployed as scalable REST endpoints, where users specify required EC2 instance types, including inference-optimized chips.
Elastic Inference allows attachment of specialized hardware to reduce costs and tailor inference environments.
Batch Transform is available for non-continuous, ad-hoc, or large batch inference jobs, enabling on-demand scaling and integration with data pipelines or serverless orchestration.

ML Pipelines, CI/CD, and Monitoring

SageMaker Pipelines manages the orchestration of ML workflows, supporting CI/CD by triggering retraining and deployments based on code changes or new data arrivals.
CI/CD automation includes not only code unit tests but also automated monitoring of metrics such as accuracy, drift, and bias thresholds to qualify models for deployment.
Monitoring features (like Model Monitor) provide ongoing performance assessments, alerting stakeholders to significant changes or issues.

Integrations and Deployment Flexibility

SageMaker supports integration with Kubernetes via EKS, allowing teams to leverage universal orchestration for containerized ML workloads across cloud providers or hybrid environments.
The SageMaker Neo service optimizes and packages trained models for deployment to edge devices, mobile hardware, and AWS Lambda, reducing runtime footprint and syncing updates as new models become available.

Cloud-Native AWS ML Services

AWS offers a variety of cloud-native services for common ML tasks, accessible via REST or SDK calls and managed by AWS, eliminating custom model development and operations overhead.
- Comprehend for document clustering, sentiment analysis, and other NLP tasks.
- Forecast for time series prediction.
- Fraud Detector for transaction monitoring.
- Lex for chatbot workflows.
- Personalize for recommendation systems.
- Poly for text-to-speech conversion.
- Textract for OCR and data extraction from complex documents.
- Translate for machine translation.
- Panorama for computer vision on edge devices.
These services continuously improve as AWS retrains and updates their underlying models, transferring benefits directly to customers without manual intervention.

Application Example: Migrating to SageMaker and AWS Services

When building features such as document clustering, question answering, or recommendations, first review whether cloud-native services like Comprehend can fulfill requirements prior to investing in custom ML models.
For custom NLP tasks not available in AWS services, use SageMaker to manage model deployment (e.g., deploying pre-trained Hugging Face Transformers for summarization or embeddings).
Batch inference and feature extraction jobs can be triggered using SageMaker automation and event notifications, supporting modular, scalable, and microservices-friendly architectures.
Tabular prediction and feature importance can be handled by pipe-lining data from relational stores through SageMaker Autopilot or traditional algorithms such as XGBoost.
Recommendation workflows can combine embeddings, neural networks, and event triggers, with SageMaker handling monitoring, scaling, and retraining in response to user feedback and data drift.

General Usage Guidance and Strategy

Employ AWS cloud-native services where possible to minimize infrastructure management and accelerate feature delivery.
Use SageMaker JumpStart and Autopilot to jump ahead in common ML scenarios, falling back to custom code and containers only when unique use cases demand.
Leverage SageMaker tools for pipeline orchestration, monitoring, retraining, and model deployment to ensure scalable, maintainable, and up-to-date ML workflows.

Useful Links

MLA 015 AWS SageMaker MLOps 1 Nov 04, 2021

Show notes

SageMaker is an end-to-end machine learning platform on AWS that covers every stage of the ML lifecycle, including data ingestion, preparation, training, deployment, monitoring, and bias detection. The platform offers integrated tools such as Data Wrangler, Feature Store, Ground Truth, Clarify, Autopilot, and distributed training to enable scalable, automated, and accessible machine learning operations for both tabular and large data sets.

Links

Notes and resources at ocdevel.com/mlg/mla-15
Try a walking desk stay healthy & sharp while you learn & code

Amazon SageMaker: The Machine Learning Operations Platform

MLOps is deploying your ML models to the cloud. See MadeWithML for an overview of tooling (also generally a great ML educational run-down.)

Introduction to SageMaker and MLOps

SageMaker is a comprehensive platform offered by AWS for machine learning operations (MLOps), allowing full lifecycle management of machine learning models.
Its popularity provides access to extensive resources, educational materials, community support, and job market presence, amplifying adoption and feature availability.
SageMaker can replace traditional local development environments, such as setups using Docker, by moving data processing and model training to the cloud.

Data Preparation in SageMaker

SageMaker manages diverse data ingestion sources such as CSV, TSV, Parquet files, databases like RDS, and large-scale streaming data via AWS Kinesis Firehose.
The platform introduces the concept of data lakes, which aggregate multiple related data sources for big data workloads.
Data Wrangler is the entry point for data preparation, enabling ingestion, feature engineering, imputation of missing values, categorical encoding, and principal component analysis, all within an interactive graphical user interface.
Data wrangler leverages distributed computing frameworks like Apache Spark to process large volumes of data efficiently.
Visualization tools are integrated for exploratory data analysis, offering table-based and graphical insights typically found in specialized tools such as Tableau.

Feature Store

Feature Store acts as a centralized repository to save and manage transformed features created during data preprocessing, ensuring different steps in the pipeline access consistent, reusable feature sets.
It facilitates collaboration by making preprocessed features available to various members of a data science team and across different models.

Ground Truth: Data Labeling

Ground Truth provides automated and manual data labeling options, including outsourcing to Amazon Mechanical Turk or assigning tasks to internal employees via a secure AWS GUI.
The system ensures quality by averaging multiple annotators' labels and upweighting reliable workers, and can also perform automated label inference when partial labels exist.
This flexibility addresses both sensitive and high-volume labeling requirements.

Clarify: Bias Detection

Clarify identifies and analyzes bias in both datasets and trained models, offering measurement and reporting tools to improve fairness and compliance.
It integrates seamlessly with other SageMaker components for continuous monitoring and re-calibration in production deployments.

Build Phase: Model Training and AutoML

SageMaker Studio offers a web-based integrated development environment to manage all aspects of the pipeline visually.
Autopilot automates the selection, training, and hyperparameter optimization of machine learning models for tabular data, producing an optimal model and optionally creating reproducible code notebooks.
Users can take over the automated pipeline at any stage to customize or extend the process if needed.

Debugger and Distributed Training

Debugger provides real-time training monitoring, similar to TensorBoard, and offers notifications for anomalies such as vanishing or exploding gradients by integrating with AWS CloudWatch.
SageMaker's distributed training feature enables users to train models across multiple compute instances, optimizing for hardware utilization, cost, and training speed.
The system allows for sharding of data and auto-scaling based on resource utilization monitored via CloudWatch notifications.

Summary Workflow and Scalability

The SageMaker pipeline covers every aspect of machine learning workflows, from ingestion, cleaning, and feature engineering, to training, deployment, bias monitoring, and distributed computation.
Each tool is integrated to provide either no-code, low-code, or fully customizable code interfaces.
The platform supports scaling from small experiments to enterprise-level big data solutions.

Useful AWS and SageMaker Resources

MLA 014 Hosting and Deploying ML: Managed APIs, Serverless GPUs, Self-Hosting Jan 18, 2021

Show notes

Where the model behind your product should run in 2026: managed APIs vs open weights, AWS native vs Modal, RunPod and Cloud Run GPU, vLLM and SGLang, quantized CPU inference on Spot, batch pricing, prod evals, and infra as code. Links Try a walking desk - stay healthy & sharp while you learn & code More OCDevel shows - this one has siblings, each on its own subject and produced the same way The infrastructure episode, standalone: where the model behind your product runs in 2026, and what each choice costs. Managed APIs versus self-hosted open weights, AWS native (Bedrock, SageMaker) versus serverless GPU platforms (Modal, RunPod, Cloud Run GPU) versus bare GPUs, the inference servers (vLLM, SGLang, llama.cpp), quantized CPU inference on Spot, queues and batch pricing, observability and evals, and a minute on infrastructure as code. The coding-agent workflow is covered in Vibe Coding in 2026 through Agentic Software Engineering; agent architecture in AI Agents in 2026. Calling a model vs running one The default for a product builder is a managed API: cost is linear in usage with no floor, while a self-hosted GPU costs the same idle as busy. Four things flip the default: sustained volume, privacy or data residency, a strict latency shape, or a model only available as open weights. Move one workload when a flip applies, not the whole stack. The cloud-hosted middle path: Amazon Bedrock's model catalog now spans Anthropic, OpenAI (including the open-weight gpt-oss models), Meta Llama, Mistral, DeepSeek, Qwen and more, and Custom Model Import serves your own safetensors weights on demand with no instance to manage. The framing on rent vs own is still a16z's "Navigating the High Cost of AI Compute": renting wins for almost everyone; owning pays only at large steady spend. AWS native Lambda and Fargate still have no GPUs; the Lambda quotas page has no accelerator dimension and the Fargate FAQ sends GPU work to EC2. Lambda offers 10 GB memory, 15-minute timeouts, 10 GB container images, and SnapStart for Python. SageMaker AI: real-time endpoints scale to zero only via inference components; asynchronous inference queues S3 payloads up to 1 GB and scales to zero; serverless inference is CPU-only; batch transform for offline scoring. AWS Batch GPU jobs on Spot compute environments are the cheapest bursty GPU on AWS, with no scheduler surcharge. Aurora PostgreSQL ships pgvector 0.8.2 with HNSW, and Aurora Serverless v2 auto-pause drops compute to zero when idle. Bedrock Knowledge Bases can use that Aurora as its store. Aurora DSQL has no extensions, so no pgvector. Serverless GPU platforms The category: ship a container or function, pay per GPU-second, scale to zero. Differentiators are cold start and warm-pool control. Modal: Python-native, per-second billing, T4 through B300; cold starts around a second with memory snapshots and minimum-container knobs; batch via Function.map. RunPod Serverless: queue-based or load-balanced endpoints, FlashBoot, async run and webhooks, wide GPU list from economy cards to B200. Cloud Run GPU: GA, NVIDIA L4 and RTX PRO 6000 Blackwell, scales to zero, instance-based billing required. Baseten with the open-source Truss packager: operated production deployments for custom models. Replicate joined Cloudflare in November 2025; Cloudflare Workers AI remains a curated open-model catalog, not a bring-your-own-weights host. fal: generative media inference first, serverless GPUs on the side. Status changes: Lambda's inference API is winding down in favor of GPU instances; Fly.io's GPU Machines appear withdrawn (docs removed, no GPU line on pricing). Bare GPUs, neoclouds, and Spot Hyperscaler families: AWS P6, Google Cloud GPUs, Azure ND/NC sizes. Neoclouds: CoreWeave, Nebius, Lambda, Crusoe; Vast.ai as a marketplace with interruptible pricing. A reserved box beats serverless when the GPU is busy most of the hour. EC2 Spot advertises up to 90 percent off on-demand, with a two-minute interruption notice. The discount is paid for with checkpointing, retry-on-reclaim, and instance-pool diversity using the SPOT_PRICE_CAPACITY_OPTIMIZED allocation strategy AWS recommends. Inference servers vLLM: PagedAttention, continuous batching, OpenAI- and Anthropic-compatible server, V1 engine, now under the PyTorch Foundation. SGLang: RadixAttention prefix reuse, releases every two weeks, production use at xAI, NVIDIA, Cursor and the major clouds. Hugging Face TGI was archived in March 2026; its notice points to vLLM and SGLang. TensorRT-LLM for NVIDIA-only maximum throughput; NVIDIA Dynamo orchestrates disaggregated prefill/decode across engines. llama.cpp for GGUF on CPUs, Apple Silicon and ARM with KleidiAI; Ollama now runs its own engine on GGML for multimodal models. Also: Triton Inference Server for non-LLM models, Ray Serve for composition, OpenLLM, LMDeploy, MLC-LLM. Quantization for CPU inference Quantized weights cut memory and, since batch-1 decode is memory-bandwidth bound, cut time per token; integer matrix instructions (ARM dot-product and MMLA, Intel VNNI) do the multiplies. GGUF quant naming: bits per weight, k-quant mixed precision, size variant; Q4_K_M takes Llama 3.1 8B from about 32 GB to about 5 GB. AWS Graviton guide for llama.cpp recommends Graviton3 and later for their BF16 and MMLA instructions and publishes a prebuilt llama-server container. vLLM's CPU backend covers x86 AVX512 and ARM. ONNX Runtime quantization for classic models, with the caveat that gains need VNNI or ARM dot-product hardware. Practice described in the episode: a quantized Qwen3-TTS model served by a C port on Graviton Spot instances via AWS Batch, checkpointing chunks to S3. Queues, batch, and real-time If no human waits, queue it: SQS with Lambda needs idempotency and partial-batch failure reporting; SageMaker async, Modal map, and RunPod async run are the same shape. Batch pricing is 50 percent off across OpenAI Batch, Anthropic Message Batches, and Bedrock batch inference, with separate rate limits and a 24-hour window. Bedrock prompt caching bills cache reads at a large discount within a short TTL; put stable prefix content first. Real-time paths need warm containers ("scale to zero" becomes "scale to one"), continuous batching, and streaming. Observability and evals in prod Trace every call with prompt, response, tokens, latency, cost. The OpenTelemetry GenAI conventions moved to their own repo; OpenLLMetry emits them. Tools: Langfuse (open source, part of ClickHouse since January 2026), Arize Phoenix (Elastic License), LangSmith, W&B Weave, Braintrust, Helicone as a proxy. Production evals score sampled traces with a judge model: Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena found over 80 percent agreement with humans and named position, verbosity and self-enhancement bias. Classic drift: Evidently covers tabular drift and LLM metrics; WhyLabs ceased operations but open-sourced whylogs and langkit. Infrastructure as code SST runs on Pulumi with Terraform providers bridged; Pulumi for languages without SST's web opinions; Terraform under BSL since 2023 with OpenTofu as the open fork. Keep ML infra in the product's repo and deploy. Shout-outs Fast custom silicon APIs: Groq, Cerebras. Open-model inference clouds: Together AI, Fireworks, DeepInfra. Aggregators: OpenRouter, Hugging Face Inference Providers; dedicated Inference Endpoints. AWS Trainium. SageMaker JumpStart delisted models in March 2026, so pin weights in your own bucket. Related episodes MLA 22: Vibe Coding in 2026 MLA 23: Inside a Coding Agent MLA 24: Agentic Software Engineering MLA 28: AI Agents in 2026 MLA 29: OpenClaw and the Personal Agent More Gnothi-generated shows on AI, coding, video and business: ocdevel.com/moremlg.

Full show notes at the publisher

Our TOPPODCAST Picks

Follow Us

Stay Connected

Related Podcasts

Links

Stay Connected