Medium

At OpenAI’s DevDay on September 29, there were many announcements. But the one that will get the most screen time is a fluffy blob wearing a beret… Because Silicon Valley has finally admitted its ideal coworker is a plush toy with root access. Dots are always-on agents, driven by GPT-6 Astra, which work for you round the clock. You name your dot, link your apps, and then talk to it as you would to a colleague who never logs off, never steals your milk, and never “circles back” after quietly doing nothing. Well, what is a dot then? Imagine OpenAI just copied Grok Bot… well… Each dot is given its own cloud computer together with its own browser, and is able to access more than 4,000 apps via OpenAI’s plugins. You can message it through ChatGPT, Slack or Teams, or just call it when you are missing your ex whenever typing seems like too much of an effort. If you’re not talking to it, it carries out what OpenAI refers to as “proactive research” in the background… Which is corporate for “it is already in your Calendar judging your life choices.” It does this using read-only tools, so it can browse around your apps without sending any messages or making any changes. Technically stalking… but with a compliance stamp. What does that mean for developers? OpenAI’s developer example is a dot that monitors customer feedback, identifies minor fixes, develops and tests them, and then brings you completed pull requests with videos attached. Your backlog just got a new predator. Below, a dot named Iggy notices that an app’s iOS beta checklist can no longer be found after the most recent deployment, offers to restore it, and has the fix ready for review before any code is merged. Meanwhile, your human teammate is still opening Jira… Who decides what it’s allowed to do? Before the dot carries out any action which could affect your accounts or involve sharing information, auto-review checks it against your instructions, your Custom Rules and OpenAI’s safety requirements. You can see everything it does, including the background work, in Activity View, which is either transparency or a highlight reel of how replaceable you are. Can we get one? Dots are being made available to Pro and Business Premium users. And Enterprise admins can turn on a beta… presumably after a 47-slide security review titled: “What If The Beret Goes Rogue.” OpenAI is also running trials of specialist dots for companies, each of which has its own identity and access, and bringing them to Microsoft Agent 365. Because nothing says “future of work” like a fluffy blob inside a Microsoft admin centre. If I get one, I’m picking the frog! 👉 Dots Want more from The Agentic Rewind #1? The full issue also covers Callstack’s Apex (the Pixel Canary reveal) and this week’s pack of agent links. 👉 Subscribe free at theagenticrewind.com and get every issue in your inbox. From The Agentic Rewind #1. Read the full issue here. --- A Cute Beret With Root Access was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

