I keep coming back to one question: why do I like building things from scratch?

From Antsand to C Kernel Engine to flight controllers and drones, there is a pattern in how I work. I do not think this pattern is normal. I am not even sure it is always efficient. But it is real.

This post connects a few threads I have already written about: Flight Controller for Drones, Quaternions, Axis-Angle, And Vector Rotation, What Is the C Kernel Engine?, I Think Like a Compiler, and the two hardening posts on long projects and Linux workflow.

The point is not that these are separate hobbies. The point is that they are starting to look like the same operating pattern across different domains.

First, I am a contrarian. I could probably write a whole book on how to be a contrarian, because that instinct drives a lot of my work. If the industry is running in one direction, I often want to understand what it is ignoring in the other direction.

Second, I cannot physically or mentally progress in many areas if I am blocked by understanding. If I cannot distill something down to a few primitives, I get stuck. I can use a tool for a while, but if the important layer stays hidden, the work feels unstable to me.

Third, I hate bloat.

Those three things explain a lot of what I build.

Great Artists Start With Simple Shapes

The simplest way I can explain this is through drawing.

When great artists draw complex things, they do not usually start with every detail. They break the subject down into simple lines, circles, squares, cubes, cylinders, and shapes. Those basic shapes become faces, bodies, objects, landscapes, machinery, scenery, and everything else.

That is generally how I think about systems too.

Thinking like a compiler is finding those basic shapes, then figuring out how to define them clearly enough that the larger system can be generated from them. Nature does something like this brilliantly with DNA. I am simplifying a lot, but DNA is basically an instruction system. A tiny cell can carry enough encoded information to help reproduce a human, a reptile, a bird, or a tree because the organism has a way to decode and execute those instructions.

That is why primitives matter. The smallest pieces are not small because they are unimportant. They are small because everything else depends on them.

This is contrarian to how many people think. It is easier to look from the top down and say, "just use the abstraction." But abstraction can make the details hurt less, which also makes it easier to stop caring about them. I usually understand systems better from the bottom up: what are the smallest pieces, what are their contracts, and how do they combine?

A compiler takes variables, loops, functions, conditions, and types, then eventually turns them into lower-level instructions the machine can run. That is the question I keep asking in every domain:

What are the variables, loops, functions, shapes, and contracts for this system?

For Antsand, the primitives are content, HTML, CSS, JavaScript, templates, and HMVC structure. For C Kernel Engine, the primitives are kernels, tensors, memory plans, graphs, and gradients. For a flight controller, the primitives are coordinate frames, quaternions, sensor samples, estimators, control laws, motor commands, timing, power, and physical feedback.

Different domains, same question: what are the primitive shapes that make the system possible?

Antsand: The Web Browser Only Understands A Few Things

Take Antsand as the first example.

Antsand is not just a website builder. I think of it more as an HMVC site compiler. The question I keep asking is simple: what does a web browser actually understand?

It understands HTML, CSS, and JavaScript.

So Antsand separates the logic into those components and compiles a website from structured data, style rules, and templates. It tries to keep the raw ingredients visible. Data is data. CSS is CSS. HTML structure is HTML structure. JavaScript should be used where behavior is needed, not because every page needs a giant application runtime.

This is why Antsand does not naturally fit the React-heavy way of thinking. Most modern frontend frameworks are almost the opposite of what Antsand is trying to do. I wrote more directly about that in 14 Ways React Brain Rot Infuriates Me and the Cost of SPA Overuse.

The web development industry loves abstraction, frameworks, bundlers, hydration, client-side state, and shipping fast. I understand why. But my bias is different. I care about simplicity, architecture, and the things that are actually true underneath the toolchain.

If the browser wants HTML, CSS, and JavaScript, why bury that truth under ten layers of framework machinery unless the problem truly needs it?

That is a contrarian stance. The industry wants speed of shipping. I keep drifting back toward architecture, slow productivity, and less bloat.

So Antsand is the no-bloat case study. It is me asking what the browser actually needs, then removing every layer that does not help the compiler produce a clean page. I am not trying to win a framework popularity contest. I am trying to keep the system close to the primitives the browser already understands.

C Kernel Engine: Modern AI As Mathematical Kernels

C Kernel Engine came from a similar instinct.

When I first started writing C-Transformer, I was trying to implement GPT-2 in C from scratch, both forward and backward. That taught me something important: a lot of modern AI can be distilled into a small set of mathematical kernels.

