DEV Community: Farzan Hajian

It All Started with "I Want a Compiler for..."

Farzan Hajian — Sun, 19 Jul 2026 09:28:32 +0000

Building a programming language with an AI coding agent.

On June 10, 2026, driven by my long-standing passion for compilers and programming languages—and curious to see how far AI coding tools could take me—I opened OpenAI Codex and wrote a single prompt.

"I want a compiler for a programming language written in Go..."

The rest of the prompt described a compiler that would generate Windows x64 binaries from a tiny programming language supporting arithmetic, variables, a handwritten recursive descent parser, print(), and if/else.

The AI replied:

"I'll build this as a small Go compiler project from scratch: lexer,
recursive descent parser, basic semantic checks, and Windows x64
executable output..."

That was the beginning of FNL (Farzan's Neat Language).

Compiler construction has fascinated me for many years. I have read books, watched talks, experimented with parser theory, and always wanted to build a compiler of my own. This project was less about creating a production language and more about exploring one of my favorite areas of computer science practically.

Looking back, I thought I was starting a coding project.

What I was really starting was a journey into programming language design.

AI Wrote the Code. I Designed the Language.

One point is worth making from the beginning. I did not write the compiler. Every line of Go code was generated by the AI. That does not mean I was a passive requester.

Throughout the project, I acted as the architect, language designer, reviewer, tester, and ultimately the person responsible for every engineering decision. I was not simply asking the AI to generate code.

I was making engineering decisions, and that was the interesting part.

The AI proposed implementations, challenged my ideas, suggested alternatives, and occasionally made assumptions of its own. Sometimes I accepted them. Sometimes I rejected them. Quite often, we spent considerably more time discussing a feature than implementing it.

The AI implemented the compiler.

I designed the language and directed its evolution.

Learning a Compiler by Building One

From the beginning, I deliberately constrained the project.

I specifically asked for a handwritten recursive descent parser because I wanted a compiler whose code I could comfortably read and understand. Parser generators are powerful, but they were not what I wanted to learn from.

Very quickly, I discovered that implementing the compiler was not the hardest part. Designing the language was.

Strings sounded like an easy feature until we started discussing them.

Should they be ASCII, UTF-8, UTF-16, or UTF-32?

Should string length mean bytes or Unicode code points?

Should comparisons be locale-aware?

Then came conversions.

Should assigning an int to a double happen automatically?

Should "123" become an integer?

How far should implicit conversions go before convenience becomes surprising behaviour?

None of these questions has a universally correct answer. Every decision simplifies one aspect of the language while complicating another.

Fortunately, FNL is still young. I do not have to worry about backward compatibility yet, so I can revisit earlier decisions whenever I discover a better design.

The Compiler Became My Laboratory

Eventually, I stopped testing the compiler with isolated snippets and started writing real programs in FNL.

The repository now includes a Hello World program, a Fibonacci sequence generator, a square root calculator, a π approximation, and a simple guessing game.

Those programs became much more than examples. They became the language's first users.

Almost every one of them revealed something missing.

While writing Fibonacci, I realised I needed break and exit().

While writing the guessing game, I discovered there was no random number generator, which later became math_random().

Later, I accidentally declared a variable named signed instead of sign. FNL accepted it, but the generated C backend failed because signed is a C keyword. Instead of leaking C restrictions into FNL, I introduced symbol mangling so backend names became independent from source names.

Over time, I realised that I did not really get to know my language while designing it. I got to know it while writing software with it.

"You Cheated."

One of the funniest moments came early in the project.

I asked the AI to generate Windows executables.

Instead of generating machine code directly, it quietly decided that the compiler should transpile FNL code to C11 and then invoke a C compiler.

My first reaction was simple.

"You cheated."

After thinking about it, I realised it was a sensible engineering
decision.

The interesting part of this project was never the instruction encoding.

It was language design, lexing, parsing, semantic analysis, symbol resolution, and code generation.

Delegating the final machine code generation to mature C compilers allowed me to focus on the parts I wanted to understand.

Today, FNL supports MSVC, GCC, and Clang backends and can also emit LLVM IR directly.

More Than a Code Generator

Before starting this project, I thought AI would mainly save me from writing code.

It certainly did.

But that turned out to be only a small part of the story.

The AI did not teach me compiler design.

I learned compiler design by building a compiler with the AI.

Knowledge mattered throughout the project.

Without understanding compiler concepts, I would not have known to ask for a recursive descent parser, question a design proposal, recognise a flawed trade-off, or steer the language in a particular direction.

The AI accelerated the implementation dramatically. It never replaced engineering judgement.

If anything, this project convinced me that expertise becomes even more valuable when an AI can implement ideas almost instantly.

Where FNL Goes Next

FNL is still a small language.

There is plenty left to build.

Functions
Structs and user-defined types
Arrays
A richer standard library
A built-in linter
Better debugging support
File I/O

One day, I also hope to reach the milestone many language designers dream about:

Bootstrapping.

Writing the FNL compiler in FNL itself.

There is still a long way to go before that becomes realistic, but it gives the project a clear direction.

Final Thoughts

I started this project because compilers have always fascinated me.

I expected to learn about lexers, parsers, ASTs, semantic analysis, and code generation.

I did not expect to spend so much time thinking about Unicode, type conversions, debugger design, standard library architecture, symbol mangling, and language philosophy.

Looking back, the biggest lesson was not technical.

It was that AI works best as an implementation partner, not a replacement for understanding.

The compiler may have been written by AI.

The language was shaped one engineering decision at a time.

If you are interested in compilers or language design, I hope you find FNL as enjoyable to follow as I found it to build. The source code and example programs are available in the project's Git repository, and I would be happy to hear your thoughts or suggestions.

If this project sparked your curiosity, you're welcome to explore the source code on GitHub. The repository contains everything related to FNL, including the compiler itself, the example programs, and the design notes that document its evolution.

The examples folder contains sample FNL programs, while PROJECT_NOTES.md covers the technical aspects of the compiler, including the language's reference grammar in both BNF and EBNF notations. If you're interested in how many of the design decisions came about, FNL_R_AND_D.md is a journal generated from my conversations with the AI throughout the project.

No, You Don’t Become a Senior Developer Just by Writing More Code

Farzan Hajian — Fri, 07 Nov 2025 14:13:07 +0000

Looking back on my journey as a software developer, I can see how much my approach to work and my way of thinking have evolved. When I started, I believed that becoming a senior developer was all about writing more code, mastering frameworks, and knowing every technical detail. Over time, I realized that while technical skill is essential, it’s only part of the story. True growth comes from how you think, communicate, and approach problems — understanding people, systems, and business, not just syntax.

Communication Is More Than Talking Tech

One of the biggest shifts I noticed as I progressed in my career was a change in how I communicate. Early on, I used to talk mostly in technical language, assuming everyone would follow along. I quickly realized that this approach didn’t work with non-technical people, such as clients, stakeholders, or team members from other domains.

Over time, I learned that the key is not expecting others to adapt to my language, but adapting my language to bridge the gap between the technical and non-technical worlds. Now, I can translate complex technical ideas into terms that make sense to clients and stakeholders, and also bring their perspectives back to the team in a way that helps us make better decisions. Bridging these two worlds has made my work far more effective and impactful.

Seeing the Bigger Picture

As I gained experience, I realized that being a senior developer isn’t just about completing the tasks in front of you. Early in my career, I focused almost exclusively on the work assigned to me. Over time, I began asking myself questions like: Could this new feature break existing functionality? Did this user story conflict with an older one?

This broader perspective also extends beyond the technical side. I started considering the business impact of my work. Every feature isn’t just code; it’s a solution created for users and a step toward solving a larger business problem. Understanding that my role isn’t just to implement tasks, but to ensure user satisfaction and business value, has fundamentally changed how I approach development.

Making a Meaningful Impact

With experience comes trust. Over time, I noticed that colleagues and clients began coming to me for guidance — not just on technical problems, but also on decisions and challenges that go beyond code. Being a senior developer isn’t about simply doing what you’re told; it’s about contributing useful opinions, questioning assumptions, and guiding others toward better solutions.

One of the most rewarding aspects of this role is being able to spot what others might overlook. Even clients who are experts in their domain can miss niche conditions or edge cases. I’ve found myself reminding clients about these subtle details, helping them avoid pitfalls before they arise. Making this kind of impact — on the team, the project, and even the client — is one of the defining aspects of senior-level work.

Solving Problems, Not Chasing Trends

Another shift I noticed as I grew was in how I approach problem-solving. Early in my career, I often felt pressure to use the latest frameworks or technologies simply because they were “modern.” Over time, I realized that solving the problem effectively is far more important than following trends.

Sometimes the best solution is a simple desktop application, even in an era dominated by cloud services and microservices. Legacy systems aren’t outdated just because they aren’t flashy; they often support the parts of the business that generate real value. Understanding when to embrace new technologies — and when to rely on proven approaches — is a key part of being a senior developer.

Closing Thoughts

Finally, one of the most important lessons I’ve learned is the value of self-awareness. As a senior developer, you come to understand what you know — and what you don’t. Early on, I used to try to learn everything at once, thinking that I needed to master every technology or concept. Now, I’ve realized that it’s not about knowing everything from the start; it’s about knowing how to learn what’s needed, when it’s needed.

This awareness brings confidence and focus. It allows you to tackle challenges methodically, seek help when appropriate, and continue growing without feeling overwhelmed. Self-awareness, combined with experience and judgment, is what enables a senior developer to be both effective and reliable.

Becoming a senior developer is a journey — one that’s shaped not by code alone, but by the way you think, communicate, and approach challenges. I’d love to hear your experiences and reflections on growth in software development.