Developer Stories | CoderLegion
Meet Alex Voste, a Canada-based systems-focused developer working across C, Go, x86_64 Assembly, NASM, FASM, C++, Linux, performance optimization, and developer tooling.
Alex describes himself as a network systems engineer and is currently building ForgeZero, a hardened cross-platform build toolchain for C and Assembly developers.
His approach to software is strongly shaped by a fascination with what happens underneath the abstractions — from memory and computer architecture to compilers, build systems, and raw execution speed.
In this Developer Story, Alex shares how he moved from PHP and Java toward systems engineering, why he decided to build ForgeZero, his philosophy around performance and complexity, what he thinks modern build systems get wrong, and why he believes developers working close to the hardware will need strong fundamentals even in an increasingly AI-driven world.
1. From Systems Engineering to ForgeZero
How did you get into systems engineering and what eventually led you to building ForgeZero?
Alex:
I often describe myself as a network systems engineer, but let's be clear, that wasn't a title I woke up one morning and slapped on my LinkedIn. It took years of grinding through the trenches to actually earn it.
I started way back with PHP and web development, then moved into Java, doing the usual backend work. Honestly, it got boring fast. I was building the same conventional stuff everyone else was, shipping the same CRUD, wiring the same frameworks, and calling it engineering when really it was just assembly-line work with better naming conventions.
I wanted to go deeper: how programming languages actually work under the hood, how systems manage memory, or how my phone quietly phones home to corporate servers whether I asked it to or not.
Building a custom build tool wasn't some boardroom decision. It started years ago as a passion project between me and a friend.
We were two enthusiasts trying to write our own operating system in Assembly from scratch, controlling literally everything down to the bit.
Tools like Make or CMake ran completely against that philosophy. We didn't want heavy, opaque black boxes making decisions on our behalf that we never signed off on.
So I built my own toolchain, first in dependency-free Node.js, and later rebuilt entirely in Go, because at some point you get tired of fighting the tool instead of the actual problem.
2. The Problem With Modern Build Systems
What problem do you think modern build systems have, and what is ForgeZero trying to do differently?
Alex:
I firmly believe most modern build systems, and honestly most software in general, run far too many redundant operations that nobody actually needs.
They try to cover every edge case and every platform under the sun simultaneously, even when nobody asked, and you end up paying for that indecision in CPU cycles you never approved spending.
ForgeZero's philosophy is heavily inspired by Gentoo and Linux From Scratch (LFS).
A build toolchain should do exactly what the developer explicitly asks it to do, nothing more.
No hidden magic, no unnecessary overhead, zero wasted cycles.
If I didn't type it, it shouldn't be running.
That principle sits at the heart of how I think about build tooling.
3. Why Build Another Build System?
People often ask why another build system is necessary. Why did you decide to build ForgeZero instead of using existing solutions?
Alex:
People ask me all the time: why reinvent the wheel?
Honestly, I don't see ForgeZero as just another wheel.
It's more like a wheel with a twin-turbo engine bolted on, built by someone who was personally offended by how slow the old wheel was.
The codebase is lean, sitting around 42k+ lines of clean code, with no dead weight padding out a changelog just to look impressive.
I originally built it purely to save my own time.
But somewhere around the third cup of coffee at 3 AM, inspiration hits, and you start bolting on optimizations you never planned at 9 PM.
My motivation was simple: I had a clear architectural idea for how build orchestration could be blazingly fast, and I wasn't going to sit around waiting for someone else to get to it.
When I benchmarked it against real-world projects, ForgeZero came out multiple times faster than the existing solutions.
My goal is to give developers what they actually care about:
- raw speed
- intelligent caching
- real security
- total manual control
Not a dashboard cheerfully telling them everything's fine while it quietly isn't.
4. Why Go and Assembly?
Why did you choose Go as the foundation for ForgeZero, and where does Assembly fit into the project?
Alex:
I chose Go as the foundation because it strikes a rare balance between simplicity and safety.
Write pure C or Assembly for everything, and it's incredibly easy to leave behind a subtle memory bug or race condition you'll be debugging at 4 AM, hating your past self with real, focused intensity.
Go gives me near-C performance while sparing me the catastrophic runtime failures I no longer have the patience to hunt at that hour.
That said, I do use Assembly in ForgeZero, specifically Plan 9 Assembly, on the performance-critical paths.
That's where a huge chunk of our raw execution speed comes from, and no amount of clever Go abstraction replaces hand-placed instructions where it actually counts.
When it's a choice between an optimization that adds complexity or keeping things simple for safety's sake, I'll take the optimization almost every time.
ForgeZero has a fair amount of low-level, high-risk Go code where we bypass standard allocations entirely.
As long as I keep tight control over those boundaries, the performance gains are massive, and I'd rather own that risk deliberately than inherit someone else's by accident.
ForgeZero reportedly performs significantly faster than some existing build tools. What is behind that difference?
Alex:
If you look at the benchmarks where ForgeZero significantly outperforms tools like Ninja on large task sets, the secret isn't some clever trick hiding in a corner.
It's simplicity, plain and unglamorous.
And I know that answer disappoints people hunting for a silver bullet.
When your architecture isn't burning cycles managing legacy abstractions, allocation overhead, or bloated state graphs nobody asked it to maintain, execution ends up blindingly fast almost by default.
We do fewer things, but we do them at the bare-metal limit, on purpose, every single time.
6. Building for Low-Level Developers
What do you think existing developer tooling gets wrong about low-level developers?
Alex:
What existing tooling gets wrong about low-level developers is assuming we want convenience over control.
Most modern dev tools are built around a web-dev mindset: hide the complexity, abstract the system, install 500 MB of dependencies for something that should take twenty lines, and pretend the hardware isn't even there.
Systems engineers, C programmers, Assembly devs, we don't want black boxes.
We want to see the hardware.
We want toolchains that stay out of our way, don't force opinionated directory structures on us like we're kids who need supervision, and don't burn cycles on telemetry or bloated config parsers nobody reads.
Existing tools try to be everything for everyone and end up being genuinely excellent at nothing.
Low-level devs just want a tool that gets out of the way, respects the hardware, and executes instantly.
Full stop.
7. Open Source and Building in Public
What role does open source play in your approach to software development?
Alex:
My core philosophy has always centered on building free, open-source software.
That doesn't mean I never build proprietary products that generate revenue, but when it comes to fundamental tooling, I'd rather keep it open for the community, because gatekeeping a build tool behind a paywall feels beneath the entire point of building one.
For instance, I'm currently working on a confidential AI project applied to medical engineering, more on that down the road.
Building in public keeps your architecture honest, because anyone can audit your code, and nothing sharpens discipline quite like knowing a stranger might read your worst commit at 2 AM and judge you for it, correctly.
How do you decide when a performance optimization is worth the additional complexity?
Alex:
In theory, there's a point where chasing performance stops being worth the engineering complexity.
But if I'm being completely honest about my own process, I don't always respect that limit, and I'm not going to pretend otherwise just to sound balanced in an interview.
I have a relentless drive to push code until it literally cannot run any faster.
As a general rule though, performance optimizations are worth the complexity when they scale linearly with user productivity.
If an optimization saves a developer five seconds on every single build loop, that's hours of focus reclaimed across a real team every week.
But if an optimization makes a codebase unmaintainable just to shave two microseconds off an idle thread nobody's even timing, you've crossed into vanity engineering.
Vanity engineering is just ego wearing a lab coat.
Balance comes down to measuring real-world impact over synthetic vanity, every time, no exceptions.
9. AI and Low-Level Engineering
How do you think AI will affect low-level software engineering?
Alex:
My stance on this is firm: AI will never fully master low-level systems engineering, and I'll happily die on this hill.
I might sound provocative, but based on my own experience, LLMs operate at a noticeably lower level of competence in systems programming compared to high-level web development.
Low-level engineering demands deep spatial reasoning, hardware awareness, and architectural intuition that isn't sitting anywhere in a training set in a usable form.
I actually tested this.
I tried using an AI assistant to help build a low-level, cryptographically secure messenger.
I wasn't asking it to write AES-256-GCM from scratch, I just wanted help with a simple client-server network implementation.
It failed miserably.
I spent days fighting hallucinations and sloppy memory handling before scrapping the AI output entirely and writing the whole thing myself, in a fraction of the time it cost me babysitting the assistant.
AI can fetch docs, summarize a man page, and sound confident doing it.
But it can't reason about bare-metal constraints the way someone who's actually been burned by them can.
For low-level devs, understanding C, Assembly, and computer architecture is only going to matter more, not less, because someone still has to fix the broken code AI generates, and that someone needs to actually know what they're looking at.
10. What Comes Next for ForgeZero?
Where do you want to take ForgeZero next?
Alex:
My immediate goal is assembling a core team of like-minded developers, engineers who are ready to break things, innovate, and move fast without asking permission for every single decision.
I want ForgeZero to be completely free, hyper-fast, and genuinely intelligent, possibly integrating lightweight, targeted AI for build-graph optimization down the line, used smartly and sparingly, not bolted on as a marketing checkbox.
I'm always inviting developers to jump into the repo and build this with me.
No corporate bureaucracy, no meetings that could've been a commit message, just pure engineering.
11. The Engineer Behind the Optimization
Where does your obsession with performance and removing unnecessary complexity come from?
Alex:
Honestly, a deep-seated refusal to accept artificial limits, the ones nobody ever actually proved necessary, just inherited from whoever came before.
Most developers look at a slow tool or a bloated framework and think, well, I guess that's just how software is now, and move on with their day.
I can't do that.
When I see an idle loop burning CPU cycles, or a build tool taking 30 seconds to parse a dependency tree that should take 50 milliseconds, it feels like a personal insult.
Call it perfectionism, call it an obsession with zero overhead.
I genuinely love taking a bloated process, stripping away the noise, and watching it run at the absolute limit of the hardware.
That feeling never gets old.
The day it does is probably the day I stop doing this for a living.
About Alex Voste
Alex Voste is a developer based in Canada with a focus on systems programming, performance optimization, open source, and developer tooling.
His technical interests include:
- C
- Go
- x86_64 Assembly
- NASM
- FASM
- C++
- Linux
- Node.js
- Performance optimization
- Linkers
Alex is currently building ForgeZero, a hardened cross-platform build toolchain for Assembly and C developers.
ForgeZero
ForgeZero brings together tools including NASM, GAS, FASM, GCC, Clang, LD, and Zig behind a unified workflow for low-level developers.
You can explore the project here:
GitHub:
https://github.com/forgezero-cli/forgezero
CoderLegion Profile:
https://coderlegion.com/user/alexvoste
Final Thoughts
Alex's story is a reminder that software development doesn't have to stop at the abstraction layer.
For some engineers, the interesting questions begin underneath it:
What is the machine actually doing?
Where are the cycles going?
Why is this process taking so long?
Which parts of the system are genuinely necessary?
And perhaps most importantly:
What happens if we remove everything that doesn't need to be there?
ForgeZero is Alex's answer to those questions — a project built around speed, control, simplicity, security, and a strong dislike of unnecessary overhead.
Whether you agree with all of Alex's opinions about modern tooling or AI, his approach highlights an important principle for developers at every level:
Understand the system underneath the abstraction.
That understanding becomes even more valuable when the tools themselves start writing the code.
