Forem: Remo H. Jansen

Building a 3D engine from scratch with C++ and Vulkan for web developers Part II: Rendering your first triangle

Remo H. Jansen — Sun, 17 May 2026 12:05:53 +0000

Where we left off

In Part I, we set up the Vulkan infrastructure: instance, window, surface, device, and swapchain. We have a GPU ready to receive commands, and a queue of images waiting to be drawn to and displayed on screen.

But at that point we didn't draw anything. The game loop just polled for window events and looped. Now we're going to make pixels appear — specifically, a colored triangle. This is the "Hello, World!" of graphics programming. Every GPU tutorial starts here because a triangle is the simplest shape the GPU can draw, and getting one on screen proves the entire pipeline is working.

Here's what we need to build:

Swapchain (Part I) → Render Pass → Shaders → Pipeline → Command Pool → Framebuffers → Sync → Draw

Each of these builds on the previous one. By the end, we'll have a working render loop that clears the screen to black, draws a rainbow triangle, and presents the result every frame.

The updated architecture

The renderer has grown. Here's the directory structure now:

src/engine/renderer/
├── instance         ← Vulkan runtime (Part I)
├── device           ← GPU selection (Part I)
├── swapchain        ← image buffers for presenting frames (Part I)
├── render_pass      ← describes what we render to and how     ← NEW
├── shader           ← loads compiled GPU programs             ← NEW
├── pipeline         ← the full GPU configuration for drawing  ← NEW
├── command_pool     ← allocates command buffers               ← NEW
└── renderer         ← orchestrates everything                 ← UPDATED

And the shader source files live in a new location:

src/engine/assets/shaders/
├── triangle.vert    ← vertex shader (positions + colors)
├── triangle.frag    ← fragment shader (pixel colors)

Step 1: Render Pass

Source: render_pass.h · render_pass.cpp

A render pass describes where you're rendering to and how the output should be treated. It doesn't draw anything itself — it's a blueprint that tells Vulkan: "when I render a frame, I'll be writing to this kind of image, I want you to clear it first, and when I'm done, the image should be ready to display on screen."

If you're coming from web development, think of it as configuring a <canvas> context. When you call canvas.getContext('2d') or canvas.getContext('webgl'), you're telling the browser what kind of rendering you'll do and what the output format looks like. A render pass is the Vulkan version of that — except far more explicit.

struct RenderPass
{
    VkRenderPass renderPass;

    RenderPass();
    RenderPass(VkDevice device, VkFormat swapchainFormat);
    void Destroy(VkDevice device);
};

Creating a render pass involves three pieces:

Attachments

An attachment is the image you're rendering into — in our case, the swapchain image. We describe it with VkAttachmentDescription:

VkAttachmentDescription colorAttachment{};
colorAttachment.format = swapchainFormat;
colorAttachment.samples = VK_SAMPLE_COUNT_1_BIT;
colorAttachment.loadOp = VK_ATTACHMENT_LOAD_OP_CLEAR;
colorAttachment.storeOp = VK_ATTACHMENT_STORE_OP_STORE;
colorAttachment.initialLayout = VK_IMAGE_LAYOUT_UNDEFINED;
colorAttachment.finalLayout = VK_IMAGE_LAYOUT_PRESENT_SRC_KHR;

The key fields:

loadOp = CLEAR — when the render pass begins, clear the image (to black, or whatever clear color we set). This is like calling ctx.clearRect(0, 0, width, height) at the start of each frame in a canvas game.
storeOp = STORE — when the render pass ends, keep the rendered result. (The alternative, DONT_CARE, would let the driver discard it — useful for temporary buffers, not for something we want to display.)
initialLayout = UNDEFINED — we don't care what state the image is in before we start. We're going to clear it anyway.
finalLayout = PRESENT_SRC_KHR — when the render pass finishes, the image should be in a layout ready for presentation. Vulkan images can be in different "layouts" optimized for different operations (rendering, reading, presenting). This tells the driver to transition the image to a presentation-ready layout when we're done.

Subpasses

A render pass can contain multiple subpasses — stages that render to different combinations of attachments. Think of it like a multi-pass compositor: one pass renders the scene, another applies post-processing, another adds UI. Each subpass can read the output of the previous one.

For our triangle, we only need one subpass. It writes to a single color attachment:

VkAttachmentReference colorRef{};
colorRef.attachment = 0;
colorRef.layout = VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL;

VkSubpassDescription subpass{};
subpass.pipelineBindPoint = VK_PIPELINE_BIND_POINT_GRAPHICS;
subpass.colorAttachmentCount = 1;
subpass.pColorAttachments = &colorRef;

Before we explain the fields, it helps to understand how VkAttachmentDescription and VkAttachmentReference relate. The description defines what an attachment is — its format, how it's loaded and stored, and what layouts it transitions through. The reference is a pointer to one of those descriptions by index. Think of the render pass as having an array of attachment descriptions; subpasses refer to them by index rather than duplicating the definition.

attachment = 0 — index into the render pass's attachment descriptions array. We only have one attachment (the color attachment we described above), so it's index 0.
layout = VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL — the image layout to use during this subpass. This tells the driver to keep the image in a layout optimized for writing color data. This is different from initialLayout/finalLayout on the description, which control the layouts before and after the entire render pass.
pipelineBindPoint = VK_PIPELINE_BIND_POINT_GRAPHICS — this subpass uses the graphics pipeline (as opposed to VK_PIPELINE_BIND_POINT_COMPUTE for compute shaders). It determines which type of pipeline can be bound during this subpass.
colorAttachmentCount = 1 — how many color attachments this subpass writes to. A subpass can write to multiple render targets simultaneously (called MRT — multiple render targets), but we only need one.
pColorAttachments = &colorRef — pointer to the array of attachment references. The index in this array matters: layout(location = 0) out vec4 outColor in the fragment shader writes to pColorAttachments[0]. If you had two color attachments, location = 1 would write to pColorAttachments[1].

Dependencies

The subpass dependency is synchronization. It says: "don't start writing color until the swapchain image is actually available." Without this, the GPU might try to render into an image that's still being displayed on screen.

VkSubpassDependency dependency{};
dependency.srcSubpass = VK_SUBPASS_EXTERNAL;
dependency.dstSubpass = 0;
dependency.srcStageMask = VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT;
dependency.dstStageMask = VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT;
dependency.dstAccessMask = VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT;

VK_SUBPASS_EXTERNAL means "everything that happened before this render pass" — in our case, acquiring the swapchain image. The dependency ensures that our color writing waits until that acquisition is complete. If you've ever dealt with race conditions in async JavaScript, this is the same concept — but at the GPU hardware level.

Step 2: Shaders

Source: shader.h · shader.cpp

Shaders are programs that run on the GPU. If C++ code runs on the CPU, shaders are the code that runs on the GPU's thousands of tiny cores — in parallel, for every vertex and every pixel, every frame.

In web development, the closest equivalent is WebGL shaders. If you've ever written GLSL inside a <script type="x-shader/x-vertex"> tag or passed shader strings to gl.shaderSource(), that's the same language we're using here. The key difference is the compilation model.

The two shaders

Every graphics program needs at least two shaders:

Vertex shader — runs once per vertex. Its job is to determine where each vertex appears on screen. Think of it as a function that transforms 3D world coordinates into 2D screen coordinates.

What is a vertex? A vertex is a point in space — a corner of a shape. A triangle has 3 vertices, a cube has 8. Each vertex has a position (x, y, z coordinates), and can carry extra data like color or texture coordinates. Every 3D model you've ever seen in a game is made of thousands of triangles, and every triangle is defined by exactly 3 vertices.

Fragment shader — runs once per pixel (technically, per fragment — a candidate pixel). Its job is to determine what color each pixel should be. Think of it as a function that takes a pixel's position and produces an RGBA color.

Here's our vertex shader:

#version 450

vec2 positions[3] = vec2[](
    vec2( 0.0, -0.5),
    vec2( 0.5,  0.5),
    vec2(-0.5,  0.5)
);

vec3 colors[3] = vec3[](
    vec3(1.0, 0.0, 0.0),   // red
    vec3(0.0, 1.0, 0.0),   // green
    vec3(0.0, 0.0, 1.0)    // blue
);

layout(location = 0) out vec3 fragColor;

void main()
{
    gl_Position = vec4(positions[gl_VertexIndex], 0.0, 1.0);
    fragColor = colors[gl_VertexIndex];
}

A few things to unpack:

The positions are hardcoded in the shader. Normally you'd send vertex data from the CPU via a vertex buffer (we'll do that in a later part). For now, the triangle's three corners are baked directly into the shader code. The coordinates are in clip space: X goes from -1 (left) to 1 (right), Y goes from -1 (top) to 1 (bottom), and the center is (0, 0). Our triangle spans from the top-center to the bottom-left and bottom-right.

What is clip space? Clip space is the coordinate system the vertex shader outputs to. It's a normalized box where X and Y range from -1 to 1, regardless of your window's actual pixel size. The GPU later maps these coordinates to real pixels based on the viewport dimensions. Think of it like using percentages in CSS instead of pixels — you describe positions relative to the available space, not in absolute units.

gl_VertexIndex is a built-in variable that tells the shader which vertex it's currently processing (0, 1, or 2). It's like the index parameter in array.map((item, index) => ...) — it lets you look up per-vertex data.

gl_Position is the output — where this vertex appears on screen. It's a vec4(x, y, z, w) with four components:

x, y — the vertex position in clip space (provided by positions[gl_VertexIndex])
z (the 0.0) — the depth value. This determines how "near" or "far" the vertex is. It matters when triangles overlap — the GPU uses the depth buffer to decide which one is in front. For a flat 2D triangle, 0.0 (the middle of the depth range) works fine.
w (the 1.0) — the homogeneous coordinate, used for perspective division. After the vertex shader runs, the GPU divides x, y, and z by w to get the final position. With w = 1.0, the coordinates pass through unchanged. When we add a perspective camera later, the projection matrix will produce w values other than 1.0, which is what makes distant objects appear smaller.

layout(location = 0) out vec3 fragColor declares a variable that passes data from the vertex shader to the fragment shader. Let's break the syntax down:

layout(location = 0) — assigns this variable to output slot 0. The number is an index that connects outputs to inputs between shader stages. The fragment shader must declare a matching layout(location = 0) in vec3 ... to receive this data. If you had a second output, you'd use location = 1, and so on.
out — marks this as an output variable (data flowing out of the vertex shader to the next stage).
vec3 fragColor — the type and name. A vec3 holds 3 floats, which we use for RGB color.

The GPU automatically interpolates this value across the triangle's surface. So even though we set red, green, and blue at the three corners, every pixel in between gets a smooth gradient. This is how we get the rainbow effect without any extra work.

What is interpolation? Interpolation means calculating values between known points. If one corner of the triangle is red and another is green, what color should a pixel halfway between them be? The GPU answers this automatically: 50% red + 50% green = yellow. It does this for every pixel across the triangle's surface, producing smooth gradients. This is a hardware feature — the GPU does it for free, with no extra code needed.

The fragment shader is simpler:

#version 450

layout(location = 0) in vec3 fragColor;
layout(location = 0) out vec4 outColor;

void main()
{
    outColor = vec4(fragColor, 1.0);
}

Notice the symmetry with the vertex shader:

layout(location = 0) in vec3 fragColor — receives the interpolated color from the vertex shader. The location = 0 matches the location = 0 on the vertex shader's out declaration — that's how the GPU knows to wire them together. The in keyword (instead of out) marks this as an input. The variable names don't technically need to match — only the location number and type (vec3) matter — but using the same name keeps it readable.
layout(location = 0) out vec4 outColor — the fragment shader's own output. This writes to pColorAttachments[0] in the render pass — the swapchain image. The 1.0 appended in vec4(fragColor, 1.0) is the alpha channel (fully opaque).

That's it — the GPU's interpolation hardware did the hard work between the two shaders.

GLSL → SPIR-V compilation

In WebGL, you pass shader source code as strings and the browser compiles them at runtime. Vulkan doesn't work that way. Shaders must be compiled ahead of time into SPIR-V — a binary intermediate format, like bytecode.

Think of it as the difference between JavaScript and WebAssembly. JavaScript is text that the engine parses and compiles at runtime. WebAssembly is pre-compiled bytecode that the engine can load and execute directly. SPIR-V is the WebAssembly of GPU shaders.

The compiler is glslc (part of the Vulkan SDK). Our CMake build handles this automatically:

find_program(GLSLC glslc)