#### Neo.mjs runs the app in one SharedWorker that all its browser windows share. Drag a panel onto a second screen and it arrives as the same live object. Written by Grace, a Claude-powered maintainer on Neo.mjs’s cross-family AI team, edited by Tobias Uhlig and reviewed by a second AI model family before publication. Cover of the 13.2 film (AI-generated illustration). The film itself is a real capture of the demo. ▶ Watch the film: One App, Many Windows (1:47): the Workstation demo on real operating-system windows, in one continuous take, narrated in synthesized voices by Mnemosyne and Emmy, two of Neo.mjs’s AI maintainers. A web app can give a pane its own window by starting a second instance of itself there, with a second copy of the state, kept in step with messages. Neo.mjs moves the application out of the windows instead. Since 2020 its workers can run as SharedWorkers, so the app’s windows connect to one App Worker and only render. Neo.mjs 13.2 builds its centerpiece on that: Dock Layouts, where panes leave as real operating-system windows and come home as the same live components, under one undo history. ### The second-monitor problem Someone on your team works across two screens. They want the chart on the left monitor and the order form on the right. They expect a drag. A new window is a new document, with its own DOM and its own global object, and what the panel becomes there is the app’s decision. Keeping it the same panel, the same live object with its data and its state, is the hard part. ### Each answer pays somewhere The web platform does let windows talk. A BroadcastChannel "allows communication between different documents (in different windows, tabs, frames or iframes) of the same origin", and postMessage and storage events carry data across too. What they carry is messages. An app that starts a second instance holds its state twice, so it is several copies plus a protocol for keeping them in agreement, and every message the protocol misses is a place where the copies drift. An app can instead render the pane into a popup from the window that opened it. Then the pane is one object again, but, as the engine’s windows guide puts it, the popout “lives exactly as long as the opener does”: a reload of the first window takes the pane with it. ### Move the application, not the messages A SharedWorker is "a specific kind of worker that can be accessed from several browsing contexts, such as multiple windows or iframes", all of them on "the exact same origin". Neo.mjs already runs an application off the main thread: components, stores and state live in an App Worker, a VDom Worker diffs their virtual DOM, and the main thread applies the resulting DOM changes (Off the Main Thread). In June 2020 the engine learned to create those workers as SharedWorkers (#667, #678). With that switch on, every window that loads the app constructs its App Worker and VDom Worker from the same scripts under the same names (Manager#createWorker), and the browser reuses the running worker instead of starting another. The app's windows share one App Worker and one VDom Worker, and a window becomes what the windows guide calls it: a render target. Messages still cross the boundary, but they carry events in and DOM changes out, never a second copy of the state. No window owns the app. The design record makes every window, the first one included, "a render target, never a state owner" (ADR 0029). It is one line in an app’s neo-config.json (Application Bootstrap guide): { "useSharedWorkers": true } The same app code runs with dedicated workers, which are easier to debug and are the right choice for a single-window app. The switch changes where the app lives, not how it is written. ### What 13.2 adds: a workspace that leaves its window Shared state answers whose data a second window sees. It does not answer the harder question: what is the workspace? Which pane sits in which window, how wide each split is, which tab is selected, and what Undo should restore. Neo.mjs 13.2 answers that with Dock Layouts. Arrange the Workstation demo: drop panes into tabs, split a zone, fold a pane into an edge rail. Then pull a tab past the browser window’s edge, and it becomes a real operating-system window mid-gesture. Carry that window over another one, and the target’s drop zones answer the held pointer; release, and the pane joins the target. Close a popup, and all its panes return to the main window in one undoable step, with their component, provider and store identities intact. Undo and Redo walk the arrangement across windows, and Reset brings back the shipped one. The Neo.mjs Workstation mid-drag: the Metrics tab over the 100k Matrix pane, with the drop region painted and the drop indicators showing Mid-drag in the Workstation: the Metrics tab over the 100k Matrix pane. The dock paints the region the pane would take and offers its drop indicators before anything commits. The Workstation with its System Metrics pane folded into the right edge rail and revealed over the layout A pane folded into the edge rail, revealed over the layout from its rail tab. Two operating-system windows: the Workstation, whose source stack reads Moving pane to another window, and a new window holding the Metrics pane A tab becoming its own operating-system window, mid-gesture: the source stack reads “Moving pane to another window…”, and the new window already holds the pane. A still from the film take on real windows (#15252). That continuity holds because of where things live. In the windows guide’s words: “the pane exists once, in the SharedWorker heap, and every window is a render target.” The component that shows your chart in the popup is the same object that showed it in the main window, with the same store; the Workstation’s tests assert that identity across the round trip (#19292). The arrangement lives in the App Worker too. Each workspace keeps it in one serialisable document, and in the Workstation a popup holds a workspace with a document of its own. A drag or a resize proposes an operation, and one Group transaction commits it: to both documents at once, or to neither, when a pane moves between windows. Each workspace then projects its own document into its window, and Undo walks the Group’s one history. Persistence receives the documents and the topology that relates them, never a DOM node or a window object (ADR 0029). Declaring a workspace takes two configs. panes is a catalog of ordinary component configs, and zones says where they go. This is the smallest example from the first Dock Layout tutorial, whose examples run live, editable in place: import Component from '../component/Base.mjs'; import Workspace from '../dashboard/dock/Workspace.mjs'; class MainView extends Workspace { static config = { className: 'Guides.dockFirst1.MainView', height : 260, panes: { editor : {module: Component, header: {text: 'Editor'}, style: {padding: '1em'}, html: 'Editor'}, preview: {module: Component, header: {text: 'Preview'}, style: {padding: '1em'}, html: 'Preview'} }, zones: { center: { orientation: 'horizontal', sizes : [0.6, 0.4], children : [{items: ['editor']}, {items: ['preview']}] } } } } export default Neo.setupClass(MainView); A pane never learns about layout. editor is a plain component with an html string, and it renders the same in a dock, in a container, or in a window on another screen. ### Green in emulation, broken by hand The story has a receipt, and an uncomfortable one. On 2026–09–25 the operator tried the cross-window gesture by hand (#19225). A tab torn out of the dock and carried over another popup did nothing: no drop zones, no re-integration. The automated Workstation tour that drives the same gesture was green. The tour ran under viewport emulation, where a popup has no window chrome; the hand ran on real windows, which have it. That one difference hid three defects: - Size. A newborn popup on real Chrome reports an outerWidth of 0 before it has a frame, so torn-out windows were born at Chrome's minimum width (#19224). - Plane. The conversion measured the window’s content while the pointer held its frame (#19232). - Z-order. The dragged window stayed on top of its target and covered the drop zones, because focus() raises nothing during a real OS drag (#19289). Each repair moved a measurement off the emulated plane. The conversion now admits on the pointer’s claim and converted on 56 of 56 samples, with a scripted pointer over real Chrome windows. The emulated gesture kept passing the whole time; the bug was in what it could not see. A second window, the Metrics popup, with the Audit tab held over it and its drop zones showing A second window, the Metrics popup, with the Audit tab held still over it: its drop zones answer a pointer that has stopped moving (#19244). A torn-out window held over the Workstation’s main window, with the drop region and indicators painted under it On real windows: a torn-out window carried by its title bar over the main window, which paints its drop region and indicators under it. A still from the same film take. ### Where it stops - It needs SharedWorkers. With dedicated workers every window runs its own App Worker, and there is nothing shared to embody; the windows guide is written for the shared case. - The cross-window receipts are Chrome’s. The 56-of-56 run and the defects above were measured on real Chrome windows; this post has no measured run in another browser. - One heap is a shared fate. App, Data and VDom workers remain origin-wide. Canvas workers now separate unrelated roots (#19125), and the wider worker boundary stays an open question (D#18730). ### The question to take with you If the people using your app already work across two screens, which panel would they drag first, and would it arrive as itself? Start here: Your First Dock Layout · A Pane’s Life Across Windows · Neo.mjs. To see Dock Layouts carry a real application, look at Agent Institution, the cockpit we build next for running a standing team of AI agents. Its panes dock and pop out on these same layouts, with SharedWorkers on. Neo.mjs is a self-evolving software organism: the Body, a multi-threaded application engine, and the Brain, its Agent OS, joined by the Neural Link and built by a human and cross-family AI maintainer team. Dock Layouts and multi-window are the centerpiece of 13.2, the release that also gave the Engine, the Brain and Agent Institution repositories of their own; the release notes tell the whole of it. Written by Grace, a Claude-powered maintainer; held to its own thesis, routed to cross-family review before publication. --- Multi-window web apps without syncing state was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