But it also exposed a problem. When I had bugs, I could not easily tell whether the issue was inside one kernel, inside the integration, inside memory layout, inside the backward pass, or inside the whole architecture being stitched together poorly.

That made me ask a different question:

What if I create individual computational kernels, make each one clear, and then stitch them together into modern AI architectures?

Each kernel does the forward pass. The backward pass follows from the chain rule. The system can plan memory, offsets, buffers, and execution order. Instead of hiding everything inside a giant framework, the runtime becomes visible.

The important part is that each kernel can be tested on its own. I can compare a C kernel against PyTorch, llama.cpp-style references, or another known-good implementation for both forward and backward behavior. That means when I stitch kernels together, I can be more confident that a failure is not a basic math-kernel issue.

This is why C Kernel Engine has daily kernel and runtime tests. The goal is not just to write C code that runs. The goal is to prove that the mathematical pieces are numerically sane before the compiler stitches them into a larger model. The current C Kernel Engine test report is part of that discipline.

That came directly from the pain of C-Transformer. If the whole transformer is one tangled implementation, a bug can hide anywhere. If the kernels are isolated, tested, and then composed, the debugging surface becomes much cleaner.

That is first-principles thinking. That is no-bloat thinking. That is mathematical thinking.

Yes, I can use PyTorch. Yes, I can use llama.cpp or vLLM. Those tools are powerful. But C Kernel Engine is my attempt to make the runtime lightweight and inspectable. It gives the compiler raw mathematical kernels and a stitching hierarchy, then generates clean C code with memory planning and offsets.

This connects directly to my older post, I Think Like a Compiler. When you think like a compiler, you are always trying to generate something. To generate something reliably, you need the critical primitives, the structure, and the contracts that let the generation work.

Antsand does this for websites. C Kernel Engine does this for AI runtimes.

Antsand takes data, CSS, templates, and HMVC structure, then composes strict HTML output. C Kernel Engine takes kernels, graph structure, memory plans, and model configuration, then compiles clean C execution. Different domains, same pattern.

C Kernel Engine is the primitives case study. It is me refusing to treat an LLM as one giant magical object and instead asking what the real mathematical pieces are: GEMM, attention, RoPE, RMSNorm, softmax, MLPs, gradients, memory offsets, and testable contracts. Once those pieces are visible, the larger model becomes less mystical and more like a system I can reason about.

So Why Build My Own Flight Controller?

This brings me to the flight controller.

I have already written about the broader flight controller stack and the attitude math behind quaternions, axis-angle, and vector rotation. Those posts explain pieces of the system. This post explains why I keep wanting to own the system instead of only using someone else's finished abstraction.

My bigger goal is to build drones and robots for ecological monitoring and biodiversity conservation. I may never be successful. But I want to give it a serious shot.

Ecological monitoring is not just "put a camera on a drone." The real problem is endurance, repairability, sensing, compute efficiency, field reliability, power budget, wind, terrain, data quality, and the ability to adapt the stack to a specific environment. A polished consumer drone is optimized for a different product definition. I want a robotics stack where the airframe, flight controller, sensors, edge compute, logs, and field workflow can all be changed for ecological intelligence instead of treated as sealed boxes.

Someone could say: just buy a drone, strap on a camera, and you are done.

Someone else could say: DJI, Skydio, PX4, ArduPilot, and many others already exist. What is your upside?

I understand that argument. But I also do not care that much, because my difference is not that I magically have more resources than those companies. My difference is how I work and how I think about systems.

A flight controller I design is not only about making a drone fly. It is about integrating the robotics stack with everything else I am building: C Kernel Engine, Antsand, ShivasNotes, Linux workflows, simulation, PCB design, local AI, and field data.

This connects to my hardening posts: Hardening Long Projects in the Age of AI and Hardening My Linux Engineering Workflow.

The loop is always the same:

1. Learn the primitives I need for the application.
2. Harden those primitives individually.
3. Integrate them into a larger system.
4. Harden the whole system as one workflow.

The flight controller will probably be the most complex piece because it involves hardware. Hardware does not care about my intentions. A bad solder joint, a noisy sensor, a wrong quaternion convention, a bad controller sign, or a poor power path can destroy the illusion immediately.

This is the contrarian and ownership case study. A finished flight stack can make something fly faster, but it can also hide the exact layers I need to understand: sensor timing, estimator behavior, control response, motor output, power noise, and field failure modes. For ecological monitoring, the stack itself is part of the product.

