Skip to content
All categories

tech

529 posts

Neural Networks — Backpropagation, TensorFlow/Keras, CNN & Traffic Sign Classification | Harvard CS50 AI Week 5

Week 5 is about neural networks: a unit multiplies its inputs by weights, adds a bias and applies an activation function; gradient descent adjusts the weights one small step at a time, and backpropagation passes the error back so hidden layers can be trained; for images, convolution and pooling come first and an ordinary network follows, which is a CNN; for sequences, an RNN feeds its output back into itself. With time links for every section, plus the approach, common mistakes and checks for the Traffic project.

Language — N-grams, Parser, Attention & the Transformer | Harvard CS50 AI Week 6

Week 6 is about getting computers to handle natural language: parse sentences with hand-written context-free grammar rules, then switch to statistics, from n-grams and Markov-chain text generation to a Naive Bayes classifier for review sentiment; turn words into vectors with word2vec, process whole sequences with an RNN encoder–decoder, and finish with attention and the Transformer. Includes section-by-section time links, plus an approach, common mistakes and ways to check your work for the Parser and Attention projects.

Course Retrospective and Next Steps: What Seven Weeks Taught, What They Left Out, What to Read Next | Harvard CS50 AI Topic Guide

The last post in the series: one table reviewing what each of the seven weeks taught and which projects it had; in 2023 the course replaced Week 6 with a new version that reaches attention and the Transformer, while the other six weeks remain 2020 recordings; the lectures do not teach how to use today's language models. The second half links to this site's overviews of nine follow-up courses, by where you want to go. Includes three review self-check questions.

A map of Looplane: how one coding-agent task crosses workspaces, runtimes, tools, and events

Looplane turns a coding-agent task into inspectable boundaries: native side effects cross Looplane tools, permissions, and sandboxing, while external runtimes retain their own loops and tools before returning a patch for Looplane audit. This article maps the planned 20-part series.

Looplane remote execution on Cloudflare: Worker, Sandbox, Capability DO, and durable RunSession

Looplane's old synchronous M6 path completed one real deployed coding run. It has since grown into an asynchronous control plane with RunSession, SSE, approvals, cancellation, and artifacts, but that newer path has not been live-revalidated. Audience-separated HMAC capabilities enter the Sandbox while provider credentials stay in the Worker; this is not production-traffic or SLO proof.

Looplane context pressure, compaction, and workspace reinjection

Near 85% context pressure, Looplane has two distinct paths: the native loop can apply one bounded deterministic history fallback, while a conversation runtime with native compaction can compact after a completed turn. Both paths re-anchor the next request with workspace context.

Looplane's disposable workspace and run bundle: why the source repository stays untouched

Looplane clones an exact Git commit into a detached-HEAD workspace inside the run directory before a runtime edits or verifies code. The source repository, execution workspace, and run artifacts therefore have distinct boundaries. This provides source isolation and an audit bundle, but it is not an OS sandbox.

Looplane's ExternalCodingRunner: why Codex and Claude Code CLI are external runtimes, not ModelProviders

`ExternalCodingRunner` is Looplane's second runtime lane. The external coding CLI owns its model loop and credentials; Looplane hands off a task and disposable clone, then treats the returned patch as untrusted input and reruns path audit, verification, and the source invariant. This is a capability-bounded handoff, not another `ModelProvider`.

Looplane IDE/LSP Context: Diagnostics, Open Files, and the VS Code Bridge

Looplane normalizes up to 200 diagnostics and 32 visible files into bounded, repository-local, untrusted context. Its VS Code and managed-LSP paths supply signals rather than completion, rename, code actions, or full IDE RPC.

Looplane local OS sandboxes: fail-closed execution on macOS, bubblewrap, and Landlock

Looplane can wrap configured local commands and verification in macOS sandbox-exec, Linux bubblewrap, or Landlock/seccomp. A required unavailable backend stops with exit 126 instead of running bare, but external CLIs, MCP/LSP processes, and the entire Looplane process are outside this boundary.

Looplane's ModelProvider multi-gateway: multiple protocols, one canonical contract

Looplane collapses OpenAI-compatible, Responses, Anthropic, Gemini, Workers AI, scripted, and experimental Codex OAuth adapters into one `ModelProvider` contract. The Codex OAuth transport reads SSE but still reduces it inside the adapter into one canonical `ModelTurn`; AgentRunner does not consume token deltas.

Looplane model roles, fallback, cache hints, and estimated cost

Looplane uses a static model-role catalog and retries or falls back only after retryable provider errors. Cache data is a provider hint plus trace, while cost is a static-table estimate; neither is live routing intelligence or a bill.

Looplane Native MCP: transport, authorization, and approval boundaries

Looplane loads project MCP servers only through an explicit allowlist, projects stdio or Streamable HTTP capabilities into the existing ToolExecutor, and preserves hooks, approvals, timeouts, and cleanup.

Looplane permission layering: how dangerous commands become allow, ask, or deny

Looplane applies a non-bypassable critical floor, evaluates user, organization, and project denies before any allows, and keeps execute operations policy-gated even in dangerous mode. This decides authority; it is not an OS sandbox.

Looplane prompts, instruction precedence, and explicit memory: what the model actually sees

Looplane resolves user and root-to-leaf project instructions before rendering named prompt sections for runtime, skills, workspace state, and the latest 20 explicit memories. The pipeline is traceable and reloadable, but it is not semantic memory and repository text does not become system authority.

Looplane's provider-neutral native loop: from one model turn to a verified terminal state

Looplane's native lane is controlled by AgentRunner: prepare a workspace, request a model turn, execute tool calls, append observations, and enter verification only when the model stops calling tools. Step, wall-time, repetition, token, and cancellation guards can terminate the run independently of the model. Protocol translation belongs to the next article.

Embedding Looplane: SDK, ConversationController, and the WebSocket Boundary

Looplane exposes bounded-run and conversation contracts through a typed 0.x SDK facade. WebSocket attach wraps one prebuilt, controller-owned runtime session rather than providing conversation-ID resume or multi-client routing.

Looplane Skills, Blocking Hooks, and Plugin Packages

Looplane treats skills as bounded repository-local guidance, hooks as opt-in host commands that can only deny, and local plugin manifests as packages for skills and hooks; their authority is deliberately different.

Looplane's state-first event journaling: recovering between manifest commits and JSONL appends

Looplane maintains append-only `events.jsonl` and atomically replaced `session.json`, reconciling sequences before crash recovery. The same event contract now supports deterministic replay, canonical JSON replay, fork seeds at a selected sequence, and new workspaces without replaying old side effects; ambiguous `tool.started` or `verification.started` states still hard-fail.

Looplane Subagent Scheduling and Parent-owned Transactions

Looplane normalizes each subagent dispatch into dependency waves of at most four nodes, runs read-only children concurrently in isolated workspaces, then makes the parent repeat hooks, approval, and transaction execution for any modification.