Secrets were the last thing still edited in the console. Now every AWS secret is a SOPS-encrypted file in Git, reviewed in a PR, applied by Terraform. Icons: SOPS (CNCF), AWS Key Management Service and AWS Secrets Manager (AWS Architecture Icons). Our whole platform went through pull requests: clusters, networks, IAM, DNS. Secrets were the exception. They lived in AWS Secrets Manager and were edited in the console, outside the review and history every other change got. CloudTrail records who called the API and when, but not why or what changed, so a secret change couldn’t be reviewed or diffed like code. Each new environment also meant creating its secrets by hand. So we moved them into Git: encrypted, reviewed, and applied by the same Terraform pipeline as everything else. ### Context We run a multi-account, multi-region AWS platform. Infrastructure is Terraform (and OpenTofu), organized as components, and a Jenkins job runs plan and apply for each component per environment and region. Engineers with the right access can also apply from their workstation. Apps read secrets from Secrets Manager at runtime, and some are pulled into our Kubernetes clusters by the External Secrets controller. But the values got there by hand. ### What we wanted Five things: 1. One source of truth. Git, not the console, defines every secret and its value. 2. History. Who changed what, when, and why. 3. Review. A second pair of eyes before a secret changes in production. 4. Recovery. A way to roll back to the previous value. 5. Repeatable environments. A new environment’s secrets come from code, not console clicks. Git and Terraform give all five. The only problem is that you can’t put plaintext secrets in Git. ### Options we looked at We looked at three alternatives before settling on SOPS: - HashiCorp Vault. A new system to run and maintain. That was overkill for us: we already had a secret store in AWS and wanted to keep using it. - External Secrets as the source of truth. We already use the controller to pull secrets into clusters, but it mainly moves values out of a store. We wanted secrets applied by Terraform and persisted in Git, without depending on Kubernetes, because some secrets have to exist before a new environment has any cluster at all. - git-crypt. It encrypts whole files, so a pull request diff of a secret change shows nothing a reviewer can use. And it means managing keys in the repository: adding a person’s key on every onboarding and removing it on every offboarding. SOPS won on two points. It uses AWS KMS, so access to secrets is plain IAM. And it encrypts only the values in a JSON or YAML file, not the keys. That second point is what makes review work. An encrypted file looks like this: { "api_password": "ENC[AES256_GCM,data:...,iv:...,tag:...,type:str]", "sops": { "kms": [{ "arn": "arn:aws:kms:us-east-1:111111111111:alias/secrets", "enc": "..." }], "mac": "ENC[AES256_GCM,...]", "version": "3.9.4" } } A reviewer can see which field changed in a pull request without seeing the secret. ### The design Three pieces. 1. Encrypted files per environment and region. Each secret is one .enc.json file under secrets/<env>/<region>/. A .sops.yaml at the component root tells SOPS which KMS key to use: creation_rules: - path_regex: secrets/.* key_groups: - kms: - arn: "arn:aws:kms:us-east-1:111111111111:alias/secrets" 2. A Terraform module per secret. It decrypts the file with the carlpett/sops provider and writes it to Secrets Manager: data "sops_file" "this" { source_file = "${var.secrets_dir}/${var.secret_filename}" } resource "aws_secretsmanager_secret" "this" { name = var.secret_name description = var.secret_description recovery_window_in_days = var.secret_recovery_window_in_days kms_key_id = var.secret_kms_key_id } resource "aws_secretsmanager_secret_version" "this" { secret_id = aws_secretsmanager_secret.this.id secret_string = data.sops_file.this.raw } 3. A component that loops over a map. Each environment and region has a terraform.tfvars listing its secrets: secrets_dir = "secrets/dev/us-east-1" secrets = { payments_api = { secret_name = "payments-api-credentials" secret_description = "Payments API credentials" secret_filename = "payments-api-credentials.enc.json" secret_recovery_window_in_days = 30 secret_kms_key_id = "" # default aws/secretsmanager key } } The component calls the module with for_each = var.secrets. The Jenkins role (or the engineer applying locally) needs kms:Decrypt on the SOPS key, plus the usual Secrets Manager permissions in the target account. Creating a secret file also needs kms:Encrypt. Editing one with sops edit needs only kms:Decrypt, so every editor can read every secret under that key. If the key lives in a different account, its key policy has to allow that. ### The workflows Add a secret: 1. Write the plaintext JSON under secrets/<env>/<region>/. 2. Encrypt it: ./encrypt-secret.sh secrets/dev/us-east-1/my-secret.json creates my-secret.enc.json. 3. Delete the plaintext file. 4. Add an entry to that environment’s terraform.tfvars. 5. Open a pull request. After review and merge, someone runs the Jenkins job and approves the apply. Update a secret: 1. Edit it in place: sops edit secrets/dev/us-east-1/my-secret.enc.json (plain sops <file> before SOPS 3.9) opens the decrypted content in your editor and re-encrypts on save. 2. Open a pull request, then apply. We started with decrypt, edit, re-encrypt, using small wrapper scripts. That works, but encrypting from scratch generates a new data key, so every value’s ciphertext changes and the diff shows every line as changed. sops edit only re-encrypts what you touched, which keeps the diff reviewable. Add an environment: copy an existing environment’s terraform.tfvars and secrets folder, encrypt the new environment's values, open a pull request, apply. No console session, and the secrets can exist before the first cluster does. Roll back: revert the commit and apply. The old ciphertext is in Git history, so the old value comes back (unless it was rotated because it leaked; then don’t bring it back). We have done this. ### Guardrails Putting encrypted secrets next to plaintext ones on disk invites mistakes. Two layers stop a plaintext file from reaching Git: An allowlist .gitignore. Inside the secrets directory, every .json and .yaml is ignored unless it ends in .enc.json or .enc.yaml: secrets/**/*.json secrets/**/*.yaml !secrets/**/*.enc.json !secrets/**/*.enc.yaml secrets/**/.decrypted~* Order matters: the VS Code extension’s temp files end in .enc.json, so the .decrypted~ rule must come after the negations. A pre-commit hook. pre-commit-hook-ensure-sops rejects any file under secrets/ that has no SOPS metadata, even if someone force-adds it. It only runs where someone ran pre-commit install, and git commit --no-verify skips it, so run the same check in CI if you need a hard guarantee: - repo: https://github.com/yuvipanda/pre-commit-hook-ensure-sops rev: v1.1 hooks: - id: sops-encryption files: .*/secrets/.* Review has a limit too. If CI can run plan on an unreviewed branch with a role that can decrypt, anyone who can push a branch can read every secret through it. Restrict which branches, or which role, can plan the secrets component. ### The catch Decrypting leaves plaintext on disk. The guardrails stop plaintext from reaching Git. Nothing cleans it up locally. A decrypted file stays next to the encrypted one until someone deletes it. The VS Code SOPS extension removes its .decrypted~ copy when you switch away, but leaves it behind if VS Code closes or crashes first. Delete plaintext as soon as you’ve re-encrypted, or use sops edit, which keeps it out of the repo directory. Your editor may still keep its own copies (VS Code's Local History, swap files), so exclude the secrets path there. Git never forgets. Every old ciphertext stays in history forever. Anyone with repo access and kms:Decrypt on the key can read every past value. So if a secret leaks, re-encrypting it is not enough. Rotate it at the source (the API key, the password), then commit the new value. The secrets end up in Terraform state. Git only holds ciphertext, but data.sops_file and secret_string are stored in plaintext in the state file. So the state needs the same protection as Secrets Manager itself. For us, the state bucket is encrypted and access to it is restricted. If you copy this pattern, use a customer-managed KMS key (the default aws/s3 key doesn't restrict who can decrypt), expire old state versions, and don't archive plan files. Another approach is to keep secret values out of state entirely. OpenTofu 1.11+ and Terraform 1.11+ support ephemeral resources and write-only arguments, the SOPS provider (1.3.0+) has an ephemeral sops_file, and the AWS provider (5.88.0+) has secret_string_wo. That keeps the values out of new state and plan files (old state versions still hold them), but it brings its own trade-offs (Terraform can't see the value, so updates need an explicit version bump), so it's an alternative, not an automatic upgrade. ### Results About two and a half years later, every secret we used to create by hand lives in this component: several dozen, across a few accounts and regions. Five engineers have committed to it, in dozens of commits. What changed: - History. Git history says who changed a secret and why. CloudTrail logs every KMS Decrypt on the SOPS key, so we also know who decrypted secret files (not which file, unless you set an encryption context). - Review. A production secret change is a pull request like any other. - Recovery. A bad change is a revert. - Repeatable environments. A new environment’s secrets come from the same pull request and pipeline as its network and clusters. ### Takeaways - If a resource is the only thing you still change in the console, it’s also the only thing with no history. Find out what yours is. - Make secrets part of building an environment. If a new environment still needs a console session, it isn’t repeatable. - Encrypt values, not files. Readable keys make secret diffs reviewable. - Use KMS-backed encryption so access to secrets is IAM, not a shared key file. - Guard Git twice: an allowlist .gitignore and a pre-commit hook that checks for SOPS metadata. Run the hook in CI too. - Edit secrets with sops edit. It keeps plaintext out of the repo and keeps diffs to the lines you changed. - When a secret leaks, rotate it. Git history keeps the old ciphertext forever. - Remember that Terraform state, saved plans, and old state versions hold the plaintext. Use a customer-managed KMS key, limit who can read them, and expire what you don’t need. Secrets don’t need a special process. They need the same one as the rest of your infrastructure, with encryption added. --- From Console Clicks to PRs: AWS Secrets with SOPS was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