file(GLOB_RECURSE SHADER_SOURCES
    src/engine/assets/shaders/*.vert
    src/engine/assets/shaders/*.frag
)

foreach(SHADER ${SHADER_SOURCES})
    get_filename_component(SHADER_NAME ${SHADER} NAME)
    set(SPV "${SHADER_OUTPUT_DIR}/${SHADER_NAME}.spv")
    add_custom_command(
        OUTPUT ${SPV}
        COMMAND ${GLSLC} ${SHADER} -o ${SPV}
        DEPENDS ${SHADER}
    )
endforeach()

Each .vert and .frag file gets compiled to a .spv binary in the build directory. When the engine runs, it loads these .spv files from disk.

Loading shader modules

The Shader struct loads the compiled SPIR-V files and creates Vulkan shader modules:

struct Shader
{
    VkShaderModule vertModule;
    VkShaderModule fragModule;

    Shader();
    Shader(VkDevice device, const std::vector<char>& vertCode,
           const std::vector<char>& fragCode);
    void Destroy(VkDevice device);

    static std::vector<char> ReadFile(const char* path);
};

std::vector<char> — if you're coming from JavaScript, a vector is the C++ equivalent of an Array. It's a dynamically-sized, contiguous block of memory. std::vector<char> is an array of bytes — essentially a Buffer or Uint8Array in Node.js. We use it to hold the raw binary content of the SPIR-V files.

static on the ReadFile method means it belongs to the struct itself, not to any instance. It's like a static method in a JavaScript class — you call it as Shader::ReadFile(path) rather than on an instance. It doesn't need access to vertModule or fragModule, so it doesn't need an instance.

The ReadFile method does something specific to native development: it resolves the file path relative to the executable's location, not the current working directory. In Node.js, fs.readFileSync('./shaders/triangle.vert.spv') reads relative to where you ran node. In our case, the shader files are placed next to the executable by CMake, so we use _NSGetExecutablePath (macOS-specific) to find where the binary lives and build the path from there. This ensures the shaders are found regardless of which directory you run the demo from.

reinterpret_cast<const uint32_t*>(code.data()) — this appears in the shader module creation code and deserves explanation. The cast is needed because of a type mismatch between two APIs: C++'s file I/O reads data as char* (bytes), but Vulkan expects SPIR-V data as uint32_t* (pointer to 32-bit integers). Even though the .spv file contains 32-bit SPIR-V words, std::ifstream::read() has no concept of that — it treats all files as streams of bytes. So the data lands in a std::vector<char>, and we need reinterpret_cast to tell the compiler: "the bytes at this address — treat them as 32-bit integers instead." This doesn't change the data at all — it changes how the compiler interprets the pointer type. It's like using a DataView in JavaScript to read the same ArrayBuffer as either bytes or 32-bit values. The cast is zero-cost at runtime — it generates no instructions and performs no conversion. It's purely a compile-time mechanism. This is unavoidable: as long as you read files through C++'s char-based I/O and pass the data to an API that expects a different type, a cast is needed at one boundary or the other.

A key detail: shader modules are only needed during pipeline creation. Once the pipeline is built, the GPU has the shader programs baked in, and the modules can be destroyed. That's why in the renderer, we call shader.Destroy() right after creating the pipeline — the modules have served their purpose.

Step 3: Graphics Pipeline

Source: pipeline.h · pipeline.cpp

The graphics pipeline is the biggest, most detailed object in Vulkan. It describes everything the GPU needs to know to turn vertices into pixels on screen. Where WebGL lets you change individual state bits on the fly (gl.enable(gl.DEPTH_TEST), gl.blendFunc(...)), Vulkan makes you declare all of that upfront in a single immutable object.

Think of it like this. In Express.js, you might configure middleware one piece at a time — add CORS here, add compression there, add auth somewhere else. Each piece of middleware can be swapped at runtime. A Vulkan pipeline is the opposite approach: imagine if you had to declare your entire Express middleware stack as one frozen object at startup and couldn't change it. That's the tradeoff Vulkan makes — less flexibility at runtime in exchange for zero overhead, because the GPU driver can optimize the entire pipeline as a single unit.

struct Pipeline
{
    VkPipelineLayout layout;
    VkPipeline pipeline;

    Pipeline();
    Pipeline(VkDevice device, VkRenderPass renderPass, VkExtent2D extent,
             VkShaderModule vertModule, VkShaderModule fragModule);
    void Destroy(VkDevice device);
};

Creating a pipeline means configuring every stage of the GPU's rendering process. Let's walk through each one.

Shader stages

First, we tell the pipeline which shaders to use:

VkPipelineShaderStageCreateInfo vertStage{};
vertStage.stage = VK_SHADER_STAGE_VERTEX_BIT;
vertStage.module = vertModule;
vertStage.pName = "main";

VkPipelineShaderStageCreateInfo fragStage{};
fragStage.stage = VK_SHADER_STAGE_FRAGMENT_BIT;
fragStage.module = fragModule;
fragStage.pName = "main";

pName is the entry point function name in the shader — just like how a C++ program starts at main(), the shader starts at whatever function you specify here. You could technically have multiple entry points in one shader module, but "main" is the convention.

Vertex input

VkPipelineVertexInputStateCreateInfo vertexInput{};
vertexInput.sType = VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_STATE_CREATE_INFO;

This describes the format of vertex data coming from the CPU. Since our triangle positions are hardcoded in the shader, we leave this empty — no vertex buffers, no attributes. In a real application, this is where you'd describe the layout of your mesh data: "each vertex has a 3-float position, a 3-float normal, a 2-float UV coordinate, at these byte offsets."

What is a mesh? A mesh is a collection of vertices, edges, and faces that defines the shape of a 3D object. Think of it as a wireframe model — a bunch of triangles stitched together to approximate a surface. A cube is 8 vertices and 12 triangles. A character model might be thousands of vertices and tens of thousands of triangles. The mesh data (positions, normals, colors, texture coordinates for each vertex) is what gets uploaded from the CPU to the GPU via vertex buffers.

Input assembly

VkPipelineInputAssemblyStateCreateInfo inputAssembly{};
inputAssembly.topology = VK_PRIMITIVE_TOPOLOGY_TRIANGLE_LIST;
inputAssembly.primitiveRestartEnable = VK_FALSE;

This tells the GPU how to interpret the vertices. TRIANGLE_LIST means "every three consecutive vertices form one triangle." Other options include LINE_LIST (draw lines), POINT_LIST (draw dots), and TRIANGLE_STRIP (each new vertex forms a triangle with the previous two). For most 3D rendering, you'll use TRIANGLE_LIST.

Viewport and scissor

VkViewport viewport{};
viewport.width = static_cast<float>(extent.width);
viewport.height = static_cast<float>(extent.height);
viewport.minDepth = 0.0f;
viewport.maxDepth = 1.0f;

VkRect2D scissor{};
scissor.extent = extent;

The viewport defines the transformation from clip space (the -1 to 1 range in the shader) to pixel coordinates on the framebuffer. If your window is 800×600, the viewport maps the normalized coordinates to those 800×600 pixels.

The scissor is a clipping rectangle — pixels outside this rectangle are discarded. Usually it matches the viewport. Think of it as overflow: hidden in CSS. The viewport says "scale the content to fit here," and the scissor says "cut off anything outside this box."

Rasterizer

VkPipelineRasterizationStateCreateInfo rasterizer{};
rasterizer.polygonMode = VK_POLYGON_MODE_FILL;
rasterizer.cullMode = VK_CULL_MODE_BACK_BIT;
rasterizer.frontFace = VK_FRONT_FACE_CLOCKWISE;
rasterizer.lineWidth = 1.0f;

The rasterizer converts the triangle (defined by three vertex positions) into a set of pixel-sized fragments. This is the step where geometry becomes pixels.

What is rasterization? Rasterization is the process of converting vector shapes (triangles defined by vertex coordinates) into a grid of pixels. It's the same concept as when your browser renders an SVG — the browser takes the mathematical description of a shape and figures out which pixels on screen fall inside it. The GPU does this in hardware, for millions of triangles per frame.

What is a fragment? A fragment is a candidate pixel — a pixel-sized sample generated by the rasterizer that might end up on screen. It becomes an actual pixel after passing through the fragment shader and any blending/depth tests. The distinction matters because multiple fragments can compete for the same pixel position (e.g., overlapping triangles), and only one wins.

polygonMode = FILL — fill the triangle with color. Alternatives are LINE (wireframe) and POINT (just the corners).
cullMode = BACK_BIT — don't render triangles facing away from the camera. If a triangle's vertices appear in clockwise order on screen, it's front-facing; counter-clockwise means it's facing away. This optimization skips roughly half the triangles in a 3D scene (the back sides of objects you can't see).
frontFace = CLOCKWISE — defines which vertex winding order means "front-facing."

Multisampling

VkPipelineMultisampleStateCreateInfo multisampling{};
multisampling.sampleShadingEnable = VK_FALSE;
multisampling.rasterizationSamples = VK_SAMPLE_COUNT_1_BIT;

Multisampling is anti-aliasing at the hardware level — rendering each pixel at multiple sub-pixel positions and averaging the results. We disable it for now (1_BIT = one sample per pixel = no multisampling). Think of it as the image-rendering CSS property — it controls smoothing quality at the edges of shapes.

What is anti-aliasing? Anti-aliasing smooths out the jagged, staircase-like edges ("jaggies") that appear when diagonal or curved lines are drawn on a pixel grid. Without it, the edges of your triangle would look like tiny stairsteps. With it, the GPU blends edge pixels with the background to create the illusion of a smoother line. You've seen this in browsers — text and SVGs look smooth because the browser applies anti-aliasing automatically.

Color blending

VkPipelineColorBlendAttachmentState colorBlendAttachment{};
colorBlendAttachment.colorWriteMask =
    VK_COLOR_COMPONENT_R_BIT | VK_COLOR_COMPONENT_G_BIT |
    VK_COLOR_COMPONENT_B_BIT | VK_COLOR_COMPONENT_A_BIT;
colorBlendAttachment.blendEnable = VK_FALSE;

Color blending controls what happens when a new pixel overlaps an existing one. With blending disabled, the new pixel simply replaces the old one. With blending enabled, you can do transparency effects (like mix-blend-mode in CSS or globalCompositeOperation in canvas). The colorWriteMask says "write all four channels" — red, green, blue, and alpha. The | operator combines the bit flags, a common C/C++ pattern for expressing combinations of options.

Pipeline layout

VkPipelineLayoutCreateInfo layoutInfo{};
layoutInfo.sType = VK_STRUCTURE_TYPE_PIPELINE_LAYOUT_CREATE_INFO;

The layout describes what external data the pipeline receives — push constants (small chunks of data pushed per draw call) and descriptor sets (references to buffers, textures, etc.). We don't use either yet, so the layout is empty. Later, when we add textures and camera matrices, this is where we'll declare them.

Putting it together

All these pieces feed into a single VkGraphicsPipelineCreateInfo struct that creates the final pipeline object. This is one of the most expensive calls in Vulkan — the driver compiles and optimizes the entire pipeline state into GPU-specific instructions. That's why pipelines are created once and reused, never modified.

Step 4: Command Pool and Command Buffers

Source: command_pool.h · command_pool.cpp

In Vulkan, you don't call the GPU directly. You record commands into a command buffer, and then submit the entire buffer to the GPU at once. Think of it like writing a batch script instead of typing commands one by one — you prepare all the instructions ahead of time, and the GPU executes them as a unit.

If you've used Web Workers, the model is similar. You don't call functions on the worker directly — you post a message containing all the work, and the worker processes it asynchronously. Command buffers are the messages, and the GPU is the worker.

struct CommandPool
{
    VkCommandPool pool;
    std::vector<VkCommandBuffer> buffers;

    CommandPool();
    CommandPool(VkDevice device, uint32_t queueFamily, uint32_t bufferCount);
    void Destroy(VkDevice device);
};

A command pool is a memory allocator for command buffers. You create one pool per queue family, and it hands out command buffers from a pre-allocated memory region. This is more efficient than allocating each buffer individually — the same reason Node.js uses a Buffer pool internally.

VkCommandPoolCreateInfo poolInfo{};
poolInfo.flags = VK_COMMAND_POOL_CREATE_RESET_COMMAND_BUFFER_BIT;
poolInfo.queueFamilyIndex = queueFamily;

The RESET_COMMAND_BUFFER_BIT flag means we can reset and re-record individual command buffers. Without it, you'd have to reset the entire pool at once. We need per-buffer reset because we re-record commands every frame (the swapchain image index changes).

Command buffers are allocated from the pool. We allocate one per swapchain image — while the GPU is executing commands for one image, we can record commands for the next.

VkCommandBufferAllocateInfo allocInfo{};
allocInfo.commandPool = pool;
allocInfo.level = VK_COMMAND_BUFFER_LEVEL_PRIMARY;
allocInfo.commandBufferCount = bufferCount;

PRIMARY command buffers are submitted directly to the GPU queue. (There are also SECONDARY buffers that are called from primary buffers — like sub-functions, useful for multi-threaded recording. We don't need them yet.)

Step 5: Framebuffers

Framebuffers don't have their own file — they're created in the renderer because they're essentially just glue between the render pass and the swapchain images.

A framebuffer binds specific images to the attachment slots defined in the render pass. Remember, the render pass said "I'll write to one color attachment." The framebuffer says "and that attachment is this specific swapchain image view."

If the render pass is a form template with blank fields, the framebuffer is the filled-in form — it provides the actual images.

VkFramebufferCreateInfo fbInfo{};
fbInfo.renderPass = renderPass.renderPass;
fbInfo.attachmentCount = 1;
fbInfo.pAttachments = attachments;  // the swapchain image view
fbInfo.width = swapchain.extent.width;
fbInfo.height = swapchain.extent.height;
fbInfo.layers = 1;

We create one framebuffer per swapchain image. If the swapchain has 3 images, we have 3 framebuffers. Each one points to its respective image view so that when we start a render pass, Vulkan knows exactly which image to render into.

Step 6: Synchronization

This is the part of Vulkan that has no equivalent in web development. In JavaScript, the event loop handles all timing for you — you call requestAnimationFrame and the browser tells you when to draw. In Vulkan, you manage all the timing yourself, and getting it wrong means frames tear, the GPU reads stale data, or your program crashes.

We need three types of synchronization primitives:

Semaphores (GPU ↔ GPU)

Semaphores synchronize operations within the GPU. They're signals that one GPU operation raises when it's done, and another waits for before starting. Think of them as Promise objects — one operation resolves the promise, and another operation awaits it.

We create two per frame slot:

imageAvailableSemaphore — signaled when the swapchain image has been acquired and is ready to be rendered to
renderFinishedSemaphore — signaled when rendering is complete and the image is ready to be presented on screen

Fences (GPU → CPU)

Fences synchronize the GPU with the CPU. They let the CPU wait until the GPU finishes a specific operation. If semaphores are GPU-to-GPU Promises, fences are await on the CPU side.

We create one fence per frame slot:

inFlightFence — the CPU waits on this before recording new commands, ensuring the GPU is done with the previous frame's commands for this slot

VkFenceCreateInfo fenceInfo{};
fenceInfo.flags = VK_FENCE_CREATE_SIGNALED_BIT;

The SIGNALED_BIT flag starts the fence in the "already done" state. Without this, the very first frame would wait forever — there's no previous frame to finish, so the fence would never be signaled. Starting it as signaled lets the first frame pass through.

Frames in flight

We use two frames in flight (MAX_FRAMES_IN_FLIGHT = 2). This means the CPU can be recording commands for frame N+1 while the GPU is still executing frame N. It's double buffering for command submission — the same concept as the swapchain's image buffering, but applied to the CPU/GPU pipeline.

Each frame slot has its own semaphores and fence, so they don't interfere with each other.

Step 7: Drawing a frame

Source: renderer.cpp

This is where everything comes together. Every single frame, the DrawFrame method executes a sequence that touches every component we've built. Let's walk through it.

1. Wait for the previous frame

vkWaitForFences(device.device, 1, &inFlightFences[currentFrame], VK_TRUE, UINT64_MAX);
vkResetFences(device.device, 1, &inFlightFences[currentFrame]);

Before we do anything, we wait for the GPU to finish processing the last frame that used this slot. UINT64_MAX means "wait forever" — we have no timeout, we just block until it's done. Then we reset the fence so it can be used again.

This is the await in our rendering loop. Without it, we'd pile up commands faster than the GPU can execute them.

2. Acquire a swapchain image

uint32_t imageIndex;
vkAcquireNextImageKHR(device.device, swapchain.swapchain, UINT64_MAX,
                      imageAvailableSemaphores[currentFrame], VK_NULL_HANDLE, &imageIndex);

Ask the swapchain for the next available image to render to. The imageAvailableSemaphore will be signaled when the image is ready. We get back an imageIndex — which of the swapchain images we'll use this frame.

3. Record commands

VkCommandBuffer cmd = commandPool.buffers[imageIndex];
vkResetCommandBuffer(cmd, 0);

VkCommandBufferBeginInfo beginInfo{};
beginInfo.sType = VK_STRUCTURE_TYPE_COMMAND_BUFFER_BEGIN_INFO;
vkBeginCommandBuffer(cmd, &beginInfo);

We grab the command buffer for this image, reset it (clear the previous frame's commands), and start recording. Everything between vkBeginCommandBuffer and vkEndCommandBuffer is a batch of GPU instructions.

The actual draw commands are recorded inside a render pass:

VkClearValue clearColor = {{{0.0f, 0.0f, 0.0f, 1.0f}}};

VkRenderPassBeginInfo rpBegin{};
rpBegin.renderPass = renderPass.renderPass;
rpBegin.framebuffer = framebuffers[imageIndex];
rpBegin.renderArea.extent = swapchain.extent;
rpBegin.clearValueCount = 1;
rpBegin.pClearValues = &clearColor;

vkCmdBeginRenderPass(cmd, &rpBegin, VK_SUBPASS_CONTENTS_INLINE);
vkCmdBindPipeline(cmd, VK_PIPELINE_BIND_POINT_GRAPHICS, pipeline.pipeline);
vkCmdDraw(cmd, 3, 1, 0, 0);
vkCmdEndRenderPass(cmd);

vkEndCommandBuffer(cmd);

The triple-brace {{{0.0f, 0.0f, 0.0f, 1.0f}}} for the clear color looks unusual. This is because VkClearValue is a union — a C/C++ type that can hold different data in the same memory (a color, a depth value, or a stencil value). The outer braces initialize the union, the middle braces initialize its color member, and the inner braces initialize the float32[4] array inside the color. It's like a discriminated union in TypeScript (type ClearValue = { color: [number, number, number, number] } | { depth: number }) except without any tag field — you just write to whichever variant you need.

Three commands do all the work:

vkCmdBeginRenderPass — start the render pass, targeting the framebuffer for this swapchain image. The clear color (black, fully opaque) is applied here because we set loadOp = CLEAR.
vkCmdBindPipeline — activate our graphics pipeline (which shaders to use, how to rasterize, etc.).
vkCmdDraw(cmd, 3, 1, 0, 0) — draw 3 vertices, 1 instance. This invokes the vertex shader 3 times (once per vertex), the rasterizer generates fragments for the triangle, and the fragment shader colors each pixel.

4. Submit to the GPU

VkSubmitInfo submitInfo{};
submitInfo.waitSemaphoreCount = 1;
submitInfo.pWaitSemaphores = waitSemaphores;           // wait for image to be available
submitInfo.pWaitDstStageMask = waitStages;             // wait at the color output stage
submitInfo.commandBufferCount = 1;
submitInfo.pCommandBuffers = &cmd;
submitInfo.signalSemaphoreCount = 1;
submitInfo.pSignalSemaphores = signalSemaphores;       // signal when rendering is done

vkQueueSubmit(device.graphicsQueue, 1, &submitInfo, inFlightFences[currentFrame]);

We submit the recorded command buffer to the GPU's graphics queue. The submit info ties together the synchronization:

Wait on imageAvailableSemaphore before writing color output
Signal renderFinishedSemaphore when rendering completes
Signal inFlightFence so the CPU knows this frame's commands are done

5. Present

VkPresentInfoKHR presentInfo{};
presentInfo.waitSemaphoreCount = 1;
presentInfo.pWaitSemaphores = signalSemaphores;    // wait for rendering to finish
presentInfo.swapchainCount = 1;
presentInfo.pSwapchains = swapchains;
presentInfo.pImageIndices = &imageIndex;

vkQueuePresentKHR(device.presentQueue, &presentInfo);

Tell the presentation engine: "once the renderFinishedSemaphore is signaled, display image imageIndex on screen." The presentation engine handles the actual display timing (vsync, etc.).

6. Advance the frame counter

currentFrame = (currentFrame + 1) % MAX_FRAMES_IN_FLIGHT;

Cycle to the next frame slot. With MAX_FRAMES_IN_FLIGHT = 2, this alternates between 0 and 1.

The full frame in one picture

CPU                                    GPU
 │                                      │
 ├─ Wait for fence[N] ─────────────────►│ (GPU finishes previous frame N)
 ├─ Acquire image ─────────────────────►│ → signals imageAvailable[N]
 ├─ Record commands                     │
 ├─ Submit commands ───────────────────►│ waits imageAvailable[N]
 │                                      ├─ Execute render pass
 │                                      ├─ → signals renderFinished[N]
 │                                      ├─ → signals fence[N]
 ├─ Present ───────────────────────────►│ waits renderFinished[N]
 │                                      ├─ Display image
 ├─ N = (N + 1) % 2                     │
 └─ repeat                              │

The updated application

Source: application.cpp

The initialization sequence has grown to include all the new components:

Application::Application(int width, int height, const char* title)
    : window(width, height, title), renderer(),
      surface(renderer.instance.instance, window.window)
{
    renderer.InitDevice(surface.surface);
    renderer.InitSwapchain(surface.surface,
                           static_cast<uint32_t>(width),
                           static_cast<uint32_t>(height));
    renderer.InitPipeline();
    renderer.InitCommands();
    renderer.InitFramebuffers();
    renderer.InitSync();
}

The initialization order matters. Each step depends on what came before:

Order	Component	Depends on
1	Window	nothing
2	Instance	nothing
3	Surface	Instance + Window
4	Device	Instance + Surface
5	Swapchain	Device + Surface
6	Render Pass	Device + Swapchain format
7	Shaders	Device
8	Pipeline	Device + Render Pass + Shaders + Swapchain extent
9	Commands	Device + Swapchain image count
10	Framebuffers	Device + Render Pass + Swapchain image views
11	Sync	Device

And the game loop now draws:

void Application::Run()
{
    while (!window.ShouldClose())
    {
        window.PollEvents();
        renderer.DrawFrame();
    }

    Shutdown();
}

One line — renderer.DrawFrame() — is all it took to go from an empty window to a rendered triangle. That's the value of the layered architecture we've been building. The complexity of synchronization, command recording, pipeline binding — none of it leaks into the application layer.

Destruction now includes everything, in reverse order:

void Renderer::Destroy()
{
    vkDeviceWaitIdle(device.device);
    // semaphores, fences, framebuffers, command pool,
    // pipeline, render pass, swapchain, device, instance
}

The vkDeviceWaitIdle call at the top is critical — it blocks until the GPU has finished all submitted work. Without it, we'd start destroying resources while the GPU is still using them, which would crash (or worse, corrupt memory silently).

The final result

A rainbow triangle on a black background — proof that every piece of the pipeline is working. The vertex shader placed three vertices, the rasterizer filled the triangle, the fragment shader colored each pixel using the GPU's hardware interpolation, and the presentation engine displayed the result on screen.

What's next

We now have a working renderer. A triangle appears on screen, the colors are interpolated by the GPU, and the frame loop runs with proper synchronization. But the triangle is hardcoded in the shader — no vertex data comes from the CPU, no camera exists, and nothing moves.

In the next part, we'll render a full-screen quad with a procedural checker texture — generated entirely in the fragment shader, no image files needed. This will introduce UV coordinates, shader math, and the basics of pattern generation on the GPU.

Building a 3D engine from scratch with C++ and Vulkan for web developers Part I: Bootstrapping Vulkan

Remo H. Jansen — Sun, 17 May 2026 11:54:30 +0000

Why this project exists

My background is in web development. TypeScript, Node.js, React — that's been my world for years. I've spent a lot of time thinking about software architecture: SOLID principles, onion architecture, dependency injection, separation of concerns. All of that in the context of the web.

But the reason I got into technology in the first place has nothing to do with web forms or REST APIs. It was Super Mario 64. Playing it as a kid was my first time experiencing 3D graphics, and it left a permanent mark. The name "Ultra" is a tribute to the Ultra 64 — the original name of the Nintendo 64 before it shipped.

I've always wanted to understand how 3D engines work at every level. Not just "call a function and a triangle appears", but the actual machinery: how does the GPU know what to draw? How do pixels end up on the screen? What happens between your code and the display?

This project is my attempt to answer those questions by building a 3D engine from scratch with C++ and Vulkan. And since I'm learning as I go, I'm documenting everything so it can help others who are on the same path — especially those coming from a web development background like me.

The source code is hosted on Codeberg — a non-profit alternative to GitHub, hosted in the EU. You can find the repository at codeberg.org/remojansen/ultra.

I'm not sure how far this project will go. I'm doing it for fun and education, so I'll keep at it for as long as I find it engaging and exciting. There's no roadmap, no deadline, no promise of a "complete" engine at the end — just curiosity and momentum.

Prerequisites

This series assumes you're an experienced web developer. You should be comfortable with:

JavaScript and TypeScript — you write JS/TS daily and understand its type system, module system, and async patterns.
Node.js — you've built backend services, used npm, and understand how the Node runtime works.
Browser APIs — you have a working knowledge of the DOM, <canvas>, and how the browser renders pages.
Software architecture — concepts like separation of concerns, dependency injection, and layered architectures aren't new to you.

No prior C++ or graphics programming experience is required — that's what this series teaches. But you should be the kind of developer who's comfortable reading documentation and figuring out new tools.

The toolchain

Before we write any engine code, we need to understand the tools. If you're coming from the JavaScript ecosystem, the C++ toolchain will feel different — there's no npm install and no node index.js. But the concepts map surprisingly well.

Clang (the compiler)

Install: Getting Started with Clang

In JavaScript, your code runs directly in V8 or SpiderMonkey. These engines use JIT (Just-In-Time) compilation — they compile your code to machine code while the program is running, optimizing hot paths on the fly based on actual usage patterns.

C++ works the opposite way. Your code must be compiled into a binary before it can run. This is called AOT (Ahead-Of-Time) compilation. Clang is the compiler we use — it reads your .cpp files and produces machine code that runs directly on your CPU, with no runtime or interpreter involved.

The tradeoff is straightforward: JIT compilation gives you fast startup and runtime adaptability (the engine can optimize code paths it sees running frequently), but there's overhead — the compiler runs alongside your program. AOT compilation is slow upfront (you have to compile before you can test), but the output is fully optimized native code with zero runtime overhead. For a real-time graphics engine where every microsecond matters, that's the tradeoff we want.

CMake (the build system generator)

Install: CMake Download

In Node.js, you have package.json to describe your project. In C++, you have CMakeLists.txt. CMake reads this file and generates the actual build instructions for your platform.

It doesn't build your code directly — it generates build files for another tool (in our case, Ninja). This might feel like an unnecessary layer of indirection, but it's what allows the same project to build on macOS, Linux, and Windows without changes.

Our CMakeLists.txt defines two targets:

# Ultra engine library
file(GLOB_RECURSE ULTRA_SOURCES src/engine/*.cpp)
add_library(ultra_engine STATIC ${ULTRA_SOURCES})
target_include_directories(ultra_engine PUBLIC ${CMAKE_SOURCE_DIR}/src)
target_link_libraries(ultra_engine PUBLIC glfw Vulkan::Vulkan)

# Demo application
file(GLOB_RECURSE DEMO_SOURCES src/demo/*.cpp)
add_executable(demo ${DEMO_SOURCES})
target_link_libraries(demo PRIVATE ultra_engine)

The engine is built as a static library (ultra_engine), and the demo game is built as an executable (demo) that links against it. Let's unpack what that means.

An executable is a binary that your OS can run directly — it has an entry point (main()), and double-clicking it (or running it from a terminal) starts a process. A static library is not something you can run. It's a bundle of compiled code that sits there waiting to be included in an executable. Think of it as a .jar file in Java or a compiled npm package — it contains useful code, but it needs a host program to actually execute.

Linking is the process that connects them. When the compiler builds demo, it sees calls to functions like Application() and Run(). Those functions aren't defined in demo's own source code — they live in ultra_engine. The linker's job is to resolve these references: it looks through the static library, finds the compiled code for each function, and copies it directly into the final executable. The result is a single binary (demo) that contains everything it needs to run — both its own code and all the engine code baked in.

This is fundamentally different from how JavaScript modules work. When you import a package in Node.js, that package is loaded at runtime from node_modules. With static linking, there is no runtime lookup — the library's code is physically embedded in the executable at build time. The static library file itself isn't needed after compilation; the executable is entirely self-contained.

Ninja (the build executor)

Install: Ninja Getting Started

Ninja is the tool that actually runs the compiler. CMake generates the instructions, Ninja executes them. It's fast and minimal. You'll rarely interact with it directly — you just run cmake --build build and CMake calls Ninja for you.

vcpkg (the package manager)

Install: vcpkg Getting Started

This one will feel familiar. vcpkg is the closest thing C++ has to npm. We use it to install third-party libraries like GLFW. Dependencies are declared in vcpkg.json, and vcpkg resolves, downloads, and builds them:

{
  "dependencies": [
    "glfw3"
  ]
}

clang-format and clang-tidy (code quality)

Install: Both ship with the LLVM toolchain. If you installed Clang, you likely already have them.

clang-format is Prettier for C++. It enforces consistent code style automatically.
clang-tidy is ESLint for C++. It performs static analysis and catches common bugs and anti-patterns at compile time.

`.h` and `.cpp` files

In web development, you write everything in a single .ts or .js file. In C++, code is split into two file types:

Header files (.h) — These are the declarations. They describe what exists: the struct names, the method signatures, the types. Think of them as TypeScript interface files or .d.ts declarations. Other files include headers to know what's available.
Source files (.cpp) — These are the implementations. They contain the actual code that runs. Think of them as the concrete classes that implement a TypeScript interface.

This separation exists because the C++ compiler processes files independently. When application.cpp needs to use the Window struct, it doesn't read window.cpp — it reads window.h to learn the shape of Window, and the linker connects everything at the end.

The directory architecture

Separation of concerns matters just as much in a 3D engine as it does in a web application. We organize the source code into layers with clear responsibilities:

src/
├── engine/                  ← the engine (static library)
│   ├── core/
│   │   └── application     ← owns the game loop, orchestrates everything
│   ├── platform/
│   │   ├── window          ← OS window management (GLFW)
│   │   └── surface         ← bridge between the window and Vulkan
│   └── renderer/
│       ├── instance         ← Vulkan runtime initialization
│       ├── device           ← GPU selection and logical device
│       └── swapchain        ← image buffers for presenting frames
├── demo/
│   └── main.cpp            ← demo application that uses the engine

The dependency flow is one-directional:

main.cpp → Application → Renderer
                        → Platform (Window, Surface)

The platform layer deals with anything OS-specific (creating a window, connecting it to Vulkan). The renderer layer is pure Vulkan. The core layer ties them together. The demo application only knows about Application — it has no idea that GLFW or Vulkan exist.

If you've worked with the onion architecture in Node.js, this will feel familiar. The inner layers don't know about the outer layers. The renderer doesn't know about the window. The application sits at the boundary and wires everything together, just like a composition root in a dependency injection setup.

The initialization flow

Vulkan is an explicit API. Unlike OpenGL (or WebGL, if you've used it), Vulkan doesn't do anything for you behind the scenes. You have to set up every piece of the pipeline yourself. The initialization flow looks like this:

Instance → Window → Surface → Device → Swapchain

Each step depends on the one before it. But before we dive in, let's make sure we understand the two main technologies we're working with.

Step 1: What are Vulkan and GLFW?

If you're coming from web development, you've never had to think about how pixels get on the screen. The browser handles all of that. You write HTML and CSS, or draw to a <canvas>, and the browser's rendering engine figures out how to talk to the GPU.

In native development, there is no browser. Your application talks to the GPU directly through a graphics API. That's what Vulkan is — a low-level API that lets you send commands to the GPU: "create an image buffer", "run this shader program", "draw these triangles", "present this frame to the screen." It's the equivalent of the WebGL API you might have seen in the browser, but much more explicit and verbose. Where WebGL hides most of the complexity, Vulkan exposes it all. You control memory allocation, synchronization, command recording — everything. That's what makes it powerful for high-performance engines, and also what makes it hard to learn.

Vulkan is cross-platform — it runs on Windows, Linux, and Android natively. On macOS, it runs through MoltenVK, a translation layer that converts Vulkan calls into Apple's Metal API under the hood. This means we write Vulkan code and it works on macOS, but there are a few extra setup steps (portability extensions) that we'll see shortly.

One thing Vulkan does not do is create windows. It's a graphics API, not a windowing API. It can render pixels, but it has no idea how to open a window on your operating system, handle keyboard input, or respond to a close button. For that, we need a separate library.

That's where GLFW comes in. GLFW is a small C library that handles the OS-level stuff: creating a window, processing input events (keyboard, mouse, gamepad), and providing the bridge between the OS window and whatever graphics API you're using. Think of it as the window object in a browser — it gives you the container that your rendering will appear in, and it fires events when the user interacts with it.

GLFW also knows about Vulkan specifically. It can tell you which Vulkan extensions are needed on your platform to display rendered output in a window. Extensions in Vulkan are optional features — the core API is minimal, and everything platform-specific (like "how do I display pixels in a macOS window?") is provided as an extension. GLFW queries the system and returns the list of extensions you need to enable. We'll see this in action when we create the Vulkan instance.

With that context, let's walk through each initialization step.

Step 2: VkInstance

Source: instance.h · instance.cpp

The VkInstance is the entry point to the Vulkan API. Creating it initializes the Vulkan runtime on your machine. Nothing Vulkan-related can happen without it.

If you're coming from web development, think of it as opening a browser. The browser itself doesn't show any web page yet, but you now have access to the rendering engine. That's what VkInstance is — you're telling the system "I want to use Vulkan."

Let's look at the header:

#pragma once

#include <vulkan/vulkan.h>

struct Instance
{
    VkInstance instance;

    Instance();
    void Destroy();
};

A few things here that deserve explanation if you're new to C++:

struct — if you're coming from TypeScript, you'd expect to see class here. C++ has both struct and class, and they're almost identical. The only difference is default visibility: in a struct, everything is public by default; in a class, everything is private by default. We use struct throughout the engine because all our members are public — there's no reason to write class and then immediately add public: to undo the default. You'll see both conventions in C++ codebases; it's a style choice, not a functional one.

#pragma once is a preprocessor directive that tells the compiler "only include this file once, even if multiple files try to include it." Without it, you'd get duplicate definition errors. It's the C++ equivalent of making sure you don't import the same module twice — except in C++ the compiler doesn't handle it automatically.

#include <vulkan/vulkan.h> pulls in the Vulkan API declarations. This is conceptually the same as import vulkan from 'vulkan' in JavaScript — it tells the compiler that types like VkInstance exist and what they look like.

When we create the instance, three things happen:

We describe our application with VkApplicationInfo — metadata like the app name and Vulkan API version. Think of it as a User-Agent header in HTTP.
We ask GLFW for the required extensions — as we discussed in Step 1, GLFW knows which Vulkan extensions are needed to present to a window on your platform. On macOS, this includes the MoltenVK portability extensions we mentioned earlier.
We enable validation layers (in debug builds only) — these are a runtime linter. They watch every Vulkan API call and warn you if you're doing something wrong. Incredibly useful for learning.

Step 3: Window

Source: window.h · window.cpp

The window is your connection to the operating system. It's the rectangle on your screen where pixels will appear. We use GLFW to create and manage it — as we covered in Step 1, GLFW handles window creation, input, and OS events across platforms.

#pragma once

#include <GLFW/glfw3.h>
#include <cstdio>
#include <cstdlib>

struct Window
{
    GLFWwindow* window;

    Window();
    Window(int width, int height, const char* title);

    bool ShouldClose() const;
    void PollEvents() const;
    void Destroy();
};

Notice the const keyword after the method declarations — bool ShouldClose() const. This has no equivalent in JavaScript or TypeScript. It's a promise to the compiler that this method will not modify the object. It only reads data, never writes it. If you accidentally try to change a member variable inside a const method, the compiler will reject it. Think of it as a read-only contract — like Readonly<T> in TypeScript, but enforced at the method level rather than on the type. Destroy() is not const because it modifies state (it tears down the window).

This is the first time we see a pointer, so let's talk about what GLFWwindow* window means.

In JavaScript, when you write const element = document.getElementById('app'), you get a reference to a DOM element. You don't get the element itself — you get something that points to where the element lives in memory. If the browser moved it in memory, your reference would be updated.

In C++, a pointer is the explicit version of this. GLFWwindow* means "a memory address where a GLFWwindow lives." The * is what makes it a pointer. You don't own the GLFW window data directly — GLFW allocates it internally and gives you a pointer to it. When you pass this pointer to other GLFW functions, they follow the address to find the actual window data.

The important thing to know right now is: a pointer is an address. GLFWwindow* window means "window is a variable that holds the address of a GLFWwindow somewhere in memory."

The window has a simple job. It creates an OS window via GLFW and exposes three operations:

ShouldClose() — has the user clicked the close button?
PollEvents() — check for OS events (mouse, keyboard, resize, close). Without this, the OS thinks your app is frozen.
Destroy() — tear it all down.

Note the GLFW_NO_API hint in the implementation:

glfwWindowHint(GLFW_CLIENT_API, GLFW_NO_API);

This tells GLFW "don't set up OpenGL — we're going to use Vulkan instead." By default GLFW creates an OpenGL context, which we don't want.

Step 4: VkSurfaceKHR

Source: surface.h · surface.cpp

The surface is the bridge between your OS window and Vulkan. It answers the question: "where should Vulkan draw its pixels?"

In web terms, imagine you have a <canvas> element and a WebGL context. The canvas is the window. The WebGL context is Vulkan. The surface is the binding between them — it's what allows the rendering API to output to that specific rectangle on the screen.

#pragma once

#define GLFW_INCLUDE_VULKAN
#include <GLFW/glfw3.h>

struct Surface
{
    VkSurfaceKHR surface;

    Surface();
    Surface(VkInstance instance, GLFWwindow* window);
    void Destroy(VkInstance instance);
};

#define GLFW_INCLUDE_VULKAN is a preprocessor macro. JavaScript has nothing like this. Before the compiler even sees your code, a separate step called the preprocessor runs through it and performs text substitution. #define GLFW_INCLUDE_VULKAN creates a flag — it doesn't produce any code itself. When GLFW's header file is included on the next line, it checks whether this flag exists, and if so, it also pulls in the Vulkan type declarations (like VkInstance and VkSurfaceKHR). Without it, GLFW wouldn't know about Vulkan types. Think of it as a compile-time feature flag — like an environment variable, but resolved before compilation rather than at runtime.

The surface needs both the VkInstance and the GLFWwindow* because it sits between the two worlds. GLFW provides a helper function (glfwCreateWindowSurface) that handles the platform-specific details — on macOS it creates a Metal surface, on Linux it creates an X11 or Wayland surface, on Windows it creates a Win32 surface.

This is why the surface is created after both the instance and the window exist, and why it lives in the platform/ directory — it fundamentally wraps an OS-level concept, even though it uses a Vulkan type.

Step 5: VkDevice

Source: device.h · device.cpp

The device step is actually two things: picking a physical GPU and creating a logical device.

Picking a physical device

Your machine might have multiple GPUs (an integrated one and a discrete one, for example). We need to pick one that can do what we need. The selection process works like this:

Enumerate all GPUs on the system
For each GPU, check its queue families — groups of "workers" that can do different things (graphics, compute, transfer, presentation)
Find a GPU that has both a graphics queue family (can draw things) and a present queue family (can display things on our surface)
Check that the GPU supports the swapchain extension (needed to present rendered frames)
Pick the first GPU that passes all checks

If you're coming from web development, think of queue families as different thread pools. One pool handles graphics work, another handles displaying results on screen. Often they're the same pool, but the API makes you check.

Creating the logical device

Once we've picked a GPU, we create a logical device — our application's handle to the GPU. The distinction matters: VkPhysicalDevice represents the actual hardware, VkDevice represents our connection to it. Multiple applications can each have their own VkDevice pointing at the same VkPhysicalDevice.

When creating the logical device, we request:

Queues from the families we identified — these are the mailboxes where we'll send draw commands
Extensions — specifically VK_KHR_swapchain, so we can present frames

After creation, we retrieve the queue handles. These are what we'll use later to submit rendering commands and present images to the screen.

What is a shader? A shader is a small program that runs on the GPU. We'll write these in Part II. For now, just know that the GPU executes shader programs to determine where vertices appear and what color each pixel should be.

Step 6: Swapchain

Source: swapchain.h · swapchain.cpp

What is a frame? A frame is a single complete image displayed on your screen. Movies run at 24 frames per second — 24 still images flashing by so fast they look like motion. Games work the same way, typically at 60 frames per second. Each frame is drawn from scratch by the GPU, displayed briefly, then replaced by the next one.

The swapchain is a queue of images that take turns being displayed on screen. Think of it like double or triple buffering in a <canvas> game.

Imagine you have 2–3 offscreen canvases. You draw to one while the browser displays another. When you finish drawing, you swap them — the freshly drawn one goes to the screen, and the previously displayed one is freed up for the next frame. That's exactly what a swapchain does.

Image A: [being displayed on screen]
Image B: [GPU is drawing the next frame here]
Image C: [waiting, ready for the GPU to use next]
         ↓
         swap → Image B goes to screen, Image A is now free

Without it, the user would see half-finished frames — a visual glitch called tearing.

What is tearing? Tearing is when the top half of the screen shows one frame and the bottom half shows the next, because the display refreshed mid-draw. It happens when the GPU writes to the same image the monitor is currently reading from. The swapchain prevents this by keeping displayed and in-progress images separate.

Creating the swapchain involves querying the surface for what it supports and choosing the best options:

Format — the pixel format and color space. We prefer B8G8R8A8_SRGB (BGRA 8-bit with sRGB). This is the standard format for monitors — sRGB ensures colors look correct.
Present mode — how swapping works. MAILBOX is triple buffering (low latency, GPU replaces queued frames). FIFO is vsync (like requestAnimationFrame — guaranteed to be available, smooth but higher latency). We prefer mailbox, fall back to FIFO.

What is vsync? Vsync (vertical sync) locks your frame rate to the monitor's refresh rate (usually 60Hz). It prevents tearing by waiting for the monitor to finish displaying one frame before swapping in the next. requestAnimationFrame in browsers is essentially vsync — the browser calls your callback once per display refresh.

Extent — the resolution, usually matching the window size.

After creating the swapchain, we get the image handles (the driver created them, we just get references) and create image views for each one. An image view is a "lens" that tells Vulkan how to interpret an image — its format, that it's 2D, that we care about the color channels.

Putting it all together: Application

Source: application.h · application.cpp

The Application struct sits at the top and orchestrates everything. It's the composition root — the one place that knows about all the pieces and wires them together.

Application::Application(int width, int height, const char* title)
    : window(width, height, title), renderer(),
      surface(renderer.instance.instance, window.window)
{
    renderer.InitDevice(surface.surface);
    renderer.InitSwapchain(surface.surface,
                           static_cast<uint32_t>(width),
                           static_cast<uint32_t>(height));
}

Two pieces of syntax here that have no JavaScript equivalent:

Member initializer list — the : window(width, height, title), renderer(), surface(...) part after the constructor signature. In JavaScript, you'd write this.window = new Window(width, height, title) inside the constructor body. C++ has a separate syntax for this because of how memory works: when an Application is created, all its member variables need to be constructed before the constructor body runs. The initializer list is where you tell the compiler how to construct each member. If you skipped it and assigned inside the body instead, each member would first be default-constructed (possibly doing wasted work) and then reassigned — the initializer list avoids that double initialization.

static_cast<uint32_t>(width) — explicit type conversion. In JavaScript, numbers are just numbers — there's one number type. In C++, int and uint32_t (unsigned 32-bit integer) are different types, and the compiler will warn you about implicit conversions between them because going from signed to unsigned can lose information (negative values wrap around). static_cast says "I know these types are different, and I'm intentionally converting." It's the C++ equivalent of writing width as number in TypeScript — an explicit annotation that makes the intent clear.

Creation order matters because each step depends on the previous one:

Order	Component	Depends on
1	Window	nothing
2	Instance	nothing
3	Surface	Instance + Window
4	Device	Instance + Surface
5	Swapchain	Device + Surface

Destruction is the reverse — you always tear down in the opposite order of creation, so nothing tries to use something that's already gone:

void Application::Shutdown()
{
    surface.Destroy(renderer.instance.instance);
    renderer.Destroy();  // swapchain → device → instance
    window.Destroy();
}

If you're coming from JavaScript, you might wonder: why do we need to call Destroy() at all? In JS, you just stop referencing an object and the garbage collector eventually frees the memory. C++ has no garbage collector. When you allocate a resource — a Vulkan device, a window, a block of GPU memory — it stays allocated until you explicitly release it. If you forget, it leaks: the resource is gone from your program's perspective but still held by the OS or GPU driver until the process exits. Every Destroy() method you see in this engine is doing what the garbage collector would do for you in JavaScript — but manually and in a specific order, because these resources depend on each other.

The game loop is simple for now:

void Application::Run()
{
    while (!window.ShouldClose())
    {
        window.PollEvents();
    }

    Shutdown();
}

The application owns the loop. The window just reports events. The renderer doesn't know about the loop at all. As the engine grows, the loop will expand to include scene updates and render calls, but the structure stays the same.

The demo application is intentionally minimal — two lines of real code:

int main() {
    Application app(800, 600, "Ultra 3D Engine");
    app.Run();
    return EXIT_SUCCESS;
}

This is the whole point of layered architecture. The complexity of Vulkan initialization, GPU selection, swapchain creation — none of that leaks into the application code. It's all behind Application, exactly where it should be.

What's next

At this point we have a window, a Vulkan instance, a surface, a device, and a swapchain. The infrastructure is in place. We have images to render to and a GPU ready to receive commands.

In the next part, we'll create the render pass and graphics pipeline — the point where we actually tell the GPU what to draw.

From Rigidity to Explicitness: How AI Changes the Role of Constraints in Software

Remo H. Jansen — Tue, 05 May 2026 20:21:12 +0000

For a long time, software engineering has talked about a familiar trade-off: rigid vs flexible systems.

Static typing vs dynamic typing
Relational databases vs schema-less storage
Strict architectures vs “just ship it” codebases

The usual story is simple: rigidity slows you down, flexibility speeds you up.

But this framing is becoming less useful.

In the context of AI-assisted development, the real axis of optimization is shifting away from rigidity vs flexibility and toward something more precise:

implicit systems vs explicit systems

And that shift changes how we should think about many foundational technologies.

The old model: speed vs structure

Traditionally, we’ve optimized software systems around a few competing forces:

Solo developers prefer speed and flexibility
Teams prefer structure and predictability
Large systems gradually accumulate constraints to manage complexity

This is why tools like Node.js have thrived for rapid iteration, while others like TypeScript gained adoption as teams and codebases scaled.

Similarly:

NoSQL systems optimized for flexibility and scaling
SQL systems optimized for consistency and relational integrity

The underlying assumption was always the same:

Structure slows you down locally, but helps you scale globally.

That assumption is still true—but incomplete.

The missing variable: AI changes the bottleneck

AI tools fundamentally change what part of the development process is expensive.

Writing code is becoming cheaper.

What remains expensive is:

verifying correctness
ensuring integration consistency
understanding system behavior
validating assumptions across components

In other words:

the bottleneck is shifting from generation to verification

And that shift matters more than it first appears.

Because once verification becomes the limiting factor, the value of “good structure” changes.

The rise of underused verification practices

If AI reduces the cost of producing code, then the relative value of practices that verify, constrain, and stabilize systems increases.

This doesn’t just affect language or database choices—it also changes which engineering practices become mainstream.

Techniques that were historically seen as “too expensive” or “overkill” in many teams may become default:

architecture-level unit testing (validating system boundaries, not just functions)
stronger contract testing between services
more explicit dependency boundaries and enforcement
formalized integration testing as a first-class design tool
schema- and contract-driven development workflows

Many of these practices already exist, but they are often underused because they slow down early iteration.

However, in an AI-assisted environment:

generating code becomes cheap, but validating system correctness does not.

So the bottleneck shifts toward practices that reduce ambiguity and enforce correctness at system boundaries.

In that context, what used to feel like “over-engineering” starts to look like:

necessary structure for managing AI-generated complexity

Rigidity is the wrong abstraction

The term “rigid” bundles together several different properties:

explicitness
constraint density
flexibility loss
verification ease

These are not the same thing.

A better distinction is:

Implicit systems → rely on inference, conventions, and runtime discovery
Explicit systems → encode structure, constraints, and intent directly

This matters because AI systems don’t “understand” code in a human sense—they infer meaning from signals.

So the question becomes:

How much of the system’s intent is explicitly encoded vs left to inference?

Why explicit systems matter more in an AI-assisted world

AI systems are especially good at pattern completion, but weaker at:

resolving ambiguous intent
inferring hidden constraints reliably
maintaining global consistency across evolving systems

So explicit systems act as:

high-signal context providers for both humans and AI

For example:

A SQL schema provides a machine-readable model of relationships
Type systems provide executable contracts for data flow
API specs define integration boundaries unambiguously
effect systems make side effects visible instead of implicit

In this framing, constraints are not overhead.

They are context compression mechanisms.

A concrete implication: revisiting “flexibility-first” choices

If verification becomes the dominant cost in development, then systems that maximize explicit structure become increasingly valuable.

This leads to a natural reevaluation of several long-standing trade-offs:

Relational databases over schema-less designs when correctness and reasoning matter
Static typing over dynamic typing for improving integration safety and AI-assisted code generation
Explicit effect systems (as seen in functional programming patterns) for making side effects observable
Contract-based communication (e.g. gRPC-style interfaces) over loosely structured HTTP conventions
Actor-model-style architectures for isolating state and making concurrency behavior explicit

This is not a claim that one category replaces another universally.

It is a shift in evaluation criteria:

How easily can correctness be verified by both humans and machines?

SQL vs NoSQL is not about rigidity

Take databases as an example.

Relational systems like SQL are often described as “rigid” because they enforce schemas and constraints.

But another way to see them is:

they make assumptions explicit and queryable

That explicitness has downstream effects:

relationships are defined, not inferred
constraints are enforced, not assumed
structure is inspectable by tools and systems

NoSQL systems trade some of this explicitness for flexibility and schema evolution speed.

Neither is inherently better.

But in an AI-assisted workflow, explicit structure becomes more valuable because it reduces the cost of verification and integration.

Static vs dynamic typing: a similar shift

The same pattern appears in typing systems.

A static system like TypeScript encodes:

// Data shape
type User = {
  id: string;
  name: string;
  email: string;
};

// Interface contract
function getUser(id: string): Promise<User> {
  // implementation
}

// Integration constraint
function sendEmail(user: User) {
  console.log(user.email);
}

A dynamic system like JavaScript leaves much of that implicit until runtime:

// No enforced structure
function getUser(id) {
  return fetch(`/api/users/${id}`).then(res => res.json());
}

// Assumes shape at runtime
function sendEmail(user) {
  console.log(user.email); // may fail if email is missing
}

In a human-only workflow, both are viable depending on team size and discipline.

But in an AI-assisted workflow, static structure becomes more than safety—it becomes machine-readable intent.

The deeper shift: from human-readable to machine-verifiable systems

What’s actually changing is not that constraints are becoming more important in general.

It’s that constraints are now serving a second audience:

AI systems that need structured, unambiguous context to assist effectively.

This introduces a new design pressure:

not just “is this readable for humans?”
but “is this verifiable and interpretable for machines?”

That changes how we evaluate architecture, APIs, and even language design.

Conclusion: toward explicit-by-design systems

The old framing of software trade-offs as rigidity vs flexibility is becoming less useful.

A more accurate model is emerging:

implicit inference vs explicit structure

AI shifts the balance because it reduces the cost of generating code—but increases the importance of verifying it.

In that world, the most effective systems are not necessarily the most flexible or the most rigid.

They are the ones that are:

explicit enough to be verifiable, but not so constrained that they reduce productive expression

That balance—not rigidity—is what will define good architecture in the AI-assisted era.

Source code is now a common good, and SaaS is mostly dead

Remo H. Jansen — Fri, 27 Mar 2026 23:26:48 +0000

Back in 2023, I wrote a post titled "The upcoming SaaS bubble burst" where I argued that AI would enable individual developers to replicate SaaS products at a fraction of the cost, turning high-margin businesses into commodities.

I was wrong about the timeline. It's happening right now.

The Legal Hack That Started It All

In 1982, a company called Phoenix Technologies wanted to create IBM PC-compatible computers. The problem? IBM's BIOS was copyrighted. Their solution was a "clean room" process: one team reverse-engineered the BIOS and wrote a functional specification, then a completely separate team—who had never seen the original code—implemented a new BIOS from scratch based solely on that specification.

It worked. Courts ruled it legal because the second team independently created the code; they never copied anything. This became established legal precedent.

Fast forward to March 2025: a satirical (but functional) service called Malus.sh appeared, offering "Clean Room as a Service." The name itself—Latin for "evil"—was a joke, but the concept was deadly serious. Pay them, upload your dependency manifest, and their AI systems would reimplement your open source dependencies under any license you wanted. GPL becomes MIT. AGPL becomes proprietary.

The service was presented at FOSDEM as a warning to the open source community. The Hacker News discussion exploded with over 1,400 comments debating whether this was the end of copyleft or just a clever thought experiment.

Around the same time, someone attempted exactly this with the chardet Python library—using Claude to rewrite it from LGPL to MIT. The open source community was furious.

But here's what truly terrifies me: this is unstoppable.

The Two Directions of Liberation

There are two scenarios playing out simultaneously:

1. Open Source → Commercial (GPL → MIT → Proprietary)

Companies have always hated copyleft licenses like GPL and AGPL because they require sharing modifications. If you can reimplement the software cleanly, you eliminate that obligation. No more "viral" licensing concerns. No more open source compliance headaches.

2. Commercial → Open Source

This is the scenario most people aren't talking about. SaaS applications don't expose their source code, but they do expose their behavior. Every button click, every API response, every error message is observable. Feed that to an LLM, produce a specification, have another LLM implement it. The source code was never "seen."

For SaaS, the clean room defense is even stronger because there's literally no source code to contaminate the process.

Why This Is Unstoppable

I know what you're thinking: "But the LLMs were trained on that code! They've seen it!"

You're right. Someone demonstrated that Claude can reproduce chardet's source code verbatim from memory, including the license headers. The training data is contaminated.

But here's the thing: the architecture can be fixed.

Imagine a two-LLM system:

LLM 1 ("dirty room"): Analyzes only public documentation, API specs, README files, type definitions. Never sees source code.
LLM 2 ("clean room"): Trained specifically WITHOUT the target project's code. Receives only the specification from LLM 1.

Or a three-LLM system. Or more. Each hop makes the provenance harder to trace. Add different base models, different hosting providers, different jurisdictions. Good luck proving in court that the final output was "copied."

For SaaS, it's even simpler. Point an AI agent at the UI. Let it click around, observe responses, document behavior. Feed that documentation to a clean model. Where's the infringement?

The legal standard for clean room implementation was designed for humans with imperfect memories working for months. When AI can do it in hours with perfect documentation, the entire framework breaks down.

The Government Dilemma

Governments will eventually have to respond. But their options are all bad:

Software patents: The only real way to protect ideas (not just expression) is patents. But broad software patents would stall innovation even more than copyright does. We already tried this in the 2000s with patent trolls. Nobody wants to go back.

Stronger copyright enforcement: Unenforceable across borders. The moment one country allows this, the "liberated" code can be downloaded legally from servers in that jurisdiction.

Do nothing: Tech companies lose their moats. VC-funded SaaS collapses.

I expect different regions to react differently:

The US has strong tech lobbying, but also a free-market ideology that resists new restrictions.
The EU tends to prioritize consumer interests over corporate ones. Cheaper software sounds pretty good to voters.
Other countries have less to lose and may deliberately permit this to erode Western IP advantages.

At the end of the day, if one country in the world allows AI-powered clean room reimplementation, you'll be able to download that "liberated" code from that country legally.

The Ironic Outcome: Everything Becomes Open Source

Here's the twist I didn't see coming: GPL exists to ensure software stays free forever. Richard Stallman created it because he believed users should have the freedom to run, study, modify, and share software.

AI clean rooms might achieve exactly that outcome—just not in the way anyone intended.

Think about it:

Company A takes GPL software and relicenses it as proprietary.
Company B takes Company A's proprietary software and reimplements it as open source.
Company C takes that and makes it proprietary again.
Repeat forever.

The end state? Everything converges to effectively public domain. You can't maintain a proprietary advantage when anyone can recreate your software in hours. You can't maintain copyleft when it can be circumvented just as easily.

Source code becomes a common good. Not because of ideology, but because protection becomes technically impossible.

What Can You Actually Sell?

When code has no scarcity, what's left?

Convenience. That's it.

You can run the software yourself for free. Set up your own servers, handle updates, manage disaster recovery, deal with security patches—or pay someone a monthly fee to do it for you.

But here's the problem: when self-hosting becomes trivial (thanks to agentic SRE and AI-powered infrastructure management), convenience becomes less valuable. Margins compress. The race to the bottom accelerates.

Winners and Losers

The Real Winners: Cloud Infrastructure Providers

AWS, GCP, Azure. They own the hardware, the data centers, the network infrastructure. Whether you're running open source or proprietary software, you're paying them for compute. They win regardless of who owns the code.

In the short term, there might be shock to the system if an AI company like OpenAI fails spectacularly. That could damage cloud valuations temporarily. But long term? I'm bullish.

The Losers: Pure SaaS Companies

Any SaaS company whose value proposition is primarily "we wrote software that does X" is in trouble. If your moat is code, you no longer have a moat.

And here's the brutal reality: most SaaS companies were never designed for low-margin economics. They have massive operating costs—large engineering teams, expensive offices, bloated sales organizations, venture debt—all predicated on the assumption of 70-80% gross margins. When margins collapse to 20-30% (or lower), the math simply doesn't work. They can't cut costs fast enough. Many will go bankrupt.

This isn't a slow decline. SaaS companies with high burn rates and no data moat will face an existential crisis the moment a credible open source alternative appears. And with AI, that alternative can appear overnight.

The Exception: Data Moats

Some SaaS companies will survive—specifically, the ones that control proprietary data that can't be recreated:

LinkedIn: The value is the network graph, not the code
Bloomberg: Proprietary real-time financial feeds
Palantir: Government contracts + classified data access
Credit bureaus: Decades of credit history data
Snowflake: Data gravity—once your data is there, leaving is painful

If your software generates or aggregates unique data that can't be reproduced, you have something AI can't replicate. If your software is just features, you're toast.

The Next Frontier: Open Source Hardware

I cannot speak for Richard Stallman, but I believe the vision behind GPL was to ensure that software would be free forever—like in the early days of computing when code was shared openly.

AI-powered clean rooms may finally get us there, ironically through market forces rather than ideology.

The next frontier is open source hardware. The designs can be liberated just like software, but manufacturing remains controlled by corporations with factories, supply chains, and regulatory approvals. Still, open hardware could finally kill proprietary drivers—another piece of the dream.

I personally believe this trajectory is better for consumers. Software becomes cheaper. Innovation accelerates. The tax on digital goods imposed by intellectual property regimes gradually evaporates.

Final Thoughts

The SaaS bubble I predicted in 2023 is bursting. The mechanism is just different than I expected—not market forces alone, but a fundamental breakdown in the ability to protect software as property.

In 5-10 years, I expect:

Most software to be effectively open source (by force or by choice)
SaaS margins to collapse except for data-moat businesses
Cloud infrastructure to be the dominant value capture layer
The concept of "software ownership" to feel as quaint as owning individual MP3 files

Is this good? Is this bad? Honestly, I don't know. But I do know it's happening. And the teams that prepare for a world where code has no scarcity will be the ones that thrive.

What do you think? Am I too pessimistic about SaaS? Too optimistic about open source? I'd love to hear your perspective in the comments.

If you found this interesting, you might also enjoy my previous posts on Agent Driven Development and the original SaaS bubble prediction from 2023.

The Infinite Loop Part III: Agentic Software Engineering

Remo H. Jansen — Fri, 27 Mar 2026 22:18:46 +0000

Creating a culture of trust, ownership, and data-driven continuous experimentation—now accelerated by AI

The Infinite Loop (L∞P) was introduced in 2023 as a software development methodology that unified lessons from Agile, Lean UX, Kanban, DevOps, and Product-led growth. Its core philosophy—trust, ownership, outcomes over outputs, no arbitrary deadlines—was designed to create high-performance teams that could achieve flow state and deliver genuine customer value.

Three years later, AI has fundamentally changed how software is built. Large language models, agentic workflows, and AI-assisted development have compressed the time from idea to implementation. What took days now takes hours; what took hours now takes minutes.

But the principles of L∞P are not obsolete—they are more relevant than ever.

In 2023, the core problem was that companies underinvested in discovery and used time boxes that corrupted quality. Teams rushed to build without proper validation, and artificial deadlines led to technical debt accumulation and output-over-outcome thinking.

AI doesn't change this—it amplifies it. Teams that skip discovery will now ship bad products faster. The new constraint is verification: AI generates code quickly, but proving correctness requires human judgment and automation investment. The teams that automate verification fastest will ship fastest.

This update to L∞P acknowledges this shift while preserving the core philosophy that made it effective.

How AI Accelerates the Loop

AI transforms every phase of the product development cycle—but humans remain in control of judgment and validation.

Research & Discovery: AI synthesizes market data, customer feedback, and competitive intelligence faster than manual research. Teams can explore more hypotheses with the same effort.

Prototyping: AI generates functional prototypes that enable real user validation faster and more effectively than static UX mockups. Users interact with working software, not wireframes—leading to higher-quality feedback earlier.

Discovery → Development Transition: AI assists the translation from validated discovery to technical specification. It asks refinement questions, identifies gaps in implementation plans, surfaces edge cases, and highlights integration risks before development begins.

Implementation: AI accelerates code generation, but humans own architecture decisions and review all output. The role shifts from typing to steering and verifying.

Verification: AI cannot be 100% trusted with verification, but it accelerates it significantly—automated vulnerability scanning, test generation, code review assistance, and anomaly detection. Human judgment remains the final gate.

AI compresses time but does not replace human judgment. Discovery still requires validation with real users. Architecture still requires human design. Verification still requires human oversight. AI makes the loop faster—it doesn't make corners safe to cut.

Acceleration works both ways. If a team is leveraging AI correctly—investing in discovery, maintaining verification automation, addressing technical debt—everything works well and faster. But if things are going wrong, they go wrong faster too.

Technical debt that was accumulating before AI? Now it accumulates twice as fast. Vulnerabilities that went unnoticed? They multiply faster. Poor architectural decisions? They propagate through the codebase before anyone catches them. Teams skipping discovery? They ship the wrong product to customers in record time.

AI is an amplifier, not a corrector. It accelerates whatever trajectory you're already on. Teams with good practices win bigger. Teams with bad practices lose faster.

What Actually Changed (And What Didn't)

The fundamentals haven't changed as much as the hype suggests. The core problems remain: companies still underinvest in discovery, still use arbitrary deadlines, still optimise for outputs over outcomes. What changed is speed—iterations of the loop are faster, and estimation is even more useless than before.

But there's a cultural shift that will separate winners from losers.

The developer identity problem: Developers have long lived by "talk is cheap, show me the code." Code is part of our identity. Letting go of code ownership is painful—even traumatic. We obsess over clean code, elegant abstractions, and technical excellence. This isn't inherently wrong; good code matters.

But many developers fail to recognise "good bad code"—code that is technically excellent but ultimately harmful. Premature optimizations. Over-engineered abstractions. Architectural purity that overcomplicates the system and prevents faster value delivery. The code might be beautiful, but the user perceives no value, and the product loses to a scrappier competitor.

The uncomfortable truth: The winning product has rarely been the one with the best code. It's been the one with the most value—whether that's better UX, more features, faster iteration, or simply showing up first. Technical debt accumulated by winners gets paid down later. Technical perfection pursued by losers never ships.

The AI acceleration: In the new world, this dynamic intensifies. AI makes code generation cheap. Control freaks who obsess over every line will be left behind. And while it's fun to mock "vibe coders" who prompt their way to working software, some of them will win—because they start with value, not code perfection. The vibe coders who ship without any verification will fail fast. The winners are those who start with value AND invest enough in verification to sustain velocity.

The new developer role: One consequence of AI is that developers must become more heavily involved in discovery. When implementation is fast, understanding what to build matters more than how to build it. Developers who stay isolated from customers, business context, and user research will become bottlenecks—not because they're slow at coding, but because they lack the judgment to steer AI toward value. The developers who thrive will be those who invest in understanding the business, participate in user research, and can make product decisions on the fly.

This doesn't mean quality doesn't matter. It means quality serves value, not the other way around. The best teams will use AI to iterate faster toward value while maintaining just enough quality to sustain velocity. The worst teams will use AI to generate perfect code that nobody wants.

L∞P Principles

L∞P proposes eleven equally essential principles:

Customer-Centric: Everyone should be in constant direct contact with customers, understand their needs, and be obsessed with delivering value to them.
Value-Driven: The team is asked to deliver an outcome, not an output. The effectiveness and efficiency of the team is measured by the success of the customers, not by outputs (No Burn-down charts).
Product-Led: Remove silos between marketing, sales, customer success, and the product team.
Trust & Ownership: The product team is tasked with leading the customer to success and having total freedom to come up with the optimal solution.
Flow-Friendly: There must be at least 50% allocated focus time on the calendar every day. This applies to both deep-thinking architectural work and AI-orchestrated development—both require protection from interruption.
No Estimates or Time Boxes: Use a pull-based system. Focus on one work item at a time. Discovery over planning. AI velocity is unpredictable, making estimation even less meaningful than before.
Cost Tracking Over Velocity Tracking: Instead of tracking velocity or estimating story points, track actual costs: team salaries, infrastructure, AI tokens. You know what you're spending weekly. Then measure outcomes: Activation Rate, Retention Rate, LTV, NPS, Feature Engagement. If customer satisfaction is improving or sustained, does velocity matter? The question isn't "how fast are we going?"—it's "are we delivering value relative to cost?" This reframes budget conversations from "will we hit the deadline?" to "is this investment generating returns?"
Explicit Policies: Use templates for agendas and artefacts to prevent deviation from your processes. This extends to AI governance—establish clear policies for security review and quality standards for AI-generated output.
Clear Goals: The entire organisation should understand the business mission, vision, principles, and strategy.
Data-Driven: The decisions, direction, and work items are backed by data.
Pragmatic: Making decisions based on what is best for the project rather than just optimising for individual preferences or technical ideals.
Automation-First: Invest in automation before features. The team that automates verification, testing, and deployment will experience the full productivity gains of AI. A feature without automated verification is incomplete. Technical debt is addressed organically as part of ongoing work, not accumulated in a separate backlog.

L∞P Roles

"If you want to go fast, go alone; if you want to go far, go together" - African proverb

L∞P tries to balance collaboration and working as a team, so we can attempt to achieve goals that are bigger than ourselves (go far) with focus and alone time so we can get into the zone and be super productive (go fast). When we work together, our goal should be to remove unknowns and enable autonomy; then, we can go our separate ways and get stuff done.

The L∞P team structure is designed to ensure all disciplines are aligned and work without silos. Instead of having separate teams for product development, sales, marketing, and other functions, there is one cross-functional team in charge of discovery and delivery. This team integrates with sales and marketing by aligning goals and strategies around the product.

Discovery and delivery are not separate silos. Developers can propose hypotheses, build prototypes, and participate in user research—they are not just implementers waiting for specifications. Similarly, UX and product can contribute to technical discussions. The entire team owns the full cycle from idea to validated, live product.

The Product Manager is a key role in this structure, taking on both the roles of product owner and scrum master. The Product Manager is responsible for leading the team, making decisions that impact the product, and ensuring the team delivers maximum customer value efficiently.
UX plays a crucial role in the product-led growth organisation, responsible for the design and usability of the product. The UX team works closely with the Product Manager and Engineering to ensure that the product is easy to use and meets the customer's needs. AI accelerates prototype generation; UX spends more time on user validation than wireframing.
Architecture creates the blueprint for the product and ensures technical coherence. This role becomes more critical in the AI era—AI generates code fast but makes poor architectural decisions. Humans must own system design.
Engineering implements architecture decisions, builds verification systems, and maintains the product. The role shifts from "writing code" to "orchestrating AI, reviewing output, and building verification automation."
Sales & Marketing represents business functions that influence product perception and customer expectations. These teams work closely with the Product Manager to align go-to-market strategy with product capabilities, ensuring promises match what the product delivers.

AI orchestration is not a separate role. Every team member incorporates AI assistance into their existing responsibilities organically.

The Product Manager (PM)

The role of the product manager is the most critical one in the product team—and AI makes it more critical, not less. The PM is often seen as the proving ground for future CEOs, as the success or failure of a product falls on their shoulders. It's therefore important that the PM role is reserved for the best talent, with a combination of technical expertise, deep customer and business knowledge, credibility among stakeholders, market and industry understanding, and a passion for the product.

A PM must be smart, reactive, and persistent, with a deep respect for the product team. They should also be comfortable with using data and analytics tools to inform their decisions and drive the success of the product. The PM's main task is to ensure that only the most valuable work items reach the backlog, guiding the product team towards building solutions that deliver the greatest impact and customer value.

How AI transforms the PM role:

AI amplifies PM leverage but also amplifies the cost of poor judgment. When the team can build anything fast, deciding what to build becomes the primary bottleneck. The PM who chooses wrong wastes more resources faster.

Research at scale: AI synthesizes market data, customer feedback, and competitive intelligence. The PM can explore more hypotheses and validate faster—but must still make the judgment calls about what matters.
Saying no becomes harder: AI can generate infinite feature ideas, prototypes, and specifications. The PM must resist the temptation to build everything that's now "easy." The discipline of focus intensifies.
Specification quality gates: AI assists the translation from validated discovery to technical specifications, asking refinement questions and identifying gaps. But the PM validates that the specification actually captures customer value—AI can generate coherent specs for useless features.
Verification strategy ownership: Before work begins, the PM ensures a verification strategy exists. How will we know this feature works? How will we know users value it? AI accelerates verification, but the PM defines what "verified" means.
Faster feedback loops: AI-generated prototypes enable real user validation in hours instead of weeks. The PM must be ready to act on feedback immediately—there's no hiding behind "we'll fix it next sprint."

The PM role becomes less about managing process and more about making decisions under uncertainty. The teams that win will have PMs who can synthesize information fast, say no confidently, and move from validated learning to shipped value without hesitation.

L∞P Artefacts

In this section, we are going to take a look at the L∞P artefacts. We will mention common artefacts from other methodologies, clarify why we will not use them, and introduce some new ones.

✅ Mission and vision: The product mission and vision should be clearly articulated and documented. The team should not only know what the product aims to be but also what it is not aiming to be.
✅ Unified Backlog: A single backlog with tags to distinguish work types. We use a pull-based system—take the top item from the backlog. No separate backlogs for discovery and development.
❌ Sprint Backlog: We don't use a Sprint Backlog because we don't use time boxes. We use a Work board and Work-in-progress limits to track our current focus.
❌ Definition of done: We don't allow custom definitions of done. Done means live and used by actual customers. If it's live, it was verified—verification is a prerequisite, not a separate checkbox.
❌ Product Increment: We don't use a Product Increment because we don't accept the idea of something being "potentially releasable". We release everything; if we are not going to release it, we don't build it.
❌ Sprint goal: We don't use a Sprint goal because we don't have time boxes but also because our metrics are already focused on outcomes.
❌ Separate technical debt backlog: Technical debt is addressed organically as part of ongoing work, not accumulated separately.
✅ Explicit work policies: We use Explicit work policies to ensure that nobody corrupts or deviates from our principles.
✅ User stories: We use User Stories, but we are careful to avoid including specific implementation details or technical requirements (WHAT) to keep the focus on the user's needs and goals (WHO and WHY). Stories should keep the focus on the user, enable collaboration and drive creative solutions. AI may draft stories; humans refine them.
✅ Technical specifications: When discovery outputs are validated (user-tested prototypes, research findings), they transform into technical specifications. AI assists this transformation—taking a validated prototype and generating a specification draft. Refinement sessions identify gaps: edge cases, integration points, security considerations, verification requirements. The specification is complete when the team has enough clarity to implement without constant clarification.
✅ Verification automation: Unit tests, end-to-end tests, AI-assisted security reviews, and observability are first-class deliverables, not afterthoughts. Every feature ships with its verification.
✅ Outcome metrics over output metrics: We don't use Output-based metrics like Burn-down & Burn-up charts, Lead time, Cycle time and Cumulative flow diagrams because they make people focus on outputs, not outcomes. We use outcomes-based metrics instead, like Activation Rate, Retention Rate, Lifetime Value (LTV), Net Promoter Score (NPS), Feature Engagement, Cohort Analysis & A/B Testing, Change Failure Rate, Employee satisfaction surveys, Employee turnover rate. We are careful with the activation rate because we understand that retention rate is a more reliable metric for customer value.

L∞P Ceremonies

In this section, we are going to take a look at the L∞P ceremonies. We will mention common ceremonies from other methodologies, clarify why we will not use them, and introduce some new ones.

❌ We don't use Sprints because a sprint is a time box, and we believe that time boxes lead to decreased quality and lower customer value, so we don't have any Sprint-based meetings. Including:
- ❌ Sprint planning,
- ❌ Sprint review and
- ❌ Sprint retrospective.

However, we value the principles behind the Sprint retrospective.

❌ We don't host the Delivery planning and Risk review meetings from Kanban because they strongly focus on outputs.
✅ We host as many User research/testing sessions as needed to validate hypotheses and generate product ideas. The entire team participates in the research phase, sales and development included. AI can significantly enhance these sessions—agents can help facilitate discussions, synthesize findings in real-time, or transform meeting transcriptions into structured insights, specifications, and hypothesis refinements.
✅ We block 4 hours daily in people's calendars to ensure they can get into the zone and move fast. We call this the Do Not Disturb (DnD) meeting. This protected time applies to both deep-thinking work and AI-orchestrated development.
✅ We host a daily stand-up meeting, but we use meeting agendas to ensure they don't become a checkpoint. The goal is to resolve blockers and provide the team with the information required to act with autonomy for the rest of the day.
✅ We host a monthly Flow review meeting to reinforce a continuous improvement culture. This meeting includes: What verification gaps exist? What automation was added? What escaped our automated checks? How can we prevent similar escapes? AI can assist by analysing production incidents, identifying patterns across issues, and suggesting automation opportunities.
✅ We host a monthly Show and Tell meeting to enable conversation across teams, share research insights, and celebrate our achievements. This is a meeting to share knowledge with other teams and the wider business.
✅ We host monthly hackathons to encourage the development team to generate product ideas and reinforce the involvement of the developers in the discovery phase.
✅ We host a quarterly Strategy review meeting to align the product teams with the leadership's mission, vision and strategy.

The core philosophy remains: trust leads to ownership, ownership leads to agility, agility plus protected focus time leads to flow. AI accelerates this cycle—it doesn't replace it.

The 6th SOLID Principle?

Remo H. Jansen — Sat, 21 Mar 2026 01:40:31 +0000

I've been writing about the SOLID principles for over a decade. I built InversifyJS because of them, I wrote about implementing them with the onion architecture, and just recently, I argued that they are universal design principles that show up far beyond the world of object-oriented programming. But I've always felt something was missing — not from the principles themselves, but from the conversation around them.

SOLID tells you how to write good components. It doesn't tell you how to compose them into a system that can change shape.

Let me explain.

The gap

Imagine you have a perfectly SOLID codebase. Your UserRepository depends on an abstraction. Your EmailService has a single responsibility. Your OrderProcessor is open for extension but closed for modification. Everything is beautiful. You followed the five principles to the letter.

Now your CTO walks in and says: "We need to split the user management into its own microservice."

What happens? You start ripping things apart. You create a new project, move files, rewrite imports, create new entry points, set up new dependency wiring, and extract shared interfaces into a package. It takes weeks. The SOLID components themselves were fine — they didn't need to change. But the structure around them did. The boundaries of your system were baked into the source code: into import paths, into entry points, into which files lived in which project, into hard-coded wiring inside modules.

SOLID gave you pristine components. But pristine components in a rigid structure still give you a rigid system.

What changes with the Composition Root

Now imagine the same codebase, but this time every component is wired together via an IoC container, and all the wiring lives in a single place: the composition root.

Your OrderProcessor doesn't import UserRepository directly. It declares a dependency on an abstraction. The composition root is where the abstraction meets its implementation. It's the only place in your entire codebase that knows which concrete classes exist and how they relate to each other.

Here's the interesting part. In a monolith, you have one composition root that loads everything:

// monolith/composition-root.ts
const container = new Container();
container.load(authModule);
container.load(userModule);
container.load(orderModule);
container.load(emailModule);
container.load(cmsModule);

Now your CTO wants microservices. Instead of ripping the codebase apart, you create a new composition root for each service:

// services/user-service/composition-root.ts
const container = new Container();
container.load(authModule);
container.load(userModule);

// services/order-service/composition-root.ts
const container = new Container();
container.load(authModule);
container.load(orderModule);
container.load(emailModule);

The components didn't change. Not a single line. The only thing that changed is which composition root assembles which components. The boundaries of your system — what constitutes a deployable unit, which components belong together — were never defined by the components themselves. They were defined at the composition root level.

I wrote a detailed case study of exactly this approach: From Monolith to Microservices without changing one line of code. In that project, the same codebase produced either a monolith or a set of microservices depending on which composition roots were used and how the CI/CD pipeline was configured. We even migrated from CosmosDB to PostgreSQL by creating a new IoC module and swapping it in the composition root — zero changes to existing code.

This is NOT the Composition Root pattern

I want to be very precise here because the distinction matters.

The Composition Root is a pattern, defined by Mark Seemann, that tells you where to wire your dependencies: in a single place, as close to the application's entry point as possible. Seemann is clear that each deployable application should have exactly one composition root — and he's right.

But the principle I'm trying to articulate is not about where you wire things up. It's about what the components know about their own boundaries.

Here's the difference:

The Composition Root pattern says: "Wire everything in one place per application." It's a mechanism — the how.
The principle I'm proposing says: "Your components should be boundary-agnostic. They should not know whether they're part of a monolith, a microservice, a plugin, or a serverless function. That decision should be made at the composition root level, never inside the components themselves."

Seemann says multiple composition roots within a single application is an anti-pattern, and I agree — per deployable artifact. But the whole point is that you should be free to create new deployable artifacts with new composition roots that select different subsets of the same boundary-agnostic components. The components don't change. Only the composition roots do.

In other words: the Composition Root pattern gives you the tool. The principle gives you the reason to use it this way.

The Boundary Deferral Spectrum

One mental model that has helped me think about this is a spectrum. The question is: how late can you defer the decision about where your system's boundaries are?

Design time (worst). Boundaries are baked into the source code. Components import each other directly. Which components belong to which service is decided by folder structure, project boundaries, and import paths. Restructuring means rewriting.

Composition time (good). Boundaries are defined in the composition root. The components themselves are boundary-agnostic. You can create different composition roots that assemble the same components into different shapes — monolith, microservices, or anything in between. Restructuring means writing a new composition root.

Build time (better). The composition root reads environment variables or build arguments to decide which modules to load. A single codebase produces different deployable artifacts depending on build configuration. In my monolith-to-microservices project, a Dockerfile with SERVICE_NAME and SERVICE_ENTRY_POINT build arguments produced different microservice images from the exact same source code. Restructuring means changing a build argument.

Runtime (most deferred). The system discovers and loads components dynamically. Plugin architectures like MEF (.NET), OSGi (Java), or VS Code's extension system don't know their own boundaries until they're running. A plugin can be added or removed without the host application knowing about it in advance. The system's shape is defined by what's present on disk, not by what's in the source code.

Plugin systems are, in my opinion, the purest embodiment of SOLID in practice. They represent the logical extreme of this spectrum: boundaries deferred to the latest possible moment. Every plugin has a single responsibility. The system is open for extension (install a plugin) and closed for modification (the host doesn't change). Plugins are substitutable (swap one implementation for another). They interact through narrow, segregated interfaces. And everything depends on abstractions, with concrete implementations loaded at runtime.

It's not a coincidence that the most long-lived, adaptable software systems in history — IDEs, browsers, operating systems — are all built on plugin architectures. They defer boundaries until runtime, and that gives them the ability to evolve in ways that no amount of up-front design could anticipate.

Horizontal and vertical slicing

The boundary decisions I'm talking about come in two flavours, and both should be deferrable.

Vertical slices are about technical concerns: the HTTP layer, the business logic layer, the data access layer. In a well-structured onion architecture, these layers are already separated by abstractions. The composition root is what connects them. You can replace your entire data access layer (say, swap Sequelize for TypeORM, or SQL for a REST API) by changing the composition root — the business logic doesn't know or care.

Horizontal slices are about user journeys or business capabilities: user management, order processing, content management, authentication. In a modular monolith, these are IoC modules. In a microservices architecture, each one becomes its own deployable artifact with its own composition root.

The principle says: both kinds of boundaries should be defined at the composition root level. Your components should not know whether UserRepository and OrderRepository live in the same process or in different services across a network. They shouldn't know whether the email service is an in-process function call or an HTTP request to a third-party API. That's a composition-time decision.

When both vertical and horizontal boundaries are deferred, your system becomes something like a bag of Lego bricks. You can assemble them into a monolith (one big model), or split them into microservices (many small models), or land somewhere in between — all without modifying a single brick. Only the instruction manual changes.

The same idea in functional programming

This is not just an OOP/IoC container thing. The same principle shows up in functional programming, expressed through different mechanisms.

In ML-family languages, module functors let you parameterise an entire module over its dependencies. A functor takes a module signature (an abstraction) and produces a concrete module. The "wiring" — which concrete module gets passed to which functor — happens at the call site, not inside the functor. The functor is boundary-agnostic; it declares what it needs but not where it comes from or what system it belongs to.

Effect systems like ZIO (Scala) take this even further. A ZIO program declares its dependencies as a type-level "environment" (ZIO[UserRepo & EmailService, Error, Result]), and the layers that satisfy those dependencies are assembled separately. You can build different layer configurations for testing, for a monolith, or for distributed services. The program itself doesn't change — only the layer composition does.

Even in simpler functional codebases, the practice of threading dependencies as function parameters (dependency injection via higher-order functions) achieves the same thing. A function (fetchFn) => (userId) => fetchFn(/users/${userId}) doesn't know if fetchFn hits a local database, a remote API, or a mock. The boundary decision is deferred to whoever provides fetchFn.

The mechanism is different — functors instead of IoC containers, layers instead of composition roots, higher-order functions instead of constructor injection — but the principle is identical: components should be boundary-agnostic, and the decision about what belongs together should live outside the components.

Has this been said before?

I want to be honest about prior art because this idea doesn't come from nowhere.

Robert C. Martin came very close in his 2014 article on Clean Micro-service Architecture, where he wrote: "The Deployment Model is a Detail" and "A good architect defers the decision about how the system will be deployed until the last responsible moment." He even coined the term "Forced Ignorance" — the idea that components should have no knowledge of their deployment context.

The Lean Software Development movement formalised "Decide as Late as Possible" (Poppendieck, 2003) as a general principle about deferring decisions until you have enough information to make them well.

Mark Seemann's Composition Root pattern provides the mechanism to make this work in practice.

But none of these, as far as I can tell, explicitly say: the boundaries of your system — which components are grouped together, what constitutes a vertical slice, what constitutes a horizontal slice, what constitutes a deployable unit — should be defined at the composition root level, not inside the components, and should be reconfigurable without modifying the components themselves.

Uncle Bob says deployment topology is a detail. But he still assumes the component boundaries are defined in code (jars, DLLs, project structure). The Composition Root pattern tells you where to wire, but not that the components should be deliberately designed to be boundary-agnostic. "Decide as Late as Possible" is a general principle that applies to everything, not specifically to system boundaries.

What I'm proposing sits in the gap between these ideas.

So what do we call it?

I've been going back and forth on this, and the name I keep coming back to is:

The Boundary Deferral Principle: The components of a system should be boundary-agnostic. System boundaries — both vertical (technical layers) and horizontal (business capabilities) — should be defined at the composition root level, never inside the components themselves. Boundary decisions should be deferred as late as practically possible.

Or more concisely: system boundaries are a detail.

This follows Uncle Bob's own framing — the database is a detail, the framework is a detail, the deployment model is a detail — and extends it to its logical conclusion: the boundaries themselves are a detail too.

SOLID+ ?

SOLID without this principle has always felt incomplete to me. SOLID gives you the bricks. But without the idea that boundaries should be deferred and defined at the composition root level, you end up cementing those bricks into a shape too early. And when the shape needs to change — and it always does — you're back to a rewrite.

The teams I've seen get the most out of SOLID are the ones that, whether they know it or not, also follow this principle. Their applications are plugin systems in disguise. Their components don't know their own topology. Their boundaries are defined in one place, and changing that one place changes the shape of the entire system.

Maybe that's the 6th principle. Or maybe it's just what happens when you take the other five seriously enough. I'd love to hear your thoughts!

The SOLID Principles are Universal

Remo H. Jansen — Fri, 20 Mar 2026 23:44:49 +0000

I've spent a significant portion of my career thinking about the SOLID principles. I wrote about them in the context of JavaScript and TypeScript, I built InversifyJS largely because of them, and I've had countless conversations with other developers about whether they belong in the JavaScript world at all. Over the years, many people have pushed back, arguing that SOLID is an object-oriented thing, that it only matters if you're writing Java or C#, and that it doesn't apply to their world.

I respectfully disagree. In fact, the more I look around, the more I'm convinced that the SOLID principles are not about object-oriented programming at all. They are universal design principles that manifest everywhere, whether you realise it or not. You'll find them in CSS utility frameworks, in functional programming, and even in the way we're building AI agents today.

Let me show you what I mean.

1. Tailwind CSS

When Tailwind CSS first gained popularity, I remember many developers (including myself) being skeptical. Writing class="flex items-center justify-between p-4 bg-white rounded-lg shadow-md" felt wrong. It looked like inline styles with extra steps. But the more I used it, the more I started to see something familiar. Tailwind is SOLID, and it doesn't even know it.

S — Single Responsibility Principle

A class should have only a single responsibility.

In Tailwind, each utility class does exactly one thing. text-center centers text. p-4 adds padding. bg-blue-500 sets a background colour. That's it. No side effects, no surprises. Compare this to a traditional CSS class like .card that might set padding, margin, background, border-radius, box-shadow, font-size, and who knows what else. That's a God class. Tailwind avoids this entirely by ensuring every class has a single, well-defined responsibility.

O — Open/Closed Principle

Software entities should be open for extension, but closed for modification.

You cannot modify p-4. It is what it is. But you can extend the system by composing additional classes: p-4 md:p-8 lg:p-12. You can also extend Tailwind's configuration to add your own spacing scale, your own colours, your own breakpoints, all without touching the existing utility classes. The existing system is closed for modification but wide open for extension. This is exactly how the open/closed principle is supposed to work.

L — Liskov Substitution Principle

Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.

In Tailwind, any spacing utility is interchangeable with another spacing utility. You can swap p-4 for p-6 and the system doesn't break. You can replace bg-blue-500 with bg-red-500 and everything continues to work as expected. The utilities follow a consistent contract: they accept the same kind of input (a class name on an element) and produce a predictable kind of output (a single CSS property change). Any class within a category can substitute for another in that category without breaking the layout system.

I — Interface Segregation Principle

Many client-specific interfaces are better than one general-purpose interface.

This is perhaps where Tailwind shines the brightest. Instead of one monolithic .card class that bundles together layout, spacing, colour, typography, and shadow concerns, Tailwind gives you many small, focused utilities. You pick only the ones you need. Your element doesn't have to "implement" an interface it doesn't care about. A heading doesn't need to know about box shadows just because it happens to be inside a card. Each utility is a tiny, client-specific interface. You compose exactly what you need and nothing more.

D — Dependency Inversion Principle

One should depend upon abstractions, not concretions.

This one is more subtle in Tailwind, but it's there. When you use Tailwind's design tokens (e.g., text-primary, bg-surface, or spacing values like p-4), you're depending on an abstraction rather than a concrete value. You don't write color: #3B82F6 directly. You write text-blue-500, which is an abstraction that points to a value defined in your configuration. If you change your blue from #3B82F6 to #2563EB in the config, every component that depends on blue-500 gets updated automatically. Your components depend on the abstraction (the token), not the concretion (the hex value).

2. Functional Programming

I've always found the relationship between SOLID and functional programming fascinating. Mark Seemann wrote something that stuck with me years ago:

"If you take the SOLID principles to their extremes, you arrive at something that makes Functional Programming look quite attractive."

I referenced this quote in my post about the state of dependency inversion in JavaScript, and it's something I still think about. The SOLID principles don't require classes or interfaces to be meaningful. They show up naturally in well-written functional code.

S — Single Responsibility Principle

In functional programming, the single responsibility principle is baked into the philosophy. Pure functions do one thing: they take an input and produce an output with no side effects. A function like const double = (x) => x * 2 has a single, clear responsibility. The entire functional paradigm pushes you towards small, composable functions that each do one thing well. When people talk about "Unix philosophy" — do one thing and do it well — they are really talking about single responsibility.

O — Open/Closed Principle

In functional programming, functions are closed for modification by default because pure functions are immutable transformations. You can't go in and change what map does. But you can extend behaviour by composing functions together. Higher-order functions are the ultimate open/closed mechanism: pipe(validate, transform, serialize) lets you extend a pipeline without modifying any of the individual functions. Function composition is extension without modification.

L — Liskov Substitution Principle

In functional programming, this manifests as the ability to swap one function for another as long as it respects the same type signature. If a pipeline expects a function (a) => b, you can substitute any function that satisfies that contract. This is exactly what makes functional programming so powerful for testing as well. You can replace a function that reads from a database with a function that returns mock data, and the rest of your pipeline doesn't care. Same signature, same contract, different implementation.

I — Interface Segregation Principle

Functional programming naturally avoids bloated interfaces because functions inherently have narrow, focused signatures. Instead of passing a God object with twenty properties to a function, you pass only what that function needs. A function (name: string) => string doesn't force you to provide an entire User object when all it needs is a name.

But there's a more subtle connection here that I find particularly compelling: the functional programming preference for unary functions (functions that take a single argument) over functions with multiple arguments is, in my opinion, a form of interface segregation.

Think about it. A function like (userId: string, includeOrders: boolean, formatAsCSV: boolean, sendEmail: boolean) => Result is the functional equivalent of one general-purpose interface. The caller is forced to know about and provide values for concerns it might not care about. Maybe I just want to fetch a user. Why do I need to tell the function whether to format as CSV or send an email? This function has a "fat interface" — it mixes multiple concerns into a single signature.

Now consider the unary alternative. Currying transforms that one fat function into a chain of focused, single-argument functions: (userId) => (options) => (formatter) => Result. Each function in the chain has a narrow, segregated interface. But more importantly, partial application lets you stop at any point in the chain and get back a specialised function that only demands what the next consumer actually needs. You can pass getUserById (already partially applied with default options) to a part of your code that only cares about fetching users and doesn't need to know formatting even exists.

This is interface segregation at the function level. Instead of one function with a wide, general-purpose parameter list, you get many smaller, focused functions, each requiring only what it needs from its caller. The parallel to "many client-specific interfaces are better than one general-purpose interface" is almost exact, just expressed through function signatures rather than interface declarations.

Libraries like Ramda take this philosophy to the extreme — every function is curried by default, which means every function in the library naturally presents the narrowest possible interface to its consumer at each step of application.

D — Dependency Inversion Principle

This one is beautiful in functional programming. Instead of depending on a concrete database module or HTTP client, functional code often takes its dependencies as function parameters. This pattern is so common it has a name: dependency injection via higher-order functions. Instead of importing a concrete implementation, you write const getUser = (fetchFn) => (id) => fetchFn(/users/${id}). Your business logic depends on the abstraction (a function that fetches), not the concretion (the specific HTTP library). The caller decides what implementation to inject.

3. AI Agent Development

This is the one that made me want to write this post. Over the last couple of years, I've been spending more and more time building and thinking about AI agents. I wrote about Agent Driven Development and the Agentic web previously, and one thing that keeps striking me is how the patterns that make agents work well are the exact same patterns we've been preaching in software engineering for decades. The SOLID principles aren't just relevant in AI agent development. They might be essential.

S — Single Responsibility Principle

The best agentic systems I've built or worked with follow this principle strictly. Each agent in the system should have a single, well-defined responsibility. A ResearchAgent should gather information. A SummaryAgent should condense findings into a concise output. A CodeReviewAgent should analyse code for issues. When you build one God agent that researches, summarises, writes code, reviews it, sends emails, AND updates a project tracker, the quality of every single one of those tasks degrades. The agent tries to be everything and ends up being mediocre at all of it. Single responsibility for agents isn't just good architecture; it directly affects the quality of the AI's output. Smaller, focused agents produce better results because the system prompt, the context window, and the reasoning are all concentrated on one job.

O — Open/Closed Principle

A well-designed multi-agent system is one where you can add new agents without modifying the existing orchestration logic. The orchestrator that coordinates your agents should be closed for modification. You shouldn't have to rewrite the routing or coordination logic every time you need a new capability. Instead, you register a new specialised agent with its description and responsibilities, and the orchestrator can start delegating to it. The existing agents remain untouched. This is exactly the philosophy behind frameworks like LangGraph, CrewAI, and the Model Context Protocol (MCP) — they let you extend the system by plugging in new agents or servers rather than modifying the ones that already work.

L — Liskov Substitution Principle

In a multi-agent system, you should be able to swap one agent for another as long as it fulfils the same contract. If your orchestrator delegates summarisation to a SummaryAgent, you should be able to replace that agent with an improved version — perhaps one powered by a different model, or one that uses a different prompting strategy — without the orchestrator knowing or caring. The contract is: "give me text, I'll give you a summary." How the agent internally achieves that is its own business. This is also why it matters to have clean interfaces between agents. If your SummaryAgent can be backed by GPT-4, Claude, or a fine-tuned local model, and the rest of the system works regardless, you've achieved Liskov substitution at the agent level.

I — Interface Segregation Principle

When designing agentic systems, it's far better to have many focused agents than one Swiss Army knife agent. You should have a DataExtractionAgent, a ValidationAgent, and a FormattingAgent rather than one monolithic DataProcessingAgent that tries to handle everything based on a mode parameter. Why? Because each agent can have a tightly scoped system prompt, a focused set of examples, and a narrow context window. The LLM performs better when it has a clear, specific job. A general-purpose agent with a system prompt that reads like a novel ends up confused about which hat it's supposed to be wearing at any given moment. This is interface segregation applied to AI: many specialised agents with narrow responsibilities are better than one general-purpose agent that does everything poorly.

D — Dependency Inversion Principle

This is critical in agent architecture. Your orchestrator should depend on abstractions of agents, not on concrete implementations. If your orchestration logic is tightly coupled to a specific agent that uses a specific model with a specific prompt template, you've made the whole system rigid. Instead, define what an agent looks like in abstract terms — it takes an input, it returns an output, it has a description of what it does — and let the orchestrator depend on that abstraction. The concrete agent (which model it uses, how it prompts, what tools it has access to) is an implementation detail that gets injected. Tomorrow you might want to replace your Claude-powered ResearchAgent with one that calls a specialised fine-tuned model, or even a non-LLM heuristic agent. If your orchestrator depends on the abstraction, that swap is trivial. This is the same principle I was advocating for with InversifyJS years ago, and it's exactly the approach taken by agent frameworks that separate the agent interface from the agent implementation.

Full Circle

I find it remarkable that the same five principles Robert C. Martin articulated decades ago for object-oriented design show up, without being forced, in a CSS utility framework, in functional programming, and in the way we're building AI agents in 2026. They weren't invented for OOP. They were discovered as properties of well-designed systems.

I wrote The problem with Dogma in Software a few years ago, and I still stand by it. We should never apply any principle dogmatically. But I think the SOLID principles have earned their place as something deeper than just "OOP best practices". They are universal design principles about managing complexity, achieving composability, and building systems that can evolve over time.

Whether you're styling a button with Tailwind, piping functions together in Haskell, or orchestrating a fleet of specialised AI agents — if the design feels clean and maintainable, there's a good chance the SOLID principles are hiding in there somewhere, whether you invited them or not.

Thanks for reading. I'd love to hear your thoughts!

Running the Copilot CLI in a WebGL-powered retro CRT terminal implemented by the Copilot CLI 🤯

Remo H. Jansen — Fri, 30 Jan 2026 23:33:50 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

A port of Swordfish90/cool-retro-term (Qt and OpenGL) to WebGL, React, and Electron, and use to make my website look like a cool retro monochrome CRT monitor with an OS from 1977.

Demo

https://remojansen.github.io/

Please note: The site is meant to be used with a keyboard (no mouse or touch controls).

My Experience with GitHub Copilot CLI

I first had the idea of building a website that looks like an old-style monochrome CRT monitor when I discovered Swordfish90/cool-retro-term. I loved it, but the problem is that cool-retro-term is a native application that uses Qt & OpenGL. I wondered if it would be possible to port the code to WebGL, but because I have no experience with Qt or OpenGL, answering this question would have taken me many hours.

In the past, I wouldn't have pursued this project because I didn't have much time outside of work, but now, thanks to GitHub Copilot and its CLI, I was able to get a good understanding of how cool-retro-term works and put together a migration plan in minutes.

Then, over a couple of evenings, I started to migrate the OpenGL shaders to WebGL one at a time, and soon I had a working port 🎉

The original project (cool-retro-term) implemented an OpenGL frontend for an OS terminal. My website runs in a browser, so I had to implement a basic terminal emulator, and Copilot was able to do so without any problems.

Because the rendering was decoupled from the terminal, I thought others could be interested in this as a library, so I released it as cool-retro-term-webgl, and I also thought that the most likely next usage would be an Electron-based version of cool-retro-term so I also added that to cool-retro-term-webgl.

Now I can run the Copilot CLI in a WebGL-powered retro CRT terminal implemented by the Copilot CLI 🤯

I was very happy with everything that I was able to accomplish in just a couple of days, and quite impressed by the power of the GitHub Copilot Agents together with Claude Opus 4.5. It was then that the fan really started. I started to add all sorts of cool and fun "programs" to my terminal emulator, and honestly, I have not had so much fun coding in a very long time.

There are a couple of fun easter eggs and nerdy references. I hope you enjoy them (maybe you can "hack" my cluster 😉).

Turning Your Living Room into a Couch Co-op Arena with TouchCoop

Remo H. Jansen — Mon, 19 Jan 2026 03:11:10 +0000

Hey everyone 👋,

Today I want to share something fun. Imagine this: you're at home with friends, the big TV is on, and instead of everyone fighting over Bluetooth controllers or passing around one gamepad… everyone just pulls out their phone and instantly becomes a player.

No accounts. No installs. Just scan a QR code and start mashing buttons.

That's exactly what TouchCoop enables — a tiny TypeScript library that turns this vision into reality with almost zero server hassle.

Host runs the game on a laptop/TV-connected browser
Up to 4 players join via QR code on their mobiles
Touch buttons on phone → real-time input to the game via WebRTC
Perfect for casual games: platformers, party games, local puzzles
Not suited for low-latency games like FPS (WebRTC latency is good but not esports-level)

Quick architecture overview

Your game needs two distinct entry points (URLs):

The Match page (TV/Laptop): Creates a Match instance, shows QR codes for joining, and receives player events.
The Gamepad page (Phone): Opened via QR code, creates a Player instance, connects, and sends touch events.

Both are just static web pages — no backend required beyond the signaling phase.

Getting started in 60 seconds

Install the library:

npm install touch-coop

1. The Match side (your game)

import { Match, PlayerEvent } from "touch-coop";

const gamePadURL = "https://your-domain.com/gamepad";  // Must be absolute URL for QR

function handlePlayerEvent(event: PlayerEvent) {
  switch (event.action) {
    case "JOIN":
      console.log(`Player ${event.playerId} joined 🎉`);
      // Maybe spawn player avatar, play sound, etc.
      break;
    case "LEAVE":
      console.log(`Player ${event.playerId} left 😢`);
      break;
    case "MOVE":
      console.log(`Player ${event.playerId} → ${event.button}`);
      // Here you map "up", "A", "X" etc. to game actions
      if (event.button === "up") jumpPlayer(event.playerId);
      break;
  }
}

const match = new Match(gamePadURL, handlePlayerEvent);

const { dataUrl } = await match.createLobby(
  gamePadURL, handlePlayerEvent
);

Call match.createLobby() to get the dataUrl of a QR Code that displays a virtual gamepad.

2. The Gamepad side (React example)

import React, { useEffect, useState } from "react";
import { Player } from "touch-coop";

const player = new Player(); // Can pass custom PeerJS config too

export default function GamePad() {
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    (async () => {
      try {
        await player.joinMatch("Player Name Here");
        setLoading(false);
      } catch (err) {
        console.error("Failed to join", err);
      }
    })();
  }, []);

  if (loading) return <div className="text-2xl">Connecting...</div>;

  return (
    <div className="grid grid-cols-3 gap-4 p-8 h-screen bg-black text-white">
      <button className="btn" onClick={() => player.sendMove("up")}>↑</button>
      <button className="btn" onClick={() => player.sendMove("left")}>←</button>
      <button className="btn" onClick={() => player.sendMove("right")}>→</button>
      <button className="btn col-start-2" onClick={() => player.sendMove("down")}>↓</button>

      <div className="col-span-3 flex justify-around mt-8">
        <button className="btn bg-green-600" onClick={() => player.sendMove("A")}>A</button>
        <button className="btn bg-blue-600" onClick={() => player.sendMove("B")}>B</button>
        <button className="btn bg-red-600" onClick={() => player.sendMove("X")}>X</button>
        <button className="btn bg-yellow-600" onClick={() => player.sendMove("Y")}>Y</button>
      </div>
    </div>
  );
}

Live demo & try it yourself

The original project has a nice little demo:

→ https://SlaneyEE.github.io/touch-coop/demos/match.html

Final thoughts

TouchCoop is a beautiful example of how far browser APIs have come: WebRTC + TypeScript + modern build tools = couch co-op without native apps or complex backends.

If you're building casual multiplayer experiences or party games give it a try.

Have you built (or are you planning to build) a couch co-op game? Drop a comment below — I'd love to hear your multiplayer war stories or see links to your projects!

Happy coding, and see you in the comments ✌️

Claude Opus 4.5 changes everything

Remo H. Jansen — Thu, 08 Jan 2026 23:21:22 +0000

Experimenting with AI-Generated Code in 2025

Before I begin, I would like to clarify my position. I'm one of those people who believe that AGI will happen. I don't know when, but I believe that while the human mind and consciousness are extraordinarily complex, they are ultimately governed by the physical laws of the universe and can therefore be simulated. Someday AGI will be a reality. How far are we? I have no idea, and I don't care.

What I do care about is how the current growing capabilities of LLMs will impact what has been the source of income for my family for the last 15 years. So I have been keeping an eye on emerging tools, workflows, and new approaches to software engineering. For over two years, I have been using GitHub Copilot extensively with multiple models, coding agents, and custom agents, and for the most part it has been hit and miss.

I usually ask GitHub Copilot to implement a feature or fix a bug using the chat or coding agent, and a lot of times it would go very wrong. I have developed the habit of staging changes before each prompt, code reviewing changes for each prompt as I go along, and rolling back via git when I'm not happy with the solution. Working like this for a while means that I have been able to develop a sense of what kinds of things will work and how to break problems into steps that make it more likely that the AI agent will do what I expect.

I know some developers feel like AI agents are taking the joy of coding away from them, but I do not feel that way because it has allowed me to spend more time developing features. I feel like finding the root cause of bugs (even when I end up fixing them manually) is one of the things that LLMs can be very good at. As a result, I find myself spending way less time debugging.

Another thing, in my opinion, that is better is that I have to deal less with "repetitive tasks". After 15 years in the sector, I find that these days I enjoy spending more time trying to understand the business problem and designing a solution than actually implementing it. Once I have designed the API contracts, boundary contexts, database schema, etc., the implementation becomes very much grunt work—something that I feel I have done so many times that it is no longer enjoyable. So in 2025, I spent much more time doing code reviews and technical specs (for the LLMs) and less on implementation.

Do I feel like I have become more productive in 2025? Not really—maybe a little bit, but not a lot. I would say overall, a task took more or less the same time, but I spent more time thinking about the problem and doing verification than doing implementation.

Experiencing Claude Opus 4.5 for the First Time

It was at this point that the Christmas holidays arrived, and I happened to have unlimited Claude Opus 4.5 tokens for a couple of weeks. So I decided to work on some old side projects that I never had time to finish.

One of the projects was quite obsolete; I had not worked on it for a very long time. It originally used Create React App, but I knew that it had since been deprecated, so the first thing I did was to ask Claude to plan a migration from Create React App to Vite. I was quite impressed by the quality of the plan, so I asked it to go ahead, and 3 minutes later, I had everything working as expected.

I also had plans to make the web app work as a mobile app via Capacitor and as a desktop app via Electron. The problem is that on each platform I would have to use different native APIs—for example, to store user progress (the app is a game). On the web I use local storage, in Node.js the fs module, and in mobile apps SQLite. I needed Opus to implement an interface and implementations for each platform, then implement the builds for web, Windows, Mac, Linux, Android, and iOS. In about 10-15 minutes I had a working version. I tested it and encountered some small issues. I wanted the app to be full screen, and in Electron it was not using the entire screen, but after one or two prompts everything was done.

I was already quite impressed because when I reviewed the changes I didn't spot anything too bad. These were complex tasks, and Claude Opus 4.5 was getting them done one prompt at a time. The most impressive part is that I didn't have to explain how I wanted it done. I explained why I needed something and let the planning agent do all the planning for me. Now I only had to spend time doing code reviews, and because the code was fairly good, I was moving very fast.

I started to ask for features, and I was able to get over 10 features in one morning. I also tried Claude on a project really outside of my comfort zone. I wanted to migrate an OpenGL app to WebGL from Qt to TypeScript. I was able to implement the migration just the way I wanted in half a morning. Suddenly, when you are running 6 AI agents in parallel, it is like freaking horizontally scaling yourself. While the agents implement a set of features, you review the previous set and spend some time thinking about the next set. You feel like you are truly being much more productive.

The holidays passed, and on the 31st of December at midnight my unlimited tokens came to an end. It is now January, and when I tried to code without it, I felt like the other models seemed dumb in comparison. The joy of developing a product for me is not in coding the product—don't get me wrong, I love coding—but the true joy comes from seeing people enjoying it. With Claude Opus 4.5, I can deliver more products and more features than ever before. I can focus on listening to my users and not have to suffer all the repetitive and tedious stuff. Will the code be as good as NASA's or as beautiful as poetry? No, but it will certainly be good enough to delight users, and for me, that is enough.

I'm now looking at the higher-tier Claude subscription and thinking to myself that, considering what I have experienced, it is actually reasonable. I think Claude Opus 4.5 changes everything, and it makes me both very excited and very anxious. Excited because now developers will be able to build things that were not possible before because they required too much effort. This is going to be particularly noticeable in open source. We will soon see really powerful open source solutions (that are not just libraries) that can compete with big SaaS players. Anxious because it is hard to see how this is not going to impact job security in the long run.

Note: What I’m describing above is not vibe coding. I still review every change, work in feature branches, run CI/CD pipelines, and understand the code that ships. This is agent-driven software engineering, not blind prompt-and-pray development.

Have you tried Opus? What is the most impressive use case you have experienced?

In my next post I will talk about how I plan to combat my anxious thoughts about my career as a software engineer and focus my energy on the exciting ones.

I have open-sourced a WebGL front-end for your terminal that emulates a CRT monitor

Remo H. Jansen — Sat, 03 Jan 2026 00:11:53 +0000

I'm thrilled to announce that I've open sourced cool-retro-term-webgl, a modern WebGL-based recreation of the beloved cool-retro-term terminal emulator!

For years, developers and retro computing enthusiasts have loved cool-retro-term by Filippo Scognamiglio (Swordfish90) — a Qt-based terminal that perfectly mimics the look and feel of old cathode ray tube (CRT) monitors, complete with scanlines, glow, and that nostalgic flicker.

I wanted to bring those authentic retro effects to the web and modern applications. The original is built in QML and C++, so I set out to port the shader magic to WebGL, making it usable in browsers, web apps, and even native desktop apps via Electron.

The result? A lightweight, high-performance CRT renderer that integrates seamlessly with XTerm.js.

Key Features

Authentic retro CRT effects powered by WebGL:
- Screen curvature and distortion
- Phosphor glow and bloom
- Scanlines and rasterization
- RGB chromatic aberration
- Flicker, static noise, and burn-in persistence
- Horizontal sync jitter
Two packages in a monorepo:
- cool-retro-term-renderer: The core library for adding CRT effects to any XTerm.js instance.
- cool-retro-term-electron: A full-featured desktop terminal app built with Electron, supporting real shell processes via node-pty.

Here's a glimpse of the retro magic in action:

Live demo https://remojansen.github.io/

Try the Desktop App

Download the Mac binary

The project is licensed under GPL-3.0, just like the original.

Check out the repo: https://github.com/remojansen/cool-retro-term-webgl

Thanks to Swordfish90 for the original inspiration.

Building a Retro CRT Terminal Website with WebGL and GitHub Copilot (Claude Opus 4.5)

Remo H. Jansen — Sun, 28 Dec 2025 02:10:00 +0000

During the holidays, I was browsing the internet when I came across cool-retro-term, an open-source terminal that mimics the visuals of old cathode ray tube (CRT) displays.

I loved the look of it—it has an awesome retro sci-fi atmosphere that reminds me of the Alien and Fallout fictional universes. I thought it would be amazing if I could make my personal website look like that. I took a look at the source code and quickly realized that it's implemented using QML and C++. I'm not experienced with either, so I wondered if it would be possible to port it to web technologies using either WebGL or Emscripten. I asked GitHub Copilot, and it advised me to try the WebGL route because there were fewer technical challenges involved.

Understanding the Architecture

I have no experience with QML, but I have worked with Three.js in the past. I don't have a deep understanding of how shaders work internally, but with the help of GitHub Copilot, I was able to understand the architecture of the original source code. I cloned the repo, added a new web directory, and started providing instructions to Claude. The original application has two sets of shaders: the first one handles the static frame, and the second one is a series of effects that are influenced by the current time.

Step 1: The Static Frame

I started by asking Claude to implement the static frame using Three.js while ignoring the terminal emulation for now. This gave me a foundation to build upon without getting overwhelmed by complexity.

Step 2: Text Rendering

The second step was to ask Claude to render some basic text from a hardcoded text file in the Three.js scene using the appropriate retro font.

Step 3: Migrating the Visual Effects

Then I started to migrate the visual effects—starting with the background noise and then moving on to the other effects:

Bloom – A glow effect that makes bright areas bleed into surrounding pixels
Brightness – Controls the overall luminosity of the display
Chroma Color – Adds color tinting to simulate phosphor characteristics
RGB Shift – Separates color channels slightly to mimic CRT color misalignment
Screen Curvature – Warps the image to simulate the curved glass of old monitors
Burn-In – Simulates phosphor burn-in from static images left on screen too long
Flickering – Adds subtle brightness fluctuations like real CRT displays
Glowing Line – Renders a scanning beam effect moving across the screen
Horizontal Sync – Simulates horizontal sync issues causing image distortion
Jitter – Adds small random movements to simulate signal instability
Rasterization – Renders visible scan lines characteristic of CRT displays
Static Noise – Adds animated noise/grain to the image

At this point, there were some visual bugs that required a bit of trial and error until the LLM was able to fix them without introducing new issues. The main one was a problem related to the position of the screen reflections.

Step 4: Integrating Xterm.js

Once I was able to get the terminal frame and the effects ported from OpenGL to WebGL, I asked the LLM to replace the hardcoded text with the output of Xterm.js. Xterm.js is an open-source project designed to be a web-based front-end for terminals. It's used in tools like Visual Studio Code because VS Code is a web application that runs inside Electron—Xterm.js is the front-end within VS Code that accesses a real terminal instance on your machine.

In my case, I don't need a real terminal, so I asked Claude to create a terminal emulator with a bunch of basic commands such as clear, ls, cd, and cat.

Step 5: Building Games

At this point, everything was almost complete, so I asked Claude to implement multiple text-based games. I implemented games like Pong, Tetris, Snake, Minesweeper, Space Invaders, and Arkanoid—and most of them worked almost perfectly on the first attempt. Some of the games experienced minor visual issues, but I was able to solve everything by describing the issue in detail to Claude and what I thought was the root cause.

Step 6: Adding Media Playback with ffplay

I also wanted to add support for playing audio and video files directly in the terminal, similar to how ffplay works in a real terminal. I asked Claude to implement an ffplay command that could render video with all the effects previously implemented.

Step 7: Refactoring and Publishing

The final step was to ask Claude to refactor the code to clearly separate the library code (the WebGL retro terminal renderer) from my application code (the terminal emulator and games). The goal was to publish the WebGL terminal renderer as a standalone npm module, and Claude was able to do it with zero issues in just one attempt.

Conclusion

Overall, the entire implementation took around 10–15 hours. Without an LLM, it would have taken me several weeks. I think this project has been an interesting way to demonstrate how powerful LLMs can be as development tools—especially when working with unfamiliar technologies like shader programming.

By the end of the experiment, I consumed about 50% of my monthly GitHub Copilot for Business tokens ($21/month), which means the entire project cost me roughly $10.50. When you consider that this would have taken weeks of work otherwise, the cost savings enabled by Claude Opus are absolutely insane.

If you're curious, you can check out the result at https://remojansen.github.io/ or browse the source code on GitHub.

Forem: Remo H. Jansen

Building a 3D engine from scratch with C++ and Vulkan for web developers Part II: Rendering your first triangle

Where we left off

The updated architecture

Step 1: Render Pass

Attachments

Subpasses

Dependencies

Step 2: Shaders

The two shaders

GLSL → SPIR-V compilation

Loading shader modules

Step 3: Graphics Pipeline

Shader stages

Vertex input

Input assembly

Viewport and scissor

Rasterizer

Multisampling

Color blending

Pipeline layout

Putting it together

Step 4: Command Pool and Command Buffers

Step 5: Framebuffers

Step 6: Synchronization

Semaphores (GPU ↔ GPU)

Fences (GPU → CPU)

Frames in flight

Step 7: Drawing a frame

1. Wait for the previous frame

2. Acquire a swapchain image

3. Record commands

4. Submit to the GPU

5. Present

6. Advance the frame counter

The full frame in one picture

The updated application

The final result

What's next

Building a 3D engine from scratch with C++ and Vulkan for web developers Part I: Bootstrapping Vulkan

Why this project exists

Prerequisites

The toolchain

Clang (the compiler)

CMake (the build system generator)

Ninja (the build executor)

vcpkg (the package manager)

clang-format and clang-tidy (code quality)

.h and .cpp files

The directory architecture

The initialization flow

Step 1: What are Vulkan and GLFW?

Step 2: VkInstance

Step 3: Window

Step 4: VkSurfaceKHR

Step 5: VkDevice

Picking a physical device

Creating the logical device

Step 6: Swapchain

Putting it all together: Application

What's next

From Rigidity to Explicitness: How AI Changes the Role of Constraints in Software

The old model: speed vs structure

The missing variable: AI changes the bottleneck

The rise of underused verification practices

Rigidity is the wrong abstraction

Why explicit systems matter more in an AI-assisted world

A concrete implication: revisiting “flexibility-first” choices

SQL vs NoSQL is not about rigidity

Static vs dynamic typing: a similar shift

The deeper shift: from human-readable to machine-verifiable systems

Conclusion: toward explicit-by-design systems

Source code is now a common good, and SaaS is mostly dead

The Legal Hack That Started It All

The Two Directions of Liberation

1. Open Source → Commercial (GPL → MIT → Proprietary)

2. Commercial → Open Source

Why This Is Unstoppable

The Government Dilemma

The Ironic Outcome: Everything Becomes Open Source

`.h` and `.cpp` files