The actual project stack already has names. Some parts are more mature than others, but each one exists because I need that layer to become inspectable:

The Flight Controller Is Where The Math Becomes Physical

To build this stack, I need to understand quaternion math, Kalman filters, state estimation, PID, LQR, dynamic modeling, motor control, aerodynamics, propellers, inertial navigation, flight planning, PCB design, power electronics, and embedded firmware.

These are not light topics. No sane person wants to casually take all of them on at once.

But I feel like I should.

The reason is similar to C Kernel Engine. It is all about the math. In C Kernel Engine, the math is tensors, kernels, attention, gradients, memory, and backprop. In a flight controller, the math is quaternions, rotation matrices, Jacobians, estimators, control laws, dynamics, motor models, and sensor frames.

Different math. Same instinct.

I want the primitives. I want the contracts. I want the system to become legible.

What I Think I Gain By Going Deep

In my attempt to build a from-scratch flight controller, I believe I will gain intuition that I would not get by only using a complete stack directly.

I will learn how to remove bloat and use only what I need. I will understand where abstractions help and where they hide the thing I actually need to see. I will understand how the math, firmware, PCB, sensors, motors, logs, and simulations connect.

Most importantly, I believe I can eventually make a drone that is world-class and differentiable for the mission I care about, not the mission DJI or Skydio cares about.

That mission is ecological monitoring. Long endurance, repairability, efficient compute, useful sensing, field data, and a stack I can inspect and adapt. That is different from simply making a polished consumer drone.

This is hard. There is a ridiculous amount to do. The hardware integration alone is complex. But this is literally how I think, and it is hard for me to work any other way.

ShivasNotes Is Part Of The Stack Too

I am writing this on ShivasNotes, a blog powered by Antsand, which is funny and also important.

ShivasNotes is how I keep track of my logs, progress, thoughts, failures, and system design. I have been building Antsand for about twelve years. I have been studying flight controllers for around ten years. I have been studying machine learning and AI for more than ten years. C Kernel Engine is newer as a specific project, but it came from that long background.

I also have a master's degree in electrical and computer engineering with a specialization in embedded systems. That does not magically make me good at everything. But it does mean math, physics, signals, systems, and embedded thinking have been with me for a long time.

Over those years I have invested in books, lab equipment, boards, components, tools, and many failed attempts to make the pieces click.

Now AI fits into this workflow in a strange but useful way.

AI Helps My Way Of Thinking, But It Does Not Replace The Work

If you like bloat, AI will generate bloat for you too. So AI is not automatically good.

But for the way I think, I feel like AI gives me an edge. I do not want an agent that blindly does everything. I do not care about agents as a buzzword. I care about learning and building.

If an agent is a catalyst for that workflow, fine. But the workflow is still mine.

The loop looks more like this:

1. I write, design, think, and plan.
2. AI helps polish, challenge, organize, and connect the pieces.
3. I build and make the system work.
4. AI helps harden the workflow, find gaps, and turn artifacts into documentation.
5. I keep studying, testing, and integrating.

It is very hard to find a human who thinks like a compiler across the whole stack: web development, AI runtimes, C kernels, drones, flight controllers, hardware, Linux, and content systems. AI has become that strange partner for me. Not perfect, not always right, but useful enough that the symbiosis is real.

That may change quickly. But right now it helps me hone in on my strength: build from scratch, go deep, remove bloat, understand the primitives, and harden the system.

Why This Matters For Independent Builders

I think this is where AI may genuinely help independent researchers and builders.

With very limited resources, one person can start to feel like a small team. Not because AI magically replaces expertise, but because it helps maintain context, generate scaffolding, check assumptions, summarize artifacts, and keep the system moving.

My flight controller stack is built on that bet.

With AI, I think I can get all these projects working sooner. Without AI, I would still try, but it would take much longer.

The work is still the work. I still have to understand the quaternion. I still have to test the Kalman filter. I still have to solder the board. I still have to check the motor current. I still have to read the datasheet. I still have to debug the C code. I still have to make the drone not crash.

But now I have a partner that can help me keep the whole map in view.

Conclusion

So why do I build things from scratch? Because primitives give me ownership, ownership gives me trust, and trust matters when the system leaves the laptop and becomes a drone, a sensor, a field workflow, or an AI runtime I need to understand. It may be slow, it may look foolish, and it may take forever, but this is the only way the work becomes real to me.