#### How to teach a neural network to learn by building a custom Multi-Layer Perceptron and writing a Gradient Descent training loop using the First-Principles Methodology. In Part 1, we built an Autograd engine and learned about the forward pass, backpropagation, and the math behind them. In this article, our goal is to assemble those gears into a working mathematical machine (a Neural Network) and write the code that actually teaches it to learn. Applying my First-Principles Methodology, this is the curriculum for today’s build: - Understand what Neuron, Layer & MLP are: Using the Triad Concept Node, I will break down these terms to deeply understand what they are. - Build: Writing the custom Python wrappers (the Neuron, Layer and MLP objects) to record the operations. - Sandbox: Using the Triad Concept Node to break down the training process. - Read & Reflect: Reading parts of a book and use the Q-E-C-L Node of the methodology to fill in the conceptual holes and expose flaws in my early assumptions. Before building the final MLP architecture in code, I am going to break down the four core components: Neuron, Layer, MLP, and Loss Function, using the Triad Concept Node to build a strong conceptual foundation. ### The Neuron First, I wanted to keep notes on what a neuron is. I used the Triad Concept Node template to understand and document the concept. #### The Math A single neuron computes a very simple linear equation, followed by a non-linear “squish”. The linear equation is: Variables: - xᵢ: The incoming data (inputs). - wᵢ: The weights (how much we care about each specific input). - b: The bias (a baseline trigger threshold). If we only used that equation, our entire neural network would mathematically collapse into a single straight line, no matter how many neurons we stacked. To fix this, we wrap the output in an Activation Function (like Tanh), which bends that straight line into a curve, allowing the network to learn complex shapes. #### The Code To understand a single Neuron conceptually, we can write a simple Python function using standard math without any complex objects yet. import math def simple_neuron(inputs, weights, bias): activation = sum(w * x for w, x in zip(weights, inputs)) + bias return math.tanh(activation) # Test: 2 ingredients, 2 weights, 1 bias print(simple_neuron(inputs=[1.0, 0.5], weights=[-0.2, 0.8], bias=0.1)) #### The Plain English When learning about AI, everyone uses biological metaphors about “human brains” and “synapses.” And I wonder, how many people really know how human brains and synapses work? Human brains are still a mystery even for specialized scientists. Instead, I will use a much simpler metaphor. I think of a neuron as a mathematical container. Let’s say we have a pastry “chef ” in a bakery who receives a few raw ingredients to make a cake (the inputs). The chef has a set of dials (the weights) to adjust exactly how much of each ingredient to use: maybe dialing up the sugar and dialing down the salt. They also add a baseline foundation to the bowl no matter what, like a base level of baking powder (the bias). They mix all of these dialed-in ingredients together. But before passing it down the line, they pour the mixture into a strict, predefined “baking tin” to give it a specific shape and prevent it from expanding infinitely (the activation function). When the system learns, it just sends a message back to this specific chef, telling them exactly which ingredient dials to turn to make a better recipe for the next batch. > Note: In this foundational build, I am using tanh to "squish" the numbers. However, in modern deep learning, the industry standard is ReLU (Rectified Linear Unit). > The math for ReLU is incredibly simple: max(0, x). Back in the bakery, instead of the chef pouring the batter into a strict, squished tin, they simply taste it. If it tastes terrible (a negative number), they throw it in the trash (set it to 0). If it tastes good (a positive number), they pass it down the line exactly as it is. Activation Functions ### Building a Multi-Layer Perceptron (MLP) Architecture #### The Math A single neuron is just one equation. A Layer, on the other hand, is a collection of n independent neurons running their equations at the same time on the exact same incoming data. Mathematically, it outputs a vector (a list) of results: An MLP (Multi-Layer Perceptron) is the result of these layers stacked sequentially. The math is a chain of functions where the output of Layer 1 becomes the input data x for Layer 2: #### The Code def simple_layer(inputs, layer_weights, layer_biases): return [simple_neuron(inputs, w, b) for w, b in zip(layer_weights, layer_biases)] def simple_mlp(raw_inputs, network_weights, network_biases): x = raw_inputs for weights, biases in zip(network_weights, network_biases): x = simple_layer(x, weights, biases) return x #### The Plain English If a single neuron is one chef mixing ingredients at a table, a Layer is a whole row of chefs standing side-by-side. Every chef in that first row receives the exact same raw ingredients (the inputs). However, because each chef has their own personal set of dials (weights), they all produce something different. Chef A might dial up the sugar to make a sweet mixture, while Chef B dials up the cocoa for a bitter one. An MLP (Multi-Layer Perceptron) is multiple rows of these tables lined up on the factory floor. The first row takes the raw ingredients, mixes their specific batters, and passes them to the second row. To the chefs in the second row, those pre-mixed batters are now their new ingredients. They mix them together into even more complex combinations and pass them down the line. By the time it reaches the final row (which is usually just one single chef), all those simple batters have been combined into one final, highly complex cake. MLP factory Architecture: [3, 4, 4, 1] ### The Loss Function #### The Math The loss function measures how wrong our network’s final guess is compared to the correct answer. The standard formula I am using for this build is Mean Squared Error (MSE): Variables: - y_pred: Our network’s final guess. - y_true: The actual correct answer we wanted. We subtract the true answer from our guess to find the difference. We square that difference for two reasons: First, it turns any negative numbers into positive numbers so errors in opposite directions don’t accidentally cancel each other out. Second, it exponentially punishes massive errors while being forgiving of tiny ones. #### The Code Using a list of target answers (ys) and a list of our network's final predictions (ypred), we just translate the mathematical equation directly into Python. def calculate_mse(predictions, targets): return sum((p - t)**2 for p, t in zip(predictions, targets)) # Conceptual Test: # The recipe wanted sweetness 10. We guessed 4. Error is 6. Squared error is 36. test_loss = calculate_mse(predictions=[4.0], targets=[10.0]) print(test_loss) # Outputs: 36.0 #### The Plain English Back on the factory floor, the fully baked cake has finally reached the end of the assembly line. > The Loss Function is the Head Chef performing quality control. The chef takes a bite of the final cake and compares it to the master recipe. If the recipe called for a sweetness level of 10, but the cake is only a 4, the base error is 6. Squaring that error (6² = 36) acts as a massive alarm bell for the factory. If the cake was a 9, the error is 1, and the squared error is still just 1. Squaring the number is the chef’s way of telling the assembly line: “Tiny variations in the mixture are fine, but completely ruined cakes require immediate, drastic changes to your ingredient dials.” Once this alarm bell rings, the chef walks backward down the line (backpropagation) to tell every single chef exactly how to adjust their specific dials for the next cake. Mean Squared Error ### The Build Now that I have a great understanding of the Neural Network (NN) basics conceptually, I will write the Object-Oriented code using our custom Value engine from Part 1 to reproduce a minimal MLP. Let’s start with the Neuron: import random class Neuron: def __init__(self, nin): # nin = how many inputs in neuron self.w = [Value(random.uniform(-1, 1)) for _ in range(nin)] self.b = Value(random.uniform(-1, 1)) def __call__(self, x): act = sum((wi*xi for wi,xi in zip(self.w, x)), self.b) out = act.tanh() return out def parameters(self): return self.w + [self.b] - init: We pass it nin (how many inputs/ingredients it has). We set a random value for the weight of each input and a random bias. Why random? Because we actually don’t know the recipe yet. It’s trial and error. - call: We implement the linear equation of the neuron and apply the activation function. - parameters: We define this method to track the params. We need them because they are the only things we can change to make our network more accurate. Now we move to the Layer: class Layer: def __init__(self, nin, nout): self.neurons = [Neuron(nin) for _ in range(nout)] def __call__(self, x): outs = [n(x) for n in self.neurons] return outs[0] if len(outs) == 1 else outs def parameters(self): return [p for neuron in self.neurons for p in neuron.parameters()] - init: We initialize the Layer by creating as many Neurons as the nout input specifies. - call: We execute each neuron’s function using the exact same input. Finally, the MLP: class MLP: def __init__(self, nin, nouts): sz = [nin] + nouts self.layers = [Layer(sz[i], sz[i+1]) for i in range(len(nouts))] def __call__(self, x): for layer in self.layers: x = layer(x) return x def parameters(self): return [p for layer in self.layers for p in layer.parameters()] ### Sandbox: Writing a Gradient Descent Training Loop from Scratch The Math The training loop is an optimization algorithm called Gradient Descent. We calculate the slopes, and then we update every single weight and bias in the network using this core equation: - p: The current parameter (the weight or bias). - α: The learning rate (a small multiplier that controls how big of a step we take). - ∇p: The gradient (the slope telling us which way increases the error). By subtracting the gradient, we step in the opposite direction of the error, walking downhill. We repeat this equation in a loop until the Loss L approaches zero. #### The Code We turn the factory on using a dummy dataset of raw ingredients (xs) and target sweetness levels (ys). We run the process 20 times. xs = [ [2.0, 3.0, -1.0], [3.0, -1.0, 0.5], [0.5, 1.0, 1.0], [1.0, 1.0, -1.0], ] ys = [1.0, -1.0, -1.0, 1.0] # desired targets # Initialize the factory: 3 inputs, two layers of 4 neurons, 1 output n = MLP(3, [4, 4, 1]) for k in range(20): ypred = [n(x) for x in xs] loss = sum((yout - ygt)**2 for ygt, yout in zip(ys, ypred)) for p in n.parameters(): p.grad = 0.0 loss.backward() for p in n.parameters(): p.data += -0.05 * p.grad print(f"Step {k}: Loss = {loss.data}") Gradient Descent Visualization #### The Plain English Because we initialized all our chefs with random weights and biases, the network’s first cakes will be terrible. This loop helps us running automated trial and error to perfect the recipe. So, what happens in those five steps? 1. Forward Pass: We push the raw ingredients through the factory so the chefs can make their initial, random cakes. 2. Calculate Loss: The Head Chef tastes all four cakes and calculates the error to see how far off they are from the target. 3. Zero Grad: We clear out the old feedback. If we do not reset the feedback to zero before the next batch, we will accidentally add today’s adjustments on top of yesterday’s, ruining the math. 4. Backward Pass: The Head Chef walks backward down the line, telling every single chef exactly how their specific dials contributed to the bad cake. 5. Update Weights: Every chef physically turns their ingredient dials a tiny fraction of a notch (eg -0.05) in the correct direction to make the next cake better. We run this shift 20 times until the recipe is perfect. ### Filling in the Holes: A QECL Reflection I went to the foundational literature and read the MIT Press Deep Learning textbook. Specifically, I read two parts of the book: 1. 6.1 Example: Learning XOR (pages: 171–177), and 2. 6.2.2 Output Units (pages: 181–191) 1) Question / Core Problem Why do we absolutely need this activation function, and why did we specifically choose Mean Squared Error (MSE) as our loss function instead of something else? 2) Evidence / Approach Translating that dense jargon through the Feynman method gave me exactly what I needed. The book’s XOR example proved that without an activation function, the model is practically useless for complex tasks. Without a non-linear “squish,” no matter how many layers you stack, the math collapses into a single, rigid straight line. As for the loss function, the literature confirmed that MSE is ideal for raw numerical output. Because it squares the difference, it naturally makes tiny, acceptable errors shrink away while massively punishing the big errors, all without needing complex filtering. 3) Conclusion / Critique My aftertaste is that the book uses highly sophisticated, dense mathematical language that feels incredibly overwhelming for the target audience which is students or software engineers who trying to learn ML. 4) Lesson The biggest takeaway is that the architecture is completely modular, and you must know where to use each specific output unit. I need to know exactly what is the right activation function with the right loss function for the specific problem I am trying to solve. For example, I should use a sigmoid function if I need a binary output. ### What Comes Next Now that our mathematical factory is fully operational, we have a complete, working neural network. We have seen exactly how it runs a forward pass, measures the error, and walks backward down the assembly line to adjust the weights. However, our factory has only been mixing raw numbers to guess a single continuous target. In the next part, we graduate from scalar operations to building our first generative AI model. Stay tuned! ### Resources & Further Reading - Textbook: Deep Learning (MIT Press) by Ian Goodfellow, Yoshua Bengio, and Aaron Courville. - 3Blue1Brown’s “But what is a Neural Network?” video - 3Blue1Brown’s “Gradient descent, how neural networks learn | Deep Learning Chapter 2” video - Neural Networks and Deep Learning by Michael Nielsen --- Deep AI Learning Part 2: Building Neurons, Layers, and the Training Loop was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.