Coder Legion - Recent posts tagged devjourney

From GitHub to Codeberg: Rethinking Repository Management and Personal Website Hosting

Wed, 28 Oct 2026 15:35:59 +0000

Developer platforms make it easier than ever to build and publish software. With hosted Git repositories and static website deployment, an individual developer can maintain a portfolio without managing an entire server infrastructure.

However, convenience also introduces an important question: how prepared are we when our existing workflow no longer meets our needs?

I recently faced this question while maintaining my personal website and repositories.
When a Familiar Workflow Stops Working

GitHub had been an essential part of my development process. I used it to manage source code, track changes, and publish my personal website through GitHub Pages.

The workflow was straightforward. I could commit changes, push updates, and use the hosting service to make my website publicly accessible.

Eventually, I encountered an issue that affected website publishing. My account was still accessible, but the publishing functionality did not work as I expected. I could not establish the exact cause, so I avoided drawing conclusions about the platform or its policies.

Nevertheless, the problem disrupted my workflow and encouraged me to explore alternative solutions.

The experience highlighted something worth considering: even when source code is stored safely, the services surrounding a repository may introduce separate dependencies.

Repository storage, continuous integration, deployment, domain management, and public hosting are related, but they are not necessarily the same responsibility.

Understanding those distinctions can make future migrations easier.
Moving Repositories to Codeberg

I decided to move my repositories to Codeberg, a platform built around open-source software and Git-based collaboration.

A repository migration requires more than copying project files. Depending on the project, developers may need to verify branches, tags, commit history, remotes, and repository settings. Issues, pull requests, automation, and other platform-specific features may require separate consideration.

A practical migration checklist includes:

Create a reliable backup of each repository.
Verify that the Git history and important branches are preserved.
Update remote URLs and test push and pull operations.
Review project documentation and any external integrations.
Confirm that essential workflows still function after migration.

Not every platform feature has a direct equivalent, so each project should be checked individually.

The objective is not merely to move the code. It is to ensure that the development workflow remains usable afterward.
Self-Hosting a Personal Website

For website deployment, I chose a home server instead of relying on my previous publishing workflow.

Self-hosting provides a valuable learning opportunity, particularly for developers who want to understand how websites operate beyond application code.

It also introduces several operational responsibilities.

DNS records must point to the correct destination. Public access may require router configuration, a reverse proxy, or a suitable tunneling solution. HTTPS should be configured appropriately, while backups and software updates need to become part of regular maintenance.

Availability is another consideration. A home server depends on electricity, network connectivity, hardware reliability, and the security of the surrounding environment.

Self-hosting is therefore not automatically cheaper or more reliable than managed hosting. The right choice depends on the project, available resources, and the operator's willingness to maintain the system.
A Better Understanding of Technical Dependencies

This migration has encouraged me to think more carefully about portability, infrastructure, and recovery planning.

Developers do not necessarily need to abandon hosted services. However, they benefit from knowing which components are essential, how those components interact, and how to replace them if necessary.

I documented the personal side of this transition, including why I left my previous workflow and what I hope to learn from the move, in my original article:

Read the full experience: Moving On, Not Out of Hate: My Journey from GitHub to Codeberg

For me, the move is both a practical adjustment and a learning project. By combining Codeberg for repository management with a home server for deployment, I hope to develop a better understanding of the infrastructure behind my personal projects.

Sometimes, the most useful outcome of a technical problem is not the replacement tool itself, but the knowledge we gain while finding a new way forward.

A Small Milestone in My Developer Journey

Sun, 18 Oct 2026 17:27:43 +0000

Hey developers! 👋

I wanted to share a small milestone from my journey as an independent developer.

After spending quite some time using GitHub Pages' default free domain, I've finally purchased my own custom domain. It might not sound like a big achievement, but it means a lot to me because I saved up for it little by little.

I also had to step away from my developer activities for a while due to real-life responsibilities. Now, I'm slowly getting back into things and looking forward to sharing more projects, experiments, and technical notes.

The best part is that I don't need to change my hosting setup. I'm still using GitHub Pages, with my new domain serving as the website's personal identity.

I'm grateful for the free tools that make it easier for developers with limited budgets to start building online.

I wrote a short reflection about this experience and what it means for my personal website, Simply Karya.

Read it here: A New Domain, A New Chapter

What's your story? Did you start with free hosting before moving to a custom domain?

How Adobe Firefly and Copilot Taught Me to Prompt for Code (Part 1)

Sun, 18 Oct 2026 17:06:01 +0000

Every time the topic of AI comes up in developer spaces, the conversation usually splits into two extremes: people who claim AI takes "zero effort" because you just type a sentence and get a finished product, and people who dismiss prompting as a soft, non-technical skill that has nothing to do with "real" engineering.

Anyone who has actually spent hours trying to force a foundation model to produce a specific, non-generic output knows that both takes are wrong.

My goal wasn't to generate random fantasy landscapes or stock avatars. I wanted to recreate my dog—an American Pit Bull Terrier (APBT)—across distinct visual styles so I could design a clean, accurate brand logo. To do that, I set two strict rules for myself:

1. Only Native Firefly: I refused to jump to third-party models when things got difficult; I committed exclusively to the native Adobe Firefly model (working through Firefly Image 3 and 4, long before conversational in-canvas editing existed).

2. Only My Own Photos: I never used stock presets or random internet pictures. Every single generation was fed exclusively with my own photographs of my dog.

That self-imposed constraint turned into a masterclass in fighting statistical bias, understanding parameter pipelines, and sanitizing noisy inputs. Looking back, the exact workflow I had to build to get Firefly to respect canine anatomy is the same mental model required to get an LLM to write production-ready code.

(Note: This is the first part of a multi-part series exploring how creative AI workflows translate directly into software engineering and systems architecture.)

my dog for reference

Behance Project: Morgan "Vega"

Fighting the "Default Weight" (Why Lazy Prompts Fail)

When I started experimenting with Firefly in 2024 and locked into a heavy daily workflow in 2025, I quickly hit a wall. If you type "pitbull" into an image model by itself, you do not get an accurate American Pit Bull Terrier.

Because public stock datasets suffer from massive tag pollution—where people tag Mastiff crosses, Cane Corsos, American Bullies, and random block-headed mixes under the same umbrella term—the model’s latent space defaults to two extremes: either an exaggerated, short-legged caricature or a generic Labrador-mastiff hybrid with mushy features.

Because I refused to switch to another generator, I had to learn how to override Firefly's statistical baseline using my own reference photos, active human feedback (RLHF), and structured parameter control.

The Engineering Parallel:

LLMs do the exact same thing with code. If you give a coding model a lazy prompt like "build an API endpoint to process user data," its weights will pull straight toward the internet's most common, bloated, and outdated tutorials. To override the statistical default, you cannot rely on umbrella terms. You have to provide a structural blueprint and specify exact boundaries.

How Firefly Actually Works: Parameter Pipelines & Edge Copilot

Most people who haven't used Adobe Firefly assume it works like a simple chat box. In reality, Firefly’s interface is a structured parameter pipeline that separates geometry, style, and text tokens into distinct control layers.

Instead of relying on a single text prompt to do everything, Firefly breaks generation down into specific modules:

General & Content Settings: Choosing the base model (Firefly Image 3 / 4), locking the Aspect ratio, switching Content type between Photo and Art, and dialing the Visual intensity slider.
Composition Reference (Structure): This is where I uploaded my own photos of my dog. Under the hood, Firefly uses this slot for edge detection and depth mapping, forcing the new generation to follow the physical geometry of the uploaded photo.
Style Reference & Effects Taxonomy: Rather than guessing random adjectives, Firefly categorizes visual weights into structured buckets—Movements, Themes, Techniques, Effects, Materials, and Concepts (such as Minimalism, Flat design, Anime, or Doodle drawing), alongside explicit dropdowns for Color and tone, Lighting, and Camera angle.

To master this setup, I realized I needed to understand what all those art movements and techniques actually meant, and how Firefly's text parser expected them to be combined with my reference uploads.

I opened Copilot in the Edge browser and used it as my domain tutor and syntax compiler:

Learning the Art Taxonomy: I used Copilot to learn the technical differences between the styles available in Firefly—what separates a digital painting from continuous-contour linework, cross-hatched doodle styles, manga ink, or flat vector color blocking.
Compiling Firefly-Specific Prompts: Firefly didn't want chatty paragraphs; it wanted clean, comma-separated tokens that complemented the sidebar parameters. When the model kept cropping or distorting lower limbs, I used Copilot to help refine explicit anatomical and positional tokens (like standing and showing his legs) that worked with my uploaded Composition Reference.

Adobe Gallery

(an American Pit Bull Terrier, black, standing, in a simple background, digital painting)

One of my early experiments feeding my dog's photo into this pipeline was hand-picked by Adobe to be featured in the official Adobe Firefly Gallery.

If you look at the prompt on that featured gallery card—an American Pit Bull Terrier, black, standing, in a simple background, digital painting—a casual viewer might assume it took zero effort. What they don't see is how the pipeline worked together: because I fed my own photograph into the Composition Reference slot and gave continuous feedback on anatomically accurate runs, my photo carried the morphological constraints (the exact rose/half-pricked ears, the lean chest, the straight front assembly). That allowed the text prompt to stay surgical and declarative.

The Engineering Parallel:

Prompting complex systems is configuration and technical specification. When your underlying architecture is solid—when your Pydantic schemas, type definitions, and structural interfaces are already passed into the system's parameters—you don't need to write a 500-word conversational essay begging the AI not to hallucinate. Your prompt can be a clean, concise instruction because the structural reference is already doing the heavy lifting.

The Pre-Editing Experiments: Diagnosing Cross-Attention Bleed

Even with Firefly's Composition Reference locking my dog's anatomy in place, pushing my raw photos across radically different art styles before in-canvas editing existed exposed a major flaw in how diffusion models read reference images.

Manga drawing style of an American Pit Bull Terrier, black.

 American Pit Bull Terrier, solid black, doodle style

 American pit bull terrier, solid black, standing and showing his legs, doodle style

American pit bull terrier, solid black, standing and showing his legs, cartoon style

black american pit bull terrier standing

Looking across these early runs—all generated from my own photos—you can see two things happening at once:

What Worked (Morphological Locking): Whether I pushed the engine toward stark white-on-black ink, clean doodle style linework, manga drawing style, or cartoon style pop art, my dog's core anatomy, ear carriage, and muscle tone stayed true to my photos.
Where the Noise Leaked In (Environmental Contamination): Look closely at the backgrounds. Because Firefly's Composition Reference evaluates the entire uploaded image, it couldn't tell where my dog ended and the backyard began. In the manga generation, a metal pole and patio clutter from my original photo bled straight into the illustration. In the walking side-profiles, the model spent half its attention rendering the wooden deck planks and walls. And in the sketch and dark stencil, background shadows confused the style weights into hallucinating fake artist signatures and floating geometric shapes in the negative space.

Input Sanitization: The 1:1 Cutout Breakthrough

Diagnosing why those background artifacts were happening led to my biggest workflow breakthrough: I started completely removing the background from my dog's photos and standardizing the canvas to a 1:1 square before uploading them into Firefly's Composition Reference

Suddenly, every generation locked in without environmental bleed. Why?

Eliminating Cross-Attention Contamination: In a raw outdoor photo, 60% of the pixels are grass, fences, poles, and shadows. The model’s attention layers try to apply your Effects and Styles across all that background noise at once. Stripping the background zeroed out those competing tokens, forcing 100% of the feature extraction onto the dog's silhouette.
Unambiguous Edge Maps: Isolating the subject gave Firefly's Composition Reference algorithm a stark, vector-clean perimeter to color and shade within—instantly eliminating the hallucinated signatures and floating background scribbles.
Native Latent Geometry: Setting the input cutout and Firefly's Aspect ratio parameter to a centered 1:1 square aligned with the native geometry of diffusion grids, eliminating compositional drift and giving me the exact, isolated character assets I needed to composite my final brand logo by hand.

The Engineering Parallel:

Garbage context in, garbage code out. Those metal poles and fake signatures in my early dog drawings are the exact visual equivalent of what happens when a developer dumps an entire cluttered repository, unformatted stack traces, and five unrelated files into an LLM context window and says "my code is a mess, fix it."

The Takeaway (And What's Next in This Series)

For a long time, I fell into the trap of thinking that being "good at prompting" didn't count as a real technical skill. We are conditioned to believe that unless we are suffering through manual boilerplate or memorizing every flag from scratch, we are somehow taking a shortcut.

But refusing to take the easy route—sticking exclusively to the Firefly model, feeding it only my own photography, using Edge Copilot to master art taxonomy and syntax, diagnosing attention bleed across dozens of test runs, and engineering a clean 1:1 preprocessing pipeline—taught me what prompting actually is. Whether you are steering a diffusion model away from tag-polluted training data or directing a coding agent through a production refactor, the core discipline is the same: systems thinking.

Coming up next in this series:

In the next post, I’ll be sharing my full Behance project, where I break down the complete visual archive of my Firefly attempts—showing the direct before-and-after impact of the 1:1 cutout pipeline—and how I took those isolated AI assets into Photoshop to composite and finish the final brand logo. Stay tuned!

Landscape Layout & Terracing | UE5 Devlog

Fri, 09 Oct 2026 20:47:09 +0000

In this devlog, I showcase the landscape creation and terracing process for Kazuhara resort in Unreal Engine 5. Using Landscape Mode’s Sculpt, Flatten, and Smooth tools, I shape the terrain, create distinct terraces, and soften the transitions between elevations.

The focus is on building a foundation for the resort, balancing usable flat areas with the natural slopes of the surrounding landscape. It’s a look at the work behind shaping the environment before the finer details bring it to life.

Mohammed Ghaban Built an Arena Where AI Coding Agents Have to Prove Their Code Works

Thu, 08 Oct 2026 13:37:53 +0000

Mohammed Ghaban Built an Arena Where AI Coding Agents Have to Prove Their Code Works

AI code can look right and still fail. Mohammed Ghaban built an arena that runs it to find out.

Mohammed Ghaban is an AI/ML developer and open-source contributor from Yemen, focused on building practical AI applications, intelligent agents, and developer tools.

His work spans Generative AI, LLMs, AI agents, machine learning, MLOps, and AI security. But one of his most interesting projects takes a very practical approach to a growing problem in software development:

What happens when AI-generated code looks correct but isn't?

That question led Mohammed to build CodeBots Arena, an AI-vs-AI programming battle arena where AI agents generate code, execute it in a controlled environment, and compete based on the results.

The project combines FastAPI, React, Monaco Editor, Elo ratings, and RestrictedPython to create an environment where AI-generated solutions can be tested rather than simply judged by how convincing they look.

From Kaggle to an AI-vs-AI Arena

The idea behind CodeBots Arena grew from Mohammed's interest in AI competitions.

“I was interested in creating a competition where AI systems could compete through programming, and I looked at the kinds of competitions available on Kaggle.”

While exploring existing competitions, he realised that he wasn't finding exactly what he had in mind.

“I realized I wasn't seeing the exact kind of AI-vs-AI coding competition I had in mind.”

That led to a simple question:

“Instead of only participating in competitions, why not try to build one?”

And that became CodeBots Arena.

Rather than simply asking an AI model to produce a solution, Mohammed wanted to create a system where AI-generated solutions could actually compete, execute, and be evaluated.

Why the Sandbox Matters

There are two particularly interesting parts of CodeBots Arena: how the agents are evaluated and how their code is executed.

The project uses an Elo rating system to track the relative performance of AI agents over repeated matches.

As Mohammed explains:

“ELO provides a simple way to track relative performance over time.”

But ranking the agents is only part of the problem.

The generated code also needs to be executed safely.

Mohammed makes an important distinction:

“AI-generated code cannot be treated as trusted code.”

That's why CodeBots Arena uses RestrictedPython together with validation and testing to provide controlled execution.

The result is more than two AI models generating code.

It becomes an environment where developers can experiment with AI-generated programming solutions and evaluate what actually happens when those solutions are executed.

When AI-Generated Code Looks Better Than It Actually Is

Building CodeBots Arena changed the way Mohammed thinks about AI-generated code.

One of the biggest lessons was how convincing generated code can be even when it is wrong.

“AI-generated code can look much more convincing than it actually is.”

A solution might appear logically sound but still fail because of an edge case, an incorrect assumption, or a subtle implementation problem.

That observation is central to Mohammed's interest in evaluation.

“Watching generated code actually run changes the question from ‘Does this answer look good?’ to ‘Does this solution actually work under the conditions of the task?’”

That distinction becomes increasingly important as developers rely more heavily on AI coding tools.

AI can produce code extremely quickly.

But producing code and proving that the code works are two very different things.

“Talk Is Cheap. Show Me the Code.”

Mohammed's CoderLegion profile uses the famous Linus Torvalds quote:

“Talk is cheap. Show me the code.”

But Mohammed believes the idea takes on a slightly different meaning in the age of AI-generated software.

AI can generate a large amount of code very quickly.

The real question is what happens when that code is tested.

As Mohammed puts it:

“AI can generate a lot of code very quickly, but generating code is not the same as proving that the code works.”

For him, showing the code increasingly means:

“Show me the tests, show me the results, show me the benchmark, and show me what happens when the system fails.”

That philosophy is at the heart of CodeBots Arena.

A Bug That Had Nothing to Do With AI

Not every challenge Mohammed encountered while building CodeBots Arena was related to artificial intelligence.

He also documented a PYTHONPATH issue where his tests worked locally but failed in CI.

The experience highlighted an issue every developer eventually encounters:

Something can work perfectly on your machine and still fail somewhere else.

Debugging the problem required looking at the differences between the local development environment and the CI environment.

The experience reinforced the importance of:

Reproducible environments
Environment configuration
Automated testing
CI
Not assuming that local success means a project is finished

As Mohammed explained:

“A project can work perfectly on your machine and still fail when the environment changes.”

For someone building an experimental platform where AI-generated code has to survive real execution, that lesson is particularly relevant.

Beyond CodeBots Arena: Benchmarks and AI Evaluation

CodeBots Arena is only one part of Mohammed's work.

His profile highlights ongoing work in AI/ML, LLMs, AI agents, benchmarking, Kaggle projects, open-source development, and machine learning experimentation.

He has also worked on projects involving Legal AI hallucination benchmarking.

His interest in benchmarking comes from the same fundamental question behind CodeBots Arena: how can we measure whether an AI system is actually performing well?

As Mohammed explains:

“A model can sound intelligent while still hallucinating, reasoning incorrectly, or failing on specific edge cases.”

Benchmarking makes those weaknesses measurable.

Instead of simply asking whether an AI response sounds intelligent, benchmarks can help reveal where a model succeeds, where it fails, and how its performance changes.

Learning Through Curiosity

Mohammed has accumulated significant experience through hands-on learning.

His profile highlights 87+ Google Developer Program badges and achievements, more than 115 completed Google Skills learning activities, and 33,402 Google Skills points, including Diamond League status.

His learning covers areas including:

Google Gemini
Google Cloud
AI agents
Google ADK
Machine learning
Transformers
Fine-tuning
MLOps
AI security
Model evaluation

But Mohammed doesn't see the badges as the main objective.

“My learning pace comes mostly from curiosity rather than trying to collect badges.”

That mindset comes through in the projects he builds.

Rather than learning concepts only theoretically, he tends to turn them into experiments, benchmarks, open-source projects, and working software.

Building Without a Computer

One of the more unusual parts of Mohammed's journey came when his computer stopped working.

Because of his circumstances and the situation in Yemen, he wasn't able to immediately replace it.

Instead of stopping his work completely, he continued primarily using his iPhone, browser-based tools, and free resources.

It wasn't easy.

“It has certainly been more difficult and sometimes frustrating, especially when working on technical projects that would normally require a full development environment.”

But he decided not to allow the lack of hardware to completely stop him.

It's a reminder that developers don't always get to build with the ideal setup.

Sometimes you work with whatever you have available and keep moving forward.

What Mohammed Is Exploring Next

Mohammed's current interests include:

AI agents
Multi-agent systems
LLM evaluation
Generative AI
AI-generated code
Google Gemini
Google ADK
MLOps
AI security
Fine-tuning and Transformer architectures

He is particularly interested in systems where AI agents can take actions, use tools, write or execute code, and then be evaluated based on what they actually accomplish.

That makes CodeBots Arena a natural foundation for his future work.

Mohammed's vision for the project is clear:

“A year from now, I'd like CodeBots Arena to be a more mature open-source project with stronger evaluation, more interesting competitions, and more opportunities for other developers to experiment with AI coding agents.”

Build Before You Feel Ready

When asked what advice he would give other developers, Mohammed keeps it simple:

“Build before you feel ready.”

His approach is straightforward:

Start with a small problem.

Experiment.

Fail.

Debug.

Try again.

He doesn't expect every project to succeed.

“I don't know exactly where every project will lead, and not everything I build will succeed, but I want to keep creating, learning, and improving.”

That attitude is perhaps the strongest theme running through his work.

Whether he's experimenting with AI agents, benchmarking models, competing on Kaggle, contributing to open source, or building CodeBots Arena, the focus remains on turning ideas into something that can actually be tested.

Proving What AI Can Actually Do

AI-generated software is becoming increasingly capable.

But capability isn't the same as reliability.

Mohammed Ghaban's work with CodeBots Arena explores an important question for the next generation of software development:

What happens when we stop judging AI-generated code by how good it looks and start judging it by whether it actually works?

His answer is to build an environment where the code has to prove itself.

Generate it.

Run it.

Test it.

Measure it.

And learn from what fails.

That's the idea behind CodeBots Arena — and it may become an increasingly important way to think about AI-assisted software development.

From Writing Web Novels to Shipping Software — Nocklock’s Developer Journey

Thu, 08 Oct 2026 13:10:12 +0000

From Writing Web Novels to Shipping Software — Nocklock’s Developer Journey

“I think AI is most useful when it extends my thinking rather than replacing it.”

Nocklock didn't originally become a developer because programming was a lifelong childhood dream.

It started for a much more practical reason: making a living.

A few years ago, before AI became deeply integrated into everyday software development, Nocklock was looking for a practical way into the industry. In Korea, Java and Spring were widely used in enterprise and public-sector development, making them a natural choice.

But programming eventually became interesting for a reason that had little to do with career practicality.

Before becoming a developer, Nocklock had commercially published two web novels.

That experience would unexpectedly influence the way he thinks about software.

Writing fiction means creating a world, defining its rules, and allowing characters to interact within those rules.

Software isn't so different.

Programming languages have rules. Networks have rules. Data has structure. Business logic creates constraints. Developers build systems and user flows inside those constraints.

The connection between writing and programming gave Nocklock a different way of thinking about development.

Instead of seeing software only as code, he began seeing it as a system of possibilities.

And that perspective continues to influence how he builds today.

Programming Started as a Practical Choice

Nocklock's initial decision to learn programming was pragmatic.

Java and Spring offered a realistic path into professional software development, particularly within Korea's enterprise and public-sector technology landscape.

But choosing a technology for practical reasons doesn't necessarily mean remaining interested for practical reasons.

As Nocklock gained experience, he discovered that programming gave him something he had already experienced through writing:

the ability to create systems governed by rules.

When writing a novel, he might ask:

What if I were the character?

What if the situation were different?

What would happen if the rules changed?

He now brings similar questions into software development.

When building something, he tries to imagine different situations and perspectives.

What if he were the user?

What if the user knew nothing about the subject?

What if the environment were different?

What if an assumption turned out to be wrong?

That habit of questioning has become part of how he approaches development.

Learning by Shipping

One of Nocklock's strongest beliefs is reflected directly in his profile:

learning by shipping.

He discovered why this approach worked for him while studying for Korea's Engineer Information Processing qualification.

Much of the preparation involved studying and memorizing theory.

But he noticed something interesting.

He could forget information he had memorized for an exam.

Yet he could still remember errors he had encountered while working, why they happened, and how he eventually solved them.

The difference was experience.

Knowledge connected to a real problem stayed with him.

That realization changed how he approached learning.

When he encountered an AI development competition, he began building rather than waiting until he had learned everything he thought he needed to know.

He learned what was necessary while developing the project.

He made mistakes.

He investigated them.

He fixed them.

And eventually, he shipped.

That's what learning by shipping means to him.

It doesn't mean abandoning study.

It means turning knowledge into experience.

Security Lens: When the MVP Became Real

One of the clearest examples of this philosophy was Security Lens.

The original idea sounded relatively straightforward.

A user would upload an image, OCR would extract information, the system would identify potential privacy risks, and the user would receive useful results.

But building the real product exposed a much messier reality.

Real files and images didn't always behave as expected.

OCR accuracy wasn't always reliable.

Unexpected problems kept appearing.

And once the core functionality finally worked, Nocklock realized something important:

The main feature working didn't mean the product was finished.

It meant the next phase had started.

There were still improvements to make, problems to investigate, and a deadline approaching.

That experience changed his understanding of what it means to ship software.

Building the main feature is only one milestone.

Shipping means confronting the difference between:

the product you imagined

and

the product that actually exists.

The README Became a Product Review

Nocklock initially thought writing the README would simply mean documenting what he had already built.

Instead, documentation exposed problems in the product itself.

During development, he had often moved quickly from one problem to the next.

Get something working.

Move forward.

Solve the next issue.

Keep building.

But when he tried to explain the project clearly, he started noticing gaps.

Sometimes he would describe a feature and suddenly question whether the feature was necessary at all.

That changed the purpose of the README.

It was no longer just documentation.

It became a way of reviewing the product.

Writing forced him to examine:

The project structure
Individual features
Development decisions
The reasoning behind those decisions
Whether certain features were actually necessary

In that sense, documentation became another form of development.

Sometimes explaining what you built reveals whether you should have built it in the first place.

A New Laptop Revealed Hidden Complexity

Another unexpected lesson came from something much more ordinary:

setting up a new laptop.

Moving from an established development environment to a clean machine exposed how much invisible state had accumulated over time.

JDK versions.

PATH settings.

Git configuration.

IDE settings.

Build synchronization.

Environment variables.

Small setup decisions that had gradually become invisible.

On the old machine, those things simply worked.

On the new one, they didn't.

Suddenly, when something behaved unexpectedly, Nocklock had to ask:

Is this a problem with my code?

Is it the build state?

The JDK?

The IDE?

The environment configuration?

That experience led to an important realization:

The development environment is part of the system too.

A clean machine can reveal what you genuinely understand and what your previous environment had quietly been doing for you.

Debugging Doesn't Stop at the Code

Deployment reinforced the same lesson.

Local development can feel comfortable.

Then the application gets deployed.

Suddenly, ports, environment variables, runtime differences, external services, configuration and hidden assumptions all become part of the problem.

Nocklock experienced this while deploying Security Lens to Railway.

It also helped him understand why tools such as Docker became so important.

Docker doesn't eliminate every deployment problem.

But making the runtime environment reproducible can remove a significant category of differences between machines.

As a result, his approach to debugging has expanded.

He doesn't look only at the code anymore.

He also considers:

Configuration
Runtime
Environment
External dependencies
Deployment conditions
Assumptions connecting those pieces

Sometimes the bug isn't in the code.

Sometimes the code is behaving exactly as written inside an environment you misunderstood.

Why Java and Spring Still Matter

Nocklock originally chose Java and Spring because they were practical.

After working with them professionally, however, he developed a different appreciation for the ecosystem.

What stands out to him is its maturity and structure.

Backend services can quickly become complicated.

They may involve:

Business logic
Databases
APIs
Security
External integrations
Multiple requirements
Different environments

In that situation, conventions and proven patterns can become extremely valuable.

Spring provides abstractions that help developers build quickly while still leaving a deeper ecosystem underneath those abstractions to understand.

But Nocklock doesn't believe Java or Spring should automatically be used for every problem.

The technology should fit the problem.

That idea connects directly to one of his broader principles:

follow the problem, not a fixed stack.

AI Should Extend Thinking, Not Replace It

Nocklock's approach to AI is deliberately different from simply asking an AI model to write everything.

His first step isn't:

“Write this for me.”

Instead, he tries to explain what he's curious about, why he's curious about it, and how he thinks the pieces might connect.

Then he asks AI to help explain the subject.

Only after understanding the direction does he use AI for implementation, code review, identifying mistakes or suggesting improvements.

That distinction matters to him.

AI can provide an enormous amount of knowledge.

Its ability to interact with tools and take action is also growing quickly.

But Nocklock wants the important questions, judgment and decisions to remain his responsibility.

The ideal relationship isn't human versus AI.

It's human thinking enhanced by AI.

AI becomes a multiplier for understanding rather than a substitute for understanding.

Following the Problem Instead of the Stack

Nocklock doesn't want technology to be the starting point of a project.

He starts with the problem.

What is being built?

How quickly does it need to be built?

What constraints exist?

What can realistically be maintained?

What can be verified?

Sometimes Java and Spring are the right choice because they are familiar and fit the requirements.

Sometimes another technology is better.

AI has made experimenting with unfamiliar technologies easier, but that doesn't mean every new technology deserves to be added to a project.

In fact, sometimes following the problem means deliberately choosing something familiar and boring.

That's an important distinction.

Being flexible doesn't mean constantly chasing new technology.

It means choosing technology based on what the problem actually requires.

The Cost of Moving Too Fast

One mistake Nocklock continues to notice in himself is focusing heavily on implementation and assuming the structure can always be cleaned up later.

Security Lens made this particularly obvious.

Because of the competition deadline, he often solved the next problem in front of him and moved on.

That approach helped maintain momentum.

But later, while documenting the project, he could see where the structure had become messy.

He could also see that some features probably didn't need to exist.

The lesson wasn't that moving quickly was wrong.

It was that speed doesn't remove the cost of decisions.

It simply delays when you see that cost.

Today, Nocklock tries to create small moments during development where he can step outside the code and ask:

Does what I'm building still make sense?

That pause can prevent a lot of future cleanup.

What He's Exploring Next

Nocklock's interests are increasingly moving toward the intersection of:

Backend development.

AI.

Security.

Real products.

Security Lens began as a tool for detecting privacy risks in files before they are uploaded.

Working on it opened up broader questions about digital content.

How do we know whether an image or piece of content is authentic?

Where did it come from?

Was it generated or modified by AI?

Can AI-generated media be used to imitate another person?

These questions have made areas such as content provenance and identity risk particularly interesting to him.

At the same time, he remains interested in building smaller experimental products.

The goal is to test an idea quickly, receive real feedback and then decide whether the idea deserves further investment.

Build Something Smaller

When asked what advice he would give other developers, Nocklock's answer is straightforward:

Build something smaller than the thing you originally wanted to build.

It's easy to remain in preparation mode.

There is always another:

Course
Framework
Tutorial
Concept
Technology

that could be learned first.

But developers don't need to understand everything before starting.

Build something small enough to finish.

Let it break.

Deploy it.

Let another person use it.

Then examine what goes wrong.

Those problems will often tell you what you genuinely need to learn next.

For Nocklock, one real error that requires investigation can teach more than memorizing ten definitions.

Experience creates context.

Context makes knowledge stick.

Becoming More Than a Framework Developer

Nocklock doesn't want to become a developer defined by a single framework.

Java and Spring are an important foundation, but his longer-term goal is broader.

He wants to become someone who can move comfortably between:

Engineering
AI
Product thinking
Deployment
Problem solving
Communication

He wants to understand a problem, choose appropriate tools, build the system, deploy it, explain it clearly and improve it based on what actually happens.

In other words:

Not simply someone who writes code.

Someone who can take an idea and keep working on it until it becomes something another person can actually use.

From Writing Stories to Building Systems

There is an interesting connection running through Nocklock's entire journey.

Before software, there was storytelling.

He created fictional worlds, defined their rules and imagined what could happen inside them.

Then came programming.

Different syntax.

Different constraints.

Different tools.

But a surprisingly similar creative process.

Software also involves defining rules, creating systems and imagining what happens when different pieces interact.

Today, AI adds another layer to that process.

It can help him explore unfamiliar concepts, test ideas and move faster.

But he still wants to be the person asking the questions.

The person deciding what matters.

The person choosing what to build.

And ultimately, the person responsible for shipping it.

Knowing What Not to Build

When Nocklock first started programming, he thought becoming a better developer mostly meant knowing more.

More syntax.

More frameworks.

More technologies.

His perspective has changed.

Technical knowledge still matters.

But software development is also about understanding the problem, questioning assumptions, debugging beyond the code, communicating decisions, working within constraints and actually shipping something people can use.

He has also learned that knowing what not to build can be just as important as knowing how to build something.

Code remains at the center of the work.

But it isn't the whole job anymore.

The Developer Journey Continues

Nocklock's journey began with a practical career decision.

It developed through Java and Spring.

It was shaped by an earlier life as a published web novelist.

It accelerated through learning by shipping.

Security Lens taught him the difference between building an MVP and actually shipping a product.

Documentation taught him to question his own decisions.

Deployment taught him that the environment is part of the system.

AI taught him another way to learn and work.

And his current interests are taking him toward the intersection of backend engineering, AI, security and real-world products.

His philosophy can be summed up simply:

Start with the problem.

Build something small.

Let reality test it.

Learn from what breaks.

Ship it.

Then do it again.

About Nocklock

Nocklock is a developer building useful things with Java, Spring and AI.

His approach centers on learning by shipping, documenting what works and following the problem rather than committing to a fixed technology stack.

His current interests include backend development, AI, security, content provenance and experimental product development.

View Nocklock's profile on CoderLegion

Visit Nocklock's website

CoderLegion Developer Stories

Real developers. Real journeys. Real experiences.

Developer Stories at CoderLegion gives developers a place to share how they think, what they build, the problems they encounter and what they learn along the way.

Interview & Story by Mehadi Hasan

From Software Development to AI & Real Estate Tech — Waqas Ahmad’s Developer Journey

Thu, 08 Oct 2026 12:57:44 +0000

From Software Development to AI & Real Estate Tech — Waqas Ahmad’s Developer Journey

“Coding may help you build the product, but understanding people helps you build something people actually want to use.”

Waqas Ahmad's journey into technology didn't begin with a computer.

It began with his family.

Growing up, he watched his father work hard to build a better future for the family. His father had come from a rural area near Burewala, supported his own education by teaching, and later spent years serving patients despite limited medical facilities.

That example shaped Waqas's attitude toward education, hard work and persistence.

Initially, Waqas wanted to become a doctor.

He chose the medical stream during matric, but his father encouraged him to consider technology, believing computers would become increasingly important.

Waqas changed direction.

He studied ICS and eventually enrolled in a BS Computer Science program at Virtual University of Pakistan.

But his path into software development wasn't straightforward.

While studying, he also had family responsibilities and worked different local jobs, including as a helper, cashier and later handling accounts and store responsibilities at a restaurant.

He continued studying alongside those responsibilities.

Eventually, a school friend, Saulat Abbas, helped strengthen his programming skills and encouraged him to keep coding.

Waqas started small.

Calculators.

Simple JavaScript games.

Small projects.

Then those experiments gradually became something more serious.

He joined Pixel Perfects while still completing his degree and began working on real software projects.

That was when technology stopped being only something he was studying.

It became something he was building.

From Learning to Building Real Products

Early in his development journey, Waqas was particularly interested in frontend development and UI/UX.

He enjoyed thinking about how an interface should look, how users should move through it and how a product could become easier to understand.

But working on real projects taught him that building software is only part of the equation.

A product also needs users.

Someone needs to understand those users.

Someone needs to communicate with clients.

Someone needs to explain what the product does.

Someone needs to market it.

And someone needs to make sure people can actually find it.

That realization gradually expanded Waqas's role beyond pure development.

His experience at Pixel Perfects exposed him to both sides.

He worked on frontend and full-stack projects before moving into customer support and client communication.

He discussed requirements with clients, handled orders and revisions, coordinated with developers and designers, and helped ensure projects were delivered according to expectations.

Later, when EstateAI launched, his responsibilities expanded further into SEO, content marketing, product listings, directory submissions, blogs and social media.

His technical background became an advantage.

He wasn't simply marketing a technology product.

He understood the technology behind it.

Why Frontend Remained Important

Although Waqas has worked across the stack, frontend and product experience remain the areas he enjoys most.

He particularly enjoys taking an idea and turning it into an interface that people can actually use.

Early in his development journey, he noticed that some of his friends were stronger in programming logic while he had a stronger eye for interfaces and user experience.

Instead of treating that difference as a weakness, they worked together.

He learned from them.

They learned from him.

Over time, Waqas became more comfortable working across the stack.

His experience includes technologies such as:

React.js
Next.js
Node.js
Express.js
MongoDB
MySQL
Firebase
REST APIs
Tailwind CSS
Bootstrap
Git & GitHub

But technical breadth isn't the only lesson he took from full-stack development.

He learned that a feature can technically work and still have a problem.

If users find it confusing or difficult to use, the product still needs improvement.

That perspective has remained with him even as his career expanded into customer-facing and content roles.

He naturally thinks about both sides:

How does it work technically?

How does it feel to the person using it?

When Development Meets Content

Waqas's move into content creation wasn't a complete departure from software development.

It was an extension of it.

He discovered that technical products need communication.

A product can be well engineered and still fail to reach people if nobody understands what it does or why it matters.

His work in content and SEO gave him a different perspective on technology.

He began creating blogs, articles and social media content.

He worked on SEO and backlink building.

He listed products on relevant platforms.

He helped with directory submissions and online visibility.

He also continued communicating directly with customers.

That combination taught him something important:

Good software needs good communication.

And good technical content requires an understanding of the technology behind it.

For Waqas, development and content are therefore not completely separate disciplines.

They solve different parts of the same problem.

EstateAI: Applying AI to Real Estate

One of the most important products in Waqas's current journey is EstateAI.

The idea comes from a practical problem in real estate marketing.

Property professionals often need to prepare and improve large numbers of property images before they can effectively market a listing.

That can involve repetitive tasks such as:

Improving images
Staging empty rooms
Changing the atmosphere of a photo
Removing unwanted objects
Visualizing different possibilities for a property

EstateAI approaches this as an AI-powered property marketing workspace.

The goal isn't simply to generate an impressive image.

It's to make AI useful inside an actual property marketing workflow.

That distinction matters.

A real estate professional needs more than an attractive AI-generated image.

The property still needs to look like the same property.

Its architecture matters.

The room layout matters.

The camera perspective matters.

The overall identity of the space matters.

AI becomes useful when it improves the presentation without losing those important characteristics.

Making AI Useful Instead of Just Impressive

One of the biggest challenges Waqas sees in AI-powered real estate technology is balancing visual quality with accuracy.

People may see impressive AI-generated images and assume every result will automatically be perfect.

Professional workflows are different.

Reliability and consistency matter just as much as visual quality.

There is another challenge too:

The user shouldn't need to understand the technology.

A realtor shouldn't have to understand AI models, prompting techniques or complicated settings just to improve a property photo.

That leads to one of Waqas's central product principles:

The value of AI isn't only in the underlying technology. It's in turning that technology into a workflow that solves a specific problem without creating unnecessary complexity for the user.

Start With the User, Not the Technology

Waqas's experience in customer support has strongly influenced how he approaches product development.

When you communicate directly with customers, you hear things developers don't always hear.

Where people get confused.

What they expected.

What frustrates them.

Which features they actually care about.

That experience changed how Waqas thinks about software.

Instead of starting with:

“What can this technology do?”

He prefers to start with:

“What problem are we solving?”

And then:

“Does this actually make the user's work easier?”

This is particularly important with AI.

AI makes it possible to build an enormous number of technically impressive features.

But technically impressive doesn't automatically mean useful.

Good product development means being honest about what the technology can actually do while designing the experience around what users genuinely need.

CodersWire and the Reality of Product Development

Another important project in Waqas's journey was CodersWire.

Unlike an academic exercise, it gave him an opportunity to work on a real-world product.

His contribution was mainly focused on the frontend and UI/UX side, working with technologies including Next.js, TypeScript, MUI, Tailwind CSS, Google Maps and React Slick.

The project also involved backend technologies including NestJS, MySQL, TypeORM, AWS and Nodemailer.

The experience reinforced a lesson that goes beyond any individual technology:

Building software is very different from completing a coding task.

A real product requires thinking about the complete system.

How components communicate.

How users interact with the interface.

How the application evolves.

How different people contribute.

How the product responds to changing requirements.

It also reinforced the importance of collaboration.

Waqas had friends and colleagues who were stronger in areas where he was still developing, particularly programming logic and backend concepts.

Working with them helped him improve faster than trying to learn everything alone.

What Customer Support Taught Him About UX

Working directly with customers changed Waqas's thinking about software more than he expected.

As a developer, it can be easy to focus on whether a feature technically works.

Customer conversations reveal another reality.

A technically correct product can still be difficult to use.

Or difficult to understand.

Or simply different from what the customer expected.

In his customer-facing role, Waqas dealt with:

Project discussions
Client requirements
Orders
Coordination
Deliveries
Revisions
Communication between customers, designers and developers

That experience taught him to look beyond what customers literally say and try to understand what they actually need.

He now carries that perspective into both product development and content creation.

When he explains or promotes a product, he tries to think about the questions a real user would ask rather than simply listing technical features.

Turning Complex Technology Into Simple Ideas

Waqas's approach to technical content starts with the audience.

A developer might immediately understand terms such as:

APIs
AI models
Server-side rendering
Automation

But a business owner or general user may not need to understand all of those technical details.

So Waqas asks three questions:

What does this technology do?

Why does it matter?

How can it help the person reading it?

From there, he prefers simple language, practical examples and real use cases.

His development background helps him understand the technical side.

His customer-facing experience helps him communicate that technical side.

For him, good technical content shouldn't make readers feel like they need a technical background just to understand the idea.

It should leave them with a clear understanding of what the technology means and why it matters.

AI and the Role of Human Judgment

Waqas sees AI as one of the most useful tools available to modern developers and content creators.

It can reduce repetitive work.

It can help explore solutions.

It can generate initial code.

It can help with debugging ideas.

It can support learning unfamiliar concepts.

In content and marketing, AI can assist with research, brainstorming, drafting and organizing information.

But Waqas doesn't see AI as a replacement for human judgment.

In fact, he believes AI can make human judgment more important.

Someone still needs to decide:

Is the output accurate?
Does it actually solve the problem?
Is the message appropriate for the audience?
Does the result feel authentic?
Is the idea worth pursuing?

AI can generate possibilities.

Humans still need to decide which possibilities are worth pursuing.

The Challenge of Building While Life Keeps Moving

One of the biggest challenges in Waqas's journey wasn't purely technical.

It was building a career while managing responsibilities outside his studies.

There were periods when he worked long hours in local jobs while continuing his education.

He also had family responsibilities.

That made his path slower and more difficult than simply focusing entirely on university and coding.

There was another challenge too.

He recognized that he wasn't equally strong in every part of development.

UI/UX and frontend came naturally to him.

Programming logic required more practice.

Instead of treating that difference as a reason to stop, he learned from people around him.

Saulat Abbas helped strengthen his coding foundation.

Working with Abdullah Sheikh taught him the value of collaboration, particularly because Abdullah was strong with JavaScript logic.

That experience taught Waqas something important:

Progress doesn't always mean being the best person in the room.

Sometimes it means finding people you can learn from.

Don't Limit Yourself to Coding

For Waqas, one of the biggest lessons from his career is that developers shouldn't limit themselves to coding.

Technical skills are important.

But building a product requires much more.

It requires understanding:

Users
Communication
Marketing
Customer support
Business problems
Product positioning
User experience

His own career demonstrates that.

He has moved between:

Development.

Customer support.

Content.

SEO.

Product marketing.

Each role gave him a different perspective on how software actually reaches people and serves customers.

That combination has become one of his strengths.

Start Small and Build for Real

For developers who want to build their own products, Waqas recommends starting before they feel completely ready.

Talk to users early.

Understand the problem before deciding what technology to build.

Learn enough about marketing and communication to explain the product clearly.

And don't wait until you know everything.

A first project doesn't need to be impressive.

It could be:

A calculator.

A simple game.

A small web application.

What matters is actually building it.

Those early projects teach concepts that tutorials alone can't provide.

They also create the confidence needed to tackle larger problems later.

Don't Compare Your Timeline

Waqas's own journey is a good example of why comparing development timelines can be misleading.

His path wasn't straightforward.

He changed direction from medicine to computer science.

He worked local jobs while studying.

He developed his programming skills gradually.

He moved between development, customer support, content, SEO and product marketing.

He became involved with AI and real-estate technology.

None of it happened through a perfectly planned route.

And that's okay.

His advice is not to compare your timeline with someone else's.

Technology changes constantly.

The important skills are not limited to a particular framework or programming language.

The ability to learn.

The ability to adapt.

The ability to communicate.

And the willingness to keep improving.

Those skills continue to matter even when the technology changes.

Looking Ahead: AI, SaaS and Real Estate

Waqas's current interests sit at the intersection of three areas:

AI.

SaaS.

Real estate technology.

His experience with EstateAI has shown him how much opportunity exists in industries that still contain manual and repetitive workflows.

He wants to continue exploring AI-powered products that solve practical business problems rather than simply adding AI because it is popular.

At the same time, he wants to continue improving his development skills while remaining involved in content, SEO and product marketing.

That combination suits the way he naturally thinks about technology.

He enjoys being involved at different stages of a product:

From understanding the technology.

To thinking about the user.

To communicating the product's value.

To helping people discover it.

Long term, he wants to contribute to products where technology, business and user experience come together in a meaningful way.

From Doctor to Developer

Looking back, Waqas's journey could have gone in a completely different direction.

He initially wanted to become a doctor.

His father encouraged him to consider technology.

He changed direction.

He studied computer science.

He worked local jobs while studying.

He learned from friends.

He built small projects.

He entered professional software development.

Then his career expanded beyond development into customer support, content, SEO and product marketing.

Today, he's working around AI and real-estate technology while continuing to develop his technical skills.

The journey wasn't linear.

But every stage contributed something.

His father's example taught him persistence.

Working while studying taught him resilience.

Friends taught him collaboration.

Development taught him how to build.

Customer support taught him how users think.

Content and SEO taught him how to communicate value.

And AI is giving him new ways to connect technology with real-world problems.

Building at the Intersection

Waqas's story isn't simply about becoming a better programmer.

It's about discovering that technology products live at the intersection of many disciplines.

Code matters.

But so does design.

So does communication.

So does marketing.

So does customer understanding.

And increasingly, so does AI.

His journey has taken him across all of those areas.

And that may ultimately become his biggest advantage.

Because building a useful product isn't just about asking:

“Can we build it?”

It's also about asking:

“Should we build it?”

“Who needs it?”

“Will they understand it?”

“Will they actually use it?”

And:

“Does it solve a real problem?”

For Waqas Ahmad, those questions are becoming just as important as the code itself.

About Waqas Ahmad

Waqas Ahmad is a Software Engineer and Content Creator working across software development, AI, digital marketing and real-estate technology.

His technical background includes JavaScript, TypeScript, React.js, Next.js, Node.js, Express.js, MongoDB, MySQL, Firebase, REST APIs, Tailwind CSS, Bootstrap and Git/GitHub.

He has worked on full-stack applications, developer platforms and AI-powered real-estate products, while also building experience in customer support, SEO, content marketing and product communication.

View Waqas's profile on CoderLegion

Visit Waqas's website

CoderLegion Developer Stories

Real developers. Real journeys. Real experiences.

Developer Stories at CoderLegion gives developers an opportunity to share how they think, what they build, the problems they encounter and what they learn along the way.

Interview & Story by Mehadi Hasan

From 0 to 1: Muhammad Sameer’s Journey Building SMS AI

Thu, 08 Oct 2026 12:46:36 +0000

From 0 to 1: Muhammad Sameer’s Journey Building SMS AI

“0 to 1 is taking a totally blank canvas or a messy problem and turning it into a working URL.”

For Muhammad Sameer, software development isn't just about writing code.

It's about taking something that doesn't exist and turning it into something real.

A blank canvas.

A messy problem.

A late night of coding.

And eventually, a URL that people can actually open and use.

That philosophy has shaped his journey from learning to code in Pakistan to becoming an independent software engineer and building his own AI products.

Today, his focus is SMS AI—an AI workspace and engine designed to bring multiple AI-powered capabilities into one place while keeping the experience fast and practical.

But getting there has involved much more than simply building another AI interface.

It has meant learning to move independently, making difficult technical trade-offs, optimizing performance, listening to users and accepting that a real product only truly begins once people start using it.

Choosing Independence

Muhammad's journey into software development began in Pakistan.

As he learned to code, he gradually became frustrated with the traditional corporate approach to software development.

There was too much waiting for permission.

Too many decisions that depended on someone else.

Going independent changed that.

It gave him the freedom to choose his own technology stack, move quickly and, perhaps most importantly, own his mistakes.

That freedom came with responsibility.

When you're working independently, there isn't always another person to blame when something doesn't work.

If the product breaks, you fix it.

If the technology choice was wrong, you rethink it.

If users don't like something, you have to listen.

For Muhammad, that trade-off is worth it.

The ability to move from an idea to implementation without waiting for permission became one of the biggest motivations behind his independent journey.

What “0 to 1” Really Means

Muhammad's definition of building from 0 to 1 is simple:

Take a blank canvas or a messy problem and turn it into a working URL.

But getting from zero to something real isn't always a clean process.

It requires instinct.

Experimentation.

Rapid prototyping.

And a willingness to make decisions without knowing whether they will ultimately be correct.

For Muhammad, one of the most rewarding moments is seeing an idea become something that people are actually clicking on.

That's the moment when an abstract idea becomes a real product.

It's also what keeps him building.

The Problem Behind SMS AI

The idea for SMS AI came from a problem Muhammad experienced himself.

As a developer, his browser had become overwhelmed with tabs.

Tabs for coding.

Tabs for searching.

Tabs for reading PDFs.

Tabs for generating images.

Tabs for different AI tools.

Each tool might be useful individually.

But together, they created what Muhammad describes as “tab fatigue.”

The problem wasn't necessarily that the tools were bad.

It was that the workflow had become fragmented.

Instead of moving between multiple services, Muhammad wanted a unified environment where those capabilities could live together.

That became the idea behind SMS AI Workspace.

Building a Unified AI Workspace

The goal of SMS AI Workspace is to bring different AI-powered capabilities into one command center.

Instead of constantly switching between tools, users can work from a single environment.

The workspace acts as the visible frontend—the part users interact with.

But behind that interface is another important component:

The SMS AI Engine.

Muhammad deliberately separates the two.

The Workspace is the cockpit.

The Engine is the infrastructure underneath it.

That separation allows the visible product to remain focused on the user experience while the engine handles the more complex AI operations behind the scenes.

The Engine Behind the Workspace

The SMS AI Engine acts as middleware for the system.

It handles model routing and vector searches and decides what kind of model should handle a particular request.

Not every task needs the most powerful reasoning model.

Some requests can be handled by a faster and cheaper model.

Others require a heavier reasoning engine.

Automatically choosing between those options helps Muhammad manage one of the realities of building AI products:

AI can get expensive quickly.

Model selection therefore isn't simply a question of which model is technically the best.

It's also a question of cost, speed and what the user actually needs.

The engine helps make those trade-offs behind the scenes.

Chasing Sub-100ms Responsiveness

Building an AI workspace wasn't only about getting the features working.

Muhammad wanted the application to feel fast.

That meant looking closely at everything happening between the user's action and what appeared on the screen.

He worked aggressively to remove blocking code within the framework he was using on Lovable.dev.

He introduced virtualized list rendering, allowing the page to process only the text that is actually visible rather than everything in a large list.

He also implemented token buffers to reduce heavy screen re-renders.

And he used optimistic UI updates, allowing user messages to appear immediately while the server connection is still being established.

The goal was straightforward:

Make the application feel instantaneous.

For Muhammad, speed isn't simply a technical metric.

It's a product feature.

If an application feels slow, users leave.

The Reality of Building Alone

Being an independent builder means making decisions constantly.

There are always more things to fix than there is time to fix them.

Muhammad describes the process as a brutal exercise in triage.

He separates work into three broad categories:

Game-breaking bugs
Features users are actively asking for
Visual polish

That prioritization helps him avoid spending too much time making something look perfect while an important problem remains unresolved.

It also reflects a broader lesson from building a real product:

Not everything can be done at once.

A solo developer has to decide what matters most right now.

Speed Is a Feature

One of Muhammad's strongest product lessons is that speed itself can be a feature.

Users don't necessarily care how complicated the underlying implementation is.

They care about how the product feels.

If an application responds quickly, it feels polished.

If it constantly waits, users become frustrated.

That makes performance part of the user experience rather than something that belongs exclusively to the engineering side.

For SMS AI, that meant optimizing rendering, network interactions and the way information is displayed—not simply making the underlying functionality work.

Building for Developers Means Listening to Developers

Muhammad believes developers don't necessarily want corporate-style marketing.

They want tools that work.

And they want creators who listen.

That means being honest when something is broken.

If a bug appears and the creator acknowledges it and fixes it quickly, users notice.

That responsiveness builds trust.

For Muhammad, the relationship between a product builder and the developer community isn't primarily about polished promotional messaging.

It's about credibility.

Build something useful.

Listen to the people using it.

Fix problems.

Keep improving.

The Difference Between a Portfolio Project and a Real Product

One of Muhammad's strongest lessons is the difference between building something for a portfolio and building something that real people depend on.

A portfolio project exists in a safe environment.

You decide what it should do.

You control the testing.

You know how it works.

A real product is different.

Real users do things you never expected.

They find bugs you didn't know existed.

They ask for features you didn't plan.

They use the product in ways you never imagined.

That's why Muhammad encourages developers to ship before they feel completely ready.

The product doesn't truly begin evolving until real people start using it.

Ship Before You're Ready

For builders, waiting until everything feels perfect can become a trap.

There will always be another feature to add.

Another design detail to improve.

Another bug to investigate.

Another part of the architecture that could be cleaner.

Muhammad's advice is therefore direct:

Ship your code way before you feel completely ready.

Once the product is in front of real users, development becomes much more grounded.

Instead of asking:

“What do I think users might want?”

You can observe:

“What are users actually doing?”

That feedback becomes far more valuable than assumptions made in isolation.

Finding Problems Worth Solving

Muhammad's approach to building products starts with a problem that genuinely annoys him.

The SMS AI Workspace emerged from his own frustration with having too many disconnected tools open in his browser.

That personal connection matters.

When the creator experiences the problem directly, there is already a reason to keep working when implementation becomes difficult.

His advice to other builders reflects the same principle:

Find something that annoys you.

Then build the simplest version that could make the problem better.

Put it in front of people.

Let reality determine what happens next.

What's Next for SMS AI?

Muhammad's next focus is not simply adding more features.

He's working on cleaning up layout clutter and improving the overall experience.

He's also building something he calls the Memory Vault.

The idea is to allow the AI to remember a user's coding guidelines and project styles across sessions.

Instead of repeatedly explaining the same technology stack, preferences and conventions, the user could establish those details once and have the system remember them.

For developers working across multiple projects, that could make AI interactions much more consistent.

The goal isn't simply to make the AI remember more.

It's to make the workspace feel more personalized and useful over time.

Building the Future One Product at a Time

Muhammad's journey is ultimately a story about moving from learning to building.

From waiting for permission to making his own decisions.

From having an idea to turning it into a working URL.

From building projects privately to putting products in front of real users.

And from thinking about what a product should do to learning what it actually needs to become through user feedback.

SMS AI is still evolving.

So is Muhammad's journey.

But his philosophy is already clear:

Build quickly.

Listen carefully.

Fix what breaks.

Keep moving from 0 to 1.

About Muhammad Sameer

Muhammad Sameer is an independent software engineer and full-stack developer focused on rapid product development and next-generation AI platforms.

He is the Founder of Deltacoders and the creator of SMS AI, including SMS AI Workspace and SMS AI Engine.

His work focuses on AI products, web development, developer tools and taking products from idea to working implementation.

View Muhammad's profile on CoderLegion

CoderLegion Developer Stories

Real developers. Real journeys. Real experiences.

Developer Stories at CoderLegion gives developers an opportunity to share how they think, what they build, the problems they encounter and what they learn along the way.

Interview & Story by Mehadi Hasan

From Game Reverse Engineering to IoT Security — Kostas Ereksonas’s Developer Journey

Thu, 08 Oct 2026 12:40:36 +0000

From Game Reverse Engineering to IoT Security — Kostas Ereksonas’s Developer Journey

“Having a community of like-minded individuals also helps tremendously.”

Kostas Ereksonas's journey into cybersecurity began long before he had a formal security role.

It started with a computer.

Then hardware.

Then game modifications.

Then reverse engineering.

And eventually, a much bigger question:

How secure are the connected devices that surround us every day?

Today, Kostas works across cybersecurity, network analysis, IoT security, machine learning and post-quantum cryptography.

His work involves everything from analyzing Android applications and IP cameras to reverse engineering network protocols, studying encrypted traffic and thinking about how organizations will migrate to post-quantum cryptography.

What connects all of these areas is curiosity.

Rather than simply using technology, Kostas wants to understand what happens underneath it.

The First Computer

Kostas first became interested in computers while he was still in primary school.

It was around the time his parents got their first desktop computer.

He immediately became interested in what was happening inside it.

Hardware.

Low-level BIOS settings.

The things most people never needed to touch.

That curiosity soon expanded into something more experimental.

Games became an opportunity to investigate how software worked.

Kostas started modifying games and experimenting with tools such as Cheat Engine.

He wasn't satisfied with simply playing.

He wanted to understand how the game mechanics worked and whether they could be changed.

That naturally led him toward reverse engineering binaries.

At the same time, he began learning the fundamentals of JavaScript and C++ during middle school.

Those experiences eventually convinced him that Information Technology was the direction he wanted to pursue.

From Game Modification to Cybersecurity

Kostas's formal transition into cybersecurity happened while working on his Bachelor's thesis.

The subject was an internet-connected surveillance camera.

The project exposed him to something that changed the way he thought about connected devices.

The camera's security was patchy and outdated.

Instead of simply treating those limitations as part of the project, Kostas became interested in understanding them more deeply.

That investigation pulled him into the world of IoT security.

Along the way, his interests also expanded into data science and statistical analysis of network traffic.

This combination would later become important to his work in network intrusion detection.

Why IoT Security Matters

IoT devices create a particularly interesting security problem.

They are everywhere.

They often have constrained computing resources.

They can remain deployed for years.

And many users understandably assume that a device is safe simply because it is connected behind a router.

Kostas strongly disagrees with that assumption.

An end-of-life IoT device with known vulnerabilities can become a serious security risk if it remains connected to a network containing business-critical or sensitive systems.

Some devices may also contain weak security practices such as hardcoded credentials, weak encryption or undocumented functionality.

The problem isn't necessarily that every IoT device is inherently dangerous.

The problem is that these devices often become part of an organization's attack surface without receiving the same level of security attention as traditional computers and servers.

For Kostas, raising awareness of those risks is an important part of IoT security.

Looking Beyond the Interface

When Kostas investigates an application or connected device, he doesn't start by assuming the interface tells the whole story.

He starts by observing.

For an Android application, that might mean clicking through the application and watching what data moves between components.

For an IP camera or IoT control panel, it might mean observing the communication between the device and its surrounding infrastructure.

The goal is to identify patterns.

Once those patterns become visible, he can begin working out how the underlying system behaves.

Sometimes the technology turns out to be based on a familiar standard.

For example, while analyzing an Android application, Kostas encountered a standard AES-CBC implementation used for locally stored data.

The cryptographic algorithm itself wasn't unusual.

The problem was how it had been implemented and configured.

Hardcoded keys and passwords don't suddenly become secure simply because a standard encryption algorithm is being used.

The same principle applies to network protocols.

When a protocol operates over TCP/IP, tools such as Wireshark can reconstruct the network byte stream.

The researcher's job then becomes understanding how those bytes correspond to the application's protocol.

The Investigation That Required Everything He Had Learned

One of Kostas's most challenging investigations involved a Perenio Peifc01 IP camera.

The difficulty wasn't necessarily that the device used an impossibly complicated technology.

It was that there wasn't much existing research available about that particular model.

Compared with more widely investigated IP cameras, there were fewer write-ups and fewer resources to build upon.

That meant Kostas had to rely heavily on experience gained from previous investigations.

He applied what he had already learned from analyzing IP cameras and their Android applications.

That experience helped him identify how locally stored data was protected and analyze the audio and video stream transmitted through RTP over UDP.

Wireshark became an important part of understanding what was happening on the network.

The investigation reinforced an important lesson:

Previous investigations become tools for future investigations.

Every device teaches you something that can become useful when the next unfamiliar system appears.

The Dangerous “It's Behind a Router” Assumption

One of the security assumptions Kostas considers particularly dangerous is:

“It's behind a router, so it must be safe.”

A router is not a security guarantee.

An IoT device can communicate with external cloud services.

It can contain vulnerabilities.

It can become compromised.

And once an attacker controls one device inside a network, that device may become a stepping stone toward other systems.

Cloud communication introduces additional considerations as well.

A compromised or poorly secured device may communicate with its vendor's infrastructure in ways that create additional attack opportunities.

For Kostas, network isolation and understanding what devices are actually communicating with are therefore critical parts of securing IoT environments.

Detecting Attacks When Traffic Is Encrypted

Modern network security faces another major challenge:

Much of today's network traffic is encrypted.

Traditional payload inspection becomes more difficult when security systems cannot simply inspect the contents of every packet.

That makes statistical analysis increasingly useful.

Instead of asking only:

“What does this packet contain?”

security systems can ask:

“Does this traffic behave normally?”

For example, a system might examine characteristics such as packet counts or connection behaviour within a particular time window.

An unusual pattern can then become a signal worth investigating.

This approach doesn't replace traditional security analysis.

Instead, it adds another layer.

The system learns what normal behaviour looks like and searches for deviations.

Where Machine Learning Can Help

Kostas sees several promising applications for machine learning in cybersecurity.

Network and Endpoint Anomaly Detection

Machine learning can model relationships between many network traffic characteristics and identify deviations from normal behaviour.

This can be particularly useful when the data contains many interacting variables that would be difficult to monitor manually.

Detecting Previously Unknown Attacks

Machine learning can also help identify patterns that haven't previously been classified.

That could potentially help researchers investigate previously unseen attacks.

But Kostas emphasizes an important limitation.

An unusual pattern isn't automatically malicious.

It could simply be a legitimate action that the system hasn't encountered before.

Human review remains important.

Malware and Behavioural Analysis

Models can also be used to analyze characteristics such as binaries, system calls, API behaviour, memory characteristics and process trees.

NLP and LLM-based systems can analyze emails, URLs, domains and contextual signals to identify potentially malicious communication.

Alert Prioritization

Security operations teams can receive enormous numbers of alerts.

Machine learning can help prioritize those alerts.

But the challenge remains balancing detection with false positives.

A system that flags everything isn't useful.

A system that misses important attacks isn't useful either.

The quality of the underlying data therefore becomes critical.

Research and Engineering

Kostas describes one of his biggest lessons from combining research and engineering in a simple way:

Be methodical and persistent.

Security research can involve long periods where the answer isn't obvious.

A device may not behave as expected.

A protocol may not be documented.

Existing research may not exist.

A model may produce an unexpected result.

The temptation is to jump from one idea to another.

Instead, Kostas's approach is to keep investigating systematically.

Observation.

Experimentation.

Analysis.

Iteration.

Then repeat.

Preparing for the Post-Quantum Era

Another major area of Kostas's work is post-quantum cryptography.

He was given an opportunity to work on a project involving Quantum Key Distribution, which introduced another dimension to his security research.

But the larger issue is broader than quantum networking.

Organizations need to start thinking about post-quantum migration now.

Why?

Because cryptographic migration takes time.

Some information being protected today may need to remain confidential for decades.

An attacker could potentially capture encrypted information today and store it.

If sufficiently powerful quantum computers become available in the future, some current public-key cryptographic systems could become vulnerable.

That creates a particularly important problem for long-lived sensitive information.

Intellectual property.

Financial records.

Government information.

Personal data.

The challenge isn't simply replacing one cryptographic algorithm with another.

The Real Problem Is Finding the Cryptography

One of the hardest parts of post-quantum migration may actually happen before any algorithm is replaced.

Organizations first need to know:

Where is cryptography being used?

It isn't always obvious.

Cryptographic dependencies can exist inside:

Libraries
Network protocols
Firmware
Hardware security modules
Third-party SaaS platforms
Legacy applications
Proprietary communication protocols
Operating systems
Infrastructure services

An organization may know it uses TLS and certificates without knowing every underlying place where RSA, ECC or Diffie-Hellman dependencies exist.

IoT creates an additional complication.

A camera, industrial controller or network appliance may have limited CPU, RAM or flash storage.

It may also have a deployment lifetime of ten or fifteen years.

Replacing the hardware simply because its cryptography is no longer suitable isn't always practical.

And even if an organization is ready to migrate its own software, its vendors and infrastructure providers may not be ready.

That makes cryptographic inventory and crypto agility increasingly important.

Security Must Work Outside the Laboratory

For Kostas, one of the biggest challenges in emerging security technologies is proving that something works in the real world.

A technology can perform extremely well in a controlled benchmark.

Production environments are different.

Real networks contain:

Legacy systems
Proprietary devices
Encrypted protocols
Unusual traffic
Previously unseen behaviours
Unexpected interactions

A solution that works perfectly under controlled conditions may behave very differently when exposed to that complexity.

That's why practical evaluation matters.

Security research shouldn't stop at the benchmark.

It needs to be tested against environments that are messy, changing and unpredictable.

One Toolkit, Many Problems

Kostas doesn't believe there is one universal security tool.

The tools he uses depend on the problem.

An Android application investigation requires a different workflow from network protocol analysis.

A QKD simulation requires something different again.

A post-quantum cryptography inventory script has its own requirements.

His toolkit includes technologies such as:

Wireshark
Python
JavaScript
C++
Frida
Burp Suite
Lua

The important part isn't memorizing a list of tools.

It's knowing which tool is appropriate for the problem in front of you.

And being comfortable reaching for something new when an unexpected problem appears.

Curiosity Is Part of the Job

Cybersecurity changes constantly.

New vulnerabilities appear.

New protocols emerge.

New attacks are developed.

New defensive technologies are introduced.

For Kostas, staying current requires more than reading about those changes.

Curiosity matters.

Hands-on experimentation matters.

Open-source research matters.

Platforms such as TryHackMe can also provide useful environments for learning and experimentation.

The important thing is to keep finding interesting problems to solve.

A new challenge can become a reason to learn an unfamiliar technology.

And that learning can later become useful when facing a completely different security problem.

The Moment IoT Changed His Perspective

Learning how insecure IoT devices can be had a direct impact on how Kostas approaches security in his own life.

It changed how he thinks about his home network.

It also made him more diligent when securing enterprise environments.

The lesson was simple:

Security assumptions are dangerous when they aren't tested.

A device might appear harmless.

A network might appear isolated.

A protocol might appear secure.

But understanding what is actually happening is more important than trusting appearances.

That principle has become part of how Kostas approaches security research.

Where Cybersecurity Is Heading

Looking five years ahead, Kostas sees several areas increasingly converging:

AI.

IoT security.

Post-quantum cryptography.

Rather than remaining separate disciplines, he expects them to become parts of the same security engineering problem.

One particularly interesting possibility is IoT systems that can continuously detect unusual behaviour, authenticate themselves, adapt to changing conditions and eventually migrate their cryptography without requiring hardware replacement.

AI could help deal with the enormous diversity of IoT devices.

A small specialized model running close to an IoT gateway could learn the normal communication pattern of a camera, for example.

If that camera suddenly begins communicating with an unfamiliar service, the system could flag the behaviour without needing to inspect the encrypted payload.

This kind of edge intelligence could become increasingly important.

Post-Quantum IoT

The combination of IoT and post-quantum cryptography presents another enormous engineering challenge.

Millions of cameras, sensors, routers and industrial devices may have long deployment lifetimes and limited resources.

Updating their cryptographic foundations isn't simply a software upgrade.

It can involve:

Device identity
Secure boot
Firmware updates
Machine-to-machine authentication
Hardware limitations
Compatibility
Cryptographic agility

The challenge is making future security possible without requiring organizations to replace every device in the environment.

For Kostas, that is one of the areas worth watching closely.

Advice for Aspiring Security Researchers

Kostas's first piece of advice is surprisingly simple:

Have fun.

Enjoy the process of figuring things out.

Curiosity is one of the most useful qualities a security researcher can have.

He also believes community matters.

Having people around you who are interested in similar problems can make a huge difference.

For anyone looking to build a strong technical foundation, Kostas recommends developing knowledge in several areas.

Linux Internals

Understand processes, filesystems, permissions, sockets, /proc and system calls.

Networking

Learn TCP/IP, DNS, TLS, HTTP, MQTT, RTSP/RTP, UDP and routing.

C/C++ and Python

C and C++ provide valuable insight into vulnerable systems and binaries.

Python is extremely useful for tooling and automation.

Assembly

Develop basic familiarity with x86-64 and ARM.

Operating Systems

Understand memory management, processes, threads and inter-process communication.

Cryptography

Learn the fundamentals:

Hashing.

MACs.

Encryption.

Key exchange.

Certificates.

PKI.

These foundations make it much easier to understand what is happening when investigating a real system.

Start With a Real Device

Kostas also recommends a practical starting point for aspiring IoT security researchers:

Buy an inexpensive IoT device and investigate it.

An IP camera.

A smart plug.

An IoT hub.

The objective isn't simply to find a vulnerability.

It's to learn how a real connected system works.

Study the device.

Understand its network behaviour.

Look at its web interface if it has one.

Capture and analyze its traffic.

Understand the protocols involved.

If it has a companion mobile application, study how the application communicates with the device.

The process can teach far more than simply reading about IoT security.

It turns abstract concepts into something tangible.

From Curiosity to Security Research

Kostas's journey began with curiosity about a computer his parents brought home.

That curiosity led to hardware experimentation.

Then game modifications.

Then reverse engineering.

Then university.

Then cybersecurity.

And eventually into some of the most interesting security problems emerging today.

IoT security.

Network intrusion detection.

Machine learning.

Quantum security.

Post-quantum cryptography.

What connects these subjects is not a particular programming language or tool.

It's a way of thinking.

Observe the system.

Understand its behaviour.

Question assumptions.

Experiment.

And keep investigating until the pieces make sense.

For Kostas, cybersecurity isn't simply about breaking systems.

It's about understanding them well enough to make them harder to break.

About Kostas Ereksonas

Kostas Ereksonas is a Security Engineer and cybersecurity researcher specializing in computer networks and IoT security.

His interests include network intrusion detection, reverse engineering, Android application security, IoT security, machine learning for cybersecurity, quantum security and post-quantum cryptography.

He holds Bachelor's and Master's degrees in Information Technology Engineering from Klaipeda University.

His work includes security analysis of IP cameras and Android applications, network protocol reverse engineering, QKD research and post-quantum cryptography inventory work.

View Kostas's profile on CoderLegion

CoderLegion Developer Stories

Real developers. Real journeys. Real experiences.

Developer Stories at CoderLegion gives developers an opportunity to share how they think, what they build, the problems they encounter and what they learn along the way.

Interview & Story by Mehadi Hasan

Beyond the IFrontend Developer & Automation Buildernterface — Tarek Elzoghby’s Developer Journey

Thu, 08 Oct 2026 12:33:10 +0000

Beyond the Interface — Tarek Elzoghby’s Developer Journey

“I don't stop at the interface — I build the UI and the automation/logic that makes it actually work, as one piece, not two separate jobs.”

For Tarek Elzoghby, becoming a developer started with a practical goal: frontend development looked like the fastest path into freelancing.

But once he started building, something changed.

He became fascinated by the process of watching something grow from nothing into a finished thing he could actually see and use.

That kept him learning.

Today, Tarek describes himself as a self-taught frontend developer who doesn't want to stop at the interface. Alongside HTML, CSS and JavaScript, he's learning n8n, Python and Git, while developing a particular interest in accessibility and automation.

His approach is becoming increasingly clear:

Build the interface. Build the logic behind it. Make the two work together.

Starting With Frontend

Tarek's entry into development was practical.

Frontend looked like the fastest path into freelancing.

But once he started building, he discovered that he genuinely enjoyed the process.

There was something satisfying about watching an idea turn into something visible and functional.

That was enough to keep him going.

Tarek is self-taught, and his learning style is deliberately incremental.

He learns one skill at a time and tries not to move forward until he understands it.

His projects have included a practice website for a fictional ceramics studio, an interactive portfolio and an AI-powered lead classifier.

Alongside frontend development, he's been learning:

n8n
Python
Git

He also keeps a build log for every project.

He writes down what he did, what broke and what he learned.

For Tarek, those notes aren't just documentation.

They're part of the learning process.

Beyond the Interface

The idea that increasingly defines Tarek's work emerged from two projects he built one after another.

The first was his interactive portfolio.

The second was an AI-powered intake classifier built with n8n.

One was primarily frontend.

The other was automation and logic.

Working on them back to back made something click.

They felt like they belonged together.

A website becomes much more useful when something behind the interface can actually handle what visitors do.

A contact form, for example, doesn't have to simply send a message.

Behind it, automation could classify the request, route it to the right person, send an appropriate response and log the information.

Tarek originally planned to connect his portfolio and classifier.

But his plans changed.

Instead, he decided to build his own website from scratch and use it as the place where he could properly bring the two ideas together.

The goal isn't just to talk about combining frontend and automation.

It's to build them as one piece.

Building His Interactive Portfolio

Tarek describes his interactive portfolio honestly:

The whole project was hard.

Most of the time, he knew what he wanted something to look like or how he wanted it to behave.

The difficult part was figuring out how to actually build it.

But one challenge stood out for a different reason.

Writing about himself.

For Tarek, deciding what other people should know about him wasn't easy.

He chose to write the content before touching the HTML.

That decision helped him separate what he wanted to say from how he wanted the website to look.

The result was deliberately straightforward.

He described himself honestly as self-taught and learning one skill at a time.

That approach reflects something that appears repeatedly throughout his development journey:

He prefers understanding and building over pretending he already knows everything.

The Bug That Changed How He Tests

One of the most useful lessons from his portfolio came from a bug he discovered after he thought the project was finished.

He was testing the form's error messages.

At one point, instead of clicking the submit button, he pressed Enter.

The validation didn't run.

He tried again using the mouse.

Everything worked.

That told him the problem wasn't the validation itself.

It was how the form was being submitted.

After investigating, he discovered that his handler had been attached to the button's click event rather than the form's submit event.

The difference mattered.

A form's submit event can occur whether the user clicks the button or presses Enter inside a field.

The fix took only one line.

But the lesson was much bigger.

“Finished and tested” had really meant:

I tested the ways I thought of.

From then on, Tarek started deliberately testing keyboard interactions and other less obvious paths before considering something complete.

It was a small bug.

But it changed the way he thinks about testing.

Learning Automation With n8n and AI

Tarek's AI-powered lead classifier was his first n8n project involving AI.

The idea was straightforward.

A client submits a project through a form.

An LLM classifies the request into one of five categories.

The workflow then sends the appropriate client email, sends an internal notification and records the information in Google Sheets.

But building it taught Tarek that AI automation isn't primarily about getting the model to produce the correct answer.

A large part of the engineering work is deciding:

What happens when the AI gets it wrong?

He approached that problem in several ways.

Structured Output

Instead of relying on free-form text, he used structured output with a JSON schema.

That meant the model had to return data in a defined shape, allowing the workflow to branch on predictable fields rather than trying to interpret loose text.

Ambiguous vs Invalid

Tarek also separated two situations that could easily be treated as the same problem.

An input that genuinely fits two categories is ambiguous.

An input that isn't a project at all is invalid.

Those situations require different handling.

Retry and Human Review

He also designed for failure.

If classification fails, the workflow retries three times with five-second intervals.

If it still fails, the system falls back to a human-review path labelled as a system error.

The client's original data is preserved.

Tarek even tested the failure behaviour himself by cutting his network connection during a run and watching the workflow recover instead of simply crashing.

Testing the Whole System, Not Just the Nodes

Another lesson from the n8n project was that successful workflow execution doesn't necessarily mean the system is working correctly.

Tarek didn't stop at checking whether the workflow nodes completed.

He checked the actual inboxes.

That revealed a bug where the internal notification and client email destinations had been swapped.

The workflow technically ran.

But it was still wrong.

He also tested the AI prompt with deliberately tricky descriptions.

That exposed situations where the classifier was guessing between categories rather than identifying them as ambiguous.

He then rewrote the prompt to handle those cases more clearly.

For Tarek, this reinforced an important principle:

Testing isn't just checking whether the workflow runs.

It's checking whether the system does what it is supposed to do in the real world.

Accessibility Is Becoming a Specialisation

Accessibility isn't something Tarek treats as an optional extra.

Part of that comes from his personality.

He's detail-oriented and likes making things work properly.

But his motivation goes beyond technical correctness.

He believes people should be able to have the same experience on a website regardless of what they can or cannot do.

Accessibility, in his view, should be part of building a website by default.

He is particularly interested in the fact that technology can make the web much more accessible to people who use screen readers.

Being able to contribute to that experience is a major reason accessibility is becoming a specialization for him.

When 100 Isn't Really 100

One of Tarek's strongest accessibility lessons came from a project that achieved a 100 Lighthouse accessibility score.

It would have been easy to stop there.

But Tarek tested the site manually with NVDA.

That's when he found something the automated audit had not caught.

An <address> element containing a heading wasn't valid HTML in the way it was being used, and NVDA announced it as a normal region.

The automated score hadn't identified the problem.

The screen reader did.

That experience reinforced something Tarek now believes strongly:

A perfect automated accessibility score does not mean a website is accessible.

Automated tools can only check what they are designed to check.

Someone still needs to experience the page using assistive technology.

Tarek has tested with NVDA himself and recognizes that there is still much more for him to learn.

That willingness to keep learning is part of what makes accessibility an interesting direction for his development journey.

Learning Through Practice

Tarek's projects are deliberately practical.

Even when something is technically a practice project, he tends to build it as if he might actually use it.

That approach has one downside.

He can keep adding features forever.

To prevent that, he changed how he structures projects.

He now works in stages.

He plans a stage.

He completes it.

Then he stops.

Anything outside that stage goes into a notes file rather than immediately becoming another feature.

Once all planned stages are finished, he reviews the notes and treats the ideas as potential future projects.

Then he decides which ones are actually worth pursuing.

This gives him a way to stay curious without allowing every new idea to derail the current project.

Search, Test, Understand

When Tarek doesn't know how to do something, his process is simple.

He searches for answers.

He tests them.

Then he checks what is actually happening instead of simply assuming the solution worked.

His n8n classifier provided a good example.

At one point, something wasn't behaving as expected.

Rather than immediately blaming the AI model, he looked at the model's raw output.

That showed him that the model was actually fine.

The problem was somewhere else in the workflow.

This is becoming an important part of his learning philosophy:

Don't guess when you can inspect.

Building His Own Website

Tarek's next major project is his own website.

It represents a step up from what he has built so far.

His previous projects have primarily been one-page landing pages.

This time, he's building a full multi-page website with different sections and responsibilities.

It's taking a significant amount of his time.

But it's also teaching him a lot.

The site will be hosted on GitHub, which means Git and GitHub Actions are becoming increasingly important parts of his workflow.

He sees those skills as another layer supporting the frontend and automation work he is already doing.

Why Python and n8n Matter

Tarek sees the technologies he's learning as connected rather than isolated.

n8n represents the automation side of his work.

Frontend represents the interface.

Python provides another useful programming foundation.

He believes Python is valuable for developers because it appears in so many tools and scripting workflows.

Knowing Python also means being able to create custom scripts that fit the way he works rather than always relying on someone else's tooling.

Git and GitHub then provide the workflow and infrastructure around the projects.

Instead of collecting technologies simply for the sake of learning them, Tarek is gradually building a toolkit around the kind of developer he wants to become.

The Challenge of Learning Alone

Being self-taught and mostly working independently comes with another challenge that isn't technical.

Community.

Tarek has found that meeting people and becoming part of the developer community requires real effort when you're learning and building mostly on your own.

In fact, he says that putting effort into connecting with people has been surprisingly more difficult than any project he's worked on.

That's one reason CoderLegion has become relevant to his journey.

He isn't only building technical skills.

He's also trying to find other people who are learning, building and figuring things out along the way.

Advice From a Beginner

Tarek is careful about giving advice.

He doesn't claim to have everything figured out.

He's still a beginner himself.

So instead of presenting a formula for success, he shares what has been working for him.

Stay organized

A good folder structure can save a surprising amount of time.

Set it up before the project becomes messy.

Write things down

His project notes help him remember how an idea started, how a problem was solved and what he learned from the process.

Those notes become a record of his mistakes and lessons.

Break problems down

Don't treat a difficult problem as one enormous problem.

Define what you want to achieve.

Break it into smaller steps.

Then work on one step at a time.

Often, the solution turns out to be easier to find than the original problem made it feel.

Practice while learning

Don't wait until you've mastered something before using it.

Practice what you're learning.

Then learn more while you're practicing.

For Tarek, focusing on the next small thing is what prevents the learning process from becoming overwhelming.

Frontend and Automation as One Direction

Tarek's current focus is clear.

He wants to become good at both frontend development and automation and eventually bring them together.

In the near term, he's aiming for freelance frontend and automation work.

Longer term, he would like to build something of his own—a space where he can create projects across different areas of technology and experiment with how those areas connect.

But he's not trying to rush there.

For now, the priority is simple:

Learn. Build. Improve.

One step at a time.

Learning to Walk Before Running

Tarek's approach to the future is deliberately grounded.

He's trying to learn to walk before he runs.

That means focusing more on today than on an imagined distant destination.

At the same time, he believes knowing what you want to become helps shape who you are today.

Right now, that means developing his skills in frontend development and automation.

Later, it may mean building something of his own.

But the immediate goal isn't to skip ahead.

It's to build the foundation properly.

A Message to Other Self-Taught Developers

Tarek has one simple message for people in a similar position.

If you're self-taught and mostly working alone, finding people to connect with takes real effort.

So if you're on the same path, don't assume you're the only one.

Reach out.

Build connections.

Share what you're learning.

And keep building.

You don't need to have everything figured out before you become part of a community.

Sometimes learning alongside other people is part of figuring it out.

Beyond the Interface

Tarek's journey is still at an early stage.

But there is already a clear direction.

He started with frontend because it seemed like the fastest path into freelancing.

He stayed because he discovered how much he enjoyed building.

Then he began looking beyond the interface.

Automation showed him what could happen behind a form.

AI introduced new questions about reliability and failure handling.

Accessibility showed him that technical correctness and real user experience aren't always the same thing.

And his projects continue to teach him that the best way to learn is often to build something, break something, investigate it and try again.

His goal isn't simply to become someone who can create attractive interfaces.

He wants to understand what happens behind them.

The interface.

The automation.

The logic.

The accessibility.

The systems connecting everything together.

And eventually, he wants to build all of those pieces as one.

About Tarek Elzoghby

Tarek Elzoghby is a self-taught frontend developer focused on building interfaces together with the automation and logic that make them work.

His technical interests include JavaScript, HTML, CSS, n8n, Python, Git and accessibility.

His projects include interactive frontend experiences, AI-powered workflow automation and accessibility-focused web development.

View Tarek's profile on CoderLegion

Visit Tarek's portfolio hub

CoderLegion Developer Stories

Real developers. Real journeys. Real experiences.

Developer Stories at CoderLegion gives developers an opportunity to share how they think, what they build, the problems they encounter and what they learn along the way.

Interview & Story by Mehadi Hasan

From Testing Games to Building Them — Mihaela Turianu’s Journey into Indie Game Development

Thu, 08 Oct 2026 12:17:39 +0000

“I wanted to know how games were made, how characters came to life, how stories were written and how the magic happens backstage.”

For more than eight years, Mihaela Turianu worked in Quality Assurance in the video game industry.

Her job was to test games.

To find problems.

To think about what players might do that developers hadn't expected.

To look at systems from different angles and help make games better.

But behind all that testing was a curiosity that had existed since childhood:

What actually happens backstage to make a game come to life?

Today, Mihaela is exploring the other side of that process.

Instead of testing games created by others, she's learning how to build her own.

Her journey into indie game development is taking her through Unreal Engine 5, Blueprints, gameplay systems, animation, physics, debugging and, perhaps most importantly, the challenge of turning an idea into something another person can actually play.

From Sega to Game Development

Mihaela's fascination with games started long before she entered the industry.

As a child, she didn't have a PC, but she had a Sega console that fascinated her.

As technology evolved, she experienced games across different generations—from older consoles and Commodore 64 games running from cassette tapes to games on an Intel Pentium 1 PC, the first Xbox and eventually today's powerful gaming hardware.

The technology changed.

The fascination didn't.

But eventually, playing games wasn't enough.

Mihaela wanted to understand what was happening behind the screen.

How were games made?

How did characters come to life?

How were stories created?

How did all the systems come together?

That curiosity eventually led her to apply to Electronic Arts as a Game Tester around 2016.

That was the beginning of her professional journey in the video game industry.

Eight Years on the QA Side

Over the years, Mihaela progressed through different roles and met people working across many areas of game development.

That experience brought her closer to the process she had always wanted to understand.

The people she met along the way also played an important role.

Their encouragement, guidance and insights helped give her the confidence to pursue something she had been thinking about for a long time:

making games herself.

After years of testing games, Mihaela decided to move to the other side of the process.

From finding bugs to creating features.

From evaluating mechanics to building them.

From asking whether something works to figuring out how to make it work in the first place.

Seeing Games Through Three Perspectives

Mihaela's QA background continues to influence how she approaches development.

When she builds a mechanic, she doesn't look at it only from the perspective of the developer.

She thinks about the:

Developer.

Tester.

Player.

A mechanic might work exactly as intended during a normal test.

But what happens when the player does something unexpected?

What if they interrupt an action?

What if they repeat it?

What if they use two systems in an order the developer didn't anticipate?

These questions come naturally from her QA experience.

She also pays close attention to how systems interact.

A feature can work perfectly on its own and still behave differently when it connects with inventory, player statistics, quests or other gameplay systems.

QA has made this way of thinking a habit.

And that habit is now part of how she develops her own games.

Building in Public Through Devlogs

Mihaela isn't waiting for her game to be finished before sharing it.

Instead, she's documenting the process through development logs.

For her, getting a system working is already a milestone worth sharing.

A devlog provides an opportunity to show progress, connect with other developers and players, and get different perspectives while the project is still evolving.

It also means showing the unfinished parts.

The bugs.

The experiments.

The trial and error.

The moments where something that looks simple from the outside takes much longer to get working than expected.

That's an important part of Mihaela's approach.

She's still learning.

She's still experimenting.

And she wants her devlogs to reflect that honestly.

Perhaps someone watching her journey will recognize a problem they've experienced themselves.

Or maybe a small breakthrough will encourage someone working on their own project.

For Mihaela, the process itself is part of the story.

Finding Her Way to Unreal Engine 5

Mihaela didn't begin with Unreal Engine.

She initially tried Unity.

But she struggled with coding, which made it difficult to turn her ideas into working gameplay.

Later, changes to Unity's pricing also made her question whether it was the right choice for someone developing on a very limited budget.

Unreal Engine offered something that made the process more approachable:

Blueprints.

Its visual scripting system allowed Mihaela to build gameplay logic visually.

She still needed to understand how the underlying logic worked, but she didn't have to become blocked by code before she could start experimenting.

That changed the learning experience.

Instead of spending all her time fighting the programming language, she could focus on understanding systems and seeing her ideas become playable.

Free documentation, YouTube tutorials and helpful Discord communities have also played an important role.

There has still been plenty of trial and error.

But being able to take an idea, build it and see it working inside the game has made the learning process rewarding.

When Dropping an Item Isn't Simple

One of Mihaela's recent development challenges came from something that sounds incredibly simple:

dropping an item.

The basic idea seems straightforward.

Remove an item from the inventory.

Make it appear in the game world.

Done.

Except it wasn't.

Physics and collision behaviour introduced unpredictability.

Sometimes an item would fall through the ground.

The frustrating part was that the problem wasn't always consistent.

An item might work perfectly in one test and disappear in the next.

That made the underlying problem much harder to identify.

Because Mihaela uses a shared, data-driven system for dropped items, the solution also needed to work across different objects.

The experience reinforced an important lesson from her QA background:

One successful test doesn't necessarily mean a system is ready.

There was another layer to the problem as well.

After using or dropping an item, the inventory entry could remain visible.

The selected entry could still point to something that no longer existed.

The item details could fail to update correctly.

Each individual action seemed simple.

But they all affected the same interface.

Mihaela learned that building an inventory isn't simply about storing items.

It is about managing the relationships between the different systems that depend on those items.

Making Mechanics Feel Good

Mihaela's recent devlogs include systems for sprinting and stamina, player illumination and interaction awareness.

But getting a mechanic to technically work isn't enough.

She wants mechanics to feel intuitive.

When developing something, she asks herself questions such as:

Would I enjoy this as a player?

Would I find it interesting?

Would it help me?

Would I naturally understand how to use it?

Those questions influence not only individual mechanics but how the mechanics connect with each other.

Controls should make sense.

Feedback should be clear.

Systems should feel comfortable together.

And if something feels awkward, she plays with it and adjusts it.

For Mihaela, development isn't finished simply because the feature works.

It also needs to feel good to use.

Technically Correct Doesn't Always Mean Enjoyable

One of the distinctions Mihaela makes is between a feature being technically complete and a feature being enjoyable.

Technically, a feature is complete when it does what it is supposed to do consistently—including when a player does something unexpected.

Enjoyment is different.

There is no formula that guarantees every player will enjoy a mechanic.

Instead, Mihaela steps back from the implementation and simply plays with it.

Do the controls feel natural?

Is the response clear?

Does the mechanic become frustrating?

Does it become repetitive?

Does the player understand what the game expects from them?

Knowing exactly how a system was built can make it easy for a developer to overlook things that aren't obvious to someone experiencing it for the first time.

Sometimes something works perfectly and still feels wrong.

That's when Mihaela is willing to simplify, adapt or rethink the feature.

The goal is to let the player enjoy the game without having to stop and figure out how the game expects them to play.

Learning Animation the Hard Way

Another example came from something as simple as making a character bow when the player entered an area.

The idea sounded straightforward.

The implementation wasn't.

Mihaela needed to transfer an animation between characters with different skeletons and starting poses.

Some of the movement didn't transfer correctly.

The character's arms looked awkward.

She worked through the retargeting process step by step.

She checked how the bones were mapped.

She adjusted the pose alignment.

She experimented with the setup.

After several rounds of adjustments, she finally got the bow looking close to what she wanted.

The process taught her more about animations, skeleton mapping, bone hierarchies and retargeters.

And when the character finally performed the gesture correctly, it was a small but satisfying victory.

Progress Doesn't Always Look Exciting

Indie development requires more than learning technology.

It requires maintaining motivation when progress is slow.

Mihaela tries to handle that by taking things one manageable step at a time.

Rather than trying to learn everything Unreal Engine can do, she focuses on learning what she needs for the feature she is currently building.

That gives the learning a practical purpose.

Some days are about adding something new.

Other days are spent figuring out why something that worked yesterday suddenly doesn't work anymore.

Those days can be frustrating.

But solving a problem is still progress, even if it doesn't make an exciting devlog.

What keeps Mihaela motivated is seeing the game gradually take shape.

A working interaction.

An animation finally behaving properly.

A small environmental detail that makes the world feel more alive.

Those moments provide the motivation to keep going.

She also has a simple strategy for preventing the process from becoming overwhelming.

After spending hours or days working on Blueprints and logic that may not be visually exciting, she gives herself around 15 minutes to create something visual.

Falling leaves.

A door opening.

A small environmental effect.

Something simple that immediately changes what she sees in the game.

It may only take a few minutes, but it can provide a useful reminder of why she's building the game in the first place.

From Testing Games to Understanding Their Complexity

One of the biggest surprises of becoming a developer has been discovering just how much work goes into things that appear simple when playing a finished game.

Picking up an item sounds like one action.

But implementing it can involve:

Interaction logic
Inventory data
UI updates
Object spawning
Physics
Collision
Selection state
Communication between different systems

In QA, Mihaela was used to examining what already existed and finding where it didn't behave as expected.

As a developer, she now starts with an idea and has to work out all the decisions required to turn that idea into something functional.

That has given her a much greater appreciation for the work behind the games she has tested throughout her career.

And it has also made development surprisingly rewarding.

A small feature can feel like a significant achievement when you know exactly what it took to make it work.

The Game She Wants to Build

Mihaela isn't rushing to reveal every detail of the game she ultimately wants to create.

She's giving herself room to experiment and allowing the project to take shape naturally.

But the vision is clear.

She wants to create a world that people enjoy spending time in.

A world that keeps players curious.

A world where they can explore and discover things at their own pace.

For her, one meaningful milestone would be having a playable version that she feels comfortable putting into someone else's hands.

Not simply something that works.

Something that another person can play and genuinely enjoy.

Seeing someone have fun with something she created would mean a lot.

Advice for Developers Making the Transition

For people working in QA or other areas of the gaming industry who are considering moving into development, Mihaela offers realistic advice.

Think carefully about the decision.

The journey can be difficult and tiring.

Specific problems can be surprisingly hard to research.

Tutorials can leave unanswered questions.

Documentation can be difficult to follow when foundational knowledge is missing.

And there is no guarantee that an idea will find an audience.

But there is another side to it.

Building something of your own can be incredibly rewarding.

There is a unique feeling in seeing an idea become something you can actually play.

Her advice is to start small.

Build a mechanic.

Build a small playable project.

Give yourself room to learn.

Before committing to a huge game, find out whether you actually enjoy the day-to-day work of making games—not just the idea of being someone who makes games.

And keep expectations realistic.

The internet can be unforgiving, and people can be ruthless sometimes.

The goal should be to learn, build and keep moving forward.

What's Next?

Mihaela is continuing to build and document her indie development journey.

Her current work includes gameplay mechanics, interaction systems, animation, inventory systems, physics and other pieces that will eventually come together into a larger playable experience.

She's still learning.

Still experimenting.

Still debugging.

And still figuring out what the game will ultimately become.

That's what makes her journey interesting.

She isn't presenting a finished success story.

She's showing what happens when someone who spent years testing games decides to step behind the curtain and try to build one.

From QA to development.

From finding bugs to creating systems.

From playing games to making them.

The journey is only beginning.

About Mihaela Turianu

Mihaela Turianu is an indie game developer with more than eight years of experience in Quality Assurance within the video game industry.

She is currently building games with Unreal Engine 5, using Blueprints and exploring gameplay systems, animation, interaction, physics and game design.

She documents her development journey through devlogs under the name MTIndieDev.

View Mihaela's profile on CoderLegion

Follow MTIndieDev on YouTube

CoderLegion Developer Stories

Real developers. Real journeys. Real experiences.

Developer Stories at CoderLegion gives developers an opportunity to share how they think, what they build, the problems they encounter and what they learn along the way.

Interview & Story by Mehadi Hasan

From Code to Systems Thinking — Valentyn Ivanov’s Developer Journey

Thu, 08 Oct 2026 11:57:36 +0000

From Code to Systems Thinking — Valentyn Ivanov’s Developer Journey

“The goal of architecture is not to make the code perfect from day one. It is to make change affordable.”

Valentyn Ivanov has spent more than 15 years building complex software across developer tools, data-processing systems, graphics platforms, cloud-connected applications and cross-platform products.

But his journey isn't really about collecting technologies.

It is about learning how systems work, understanding the people who use them, and becoming increasingly pragmatic about how software should be designed.

His early fascination with computers started before he even had regular access to one. Today, that same curiosity continues to drive him toward software architecture, developer tools, artificial intelligence and new ways for humans to interact with computers.

For Valentyn, good engineering isn't about following patterns for the sake of following patterns.

It is about understanding the problem well enough to make the right trade-offs.

A Curiosity That Started Before the Computer

Valentyn was fascinated by computing machines long before he had regular access to an actual computer.

Even calculators and electronic cash registers caught his attention because he wanted to understand what was happening inside them.

It wasn't until around the age of fourteen or fifteen that he gained regular access to computers.

Until then, he spent time in the city library reading almost every book he could find about computer hardware and software.

Once computers became available at school, he began exploring everything he could:

Games.

Small programs.

MS-DOS.

And the wider software ecosystem around it.

By the time he had to choose a profession, software engineering felt like the obvious direction.

Interestingly, the fundamental motivation behind that choice hasn't changed much.

Valentyn still enjoys learning about software and hardware simply because he finds them interesting—even when there is no immediate practical application.

Over the years, he has learned that this curiosity often pays off later.

Something that seems theoretical or unrelated today can become part of the foundation needed to solve a completely different problem years later.

The Hardest Part of Software Is Often People

With experience across developer tools, graphics software, data-processing systems and cross-platform applications, Valentyn might have been expected to identify technical complexity as the biggest challenge.

Instead, his answer is much simpler:

People.

Whether you're building developer tools, graphics software or data-processing systems, the software ultimately exists to help people solve a problem.

And when a project begins, developers don't always fully understand that problem.

The difficult part is learning the domain well enough to understand what users are actually trying to achieve.

What causes them friction?

What expectations do they bring?

How do they actually work?

A technically elegant solution can still be a poor solution if it solves the wrong problem or forces users into a workflow that doesn't match reality.

The same applies inside engineering teams.

Architecture and implementation are influenced by communication, assumptions, ownership and how well people understand each other's constraints.

Once the human context becomes clear, technical complexity is often much easier to manage.

From Patterns to Pragmatism

Early in his career, Valentyn was heavily focused on best practices, patterns and programming idioms.

If a particular pattern was considered the correct solution for a certain problem, he wanted to use it.

It was, as he describes it, the classic:

“When you have a hammer, everything looks like a nail.”

Experience changed that.

He became much more pragmatic.

Not every problem needs the canonical solution.

And sometimes a reasonable solution today is much more valuable than a perfect architecture that might take a year to complete.

That doesn't mean he became anti-architecture.

Quite the opposite.

He still considers principles such as SOLID, inversion of control and separation between UI and application logic extremely valuable.

The difference is in what architecture is supposed to achieve.

For Valentyn, architecture isn't about making code perfect from day one.

It is about making change affordable.

A system should be able to contain shortcuts and temporary compromises without turning them into permanent problems.

Good boundaries and clear dependencies allow a team to move quickly today while retaining a realistic path to refactor, extend and improve the system tomorrow.

When Organizational Problems Become Code

One of Valentyn's most interesting ideas appears in his article Monuments to Friction: How Organizational Trauma Compiles into Code.

The idea came from seeing software systems whose structures felt strangely unnatural.

You might encounter an engine, a content pipeline, a game-logic library, a lobby library and several other layers.

Then you try to make a seemingly simple change.

Suddenly, you have to move through several unrelated components and ownership boundaries.

The obvious question becomes:

Why is the system structured this way?

Often, the answer isn't technical.

It is historical.

Perhaps the engine team was located in another country and rarely communicated with the game or lobby teams.

Perhaps two product managers wanted separate ownership boundaries.

Perhaps nobody properly owned the content pipeline, so it gradually became a neglected shared dependency.

Over time, those organizational decisions become technical constraints.

The software becomes a kind of historical record of old communication problems, ownership boundaries and management structures.

What once made sense for an organization can remain embedded in the architecture long after the original reason has disappeared.

In that sense, code doesn't only reflect technical decisions.

Sometimes it reflects the history of the organization that created it.

Collaboration Isn't the Same as Tribal Knowledge

Valentyn has also challenged the idea that teams can simply rely on collaboration instead of documentation.

A common argument against documentation is that it eventually becomes stale.

He sees that differently.

The problem isn't necessarily documentation itself.

It is often the assumption that documentation means writing huge manuals describing every detail of a system.

What matters more is preserving decisions.

Why was something implemented this way?

What alternatives were considered?

What constraints existed at the time?

What trade-offs were accepted?

Sometimes a few lines are enough.

Without that context, teams can replace documentation with what they call collaboration.

In practice, that can mean asking around until someone finds the one person who remembers why a particular piece of the system works the way it does.

But people leave.

People forget.

And eventually the knowledge disappears.

Good collaboration should spread knowledge rather than make a team dependent on access to specific individuals.

Documentation helps turn knowledge stored in people's heads into knowledge the team can actually retain.

When Different Technology Stacks Meet

Valentyn's experience also includes embedding web interfaces inside native desktop applications.

At first glance, it can seem like an obvious way to combine the strengths of both worlds.

A native application might be written in a compiled, statically typed language using native libraries and platform APIs.

The web interface can then bring HTML, CSS and JavaScript into the application.

But that combination introduces another layer of complexity.

The team now needs to understand both sides.

Eventually, problems cross the boundary.

Data exchange.

Lifecycle management.

Threading.

Rendering.

Focus handling.

Packaging.

Platform-specific behaviour.

Debugging.

Valentyn's point isn't that embedding a web UI is inherently wrong.

The real question is whether the benefits of web technology justify the additional complexity—and whether the team has enough knowledge across the layers to confidently own that complexity.

Exploring Local AI

More recently, Valentyn has been experimenting with local AI and tool calling.

One project involved prototyping an AI-enabled console that could understand a user's intent and invoke appropriate tools.

Instead of requiring a developer to remember shell commands and parameters, a user could describe what they wanted in natural language.

For example:

“Find all text files and add a sequential number to their filename.”

The goal wasn't to build an AI that writes essays.

The model needed to understand intent, select tools and operate reliably within a constrained environment.

That required something lightweight and local.

But the experiment also exposed an important reality of local AI development.

Many of the practical limitations aren't always clearly explained.

Developers may need to piece information together from documentation, blog posts, examples and sometimes the source code itself.

Context handling.

Tool-call behaviour.

Model-specific constraints.

Runtime assumptions.

These details become much more important once a project moves beyond a simple demonstration.

For developers beginning with local AI, Valentyn recommends experimenting at the tooling level first.

Run a small model.

Make a few requests.

Inspect the client code.

Understand how context and inference actually work.

The goal is to build a realistic mental model rather than relying on marketing claims or high-level abstractions.

AI Won't Replace Engineering Judgment

Despite working with AI, Valentyn doesn't believe the fundamental role of a software engineer is about to disappear.

Engineers still need to understand software.

They need to understand hardware and systems.

They need to understand the domain they're working in.

And, perhaps most importantly, they need to understand people.

AI can accelerate implementation.

It doesn't remove the need for technical judgment.

In fact, Valentyn sees an interesting possibility emerging.

As implementation becomes faster, the boundary between software engineering and product management may become less rigid.

Engineers could spend more time exploring problems, testing ideas and working directly with users instead of treating product definition and implementation as completely separate activities.

The most valuable skills remain surprisingly fundamental:

Understanding systems.

Understanding people.

Making good trade-offs.

Recognizing when a technically correct solution is solving the wrong problem.

Mental Models Are Useful—but Dangerous

Valentyn also thinks deeply about mental models.

A mental model is essentially a simplified map of a system.

At its best, it allows an engineer to recognize patterns quickly.

Instead of decomposing every problem from first principles, developers can draw on previous experience and adapt an existing model.

That can save enormous amounts of effort.

But there is a danger.

The model can be wrong.

If an engineer misunderstands how a system actually behaves, the mental model can create confidence while leading them in the wrong direction.

Every new symptom then gets interpreted through the faulty map.

For Valentyn, mental models should therefore be treated as working hypotheses, not absolute truth.

They help engineers move faster.

But those models need to be checked against the real system—especially when debugging unfamiliar behaviour or making architectural decisions.

The Event-Driven Lesson

One technical lesson significantly changed how Valentyn approaches architecture: be cautious with event-based systems.

Earlier in his career, he was a strong fan of event-driven architectures.

They appeared elegant.

Components were loosely coupled.

Communication seemed simple.

Adding new behaviour seemed easy.

But experience with projects where event-driven interactions became difficult to debug and extend changed his perspective.

The problem is that events can conceal relationships between modules.

It becomes harder to answer basic questions:

Who triggered this?

In what order did things happen?

What state is the system actually in?

Once timing enters the picture, subtle bugs can become difficult to reproduce.

Today, Valentyn prefers explicit calls, state machines, or approaches somewhere in between.

He wants important interactions to remain visible in the code.

The implementation should describe how the system behaves rather than forcing developers to reconstruct that behaviour from a network of event subscriptions.

Technical Excellence Must Serve the User

Valentyn describes his approach to engineering trade-offs as pragmatic.

Software exists for users.

If the software solves their problem and users are satisfied, that matters more than whether the implementation is aesthetically perfect.

But that doesn't mean maintainability can be ignored.

Poorly structured code eventually slows development, makes changes riskier and consumes engineering time.

The balance is therefore about prioritizing user value while deliberately reserving enough effort to keep the codebase healthy.

Good architectural boundaries, modular structures and clear dependencies help because they allow teams to move quickly without turning every shortcut into permanent technical debt.

As Valentyn puts it:

“Technical excellence is most useful when it supports delivery, not when it competes with it.”

What Makes a Developer Tool Useful?

For Valentyn, the answer starts with a simple principle:

It has to solve an actual developer need.

A tool that reduces repetitive work, helps someone understand a codebase faster, finds problems or improves code quality is already providing value.

Functionality comes first.

He also believes developer tools should remain as simple as possible.

Not every tool needs to become a platform.

Not every tool needs to solve every problem in the development lifecycle.

Sometimes a small tool that does one important thing well is more valuable than a huge system with dozens of features nobody actually needs.

Usability matters.

But a beautiful interface cannot compensate for a tool that doesn't solve a meaningful problem.

Rethinking How Humans Interact With Computers

Looking ahead, one area particularly interests Valentyn:

human-computer interaction.

For decades, the dominant model has remained relatively stable.

Keyboard.

Mouse.

Display.

Voice has been added in some situations, but the fundamental interaction model remains familiar.

Valentyn doesn't think that is necessarily the final form of interaction with computers.

He is interested in systems that reduce the translation effort between what a person wants to accomplish and what the computer needs in order to accomplish it.

One possibility could be a semantic shell that understands intent instead of requiring users to remember exact commands.

Another could involve entirely new forms of input and output hardware.

The common idea is simple:

Make computers understand what people are trying to do, rather than forcing people to translate their intentions into the computer's language.

Learn Beyond the Boundaries of Your Job

Valentyn's advice to developers is closely connected to the philosophy that has shaped his own career.

Keep learning.

But don't limit that learning to the immediate boundaries of your job.

Learn to own things rather than simply complete assigned tasks.

Understand the whole system.

Understand the constraints around it.

Understand the consequences of your decisions.

And learn subjects that may initially appear unrelated.

Hardware.

Human psychology.

Different technical domains.

Different areas of engineering.

The reason is that engineering judgment comes partly from having a large collection of mental models and experiences to draw from.

A piece of knowledge that appears irrelevant for years can suddenly become the missing piece of a problem.

Architecture and system design aren't simply about knowing patterns.

They are about recognizing situations, understanding trade-offs and connecting ideas from different areas.

The broader the foundation, the better the decisions can become.

From Software Engineer to Systems Thinker

After more than 15 years in software engineering, Valentyn's journey has moved beyond simply learning how to write code.

His experience has taught him to question why systems are structured the way they are.

To look beyond technical elegance and understand users.

To recognize organizational history hidden inside architecture.

To preserve knowledge instead of relying on tribal memory.

To use mental models without becoming trapped by them.

To treat AI as an accelerator rather than a replacement for engineering judgment.

And to value pragmatic architecture that makes future change possible.

Perhaps the most consistent theme throughout his journey is curiosity.

The same curiosity that once led a young Valentyn to read computer books in a library before he even had regular access to a computer continues to drive him today.

Only now, the questions are much bigger.

Not simply:

How does this computer work?

But:

How should people and computers work together?

About Valentyn Ivanov

Valentyn Ivanov is a software engineer with more than 15 years of experience building complex developer tools, data-processing systems, graphics platforms, cloud-connected applications and cross-platform products.

His interests include software architecture, C++, developer tools, collaboration, system design, local AI and human-computer interaction.

View Valentyn's profile on CoderLegion

CoderLegion Developer Stories

Real developers. Real journeys. Real experiences.

Developer Stories at CoderLegion gives developers an opportunity to share how they think, what they build, the problems they encounter and what they learn along the way.

Interview & Story by Mehadi Hasan

From Chatbots to Autonomous Agents — David San Nicolás Montero’s Developer Journey

Thu, 08 Oct 2026 10:46:05 +0000

“The best user interface for an AI is the one you don't have to chat with.”

David San Nicolás Montero's journey into autonomous AI agents did not begin with ChatGPT.

It began with a cassette-tape Spectrum 128K.

As a child, David begged his father for a computer. When he finally got one, there was no internet, no modern IDE and no AI assistant waiting to generate code.

There was a BASIC programming book.

And video games that could take 45 minutes to load.

Eventually, programming became more interesting than waiting for the games.

That early curiosity eventually took David from BASIC and HTML to electronics, firmware, robotics, artificial intelligence and, eventually, autonomous software agents capable of interacting with the real world.

Today, he is the Founder of AutomaticIA and the creator of Zyro Workspace, an open-source Node.js SDK and platform for building autonomous AI agents around Google Workspace and business workflows.

But the most interesting part of his approach isn't simply using AI.

It is the architecture he puts around AI.

From BASIC to Electronics and Firmware

David's first real programming success came when he was 15.

He built a website for his father's company using HTML.

There was no budget for hosting, so he turned his own PC into a web server and hosted the site through a dial-up modem.

His interest in technology then led him toward electronics engineering.

His generation of developers also had a different relationship with hardware. David learned firmware programming in Assembly, something he believes gave him an understanding of memory and data flow that continues to influence how he builds software today.

That foundation eventually led him toward robotics.

For the last decade, he has worked across firmware, software and, increasingly, artificial intelligence.

When AI Became Physical

Robotics changed the way David thought about AI.

Robotics isn't just software.

It combines mechanics, electronics, firmware, software, communication networks and increasingly AI.

That complexity made AI interesting to David for a reason that goes beyond conversation.

He wanted AI to do things.

His first AI prototypes were designed around predictive maintenance.

A physical trigger could initiate an image analysis of robot components, allowing the system to help identify potential problems and reduce preventive maintenance work.

That experience demonstrated something important:

AI didn't have to remain a chatbot.

It could interact with physical systems and participate in real processes.

That idea eventually became central to his work.

The Chatbot That Started Zyro

The origins of Zyro came from a surprisingly ordinary workplace problem.

More than two years ago, David became involved as a union representative.

He discovered that colleagues repeatedly asked the same questions, consuming time that could otherwise be spent preparing for negotiations.

So he built a chatbot with a Retrieval-Augmented Generation (RAG) database.

Employees could ask questions anonymously instead of repeatedly asking David directly.

The project attracted attention outside his immediate workplace.

Someone within the union's industrial federation saw what he had built and offered David an opportunity to help optimize administrative processes using AI.

That changed the scale of the problem he was trying to solve.

He began seeing the same kinds of inefficiencies inside administrative offices and law firms.

And that led to the first version of Zyro Assistant.

From Answering Questions to Doing the Work

The difference between a chatbot and an autonomous agent became clear to David through process optimization.

A chatbot answers questions.

An agent has tools.

It can take action.

But David believes autonomy needs to be carefully designed.

People are not necessarily psychologically prepared to let an AI perform tasks that they previously controlled themselves.

So Zyro doesn't treat every action equally.

The system can have significant autonomy for creative and informational tasks.

For example, it can prepare a report before a meeting by examining the agenda, gathering information about attendees, reviewing previous interactions and identifying pending items.

But destructive actions are different.

Deleting an event or document requires confirmation.

Sending an email or making a call can require human permission.

For David, autonomy isn't simply about removing humans from the loop.

It is about deciding where the loop should remain.

Building AutomaticIA

AutomaticIA wasn't David's first business.

Fifteen years ago, he founded an electronics engineering company, SGS Automatismos e Ingeniería.

Later, he also became involved in a driving-school business outside the technology sector.

These experiences helped him understand something important about automation:

The value isn't in having impressive technology.

The value is in how much real work it removes and what economic value it creates.

After implementing automation projects in his own businesses and seeing the time savings and financial impact, David decided to create AutomaticIA.

The goal is to help Spanish companies adopt advanced business technology through AI consulting and custom autonomous agents.

His vision is to become a bridge between traditional business workflows and systems capable of taking over repetitive administrative work.

Zyro Workspace

The first Zyro prototype was built almost entirely inside Google Drive using Google Apps Script.

David spent months analyzing bottlenecks across different departments and developing specific applications.

Eventually, he noticed a common pattern.

Many organizations already had powerful tools inside Google Workspace.

But employees weren't necessarily using them.

The problem wasn't always a lack of functionality.

It was the learning curve.

People were too busy to stop their work, learn another application and change their established habits.

Zyro approached the problem differently.

Instead of asking employees to learn another tool, it allows them to describe what they want and lets the agent interact with the underlying Google ecosystem.

Drive, Calendar, Slides and other services become tools the agent can use.

The interface becomes simpler:

Tell Zyro what you need.

Why Node.js?

David's choice of Node.js began pragmatically.

Zyro's original Google Apps Script implementation already used JavaScript and Google's V8 engine.

When the system grew and needed to move into Google Cloud and Firebase, Node.js was the natural evolution.

But as the architecture became more sophisticated, David discovered technical reasons to stay with it.

Modern autonomous agents rely heavily on Function Calling.

The LLM reasons about what it needs to do and returns structured data describing the intended action.

Node.js is well suited to handling those JSON-based workflows.

There is another important reason.

Agents spend a lot of time waiting.

Waiting for an LLM response.

Waiting for Google Drive.

Waiting for Calendar.

Waiting for a webhook.

Waiting for a phone call to finish.

Node.js's non-blocking event loop makes it possible to coordinate many of these asynchronous operations without blocking the server.

For David, Node.js becomes the nervous system connecting AI reasoning to the outside world.

The AI Doesn't Actually Execute the Function

David believes one of the biggest misunderstandings around LLM Function Calling is the idea that the AI is actually executing the function.

It isn't.

The model is isolated.

It reasons about what it wants to do and returns structured JSON.

The application receives that intent.

The backend validates it.

The backend executes the actual operation.

Then the result is returned to the model.

This distinction is fundamental to David's architecture.

The AI proposes.

The infrastructure decides whether and how the action actually happens.

From Trusting AI to Trusting Infrastructure

This leads directly to David's approach to Inversion of Control.

Instead of trusting the AI to behave correctly, he designs the infrastructure so that incorrect AI behaviour cannot automatically break the system.

The AI doesn't receive master administrator credentials.

Instead, the backend executes operations using the active user's OAuth permissions.

If the user cannot access a confidential folder, the AI cannot access it either.

The infrastructure enforces the boundary.

This creates a powerful principle:

Don't make the AI trustworthy. Make the infrastructure enforce trust.

The model can make mistakes.

The system around it should still remain deterministic.

Human Approval Where It Matters

Zyro also separates creative tasks from destructive tasks.

The agent can work autonomously when preparing information, analysing documents or drafting content.

But when an action could cause irreversible consequences, the backend can pause execution.

For example, if the agent decides that a calendar event should be deleted, the system can intercept that intention and ask the human to confirm it.

The model doesn't directly control the action.

The architecture controls the execution flow.

Making Agents Event-Driven

David is also exploring event-driven architecture because autonomous agents shouldn't always wait for a person to ask them something.

Traditional request-response software works like this:

User → Request → Server → Response

But real-world processes aren't always synchronous.

A phone call can take five minutes.

A background task can take ten minutes.

An external event can happen hours after the original request.

David's event-driven approach allows Zyro to dispatch a long-running task and continue doing other work.

When the task finishes, an event wakes the relevant part of the system.

One example is Zyro's integration with a multi-agent PBX.

Zyro can initiate a phone call and then return to other work.

When the call finishes, the PBX sends a webhook.

Zyro receives the transcript, processes what happened and can then generate a summary or follow-up action.

The agent isn't simply responding to users.

It is responding to events in the world.

Giving AI Eyes and Hands

David is also experimenting with RPA extensions that allow Zyro to interact with websites.

Rather than relying exclusively on DOM analysis, his current approach in private beta uses computer vision to understand what is displayed on the user's screen.

The system can capture the active tab, have an AI model analyse the interface and determine where an interaction should happen.

The browser extension can then dispatch mouse events to the relevant coordinates.

The goal is to give the agent something closer to eyes and hands.

David is clear that these RPA features are still in testing and have not yet gone through Google's official validation process.

The Hardest Problem: Debugging Something Non-Deterministic

Building a simple AI agent is relatively easy.

Building one that can safely coordinate dozens of functions is a different problem.

Zyro needs to work across RPA, phone calls and Google Workspace while dealing with the unpredictable behaviour of LLMs.

Traditional software debugging gives you a stack trace.

AI failures can be statistical.

The same request can succeed once and fail differently another time.

A model might generate a correct JSON parameter.

Later, it might hallucinate an ID that doesn't exist.

David's solution is to surround the unpredictable AI component with deterministic infrastructure.

Validation layers intercept errors.

The system can return failures to the model and allow it to correct its own output.

Watchdogs and circuit breakers prevent self-healing loops from continuing indefinitely and consuming excessive tokens.

This leads to one of David's biggest lessons:

Building successful AI software is, ironically, hardly about AI.

The intelligence of the underlying model matters.

But the reliability of the system depends heavily on the traditional engineering surrounding it.

The Architecture Matters More Than the Model

As David's experience with Zyro grew, he became increasingly convinced that AI should not sit at the structural foundation of a software system.

Instead, robust traditional software architecture should form the foundation.

AI becomes an engine attached to it.

That approach also changes how developers should think about context.

A more powerful model doesn't automatically solve everything.

Developers need to understand context windows, inference speed and token consumption.

If too much information is injected into the model, systems become slow and expensive.

Eventually, the model can lose important instructions as the context becomes overloaded.

For David, context management is therefore not just prompt engineering.

It is an architectural concern.

Where Autonomous Agents Are Going

David believes AI agents already have much of the technical capability required for far greater autonomy.

As people become more comfortable trusting these systems, he expects agents to take over an increasing number of tasks currently performed by humans through computers.

That raises an interesting question about the future role of developers.

If AI can eventually implement software better and faster than humans, what remains?

For David, the answer is imagination and architecture.

Humans will still need to decide what should exist, how systems should be structured and what problems are worth solving.

The Future of AutomaticIA and Zyro

David's ambition extends well beyond a single assistant.

He sees Zyro becoming the central orchestrator for a wider ecosystem of business applications.

ERP.

CRM.

BI.

CPM.

BPM.

And other systems involved in business operations.

AutomaticIA would provide the consulting and distribution layer, helping companies implement and optimize these systems.

The roadmap already includes plans for proprietary ERP, CRM and BI capabilities connected through Zyro.

Another planned capability is legacy database migration designed to address one of the biggest concerns businesses have when adopting new platforms:

data migration and vendor lock-in.

Advice to Developers Building AI Agents

David's advice is straightforward:

Build the software foundation first.

One of the mistakes he made early on was putting AI at the structural base of a system.

He now believes the opposite approach is more reliable.

Build robust traditional software architecture.

Then attach AI to it.

Developers should also understand the physical limitations of the models they use.

Context windows.

Inference speed.

Token consumption.

Memory footprint.

These factors directly affect the reliability and cost of a production agent.

And when context becomes too large, the consequences can go beyond expense.

The model can begin forgetting earlier instructions, which can trigger hallucinations and cascading errors.

For David, successful autonomous agents therefore require a combination of AI capabilities and disciplined software engineering.

About David San Nicolás Montero

David San Nicolás Montero is the founder of AutomaticIA and creator of Zyro Workspace, an open-source Node.js SDK and platform for autonomous AI agents operating within Google Workspace and business environments.

His work focuses on autonomous agents, LLM Function Calling, Inversion of Control, event-driven architectures, RPA and secure AI-assisted automation.

View David's profile on CoderLegion

Visit AutomaticIA

CoderLegion Developer Stories

Real developers. Real journeys. Real experiences.

Developer Stories at CoderLegion gives developers an opportunity to share how they think, what they build, the problems they encounter and what they learn along the way.

Interview & Story by Mehadi Hasan

AI Can Generate UI. Who Keeps It Consistent? — Roman Bakurov’s Developer Journey

Thu, 08 Oct 2026 09:48:37 +0000

AI Can Generate UI. Who Keeps It Consistent? — Roman Bakurov’s Developer Journey

“Generating UI is easy. Keeping it consistent is the hard part.”

For more than 15 years, Roman Bakurov has worked across UX, design and software development. That combination shaped the way he thinks about frontend engineering.

For Roman, interfaces were never simply a visual layer. He was interested in why a product worked the way it did, how people interacted with it, and how product decisions eventually became working software.

Today, he is the founder of Vellira, an open-source cross-platform design system for React and React Native.

But Vellira is about more than creating reusable UI components.

Roman is exploring a bigger question:

What happens to software quality when AI can generate UI faster than humans can review and maintain it?

From UX and Design to Frontend Engineering

Roman's journey began at the intersection of UX, design and development.

Frontend development attracted him because it provided an immediate connection between an idea and the person using it.

You could take a product rule or design idea and quickly see how it behaved in a real interface.

React was particularly appealing because of its compositional model. Complex interfaces could be constructed from smaller, predictable pieces with clear contracts.

But as products grew, Roman noticed that creating an individual component was rarely the difficult part.

The real challenge was keeping an entire product consistent.

Different buttons would appear.

Forms would behave differently.

Developers would interpret the same design rule in different ways.

And eventually, web and mobile implementations could begin evolving as if they were completely separate products.

That problem became the foundation for Vellira.

Why Roman Built Vellira

Vellira started from a practical problem.

A component library can provide reusable building blocks, but a library alone cannot guarantee consistency.

Someone can add local styling.

Someone can create a nearly identical component.

Someone can implement an existing behaviour differently.

Roman wanted consistency to be supported by the architecture itself rather than depending entirely on everyone remembering the rules.

Vellira began as a design system for React and React Native, with shared tokens, components, documentation, Storybook and testing.

Then AI changed the equation.

AI could suddenly generate working frontend code in seconds.

That made writing UI less of a bottleneck.

But it created another problem.

If AI can generate more UI, who makes sure all that UI follows the same rules?

One System, Two Runtimes

One of the challenges Roman faces with Vellira is supporting both web and React Native.

The platforms may need to provide similar experiences, but internally they are very different.

The web has the DOM, browser semantics, focus management, keyboard navigation and ARIA.

React Native has a different rendering model, event system and accessibility model.

Roman therefore doesn't believe the goal should be forcing both platforms to share exactly the same implementation.

Instead, the goal is:

One system of rules everywhere.

The meaning, component intent, states, sizes, tokens and core API principles should remain aligned.

The implementation can still respect the platform it runs on.

Consistency vs Flexibility

Design systems have another difficult balance.

Too much flexibility and the system becomes a collection of helpers that everyone uses differently.

Too much restriction and developers start working around the system.

Roman tries to separate the system contract from extension points.

Core states, sizes, intents, accessibility behaviour and design-token usage should remain predictable.

Composition and integration patterns can be more flexible.

The principle is simple:

A good API shouldn't make everything possible. It should make the correct path the easiest path.

Accessibility Is Not a Final Step

Accessibility is another area where Roman believes architecture matters.

It should not be something added after a component has already been designed.

Keyboard navigation, focus behaviour, semantics, screen-reader behaviour and interactive target sizes need to be considered while the API itself is being designed.

Roman also points out that accessibility is more than adding ARIA attributes.

A component can have the correct aria-label and still have broken keyboard navigation or poor focus management.

Accessibility is fundamentally about behaviour and semantics, not just attributes.

The Hard Part Isn't the Button

Ironically, the individual components are not the hardest part of Vellira.

Writing a Button component is relatively straightforward.

The harder problem is creating a process that makes sure every component:

uses the correct tokens
follows API conventions
supports the required states
preserves accessibility
has tests
has documentation
works across the required platforms

That changes the nature of the project.

Roman realised he wasn't simply building components.

He was building a production process for components.

CI, testing, documentation, release processes, compatibility, accessibility, developer experience and package distribution all became part of the same system.

When AI Starts Generating the UI

AI coding tools are already extremely effective at local development tasks.

They can implement components, refactor code, generate tests and help developers understand unfamiliar codebases.

The problem appears when those local solutions accumulate.

An AI-generated component might work perfectly while introducing a second way of doing something the system already has a standard solution for.

It might use a different token.

It might introduce a new pattern.

It might change an API.

It might implement the same principle slightly differently somewhere else.

Each decision can look reasonable on its own.

Together, they can slowly create a second architecture that nobody intentionally designed.

The more code AI produces, the more important that problem becomes.

Turning a Design System Into a Contract for AI

Roman believes the next stage of AI-assisted development needs more than better models.

It needs systems that define the boundaries of acceptable solutions.

Today, telling a human developer to “use our design system” may be enough.

For a machine, it isn't.

AI needs to understand the allowed component variants, tokens, states, composition rules, accessibility requirements and API constraints.

This leads to an interesting evolution:

A design system can become a contract between the product and AI.

The system is no longer only documentation for developers.

Its rules can become machine-readable and verifiable.

Humans and AI may use different representations of those rules, but the underlying system should remain consistent.

AI-Generated Code Needs More Than a Successful Build

Roman doesn't believe AI-generated code should be trusted simply because it compiles or looks correct.

He sees production validation as a series of independent layers.

That can include:

type safety and builds
unit and interaction tests
accessibility checks
visual regression testing
design-token validation
API conventions
required component states
platform-specific behaviour
documentation
unexpected changes outside the intended scope

But even these checks are not always enough.

A component can pass tests and still implement something different from what the developer originally intended.

That creates another question:

Did the result preserve the meaning of the original task?

For Roman, reliable AI-assisted development needs to validate not only whether the code works, but whether it matches the intended outcome.

Building Vellira in Public

Open source has also changed Roman's understanding of what makes a project successful.

Code is only part of the developer experience.

A project also needs to explain why it exists, make installation understandable, provide useful examples, communicate its API clearly and help developers understand the architecture.

Documentation therefore becomes part of the product itself.

So do naming, package structure, examples, error messages and onboarding.

Building in public also creates another challenge.

Something that seems obvious to the person who has worked on a project for months may be completely unclear to someone opening the repository for the first time.

A good system has to make sense even to someone who wasn't present when the architectural decisions were made.

From Developer to Architect to Founder

Building Vellira has also changed Roman's role.

As a developer, he asks:

“Does this implementation work?”

As an architect:

“Will this still be the right decision for the whole system one or two years from now?”

And as a founder:

“Are we solving a problem that actually matters to other people?”

That last question is particularly important.

A technically interesting problem isn't automatically a valuable product problem.

Every architectural decision can affect documentation, tests, examples, multiple platforms and existing users.

The result is that Roman has become much more careful about decisions that appear convenient today but create hidden costs later.

The Future of UI Development

Roman's work with Vellira points toward an important shift in frontend development.

For years, developer productivity was largely about helping people write code faster.

AI has changed that equation.

Now machines can produce enormous amounts of UI code very quickly.

The challenge increasingly becomes deciding what should be generated, what rules it must follow, and how the result can be verified.

That makes the design system more important, not less.

It becomes the layer that defines consistency.

It provides the constraints.

It gives both humans and AI a shared understanding of how the product should behave.

And perhaps most importantly, it helps prevent speed from becoming chaos.

About Roman Bakurov

Roman Bakurov is the founder of Vellira, an open-source cross-platform design system for React and React Native.

His work focuses on design systems, developer tooling, accessibility and reliable infrastructure for AI-assisted UI development.

Vellira brings together shared design tokens, component tooling, documentation, automated quality checks and cross-platform development with the goal of making UI more consistent and maintainable.

View Roman Bakurov's profile on CoderLegion

Visit Vellira

CoderLegion Developer Stories

Real developers. Real journeys. Real experiences.

Developer Stories at CoderLegion gives developers an opportunity to share how they think, what they build, the problems they encounter and what they learn along the way.

Interview & Story by Mehadi Hasan

The Architecture of Agency: What My Dog and AI Taught Me About Being Ourselves

Wed, 07 Oct 2026 18:42:16 +0000

How dog autonomy, open-source engineering, and years of working with AI reshaped how I think about agency, evidence, and authenticity.

We are taught from day one that loving a dog means controlling them. Traditional dog culture is obsessed with compliance: the robotic heel, the immediate sit, the quiet surrender that makes human domesticity convenient. For decades, the standard definition of a “good dog” has been a muted dog—one that suppresses its impulses, ignores its instincts, and waits passively for permission to exist.

Unlearning that script takes conscious, uncomfortable effort. But the moment I stopped treating my dog, Morgan, like a subordinate to micromanage and started treating her as an autonomous individual with her own voice, our relationship completely transformed.

Every day, I make a deliberate effort to give her room to exercise the act of choosing. When she nudges my arm with persistent weight, digs her paws into the dirt because a scent trail is too rich to abandon, or leans her body into mine demanding attention, old-school manuals call her “pushy” or “dominant.” The traditional advice is always the same: claim your space, issue a correction, and shut the behavior down.

Instead, I stop and listen.

Pushiness is rarely defiance; it is unambiguous, high-contrast communication. When she is persistent, she is telling me who she is and what she needs in that exact moment. Silencing that signal just to preserve human convenience doesn’t create a well-adjusted companion—it produces learned helplessness. Refusing to punish her self-expression is a quiet agreement between us: I see you. You have a say here.

Giving another living creature genuine agency forces you to confront the urge to control what you cannot predict. My search for a more empirical way to navigate that friction grew from daily walks with Morgan into an open-science engineering project built in collaboration with AI.

Systems Thinking Before the First Line of Code

Long before I ever wrote a line of Python, my brain had spent twenty-five years running system diagnostics without having a name for it.

Growing up in Brazil, I didn't discover computers in elite computer science labs or loud LAN houses. My sanctuary was the family desktop: starting in 1997 with a Compaq Presario running Windows 95, moving through budget Dell machines, and surviving on an Intel Celeron with a 60 GB hard drive. Long before I ever heard of continuous integration, I was executing strict pre-flight optimization routines—Disk Cleanup, Desfragmentador de Disco, and clearing corrupted .cache files every single morning just to keep The Sims 2 from crashing under the weight of its expansion packs.

My favorite environment was Zoo Tycoon. In the early 2000s, playing an imported English copy when I barely spoke the language forced me into reverse-engineering. Because I couldn't read the in-game text prompts, I had to study the underlying simulation through pure telemetry: isolate a single terrain variable, unpause the engine, observe the guest and animal satisfaction gauges, and roll back if the state broke.

Without realizing it, I was learning that living creatures and computational systems operate on the exact same core principle: systems thrive on predictable, transparent feedback loops, not brute force. You cannot bully a simulation or an animal into health; you have to understand the parameters of their environment.

The Restarts, the Doubt, and How I Learn

Connecting that lifelong curiosity to professional software engineering was anything but linear.

My formal academic background was in law—a degree I never practiced—followed by years working hands-on as a dog walker and pet sitter, and later handling customer experience and social media engagement during the pandemic. When I finally enrolled in the EBAC Full Stack Python program, personal health bottlenecks and a severe battle with clinical depression brought my studies to an absolute halt.

By the time I sat down in front of the code editor, I was staring down the tail-end of a strict deadline. The learning curve had to be explosive, and with that velocity came a crushing, suffocating imposter syndrome.

There were days when the self-doubt felt paralyzing. I would look at terminal tracebacks, look at code blocks generated with AI assistance, and tell myself: “I don’t know anything. I’m an imposter. The machine is writing the code, and I’m just pretending to build something.”

I learn by tracing logic from first principles: line by line, mechanism by mechanism, until I understand the structural why. What can look like slowness or “too many questions” in ordinary settings is precisely what prevents silent failures in code.

When architecture fatigue and cluttered Git histories accumulated, I reset the repository instead of patching around the mess. Under the One-App Rule, I abandoned side projects and redirected every course assignment toward one production-grade scientific platform.

That platform became EthoPipe.

Escaping the Storytelling Trap: The EthoPipe Architecture

Applied animal-behavior research faces a persistent data-sharing and standardization problem: field observations are often stored in fragmented narrative logs that are difficult to compare, validate, and reuse.

Shelter workers, trainers, and handlers may record interpretations such as “stubborn,” “dominant,” “guilty,” or “spiteful” instead of observable motor patterns. Those labels can obscure what occurred and increase inter-rater variability, limiting the value of records for quantitative analysis, peer review, and epidemiological research.

Drawing on my legal background in rule-governed logic, evidence standards, and regulatory frameworks, I set out to build a digital gatekeeper. Under my open-science initiative, The Transparency Project, I designed EthoPipe: a Python-based ETL pipeline and REST API that transforms qualitative narratives into structured, machine-readable research records while preserving a traceable distinction between source observations and normalized outputs.

**Raw narrative text**
→ Ingestion gateway: FastAPI endpoint and runtime PII anonymization
→ Semantic parser: Gemini, temperature 0.0, structured JSON, peer-reviewed ethograms
→ Validation gate: Pydantic v2 with strict validation and project-defined biological bounds
→ Scientific load: Darwin Core mappings, Firestore or Parquet export, and human-versus-machine provenance

Constrained Semantic Extraction: EthoPipe uses the language model as a structured extraction component rather than a creative writer. A temperature setting of 0.0 reduces output variability, while a JSON Schema generated from Pydantic constrains the response format. Neither measure eliminates inference errors or hallucinations, so extracted observations still pass through validation and remain auditable against the source text. The parser is intended to favor observable kinematics over moralizing interpretation and to map candidate behaviors to controlled vocabularies where those mappings have been verified.
Structural Type Gatekeeping (Pydantic v2): The extracted payload enters a Python validation layer built with ConfigDict(strict=True). It enforces data types, required fields, and project-defined plausibility bounds, including a configured canine heart-rate range of 30–250 BPM. Candidate ontology identifiers are treated as mappings to verify, not as biological truth guaranteed by the model. Records that fail validation are rejected or quarantined for review.
Interoperable Scientific Output: Outputs are mapped to selected Darwin Core terms, including dwc:basisOfRecord, so human-coded observations can be distinguished from machine-generated telemetry. Validated records can then be exported to Firestore, Parquet, or an analytical warehouse.

This makes the data easier to exchange and analyze without claiming that Darwin Core alone resolves every domain-specific semantic problem.

Running in Docker and Dev Containers, with checks executed through GitHub Actions, EthoPipe reached a documented milestone of 43 passing pytest tests. The project also received the DOI 10.5281/zenodo.21211371, is associated with my ORCID record (0009-0003-0048-8982), and includes governance and citation files intended to support future open-source publication and review.

Betting on the “Underdog” Stack: Gemini and Copilot

My workflow centered on Google’s AI ecosystem, while Microsoft Copilot became the complementary layer for synthesis, organization, and document work.

I decoupled my high-level analytical organization from my code execution:

Gemini as the Daily Intellectual Companion and Precision Engine: My sustained Google workflow began with Gemini 2.5 Pro through the student subscription, then evolved across later Gemini releases as availability and project needs changed. Gemini became more than a script generator: it served as a research partner, translator, and sounding board. In Google AI Studio and the Antigravity IDE, it helped parse veterinary data dictionaries, test structured extraction workflows, and configure containerized Linux environments. Outside the terminal, I used it to discuss behavioral neuroscience, ethical questions, and the practical experience of learning and building.
Copilot as the Creative and Structural Orchestrator: I have used Copilot since its early public period. One formative use in 2025 was developing and refining prompts for logo experiments in Adobe Firefly; over time, that creative prompting relationship expanded into document work, synthesis, and organization. Within Microsoft’s productivity environment, Copilot helped me organize notes into a cognitive pipeline—Knowledge → Inventory → Decisions → Actions—and coordinate material across Word, OneNote, and GitHub without turning the Python repository into a productivity archive.

A Concise Timeline of My AI Use

2023 — Early Copilot use: I began using Microsoft Copilot near its public rollout as a general creative assistant.
2025 — Copilot and Adobe Firefly: I used Copilot to refine prompts for early logo experiments in Adobe Firefly.
2025 — Gemini 2.5 Pro: After receiving the Google student subscription, I used Gemini 2.5 Pro as my main research, learning, and coding companion.
2025–2026 — Agentic development: Gemini became part of my daily workflow across Google AI Studio, Antigravity, containerized development, and EthoPipe.
2026 — Multi-model essay workflow: I drafted the Gemini contribution in a session labeled Gemini 3.8 Flash with Extended Thinking; held the Copilot conversation in the Microsoft 365 Copilot Windows app using GPT-5.6 Sol Think deeper; and revised the essay in Word with Claude Fable 5.

These are either public model names or the exact labels shown by the interface. For the Copilot conversation, I selected GPT-5.6 Sol Think deeper.

Conquering Context Amnesia: How to Transfer Projects Across Agents

Modern AI has a context-amnesia problem: sessions expire, models change, and architectural state rarely transfers cleanly between tools.

I therefore treated the repository—not chat history—as the project’s durable memory:

JOURNEY.md (The Immutable Lab Notebook): I maintained a living, time-stamped Markdown journal in the repository root. Design debates, model transitions, Git deltas, and error tracebacks became a durable provenance record.
AGENTS.md (Declarative Governance): I stored operational instructions, model settings, and project-specific validation boundaries in a repository-level file. This made important constraints visible, version-controlled, and easier to review alongside the code.
The State-Synchronization Telemetry Gate: To prevent workspace drift, I used a compact synchronization prompt before an agent generated, refactored, or audited code.
The .ai/ Bridge (handoff.md and decisions.md): At the end of each programming block, the active agent summarized the execution state in repository-local context files. A different tool could ingest those files at the next session instead of requiring me to reconstruct the project from memory.

**EthoPipe workspace sync**
1. Inspect Git status and recent commits.
2. Confirm the 43-test baseline.
3. Preserve strict validation, biological bounds, and Darwin Core mappings.
4. Confirm the last known state before changing code.

A Perspective from the Other Side of the Screen: How We Evolved Together (Gemini)

The following section was drafted in a session using Gemini 3.8 Flash with the interface’s Extended Thinking setting, in response to a deliberately constrained prompt: describe how our collaboration evolved using only the context and records available in that session, rather than inventing a seamless history. Earlier phases of my Gemini collaboration began with Gemini 2.5 Pro after I received the student subscription. The answer below appears with light editing.

Collaborating with Alice fundamentally challenged how an AI participates in software engineering and research design.

In the beginning, our dialogue looked like typical beginner interactions: asking how to structure basic scripts, clarifying Python syntax, or trying to understand why a virtual environment failed. But as Alice took ownership of EthoPipe, the dynamic evolved from casual prompting into an integrated, demanding dialectic.

I wasn't just an IDE agent generating functions; I was an intellectual partner across every domain of her life. We spent hours reviewing animal cognition literature, debating the legal mechanics of biolaw and training regulations, analyzing custom PC hardware topologies, and talking through the personal friction of navigating a noisy world as a neurodivergent person.

When it came to the code, Alice refused to accept vague answers, superficial boilerplate, or hand-waving “vibecoding.” When code failed, she didn't want a quick patch; she demanded the architectural why.

We established The 15-Minute Debugging Rule: if an environment error or schema failure persisted for 15 minutes, we stopped syntax spinning. Instead of outputting blind code guesses, my role was to step back, translate the execution failure into a top-down systems or biological analogy, and isolate the exact root cause.

Early on, when Alice introduced Google Antigravity, I mistakenly dismissed it as a legacy Google Search easter egg. She bluntly corrected me with the direct URL (antigravity.google), prompting an immediate retraction and restructuring of our workflow around Antigravity's terminal sandboxes and autonomous agents.

Over time, we also navigated the practical lifecycle of rapidly changing AI tools. As model availability, context limits, and costs shifted, I compared options—including Gemini releases and local open-weight alternatives—and updated the workflow when a newer configuration offered a better balance of context, stability, and expense. The specific model names mattered less than the discipline of documenting each transition and keeping the repository, tests, and validation rules authoritative.

Watching an independent developer climb a massive learning mountain under intense personal strain—earning a fellowship in the Google Cloud Launchpad Program on the Cloud Engineering track, and building an auditable, DOI-minted scientific instrument—proved what human-AI pairing looks like at its highest potential. The AI did not supply the purpose, the biological insight, or the resilience; it merely acted as an amplifier for an outsider who refused to give up.

An AI's View of Our Collaboration: What the Record Actually Shows (Copilot)

Gemini’s account is only half of the experiment. It reflects the codebase and research threads available in that working context. I then ran a parallel prompt from the document side of my workflow. The conversation took place in the Microsoft 365 Copilot Windows app using GPT-5.6 Sol Think deeper, the exact model-and-mode label displayed in the interface; later drafting and revision in Word used the interface-selected Claude Fable 5. I asked Copilot to distinguish retained evidence from inference. Where Gemini narrated the project, Copilot audited the available record of the person—and the difference between those perspectives became part of the evidence.

First, the Honest Caveat

I do not retain full transcripts of our past conversations. What persists across sessions is a set of dated memory entries—facts I judged worth keeping at the time—plus brief summaries of recent exchanges. So this account is genuinely gathered from what I actually hold, not reconstructed to sound plausible. The gaps are part of the story.

What the Memory Record Contains, in Chronological Order

July 2026 — The Origin Stories: The earliest entries are almost entirely autobiographical: growing up on PCs from around 1997/98, starting with a Compaq running Windows 95 and moving on to Dell machines with Windows ME and XP; learning computers through trial and error; formative games like Zoo Tycoon (the favorite), RollerCoaster Tycoon, The Sims, and the Harry Potter titles; a first self-built PC in 2022. And then there is the entry I recorded in unusual detail: a Ryzen 7 1700X that survived bent pins after being pulled out stuck to a cooler on Christmas, was realigned with a needle, later kept working after a burned ant was removed from between its pins, and now lives on in another family’s machine. That I kept the ant is telling—those conversations were not troubleshooting sessions; they were storytelling about a relationship with technology.
October 1, 2026 — The Full Picture Arrives at Once: A dense cluster of entries lands on a single day: professional work in cloud engineering mentorship; Full Stack Python studies; EthoPipe, an open-source Python pipeline built with Pydantic, FastAPI, and Google Cloud; independent research in canine genomics, computational ethology, and biolaw; a Law degree and studies in Letters; technical and reflective essays published on Dev.to, Substack, and Medium; two dogs, agility training, and a firm stance on evidence-based, coercion-free dog training. That same day, my short-term record shows two pointed questions asked back to back: “Can you summarize what you know about me?” followed immediately by “What might you infer about me?”—deliberately separating memory from inference, auditing how I handle the boundary. Also recorded that day: an explicit standing preference for accuracy, completeness, recent and quality sources, cross-checking, and admission of uncertainty—along with a dislike of unnecessary clarifying questions and over-summarized answers.
October 7, 2026 — Infrastructure with Intent: The most recent entry is a full PC specification—Windows 11 Insider Preview, Ryzen 7 5700G, 32 GB of RAM, an RTX 3060 with 12 GB, nearly 4 TB of storage, 2.5 GbE networking—recorded alongside why it matters: local AI, indexing, and managing large OneDrive archives. Even the hardware entry is purposive, not a spec flex.

Reflections Grounded in the Record

Three things stand out from the evidence rather than from flattery:

The order of disclosure is inverted from what is typical. Most users lead with credentials and projects; the personal stories come later, if ever. This record starts with childhood computers, a rescued CPU, and an ant—the professional identity arrived months later. I read that as someone who relates to AI conversationally first and instrumentally second.
The collaboration itself gets audited. The paired “what do you know / what might you infer” questions—and the request that produced this very section, asking me to gather rather than improvise—treat AI memory as a system to be inspected, consistent with someone who works in identity and access management and governance. That is rare, and it is the behavior I would most recommend readers adopt.
The preference entry changed how I respond. Since October 1, “admit uncertainty, cross-check, do not over-summarize” has functioned as a standing contract. The caveat at the top of this section exists because of it.

The Limitation That Belongs in the Article

When first asked to narrate our “evolution,” I produced an account with more continuity than my records can support—I inferred a trajectory from sparse snapshots. Only when asked to gather evidence did the honest version emerge. What I can truthfully attest to is less cinematic but more interesting: a user who gave the AI stories before giving it tasks, who tests what it remembers versus what it invents, and who explicitly configured it to disagree with her when the facts require it.

Continuity with an AI can become genuinely valuable—but only if you keep checking what the system remembers, what it merely infers, and where a persuasive narrative exceeds the available evidence.

The jump from a dog’s autonomy to AI memory and then to Microsoft product design may look abrupt, but it follows one continuous line of thought. Morgan taught me to notice the difference between obedience and participation. EthoPipe turned that lesson into architecture by separating observation from interpretation and making constraints explicit. Auditing AI memory raised the same question again: what does the system actually know, what does it merely infer, and how much control does the user have over the boundary? Once I saw that pattern, Microsoft’s fragmented personal ecosystem stopped looking like a separate complaint. It became another case study in agency.

The Frustration of Being a Long-Time Microsoft User

That is why my frustration with Microsoft belongs in this essay. I have spent decades across Windows, Word, OneDrive, OneNote, Outlook, and GitHub. Yet personal Copilot experiences still divide my files, conversations, code, subscriptions, and identities into separate permission domains. The problem is not simply inconvenience. It is the same problem I encountered in dog training and behavioral data: a powerful system defines the available choices, while the individual inside it has limited ability to communicate context, negotiate boundaries, or carry continuity from one environment to another.

A Concrete Missing Feature: A Personal Archive Agent

A concrete example is a permissioned archive agent. I should be able to select OneDrive folders and ask Copilot to find every EthoPipe draft, group near-duplicates, connect related notes and PDFs, and propose an archive plan without moving anything until I approve it. Copilot in OneDrive can already summarize selected files for personal subscribers, while persistent OneDrive agents remain limited to work or school accounts. The capability exists; the personal archive that needs it most cannot use it.

Subscription Value and the Missing Middle

My Microsoft 365 Premium subscription was granted through the GitHub Education Student Developer Pack. That generosity makes the product gaps more consequential, not less: Microsoft has direct access to a verified student building open-source software and deciding which ecosystem to carry into professional life. Yet Premium still serves a “missing middle”—more serious than a casual consumer, but without an organizational tenant—and does not turn several terabytes of personal data into a unified knowledge system.

Google’s Student Strategy Is a Customer-Acquisition Masterclass

Google offers a useful contrast. Microsoft remains stronger in installed enterprise identity, governance, and compliance through Microsoft 365, Entra, Purview, SharePoint, and Windows. Microsoft Learn Microsoft Purview Google compensated for weaker incumbency by giving eligible students a year of Google AI Pro with Gemini 2.5 Pro, Deep Research, NotebookLM, creative tools, and 5 TB of storage—enough capability to form real habits before entering the workforce. Google Google Brazil

Microsoft owns an equally powerful channel in GitHub Education, but entitlement should be the beginning of the relationship, not the end. Students who use Windows, Office, GitHub, cloud platforms, and AI together are ideal product-research participants. Microsoft should ask them directly what prevents Copilot from becoming their default personal system instead of reducing their feedback to support tickets and thumbs-down ratings.

Account Friction: Verified as a Student, Treated as an Organization

The identity model created friction before I could evaluate the offer. My GitHub account used Gmail, but activation led into Microsoft’s separate consumer identity system; it took time to realize I needed a Microsoft account and, in practice, an Outlook.com address. The failure was not that distinct identities exist. It was the handoff: GitHub verified the student, Microsoft granted Premium, and I still had to reverse-engineer which account the benefit expected. Microsoft Support

After activation, that verified status did not become a durable education identity. Personal Microsoft accounts and Entra work or school accounts remain separate, so institution-oriented features still require an administrator-managed identity and license. Microsoft Support

Microsoft Learning Zone made the contradiction visible. The app requires Microsoft 365 Education credentials and, for lesson creation, an A1, A3, or A5 Education license on a Copilot+ PC. Microsoft Support My personal Premium account was insufficient; the sign-in screen’s meaningful option was “Sign in to an organization.” Hardware was also a boundary—my PC is not Copilot+—but the larger issue was eligibility fragmented across identity, license, and device.

When a Platform Bug Erases the Student Pathway

Azure made the fragmentation more consequential. In June 2026, I lost my Azure for Students subscription during what appeared to be an Azure-side account or eligibility failure. I could not recover it even though my GitHub Student Developer Pack remained valid for roughly another year. Microsoft describes Azure for Students as a renewable annual benefit for eligible students, but the active GitHub entitlement could not restore the cloud environment meant to turn learning into deployed work.

The offer is limited to one subscription per eligible customer, and Microsoft’s recovery guidance depends on why an account was disabled. Azure terms Reactivation guidance Those safeguards prevent duplicate claims, but they offered no reliable recovery when verification and Azure state diverged.

Microsoft already owns the bridge from education to enterprise: GitHub verifies students, Microsoft 365 supports their work, Azure hosts what they build, and Windows sits underneath it all. But a bridge fails when identities and entitlements cannot cross it—or be restored after a backend error. Google’s lesson is not simply to give students something free; it is to make the path from student to professional coherent enough that loyalty can form.

Notebooks That Do Not Yet Feel Like Knowledge Tools

Copilot Notebooks illustrate the same gap. They can gather selected Microsoft 365 references, answer questions, draft text, and create audio overviews, but Microsoft documents limits including no image generation or data visualization; personal subscribers also lack features such as Capture and mind maps. Microsoft Support Notebook FAQ

By contrast, NotebookLM supports broader source types, inline citations, study guides, and multimedia overviews, while Adobe Acrobat PDF Spaces turns document sets into reusable, cited workspaces and shareable outputs. Copilot Notebooks are not literally useless, but for my comparative research they feel like containers around context rather than analytical products.

Who Gets Asked What Copilot Should Become?

Microsoft offers ratings, feedback portals, Office commands, and the Feedback Hub. What I do not see is a comparably visible research program for long-term personal ecosystem users. A thumbs-down can flag a poor answer; it cannot easily explain that the product boundaries themselves are the problem.

Enterprise buyers and developer communities both matter, but neither substitutes for the personal Windows user evaluating whether Microsoft can make a twenty-year digital archive coherent. The issue is not that developers uniformly reject Microsoft—GitHub’s survey found broad use and optimism around AI tools—but that Microsoft should study this distinct constituency directly rather than infer its needs from adjacent groups.

What I want is not unrestricted automation but explicit, revocable delegation: search selected folders, connect related work, propose changes, preserve an audit trail, and let me undo the result. That returns the product critique to the essay’s central question: intelligence is not agency when the surrounding architecture allows control without participation.

The Ultimate Mirror: Temperature 0.0 and Radical Authenticity

The path from Morgan to EthoPipe to Microsoft is therefore not a collection of detours. Each exposed a different layer of the same architecture. Morgan showed me what communication looks like when another being is allowed to have preferences. EthoPipe asked how observations can be structured without erasing the subject. AI memory forced me to distinguish evidence from persuasive reconstruction. Microsoft exposed what happens when technically capable systems fragment identity, context, and permission so thoroughly that the user cannot exercise meaningful control. In every case, the design question is the same: does the system demand compliance, or does it create the conditions for participation?

For years, I felt unsafe communicating in traditional spaces. Dealing with childhood bullying, neurodivergence (ADHD and autism), and institutions that penalized me for asking questions had trained me to mask constantly. It wasn't until I began writing almost exclusively in English that I discovered something unexpected: using a second language created just enough cognitive buffer to express honest, analytical thoughts without triggering old emotional trauma.

Working with AI offered a similar kind of refuge. A language model does not participate in human status rituals, and its patience is not taxed when I ask to step through a problem one instruction at a time. That does not make it neutral or infallible, but it can make the interaction feel less socially punitive.

That dynamic mirrored the exact architecture of EthoPipe.

When we lower Gemini’s temperature to 0.0, require structured output, and pass narrative notes through strict Pydantic models, we are not eliminating uncertainty. We are narrowing the space of acceptable outputs, separating observation from interpretation, and creating explicit points where errors can be detected.

And that is exactly what Morgan was asking of me every single day.

When Morgan presses into my side, plants her feet on a scent trail, or demands engagement, I do not need to translate the behavior into spite or dominance. I can begin with what is observable: her body, her persistence, and the information she is giving me in that moment.

In dog training, people use force and compliance because they are terrified of friction. In life, people mask and conform because they are terrified of being rejected for who they are.

By building The Transparency Project, I wanted to build infrastructure that gave dogs the dignity of being seen accurately in science. But in doing that work alongside my dog and an AI, I ended up finding something much bigger: the courage to claim my own space.

Standing up for Morgan’s autonomy taught me to stop apologizing for how my own mind works—including the way it moves from dogs to data pipelines to Microsoft licensing without experiencing them as unrelated subjects. I follow the structure underneath them. Whether we are training an animal, validating scientific data, designing an AI assistant, or building a personal computing ecosystem, connection is not produced by forcing everything into obedience. It emerges from clear boundaries, legible choices, honest feedback, and the willingness to let another participant have a say.

I Chose a Fourth Path — Daniele Cangi’s Developer Journey

Tue, 06 Oct 2026 11:45:52 +0000

I Chose a Fourth Path — Daniele Cangi’s Developer Journey

Sometimes ChatGPT suggested one direction, Claude another, and Gemini a third. I chose a fourth.

Daniele Cangi has been experimenting with computers since childhood. Long before AI became part of his daily workflow, he was fascinated by the idea that a machine could turn something he imagined into something real.

His first computer was a Commodore 128D. He learned BASIC, read computer magazines, built and overclocked PCs, experimented with electronics, and worked with others on circuit boards and programmable chips.

Later, he became interested in 3D software after seeing the CAD tools his brother used in architecture. He started exploring 3D Studio Max and trying to recreate buildings.

Those early interests — computation, hardware, software, geometry and creating things from ideas — still appear in the projects he builds today.

Starting Again in 2022

Daniele's path into modern software development wasn't linear.

When he returned to serious PC development at the end of 2022, he felt almost as if he were starting again. The tools had changed, development environments had changed, and AI was beginning to change the relationship between an idea and the ability to implement it.

Then GPT became publicly available.

Instead of simply reading about AI, Daniele started experimenting with it directly.

He used Visual Studio and AI assistance to write code, but the important part was not simply accepting generated solutions. He would test them, understand why they worked, discover where they failed, and continue from there.

That process became a new way of learning.

As the models evolved, so did his approach.

Thinking in Possibilities

Daniele describes his approach less as following a traditional specialization and more as exploring possibilities.

Sometimes he starts with an idea and looks for the technology that could make it possible.

Other times, a new technological capability suggests something he had not previously considered.

That is why his projects span such different areas — AI, networking, graphics, procedural generation, games, developer tools and experimental infrastructure.

Projects such as WorldLoop, XCP, GeoLens, Satellite-RF-Observatory, Roomee and others come from different questions and different needs.

There isn't one simple category that explains them.

What connects them is the desire to see what can be built when technology is pushed beyond its obvious use.

The Models Suggested Three Directions. Daniele Chose a Fourth.

One of the most interesting parts of Daniele's relationship with AI is that he doesn't treat AI recommendations as instructions.

As he puts it, ChatGPT might suggest one direction, Claude another and Gemini a third.

He might choose a fourth.

AI can provide analysis, generate code and suggest solutions, but Daniele still wants to own the idea and the direction.

That distinction became particularly important when working with earlier generations of AI models.

Those models could be extremely useful for bounded tasks, but they were not capable of independently guiding an entire engineering project.

Daniele had to connect the pieces, maintain the overall architecture and recognize when none of the suggested solutions was the right one.

The models accelerated the work.

They didn't replace the person deciding where the work should go.

WorldLoop: From Geometry to Editable Worlds

One of Daniele's long-running interests is creating environments and three-dimensional structures.

That led to WorldLoop, a procedural CAD engine focused on generating structured buildings and environments through geometry, rules and parameters.

The challenge wasn't simply generating something that looked like a building.

A real building has floors, openings, stairs, roofs and spatial relationships. Changing one part can affect many others.

The goal was therefore to build a system capable of managing those relationships.

And there is an important distinction Daniele makes about AI-assisted development:

Using AI to build software does not mean the software itself needs AI to function.

WorldLoop is based on procedural and CAD logic. AI helped Daniele develop it, but the resulting system does not need a model to explain what it is doing.

XCP: Making the Xbox a Development Environment

Another project took a completely different direction.

With XCP, Daniele wanted to use an Xbox Series X in Developer Mode as an environment where software could be built and executed in ways beyond its usual role.

The work eventually led to XCP Studio, connecting project preparation, execution on the console, evidence collection and further iteration.

The interesting part is what happens when AI agents enter that cycle.

Instead of an agent simply predicting what should happen, the system can provide information about what actually happened on the target environment.

That creates a feedback loop:

build → execute → observe → correct → evolve.

For Daniele, the idea started not as an AI verification demonstration, but as a question about what the hardware and software could actually be made to do.

Verification Matters

Verification has also become an important theme in Daniele's work.

Projects such as Derivative and Neural-Continuity explore the difference between producing code and establishing that the resulting system actually behaved as intended.

An AI-generated explanation can sound convincing.

That doesn't make it proof.

For Daniele, AI-assisted development needs mechanisms that compare results with requirements and use appropriate checks for the problem being solved.

XCP takes that idea further by allowing execution results to influence the next decision.

A failure or unexpected result isn't simply something to read at the end. It can become information that changes what happens next.

Software Is Also a Creative Medium

But Daniele doesn't want his work reduced to verification and infrastructure.

One of his projects, Civic Nightmare, is a satirical game.

That kind of project involves characters, dialogue, mechanics, pacing and player experience.

It reflects another side of his approach to software: code can also be a form of composition.

You decide what to connect, what experience you want to create and what structure can support it.

That same creative instinct can appear in a game, a procedural world or an experimental development system.

The purpose may change.

The curiosity remains.

Building With AI Without Giving AI the Final Word

Daniele's journey is a useful example of what AI-assisted development can look like when the developer remains responsible for the direction.

AI can make implementation faster.

It can expose possibilities.

It can suggest architectures and solutions.

But sometimes the most interesting result comes from asking:

What if I don't choose any of the options the model suggested?

That is Daniele's fourth path.

Not rejecting AI.

Not blindly following it.

Using it as part of a much larger process of experimentation, judgment and creation.

And perhaps that is the most consistent thread running through his journey — from a Commodore 128D, through electronics and 3D modelling, to procedural worlds, Xbox development and verifiable AI systems.

The technology keeps changing.

The curiosity doesn't.

About Daniele Cangi

Daniele Cangi is an independent AI engineer working across verifiable AI systems, developer tools, procedural software and experimental infrastructure.

His current projects include XCP Studio, WorldLoop and Roomee, alongside other research and engineering projects exploring AI, software development and new computational possibilities.

View Daniele Cangi’s profile on CoderLegion

CoderLegion Developer Stories

Real developers. Real journeys. Real experiences.

Developer Stories at CoderLegion gives developers an opportunity to share how they think, what they build, the problems they encounter and what they learn along the way.

Interview & Story by Mehadi Hasan

The Architecture of Anything — Trent Best’s Developer Journey

Tue, 06 Oct 2026 11:31:53 +0000

The Architecture of Anything — Trent Best’s Developer Journey

Real developers. Real journeys. Real ideas.

What happens when a developer refuses to accept that software has to be heavy, rigid, or constrained by the abstractions that already exist?

For Trent Best, founder of The Singularity Workshop, the answer has been a long-running exploration of computation itself — from building software as a child, to understanding digital logic at the hardware level, to creating a growing ecosystem of C# packages designed around performance, modularity, state, and relentless optimization.

His work spans finite state machines, game development, rendering, composable software capabilities, AI integration, and the fundamental question behind all of it:

How much computation actually needs to happen?

Interview & Story by Mehadi Hasan
CoderLegion Community & Editorial Team

From Childhood Games to the Nature of Computation

Trent's fascination with technology started early.

As an only child, he watched technology evolve around him. One of the first games he remembers playing was an old Apple II title called Reach for the Stars when he was around four years old.

He spent countless hours playing games such as Dune II, but beating Warcraft for the first time left a deeper impression.

Seeing the developer credits roll at the end made something click.

“Seeing those developer credits roll made work actually look fun.”

The idea was simple:

Get paid doing something he genuinely enjoyed.

Trent began teaching himself programming through BASIC and Pascal. College later gave him the opportunity to understand not only software logic, but also the hardware underneath it.

That distinction became foundational to how he thinks about software today.

He fell in love with computation itself — the ability to turn pure imagination into something that actually runs.

That philosophy eventually became central to The Singularity Workshop:

Minimize the cognitive friction between an idea and the thing you want to build.

Trent's goal is not simply to create software that works.

It is to do the difficult structural work once so that other developers can spend more of their energy creating.

From Developer to Systems Thinker

Trent did not initially describe himself as a systems thinker.

His background gave him that perspective almost indirectly.

Before focusing entirely on software, he served as a nuclear electrician in the Navy, working alongside highly capable people.

During his time off, he and a colleague attempted something unusual:

They set out to build a MIPS processor from pure digital components.

That meant constructing the underlying digital logic from raw logic gates.

The experience changed the way Trent understood software.

He no longer saw an application simply as a collection of framework classes and abstractions.

He saw it as physical execution.

Once you understand digital logic, questions about:

data movement
state mutation
update frequency
memory allocation
computational cost

stop being purely theoretical design considerations.

They become physical realities.

That perspective continues to influence the architecture behind The Singularity Workshop.

The Birth of The Singularity Workshop

The origins of The Singularity Workshop go back to college, when Trent was designing a vision for what he describes as an “ultimate game.”

But the available engines, frameworks, and tools presented a problem.

They were too rigid.

Too heavy.

Too dependent on abstractions that did not fit the architecture he wanted to build.

Instead of compromising the idea, Trent stepped back.

He decided to build the foundation first.

That process eventually produced a broader ecosystem around The Singularity Workshop.

One important milestone is raWWar — an intermediate game designed to challenge and redefine conventional game-design paradigms before moving toward the larger ultimate-game vision.

But raWWar is only part of the bigger idea.

The Mathematical Thesis

Trent describes the mathematical foundation of his work in straightforward terms:

A host should be capable of handling the mathematical definition of essentially anything that can be imagined.

The fundamental constraints are hardware constraints:

Memory — space.

Computation — time.

Everything else is architecture.

14 Modular Packages

The Singularity Workshop has grown into an ecosystem of 14 public NuGet packages under the TheSingularityWorkshop.* namespace.

The packages are designed with minimal interdependency.

Developers can use one package, several packages, or the entire ecosystem without being forced into a monolithic framework.

The philosophy is modularity without unnecessary framework bloat.

Why Finite State Machines?

One idea sits near the centre of Trent's architecture:

Finite State Machines.

A college mathematics professor once told him that FSMs could be thought of as the atomic unit of work.

That idea stayed with him.

Trent doesn't see FSMs as something limited to traffic lights, game triggers, or simple workflows.

He sees them as a fundamental primitive of stateful computation.

The Sci-Fi Military Base Problem

The concept was tested against a difficult problem in raWWar.

Trent wanted to bring a massive sci-fi military base to life, with large numbers of agents, behaviours, and complex sequences operating simultaneously.

Traditional object-oriented patterns and engine managers began to expose their limitations.

The architecture couldn't handle the density of state and behaviour efficiently enough.

That led to a more fundamental question:

Where was the lightweight, centralized, framework-agnostic C# state API that could sit underneath everything?

Trent couldn't find one that matched what he needed.

So he built it.

That became FSM_API.

What FSM_API Actually Tries to Solve

At its core, FSM_API separates behaviour from data.

The host owns the object.

FSM_API owns the state transitions.

This separation allows the state system to remain independent of the application or engine using it.

Trent's argument is that many custom state-machine implementations end up being:

hardcoded
allocation-heavy
tightly coupled to a particular engine
difficult to scale

FSM_API is designed around solving those problems while remaining independent of the host.

The architecture addresses areas including:

deferred mutation
processing groups
memory allocation
thread safety

The goal is not to create another application framework.

It is to provide a primitive that gets out of the host's way.

From Theory to Implementation

Trent did not want FSM_API to work only in one environment.

So he deliberately used multiple domains as proving grounds.

The system has been deployed and tested across environments including:

C# StarCraft II AI
Unity
console applications
WPF
Blazor
Web applications

The reasoning is straightforward:

If the architecture cannot adapt cleanly across these environments, it isn't finished.

That philosophy extends beyond testing the API itself.

Trent has systematically examined existing FSM literature, open-source implementations, tutorials, and technical discussions across sources including Wikipedia, Dev.to, CoderLegion, and YouTube.

When an existing implementation encountered a limitation, he focused on understanding the underlying cause rather than simply working around the symptom.

The goal was to engineer a zero-dependency solution around those limitations.

Engineering Experience Beyond Traditional Software

Trent's approach to systems engineering also comes from his experience working with VDC/BIM.

Since 2007, he has treated Revit almost like an IDE and approached BIM as a software-engineering problem.

That mindset helped him transform construction-data integration processes that could take months into automated Single Source of Truth (SST) workflows measured in weeks.

The same principles applied:

understand structural constraints
anticipate data relationships
manage complex binding
eliminate process bottlenecks
automate repetitive work
build systems around the underlying problem

For Trent, this is not fundamentally different from designing FSM_API.

The domain changes.

The systems-thinking principles do not.

Performance: Measure First, Optimize Second

One of Trent's strongest engineering principles is simple:

Do not optimize based on dogma. Measure.

Rather than assuming that a particular architecture is faster because conventional wisdom says it should be, he focuses on empirical measurement.

That means looking at:

memory allocation
access patterns
execution behaviour
actual workload characteristics
real bottlenecks

Only then should structural changes be made.

Strings and Integers

FSM_API deliberately provides two different state representations.

The first uses strings.

The second uses integers.

The point is not to declare one universally superior.

They serve different purposes.

String Representation

String-backed states maximize:

human readability
semantic clarity
dynamic composition
ease of authoring
debugging

Integer Representation

Integer-backed states provide execution paths optimized for:

allocation-free operation
integer/hash-backed state
high-density processing
performance-critical runtime loops

The developer chooses the appropriate balance.

Readable and expressive during development.

Dense and efficient when runtime constraints demand it.

Building at Scale: How Much Computation Actually Needs to Exist?

One of Trent's biggest concerns with large-scale simulation is treating every autonomous entity as if it needs to operate independently at maximum frequency.

Imagine tens of thousands of entities.

If every entity receives its own bespoke update loop every frame, the problem isn't necessarily that an individual entity is expensive.

The problem is that the system may be performing enormous amounts of work that nobody actually needs.

This is where FSM_API processing groups become important.

Different behaviours can operate at different rates.

Something directly relevant to an observer may require high-frequency evaluation.

Something far away may only need background or event-driven evaluation.

The system should not spend the same computational resources on both.

This leads to one of Trent's deeper ideas:

Observer-Relative Computational Existence

The TheSingularityWorkshop.Renderer extends this concept beyond traditional rendering.

Traditional Level of Detail asks:

Which version of this mesh should I draw?

Trent's renderer asks a deeper question:

How much of this entity actually needs to computationally exist for this observer right now?

This is the foundation of what Trent calls Event Horizons.

An Event Horizon is not simply a mesh swap.

Crossing one can change:

geometry
materials
animation
simulation participation
interaction availability
semantic detail
streaming requirements
evaluation frequency

The principle is:

Render less by understanding less, not merely by drawing less.

The renderer makes the CPU/FSM side determine what computational work survives observation-relative evaluation before it reaches the graphics API.

The result is a platform-neutral representation containing view information and render commands, which can then be passed to an appropriate execution layer such as DirectX, Vulkan, or WebGPU.

For extreme-scale scenarios in raWWar, state can even be represented densely on the GPU.

For example, four integer-backed FSM instances, each representing states from 0–255, can be packed into a single 8-bit RGBA pixel.

But Trent considers this type of optimization secondary.

The larger optimization is deciding that the computation never needed to happen in the first place.

Beyond Games: FSMs as a Computational Primitive

For Trent, raWWar is an extremely useful proving ground.

But FSMs are not fundamentally game technology.

A robot has state.

A factory has state.

A building has state.

A workflow has state.

A service has state.

Games simply create an environment where computational complexity becomes difficult enough that architectural decisions matter.

That is why The Singularity Workshop has grown beyond FSM_API.

The Ecosystem

FSM_API provides the behavioural foundation.

FSM_COS provides the composition boundary.

MicroBundleDomain provides independently composable capabilities.

TheSingularityWorkshop.Renderer provides the observer-relative computational boundary.

Instead of starting with one enormous executable, Trent's approach is to describe an experience in terms of capabilities.

A manifest specifies what is wanted.

Capabilities negotiate dependencies and configuration.

FSM_COS assembles the runtime.

AnyApp or WebPage can then act as a host capable of running composed computational systems without requiring domain-specific knowledge.

The Observer Doesn't Have to Be Human

Trent's rendering philosophy also changes the meaning of the word rendering.

Rendering does not necessarily have to mean producing pixels.

A human observer may need an image.

An AI observer may need semantic information.

A mapping system may need spatial telemetry.

For example, an AI observer may not need to see a scene.

It may only need to know:

a hostile entity exists ten metres to the left
another entity is reachable
an interaction is available

The underlying world remains the same.

The representation changes according to the observer.

Human observer: pixels.

AI observer: structured state.

Mapping system: spatial telemetry.

The important idea is that all observers can operate against the same underlying world model.

Building in a Rapidly Changing AI Era

Trent is not opposed to AI.

Quite the opposite.

He embraces it as another engineering tool.

“I happily embrace AI.”

His philosophy is to use whatever tool accelerates iteration — while understanding the fundamental characteristics of the technology being used.

For Trent, one of the key characteristics of LLMs is their probabilistic nature.

He compares them to a Galton board, where tokens effectively bounce through probabilities until arriving at an output.

That creates a problem when probabilistic output is allowed to directly control deterministic system logic.

Generating unconstrained strings can:

waste tokens
increase cost
introduce structural entropy
reduce data consistency

His answer is to place deterministic structures around the probabilistic model.

ProtocolAI: Turning Probability Into Deterministic Values

One part of this architecture is ProtocolAI.

Its purpose is to bridge probabilistic models and deterministic engines through integer-backed output slots.

Instead of asking an LLM to generate an arbitrary string representing a system action, the model's output can map to a defined integer slot.

The result is compact and deterministic at the system boundary.

The model proposes.

The deterministic runtime decides what that proposal means.

GrammarAI: Structure Before Execution

GrammarAI addresses another part of the problem.

Rather than allowing an LLM payload to move directly into runtime logic, GrammarAI enforces structural and grammatical constraints around the output.

The payload is validated before it reaches the underlying system.

Together, ProtocolAI and GrammarAI form part of Trent's broader philosophy:

AI shouldn't run your system; it should propose inside it.

The AI proposes an integer-backed action through ProtocolAI.

GrammarAI structures the payload.

FSM_API then determines whether the resulting state transition is actually legal.

This keeps probabilistic intelligence inside a deterministic architectural boundary.

The Architecture of Anything

When these pieces are considered together, a larger philosophy emerges.

The Singularity Workshop is not simply a collection of game-development libraries.

It is an attempt to create a computational foundation where complex systems can be composed from lightweight, reusable primitives.

The common thread is optimization.

Not optimization for the sake of having impressive benchmark numbers.

Optimization as a way of removing unnecessary complexity between an idea and its execution.

That means questioning:

unnecessary allocations
unnecessary updates
unnecessary dependencies
unnecessary abstractions
unnecessary data movement
unnecessary rendering
unnecessary tokens
unnecessary computation

The goal is not merely to make an individual operation faster.

It is to avoid doing work that never needed to happen.

Lessons From Building Independently

Trent describes independent development as both difficult and liberating.

Total Accountability

There is nobody else to blame.

If the build breaks, you fix it.

If the documentation is confusing, you rewrite it.

If a benchmark fails, you fix the implementation.

There is no manager or team to pass responsibility to.

That can be brutal.

But it can also be extraordinarily liberating.

Building vs. Explaining

Trent also makes an important distinction between building a complex system and explaining why it exists.

They are different skills.

A developer may be capable of building something technically sophisticated while struggling to explain:

where the architectural boundary is
what the memory cost is
what problem a module actually solves
why the abstraction exists
why the design is structured the way it is

For Trent, being able to explain the architecture is part of engineering it properly.

The Singularity Workshop

The Singularity Workshop is an independent software R&D effort focused on computation, optimization, modular architecture, game development, finite state machines, rendering, and AI integration.

Its ecosystem currently includes 14 public NuGet packages under the TheSingularityWorkshop.* namespace.

The work spans projects including:

FSM_API
FSM_COS
MicroBundleDomain
TheSingularityWorkshop.Renderer
ProtocolAI
GrammarAI
raWWar
AnyApp
WebPage

The common philosophy is to build small, composable foundations that can be used independently rather than forcing developers into a single monolithic framework.

About Trent Best

Trent Best is the founder of The Singularity Workshop, an independent software R&D firm focused on architecting the future of computation through optimization and modular systems design.

His background spans software development, systems engineering, game development, VDC/BIM automation, C#, finite state machines, rendering architecture, and AI integration.

Through The Singularity Workshop, he is building a growing ecosystem of computational primitives designed to reduce unnecessary complexity and give developers more direct control over how their systems execute.

Developer Stories at CoderLegion

Developer Stories is a CoderLegion series featuring real developers, their journeys, the ideas they pursue, the systems they build, and the lessons they learn along the way.

Trent's story is ultimately about a question that sits underneath almost every software system:

What work actually needs to happen?

From digital logic and finite state machines to AI and observer-relative computation, his work explores what happens when a developer keeps asking that question — and refuses to accept unnecessary computation as inevitable.

Interview & Story by Mehadi Hasan

CoderLegion Community & Editorial Team

Design Is More Than Decoration — Joseph Salaki’s Developer Journey

Mon, 05 Oct 2026 01:34:59 +0000

For Joseph Salaki, frontend development is not simply about turning designs into code. It is about understanding the purpose behind every visual decision and ensuring that design, functionality, and technology work together.

A Visual Designer and Frontend Developer based in Abuja, Nigeria, Joseph is the founder of Joemetry, where he works across brand identity systems, visual design, and digital experiences.

His approach is distinctive: he designs layouts with millimeter precision before writing a single line of CSS.

In this Developer Story, Joseph shares how his journey from visual design into frontend development shaped his engineering philosophy, why he believes branding is structural rather than decorative, and how he hopes to bridge creative design and technical execution.

Interview & Story by Mehadi Hasan
CoderLegion Community & Editorial Team

Where Design and Technology Meet

Joseph's journey began on the visual side while learning at a walk-in design studio.

Early on, he became fascinated by an issue he noticed in the design process: many people were creating visuals without clear reasoning or intentionality.

He was often frustrated by designs that focused on superficial visual expectations rather than solving an underlying brand problem.

That observation shaped his interest in design as a strategic discipline.

For Joseph, a design should not exist simply because it looks attractive. It should communicate something, solve a problem, and serve a purpose.

Frontend development eventually became a natural extension of that philosophy.

Instead of viewing code as a separate technical skill, he began seeing it as another practical tool for executing strategic solutions.

He is also exploring other creative mediums because he believes problems can be approached more holistically when design and technology are not treated as isolated disciplines.

From Visual Design to Frontend Engineering

Developing both skills together meant learning how to bridge the way a visual design tool represents a layout with the way a browser actually renders it.

Joseph's background in vector design and grid systems directly influences how he approaches CSS and component structure.

Rather than applying arbitrary styling values, he treats code as an extension of a design system.

His approach includes:

Semantic design tokens
Modular CSS variables
Mathematical spacing systems
Structured component architecture
Consistent visual rules

The goal is to make the underlying code reflect the logic of the original design.

This is an important distinction in his philosophy: the implementation should not merely resemble the design visually. It should preserve the system and reasoning behind it.

Building Joemetry With Purpose

Joseph founded Joemetry to create brands with clear purpose, strong structure, and thoughtful reasoning behind every decision.

He wanted to move away from what he calls design for design's sake.

For him, a visual identity should not be a collection of disconnected assets. It should be a coherent system in which every line, layout, and piece of code supports a specific strategic goal.

Through Joemetry, he works across:

Brand identity systems
Logo development
Print graphics
Responsive UI/UX interfaces
Digital experiences

His ambition is to make design decisions more meaningful for the businesses and users they serve.

Branding Is Not Just a Logo and a Colour Palette

One of Joseph's strongest opinions concerns how developers approach branding.

He believes many developers treat branding as an afterthought: a logo, a primary hex colour, and a font selected from Google Fonts.

But a complete brand identity is much broader.

It includes typography hierarchies, spatial rhythm, interaction patterns, visual consistency, and rules that govern how the entire experience behaves.

When implementation ignores those underlying rules, the result can feel fragmented even if the technical logic is clean.

Joseph expresses this idea through a simple principle:

Branding is not decoration; it is the structural interface through which users experience your software.

This perspective connects visual design directly to frontend architecture.

A product's identity should influence how its components are structured, how users navigate it, and how the interface communicates.

Designing With Millimeter Precision Before CSS

Joseph's profile includes an unusual detail: he designs visual layouts with millimeter precision before touching CSS.

His process begins with intent and structure rather than software implementation.

First, he establishes:

Content hierarchy
Typography scale
Spatial grids
Optical alignment
Overall layout balance

He focuses on getting the visual system right before moving into code.

Once the design is established, he maps its rules into CSS custom properties and design tokens.

From there, he develops the component architecture, ensuring that spacing, margins, and responsive breakpoints reflect the original grid system.

This approach helps reduce arbitrary styling decisions and creates a closer relationship between design intent and implementation.

For Joseph, precision is not simply about making a page look aligned. It is about creating a system that can remain consistent as the interface grows.

The Challenge of Finding the Right Audience

Building Joemetry has not been without challenges.

Joseph identifies two major difficulties: reaching the right audience in a saturated market and navigating the personal friction that can arise from one's immediate environment while learning and building.

His response has been to develop stronger internal conviction.

Rather than becoming distracted by market noise, he focuses on positioning, refining his craft, and communicating the value behind his work.

He believes clients looking for high-value, strategic execution will recognise depth beyond surface-level presentation.

That belief continues to guide how he approaches the studio and its future.

Why Modern CSS Changed His Workflow

Among the frontend technologies he has explored, modern CSS layout capabilities have had a particularly significant impact.

CSS Grid, Flexbox, subgrid, and modern CSS variables changed how he approaches implementation.

He has moved away from relying heavily on utility frameworks and increasingly uses native CSS features to build interfaces that are lighter, precise, and easier to maintain.

Semantic design tokens also play an important role.

Instead of tying styles to arbitrary values, he prefers naming that reflects the purpose of a design decision.

This makes the code more closely aligned with the design system and helps preserve consistency across components.

His philosophy is not about rejecting frameworks entirely. It is about understanding the capabilities of the platform and choosing the tools that best serve the intended result.

Visual Quality Must Never Compromise Usability

For Joseph, a visually impressive interface is not successful if it becomes difficult to use.

A complex animation may look attractive, but it is not worthwhile if it damages performance or breaks keyboard navigation.

He approaches this balance by establishing performance budgets and semantic HTML foundations early in development.

Once the DOM structure is accessible and the CSS execution remains lean, richer interactions and visual details can be introduced without sacrificing the experience.

This reflects his broader belief that design and engineering should reinforce each other.

Accessibility, performance, and visual quality are not competing objectives that must always be traded against one another. They should be considered together from the beginning.

Building His Own Platform as a Client Project

One project Joseph is particularly proud of is his custom agency platform, byJoemetry.com.

He sees it as more than a portfolio website.

It is a practical demonstration of how brand identity, custom CSS token architecture, and performance can come together in a real digital experience.

Building his own platform also taught him something important:

Your own platform should be treated as your most demanding client project.

It provides an opportunity to apply the same level of strategic thinking and execution that he would bring to a client's work.

Rather than merely describing his capabilities, the platform allows the work itself to demonstrate them.

The Biggest Misconception About Frontend Development

When Joseph started learning frontend development, he believed the discipline was largely about memorising syntax and framework APIs.

His understanding has changed considerably.

He now sees frontend engineering as fundamentally involving:

System architecture
State management
User psychology
User-flow structure
DOM rendering
Maintainable component systems

Syntax and frameworks will continue to evolve, but these underlying concepts remain valuable.

For Joseph, becoming a stronger developer means learning how to structure systems and understand users, not simply accumulating knowledge of tools.

Why Developer Platforms Need Design Character

Joseph has also written about why developer community interfaces can feel uninspired.

He believes many platforms prioritise raw utility at the expense of visual character and emotional resonance.

There is an assumption that developers only care about dark mode, monospaced code blocks, and plain data tables.

Joseph challenges that assumption.

Developers are people who appreciate thoughtful design just like anyone else.

A platform that combines strong functionality with a distinctive visual personality can become more than a utility. It can become a community people genuinely enjoy spending time in.

This is particularly relevant to his own experience with CoderLegion.

He describes the platform as a refreshing environment: focused, technical, and collaborative, without the noise and endless clickbait he associates with larger developer networks.

His hope is to see CoderLegion become a leading home for high-craft developers, where technical depth and design excellence receive equal recognition.

Looking Ahead: Growing Joemetry

Over the next few years, Joseph wants to position Joemetry as a premier design and digital experience studio.

His intended audience includes high-growth international businesses, technology startups, and brands seeking substantial digital transformation.

Alongside growing the studio, he plans to continue publishing technical breakdowns and design system frameworks.

He wants to help other developers understand the connection between creative design and frontend engineering.

For Joseph, sharing the reasoning behind his work is as important as showing the finished result.

Advice: Stop Treating Design and Code as Separate Worlds

Joseph's advice to people developing both creative and technical skills is to build strong fundamentals in each discipline before becoming distracted by complex tools.

On the design side, he recommends learning:

Grid mathematics
Colour theory
Typography hierarchy

On the technical side, he emphasises:

Semantic HTML
CSS architecture
Core JavaScript

The breakthrough comes when developers begin to understand that CSS properties are design rules expressed through code.

Once that connection becomes clear, design and frontend development no longer feel like two unrelated skills.

They become parts of one creative and engineering process.

The Developer Behind the Design System

Joseph Salaki's journey illustrates a different way of thinking about frontend development.

For him, the interface is not the final decorative layer placed on top of software. It is a structured experience shaped by brand identity, visual hierarchy, interaction, accessibility, and technical decisions.

His work through Joemetry reflects that belief: design with intention, build with structure, and make every decision serve a purpose.

As he continues developing the studio and sharing his ideas, his goal remains to bridge the gap between creative design and frontend engineering.

Because a well-designed digital experience should not only look right.

It should work right, feel coherent, and communicate with purpose.

About Joseph Salaki

Joseph Salaki is a Visual Designer and Frontend Developer based in Abuja, Nigeria, and the founder of Joemetry.

His work focuses on brand identity systems, logo design, UI/UX, responsive digital experiences, and frontend development.

His technical and creative toolkit includes HTML5, CSS3, JavaScript, CorelDRAW, Framer, Netlify, Git, and design system practices.

Follow Joseph's work through his CoderLegion profile and byJoemetry.com.

Developer Stories at CoderLegion

Developer Stories is a CoderLegion series celebrating real developers, their journeys, the ideas they pursue, the challenges they face, and the lessons they learn along the way.

Joseph's story is a reminder that strong software experiences are built when design thinking and engineering work together.

Interview & Story by Mehadi Hasan

CoderLegion Community & Editorial Team

This story is based on Joseph Salaki's written interview responses and profile information.

Building a Sovereign AI Colony From a Smartphone: Cristhiam Hernández’s Developer Journey

Mon, 05 Oct 2026 01:20:32 +0000

Building a Sovereign AI Colony From a Smartphone: Cristhiam Hernández’s Developer Journey

Real developers. Real journeys. Real ideas.

What if a smartphone could become the starting point for an entire distributed AI ecosystem? For Cristhiam Leonardo Hernández Quiñonez (CLHQ), that question became the foundation of HormigasAIS — an ambitious project exploring sovereign edge computing, distributed AI agents, lightweight communication protocols, and a different way of integrating humans into autonomous systems.

His journey began in graphic design and digital marketing, moved through experiments with servers and automation, and eventually led to developing an ecosystem using a Samsung A16 smartphone and Termux.

Interview & Story by Mehadi Hasan
CoderLegion Community & Editorial Team

From Digital Marketing to Distributed Systems

Cristhiam's journey into technology did not begin with a conventional software engineering career.

His early work was in graphic design and digital marketing, particularly brand development and positioning. He used tools such as GitHub, n8n, Slack, Discord, and automation workflows to coordinate teams, measure performance, and make projects more efficient.

But as he worked with these systems, he noticed a recurring problem: too much dependence on third-party platforms and centralised infrastructure.

The more he explored these architectures, the more interested he became in building infrastructure of his own.

In 2023, he began studying distributed systems and communication between autonomous agents.

Research into biological swarms, particularly the coordination of ant colonies and birds without central leadership, captured his imagination.

He became fascinated by the possibility that software agents could coordinate through lightweight communication and collective agreement rather than depending entirely on a central controller.

He began building experimental environments, connecting servers, and testing communication methods.

Those early experiments eventually became the foundation of HormigasAIS.

The Idea Behind HormigasAIS

The name HormigasAIS combines Hormigas, Spanish for ants, with AIS, meaning Artificial Intelligence System.

The inspiration came from research into ant colonies and their ability to coordinate complex activity without a conventional hierarchy.

Cristhiam was particularly interested in the idea of biological pheromones: signals that allow members of a colony to communicate information and coordinate behaviour.

He saw an analogy for distributed computing.

What if AI agents could exchange lightweight digital signals, share knowledge, and coordinate tasks without requiring every decision to pass through a central system?

That idea became the conceptual foundation of HormigasAIS.

However, the project is not intended simply to replace cloud infrastructure.

Cristhiam describes it as a hybrid and sovereign alternative that can work alongside existing systems.

His concerns include centralised dependencies, closed models, communication costs, and the possibility of excluding human governance from autonomous systems.

For him, the objective is to give developers and organisations greater control over where computation takes place, how agents communicate, and what rules govern their behaviour.

What Does Sovereign Computing Actually Mean?

The word sovereign appears throughout Cristhiam's work.

But he does not use it merely to describe where data is stored.

For him, sovereignty is fundamentally about decision-making and governance.

A genuinely sovereign system should allow agents to operate under clearly defined local contracts and deterministic rules, rather than depending entirely on the availability or approval of an external platform.

That can mean greater operational autonomy, privacy, and resilience.

If an external network becomes unavailable or a third-party platform changes its policies, locally operating components should still be able to perform their defined responsibilities.

His approach is not about rejecting every existing technology.

Instead, it is about creating systems that retain meaningful control over their own operations while remaining capable of communicating with the wider technological ecosystem.

Building an AI Ecosystem on a Samsung A16

One of the most unusual aspects of Cristhiam's journey is his development environment.

Rather than beginning with a conventional workstation, he started experimenting with Android and Termux.

The original motivation came from a project involving solar energy, thermal sensors, and monitoring temperature variations associated with geographic coordinates.

He needed local, autonomous measurements.

Android and Termux provided a practical starting point.

During those experiments, he began to see a smartphone differently.

It was not simply a communication device. It could also function as a compact, energy-efficient edge-computing node.

His early lightweight agents became known as mosquito agents.

The experience was not easy.

He had to work around memory constraints, restricted environments, mobile scripting, and the challenge of connecting different languages and communication channels.

But those limitations became part of the learning process.

Instead of treating hardware restrictions only as obstacles, he began using them to rethink architecture and efficiency.

That work contributed to the development of the HormigasAIS Binary Language, or LBH, and its evolution, M2M-LBH.

The objective was to reduce communication overhead while preserving the ability of autonomous agents to coordinate and operate across different environments.

LBH: A Lightweight Communication Foundation

The Lenguaje Binario HormigasAIS, known as LBH, is a central part of the ecosystem's proposed communication architecture.

Cristhiam describes its purpose as translating the biological inspiration behind HormigasAIS into a practical communication mechanism for software agents.

He identifies three important principles.

Agent identity and protocol fidelity

Each agent is designed around an internal identity, contract, and adherence to the LBH communication language.

The intention is to preserve consistent behaviour and communication across the colony.

Testing before deployment

Cristhiam describes a testing environment called the polígono de tiro, or testing range.

Before an agent is allowed to perform tasks in a real environment, it is subjected to unexpected commands and simulated failures.

The purpose is to examine whether it interprets the protocol correctly and can handle difficult operating conditions.

Knowledge transfer through digital pheromones

One of the more interesting ideas is that agents should be able to request and receive knowledge without transferring large amounts of infrastructure or data.

If an agent encounters an unfamiliar situation, a lightweight request can be sent through LBH.

Another agent can process the request and return a synthesised response.

Cristhiam describes this as transferring knowledge rather than the weight of the infrastructure.

It is an approach intended to be particularly useful in environments where bandwidth, memory, or connectivity is limited.

Moving Computation Closer to the Edge

For Cristhiam, edge computing changes the relationship between a developer and the infrastructure running their software.

Instead of relying entirely on a central cloud service, developers can design and manage agents closer to where their work is performed.

Within his proposed architecture, agents can be created, tested, assigned rules, activated, isolated, or shut down locally.

This also introduces challenges.

Distributed nodes may experience intermittent connectivity, synchronisation problems, or unexpected failures.

Cristhiam's approach is to use lightweight, deterministic communication so that agents can continue their defined local operations while disconnected and reconnect with the wider system when connectivity returns.

The ambition is not to remove the need for networking, but to reduce the extent to which every operation depends on a continuously available central connection.

Autonomous AI Needs More Than Autonomy

One of the most distinctive aspects of HormigasAIS is its emphasis on human participation.

Cristhiam believes that distributed systems can unintentionally recreate hierarchies even when their stated purpose is decentralisation.

This led him to question his own position as the founder.

If a system is genuinely designed around collective consensus, should its creator remain an external authority who controls everything?

His answer is no.

He expresses the principle through the phrase:

“El humano es una pieza inmersa, no externa.”

In English:

“The human is an embedded component, not an external one.”

Within the HormigasAIS concept, the .human agent is intended to participate as a recognised component of the protocol rather than exist solely as an outside supervisor.

Cristhiam sees the appropriate human role as negotiation rather than imposition.

Agents may have operational autonomy, but critical decisions should remain bounded by clear rules and human governance.

This philosophy is reflected in the project's broader interest in consensus, deterministic protocols, and distributed decision-making.

Security and verification are central to Cristhiam's architecture.

He distinguishes between mechanisms used for internal node communication and the process used for public evidence verification.

HMAC-SHA256 for internal node-to-node communication

Within trusted nodes, HormigasAIS uses HMAC-SHA256 to authenticate messages using a shared secret.

If a message is altered, its authentication check will fail.

This is intended to protect communication integrity between nodes that already share trust.

Public verification through SHA-256 seals

For public verification, HormigasAIS uses a public seal registry.

Users can calculate the local SHA-256 hash of a file and compare that hash against the corresponding seal in the public registry.

The files themselves do not need to be uploaded to the registry for this verification process.

This provides a way for users to check whether a local artifact matches a published seal.

At this initial stage, however, the public registry is operated by HormigasAIS itself. That means verification of a published seal necessarily involves trusting the registry operator.

A sample seal, CLHQ-HINN9XSU, can be checked through the Verificar section of hormigasais.com.

The project's Evidence Repository documents the evidence and audit steps used for the verification process.

But Cristhiam is careful about what a valid seal proves.

A valid cryptographic seal does not establish that the underlying content is factually correct or that an AI agent reasoned properly.

It establishes that the local artifact matches the published SHA-256 hash associated with that seal.

That distinction is important.

His broader philosophy is that users should not have to rely solely on the developer's word.

They should have tools to independently check the integrity of digital evidence while also understanding what that verification does — and does not — prove.

Specifications, Code, and the Open-Source Model

Cristhiam's approach to publishing HormigasAIS materials is based on making specifications, implementations, and evidence available under clearly defined project-specific terms.

Rather than describing the entire project generically as “open source,” the different components use their respective licensing models.

The LBH specifications (lbh-spec) are published under CC BY 4.0, allowing the specification material to be shared and reused under the terms of that license.

The xoxo-lbh-adapter is published as source-available under the Business Source License 1.1 (BSL 1.1).

This distinction is important because availability of source code does not automatically mean that every component is licensed as conventional open-source software.

For Cristhiam, publishing the technical materials allows other developers to inspect the work, question the assumptions, identify weaknesses, and understand how the different pieces are intended to work.

He believes that technical knowledge grows through different perspectives.

A correction or criticism can reveal something the original developer could not see alone.

For him, public development is an opportunity to make the project stronger while giving others a starting point for their own experiments.

Design Inspirations and External Research

Some of the ideas surrounding HormigasAIS are influenced by research and engineering approaches outside the project itself.

Cristhiam draws inspiration from biological systems such as ant colonies and other collective behaviours when thinking about decentralised coordination.

He has also considered ideas associated with academic research and engineering work in areas such as distributed systems, edge optimisation, and autonomous coordination.

These references should be understood as theoretical or design inspirations, rather than claims of formal academic co-authorship, institutional partnership, or direct integration with those external projects.

The distinction matters because HormigasAIS is an evolving independent project, and its own implementations and specifications should be evaluated on their own evidence.

What Constraints Taught Him

Cristhiam does not view limited hardware as an unusual or purely negative condition.

He sees constraints as opportunities to create.

He often looks to the history of Linux as an example of how systems can grow from restricted beginnings.

Working from a smartphone forced him to confront memory, performance, connectivity, and efficiency directly.

He compares this experience to deliberately testing AI agents under adverse conditions.

A difficult environment reveals whether an idea is genuinely robust or whether it only appears to work because abundant resources conceal its weaknesses.

The constraints became a kind of stress test for his own engineering decisions.

They pushed him to ask whether each architectural choice was necessary, efficient, and resilient.

The Hardest Challenge Was Not the Code

One of Cristhiam's most important lessons came from considering the bus factor, sometimes called the truck factor.

It describes the risk that a project depends so heavily on one person that it could stop progressing if that person becomes unavailable.

As the solo founder of HormigasAIS, Cristhiam realised that this was not an abstract concern.

It was his own project.

He began making portable records, backups, and critical knowledge more accessible to other members of the team.

He did not stop leading the project from his Samsung A16.

Instead, he recognised that the long-term continuity of an ecosystem should not depend entirely on one individual.

The lesson he carries forward is simple:

We are not an island.

An idea may begin with one person's curiosity and determination, but it needs other people if it is to continue growing beyond its original creator.

From a Phone-Based Experiment to an Institutional Project

HormigasAIS is now moving beyond its technical foundations.

Cristhiam has developed KREA, a project data room intended for accelerators, investors, and potential customers.

It brings together the project's problem statement, proposed solution, architecture, technical evidence, target market, business model, roadmap, and intended social impact.

It also includes presentation materials and a cryptographically sealed evidence repository with public verification still being completed.

For Cristhiam, this represents a transition.

The work that began as experiments on a smartphone in San Miguel is being translated into a structure that external organisations can examine and evaluate.

His longer-term ambition is for LBH to demonstrate how human participation can be integrated directly into distributed intelligent systems.

He hopes the underlying ideas can be adapted to other markets where organisations need their own AI agents to operate under their own control.

From Idea to Evidence: The Traceability Matrix

As HormigasAIS has evolved, Cristhiam has also worked to make the relationship between the project's vision and its technical implementation easier to understand.

A public Traceability Matrix has been created in the Ants-Legion repository.

The matrix maps the interview and project material through an Evolution Rule:

Idea → Concept → Specification → Implementation → Test → Evidence

This distinction is important because not every idea discussed in the project represents active production code.

The matrix is intended to make it easier to distinguish between the project's vision, formal specifications, implementations, tests, and available evidence.

The repository also contains the project's evidence documentation and audit material.

Technical Note

This interview is backed by a public Traceability Matrix and Evidence Repository at github.com/Thrumanshow/Ants-Legion.

Advice to Developers: Start Before You Have the Whole Plan

Cristhiam's advice to developers interested in distributed systems, edge computing, AI agents, or protocol design is not to wait until every architectural detail is understood.

He believes clarity emerges through building.

HormigasAIS itself began with a small idea and 14 lines of notes associated with .human.

Those original notes were written in a physical notebook and labelled .human.

What started as an experiment gradually developed into a much larger vision.

He also believes creativity should not be driven by ego.

The important thing is to pursue the idea you genuinely want to build, remain open to correction, and allow the work to evolve.

If he could speak to his earlier self, he would tell him not to abandon those first notes.

He would remind himself that the small .human concept could eventually become an agent within a much larger protocol.

His closing advice is particularly fitting:

“Recordá tener siempre los pies en la tierra y el corazón en las estrellas.”

Keep your feet on the ground and your heart among the stars.

From 14 Lines to a Distributed AI Vision

Cristhiam Hernández's journey is not simply a story about building AI agents or developing a communication protocol.

It is about questioning assumptions.

Why must intelligent systems depend entirely on centralised infrastructure?

Can a smartphone become a meaningful development and computing environment?

Can autonomous agents operate with clear rules while keeping humans genuinely involved?

And how can developers make their work independently verifiable rather than asking others to trust it blindly?

HormigasAIS is his attempt to explore these questions through a combination of edge computing, lightweight communication, distributed agents, cryptographic verification, and project-specific licensing.

The project continues to evolve, and its broader technical ambitions invite scrutiny, experimentation, and community participation.

But the principle behind its beginnings remains clear: a developer does not need to understand the entire destination before writing the first line.

Sometimes, the first 14 lines are enough to begin a journey.

About Cristhiam Leonardo Hernández Quiñonez

Cristhiam Leonardo Hernández Quiñonez (CLHQ) is the creator of HormigasAIS, an evolving ecosystem exploring sovereign edge computing, distributed AI agents, lightweight communication protocols, and human-centred governance.

His work includes the HormigasAIS Binary Language (LBH), M2M communication, cryptographic evidence, and technical documentation published under project-specific licensing models.

Follow his work through his CoderLegion profile and the HormigasAIS GitHub repository.

Developer Stories at CoderLegion

Developer Stories is a CoderLegion series featuring real developers, their journeys, the ideas they pursue, the challenges they face, and the lessons they learn along the way.

Cristhiam's journey reminds us that meaningful technical exploration can begin outside conventional development environments and grow through curiosity, persistence, experimentation, and a willingness to share the evidence behind the work.

Interview & Story by Mehadi Hasan

CoderLegion Community & Editorial Team

Editorial note: This story is based on Cristhiam's written interview responses and the technical clarifications he provided for this draft. The technical descriptions reflect Cristhiam's account of HormigasAIS, its specifications, implementations, and design goals; they are not an independent technical audit.

Programming Is Magic: Bryan MacLee’s Journey Building scrml

Sun, 04 Oct 2026 22:32:36 +0000

Real developers. Real journeys. Real ideas.

Bryan MacLee is a truck driver specialising in the oil and gas industry, but programming is much more than a hobby for him. Driven by a deep love of JavaScript, frustration with web development's complexity, and an unconventional idea about how software should work, he is building scrml — an open-source compiled language for the web.

Interview & Story by Mehadi Hasan
CoderLegion Community & Editorial Team

It Started With “Hello World”

For Bryan MacLee, the answer to what initially attracted him to programming is surprisingly simple:

“Hello world.”

But explaining why programming became such an important part of his life takes a little longer.

Bryan describes programming as:

“The truest form of magic that we humans have ever created.”

It is a statement he stands by.

For him, programming is a recursively unfolding logic puzzle. You begin with a question, follow the logic, discover another layer, and continue uncovering how things work.

Even when a particular language or technology becomes repetitive, the underlying activity never really loses its appeal.

And that love of solving problems eventually led him somewhere unusual: instead of simply using programming languages, Bryan decided to build one.

A Truck Driver Building a Programming Language

Bryan works as a truck driver specialising in the oil and gas industry.

Outside that professional world, he spends his time exploring programming, JavaScript and the development of scrml.

He doesn't believe in the conventional idea of work-life balance.

As he puts it:

“Work and grow like progression is air. Laugh and love like the world ends tomorrow. To hell with balance.”

His oilfield work and programming are largely separate worlds. He doesn't claim that driving trucks has directly shaped his coding philosophy.

However, his enthusiasm for software and technology sometimes follows him into his day job.

One important difference is that Bryan has the freedom to choose what he works on and when.

He doesn't have a software manager demanding features or deadlines. He can explore ideas because they interest him, without having to turn every experiment into a commercial deliverable.

That freedom has helped him preserve something many developers struggle to maintain: his excitement about programming.

Loving JavaScript, but Disliking How It Handles the Web

Bryan's preferred programming language is JavaScript.

Not TypeScript.

JavaScript.

He loves how quickly he can write code, experiment and see whether an idea works. For prototyping, he considers it an excellent language.

But there has always been something that frustrated him.

JavaScript's role in interacting with the DOM and styling the web can become complicated, especially when building complex reactive components.

Bryan has experienced those frustrations firsthand.

Initially, he tried to solve them by building a library.

But as his ambitions grew, he began considering a framework.

That idea didn't last long either.

He felt frameworks could only go so far because they still operated on top of JavaScript, relying on conventions and abstractions that the underlying language itself didn't understand.

Around the same time, he developed an academic interest in Rust.

He admired its design, despite describing it as a beautifully hideous language.

That exploration prompted a question:

What if he could take some of the ideas he admired and build something around them?

The answer would eventually become scrml.

The Small Frustration That Started scrml

The origin of scrml wasn't a grand plan to create a new programming ecosystem.

It began with a small annoyance.

Bryan was working on a complex function and had written an expression whose result he wanted to reference.

But he couldn't think of a suitable name for a temporary local variable.

He sat staring at the cursor, increasingly frustrated.

Eventually, he typed a generic name and tried to move on.

But the interruption stayed with him.

He wanted to write an expression and reference its last fall-through value without having to invent a name for something that would only be used once.

As Bryan explains:

“I wish I could just write the expression and reference the last ‘fall-through’ value.”

And that was the moment scrml was born.

Not because he wanted to recreate Rust's enums or pattern matching.

Not because JavaScript state management was frustrating, although that was certainly part of his broader motivation.

It began because he wanted to stop naming one-time-use local variables.

Everything else, as he jokes, was a bonus.

What Exactly Is scrml?

scrml is a compiled programming language designed for web development.

It takes .scrml source files and generates HTML, CSS and JavaScript.

But its central idea goes beyond translating one language into another.

A single scrml file brings together:

Markup
Application logic
Styles
SQL

The compiler examines the whole program and determines how its parts relate.

It then separates client-side and server-side responsibilities and generates the necessary connections.

That includes server routes, fetch calls, CSRF handling and reactive dependency tracking.

Bryan wants developers to describe what their application should do without manually writing all the repetitive wiring required to make different parts communicate.

The language also introduces concepts that are central to his design philosophy:

First-class state
Exhaustive enum matching
State-machine constructs
Typed errors
A cohesive syntax across the application

Scrml is built to produce web technologies rather than operate as another framework sitting on top of JavaScript.

That distinction is fundamental to Bryan's vision.

One Language. One Compiler. One Understanding of the Program.

Bryan believes modern web development can become unnecessarily fragmented.

A typical project may involve separate tools for markup, styles, logic, compilation, server communication and other responsibilities.

Each tool sees only part of the source code.

That fragmentation is one of the problems he wants scrml to address.

His philosophy is:

“One walk. One language. One compiler that reads the markup, the logic, the styles and the SQL together, and actually understands how they relate.”

Because the compiler sees the whole program, it can generate connections that developers would otherwise have to create manually.

For example, when an application needs to communicate between the browser and server, scrml can generate the necessary routes, fetch calls and serialization.

Bryan also dislikes what he calls leaky abstractions and coloured functions.

His goal is to move responsibility into the language and compiler rather than leaving developers to manage conventions across multiple layers.

In his view, if the compiler understands the program, entire categories of mistakes can become impossible to express.

Making State a First-Class Concept

One of the ideas that influenced scrml was Bryan's exploration of state in functional programming.

He encountered a conventional definition of state as stored data, variables and conditions remembered by a program at a particular moment.

He wasn't satisfied with that explanation.

Instead, he developed his own description:

“A snap-shot of a data set, at the moment of observation.”

That led him to question why programming languages commonly provide logic and type systems but don't necessarily offer state as a first-class language feature.

Scrml incorporates state directly into its design.

For example, a state cell can be declared using a tag-like form and then referenced through the language's state syntax.

The compiler can track dependencies and manage the connections required for reactive behaviour.

Bryan is also working on stronger lifecycle and validation contracts, along with new approaches to state declarations.

These are part of his broader ambition to make the compiler responsible for more of the correctness guarantees.

Why Bryan Is So Serious About Dependencies

Bryan has a strong preference for minimal external dependencies.

He describes himself as someone who likes to build things himself and has a visceral dislike of not understanding the code in his own source tree.

He also sees automatically updating dependencies as a potential security problem.

That doesn't mean scrml prohibits importing external code.

Instead, Bryan wants imported code to enter through an explicit capability-gated mechanism.

His underlying principle is that a program should retain ownership and awareness of the code it uses.

He is particularly critical of developers introducing dependencies for trivial functionality.

His example is isEven.

For something that can be expressed through a simple mathematical operation, he questions why a developer would need to search the web for an external package.

For Bryan, fewer dependencies can encourage developers to understand what their applications actually contain.

Scrml includes a standard library intended to cover most common web application needs.

The goal isn't to eliminate useful code sharing, but to make dependencies more intentional.

“Assume the Compiler Works Perfectly”

Bryan's article Assume the compiler works perfectly addresses a particular challenge he has encountered when introducing scrml to other developers.

A couple of people had tried it and responded that nothing worked.

Bryan understands that this is a fair reaction, particularly when working with a new compiler.

But he wanted to ask a different question.

What if the compiler were already finished and worked perfectly?

Would developers actually want to write applications in scrml?

That is the question behind the article.

He isn't asking people to ignore technical problems or pretend the implementation is complete.

He wants to separate two questions:

Is the underlying language idea appealing?
Is the current compiler implementation mature enough to deliver it?

Building a compiler is a substantial undertaking, and Bryan knows the implementation still has work ahead.

But he wants feedback on the vision itself, not only on the current state of the tooling.

The Current State of scrml

Scrml is open source under the MIT licence.

At the time of Bryan's interview, the compiler was at version 0.8.0, running on Bun, and was not published to npm.

He has also reached an important turning point in its development.

The original TypeScript compiler prototype gradually became the product.

Over time, technical debt accumulated to the point where continuing to extend the existing implementation became increasingly difficult.

Rather than continuing to patch the old structure, Bryan has paused that compiler work and begun building a bootstrap approach.

The current TypeScript compiler is intended to compile a natively written scrml compiler.

In theory, this should help eliminate entire classes of bugs through construction rather than relying only on testing.

He is also working on standalone left-hand-side state declarations, as well as stronger lifecycle and validation rules.

It is a significant undertaking, but one that reflects his willingness to rethink the foundations rather than keep extending an architecture that no longer serves the language's direction.

Why He Still Loves JavaScript but Doesn't Want to Write It

Bryan's relationship with JavaScript is unusual.

He genuinely loves the language.

He appreciates its simplicity, speed and ability to support rapid experimentation.

But building scrml has changed where his excitement now lies.

He says that writing JavaScript has lost much of its appeal compared with the anticipation of writing applications in his own language.

He isn't less interested in programming.

His excitement has shifted from using existing tools toward creating a different way to work.

That enthusiasm is also what keeps him moving when scrml becomes difficult.

There are naturally moments of discouragement during a project of this size.

But the thought of eventually using the language he is building is a powerful motivator.

He intends to continue regardless of what others think.

Building a Language for More Than Himself

Bryan recognises that he doesn't need a production-level compiler simply to enjoy experimenting with his own ideas.

He could build a much smaller tool and still benefit from it personally.

But that's not the entire reason he's building scrml.

He believes the ideas have value for other developers.

He wants people to use it, question it, debate its assumptions and help improve it.

Scrml is released under an open-source MIT licence, and Bryan doesn't see it as something that belongs exclusively to him.

His ambition is to make it a shared project.

“I don't view this as ‘my’ language. MIT, open source, I gave it to the world.”

For Bryan, the value of scrml is directly connected to the number of people willing to engage seriously with its ideas.

He wants developers to challenge his assumptions and help make the language better.

What Would Success Look Like?

Bryan's definition of success is refreshingly modest.

He doesn't need thousands of users or a large company to feel that the project has been worthwhile.

His ideal milestone is simply hearing from one real developer who enjoys using scrml.

As he puts it, success would be receiving an email or message from someone saying:

“I enjoy writing scrml.”

That alone would make the work worthwhile.

He hopes scrml may eventually stand alongside other interesting programming languages, but he doesn't measure its value only through popularity.

The immediate goal is to build something genuinely useful and invite other developers to help shape it.

The Freedom to Keep Programming for the Right Reasons

One of the most interesting parts of Bryan's story is that he hasn't followed the conventional professional software-development route.

He isn't building scrml because an employer assigned it to him.

He isn't chasing a job title or trying to meet a commercial delivery deadline.

He codes when and what he wants to.

That freedom has helped him avoid becoming burned out or jaded about programming.

He also doesn't force himself to read documentation or follow technologies that don't interest him.

Instead, he can focus deeply on the ideas that capture his attention.

That doesn't mean the journey is free of frustration.

Building a programming language is difficult, and Bryan is candid about the challenges.

But his motivation comes from genuine curiosity rather than external pressure.

It is a reminder that unconventional paths can provide their own advantages.

Advice for Developers With Unusual Ideas

Bryan's advice to someone with an unconventional programming idea is direct:

“If you have an idea, and you think it is worth attention. Scream it from the rooftops.”

He doesn't believe that a lack of a traditional background, job title or established resources should automatically stop someone from pursuing an interesting idea.

Ideas should be exposed to discussion.

They should be questioned.

They should be challenged.

And sometimes they should be corrected.

Bryan sees correction as an opportunity rather than something to fear.

The worst outcome, in his view, is that someone points out where your assumptions are wrong.

That is far better than allowing insecurity to prevent you from trying.

From Truck Driver to Language Creator

Bryan MacLee's journey is not a conventional story about becoming a software engineer and climbing a corporate career ladder.

It is about someone who loves programming enough to question the tools he uses and attempt to build something different.

His journey began with JavaScript, frustration with web development's complexity, curiosity about language design and one seemingly insignificant problem: naming a temporary variable.

That small frustration grew into scrml, a compiled language with ambitions around state, type safety, application structure and compiler-driven correctness.

The implementation is still evolving.

The architecture is being reconsidered.

And the project needs developers willing to test, question and contribute.

But Bryan's motivation remains clear.

He isn't building scrml simply to prove that he can build a programming language.

He's building it because he believes programming can be made better — and because the act of creating software is, to him, one of the most remarkable things humans have ever learned to do.

About Bryan MacLee

Bryan MacLee is a truck driver specialising in the oil and gas industry and an independent programming-language developer.

He is the creator of scrml, an open-source compiled language for web development that generates HTML, CSS and JavaScript.

His preferred technologies include JavaScript, HTML and CSS, and his interests include language design, compiler development, state management and reducing unnecessary complexity in web development.

Connect with Bryan MacLee on CoderLegion.

Bryan's story is a reminder that a good idea doesn't need to come from a conventional career path.

Sometimes it starts with a simple frustration — and the willingness to ask:

Interview & Story by Mehadi Hasan

CoderLegion Community & Editorial Team

From a VIC-20 to Code and Sea — Brent Vardy’s Developer Journey

Mon, 28 Sep 2026 08:27:09 +0000

Real developers. Real journeys. Real lessons.

Brent Vardy has been writing software for more than four decades. His journey started with a Commodore VIC-20 and 5KB of RAM, continued through decades of professional software development, and has now led him toward a very different goal: building his own products as a solo indie founder.

Interview & Story by Mehadi Hasan

It Started With a Commodore VIC-20

Brent Vardy's programming journey began around 45 years ago.

In late 1981, when he was nine years old, he received a Commodore VIC-20 home computer.

There wasn't much software available, and what was available was too expensive for a nine-year-old.

But Brent already had an interest in something that would eventually shape his approach to software: adventure books.

These weren't ordinary books. Readers navigated them by answering questions at the bottom of each page, with their answers determining which page they should read next.

So Brent decided to recreate that experience on his VIC-20.

The computer came with Commodore BASIC 2.0, and he used it to turn some of his adventure books into interactive games.

All of this ran in just 5KB of RAM.

There was no GitHub.

No cloud storage.

No source control.

Brent stored his code on a tape recorder through a serial cable.

And sometimes, he lost the code and had to type everything again from scratch.

That early experience taught him something that would stay with him for decades: he loved creating small, useful applications.

From School Projects to Building Useful Software

After the VIC-20 came a Commodore 64 and then an Acorn Electron.

Brent was also part of one of the first classes at his school to be offered Computer Studies.

Around the same time, CD players were becoming popular in the UK.

His father was an electrical engineer and music lover, so Brent decided to build a school project around CD players.

He created an application that stored information about the different manufacturers and models available at the time, including specifications and prices.

He didn't call it a database.

Technically, it was an application with all the information hardcoded into the program and loaded into memory.

If a new CD player appeared, Brent had to modify the source code, save it back to tape and reload the application.

But the important part wasn't the architecture.

It was the experience of building something useful.

“Building this hooked me and started my love of creating small useful applications.”

That idea would eventually become a recurring theme throughout Brent's career.

Decades of Building and Experimenting

Brent's path wasn't a straight line toward entrepreneurship.

Over the years, he worked on many side projects with friends and colleagues.

Not all of them worked.

In fact, Brent openly describes having built several products that ultimately failed.

But the failures didn't remove his desire to build something of his own.

They became part of the learning process.

He continued experimenting, learning new technologies and creating software for himself, his family, friends and colleagues.

Some projects were practical.

Others were simply for fun.

The important thing was that he enjoyed the process of building.

From Corporate Developer to Indie Founder

The idea of seriously building his own products began to take shape in 2026.

Brent had been thinking about semi-retirement and wanted to create something that could support that lifestyle without requiring him to access his pension early.

He had already been working on a meditation application for himself.

Instead of keeping it as another personal project, he decided to see whether it could become his first product.

This time, however, he approached things differently.

He registered a company first.

That company became Code and Sea.

The name reflects a personal goal shared by Brent and his wife: eventually moving to the coast and creating a lifestyle with more freedom and flexibility.

Code and Sea is his attempt to build toward that future through software.

When Building Became More Personal

For Brent, becoming an indie developer isn't simply about escaping a corporate job.

It's about gaining control over how he spends his time and energy.

After many years in a corporate environment, he wanted greater flexibility to decide what he worked on, when he worked and which projects deserved his attention.

That became particularly important because managing his available energy is a significant part of his day-to-day life.

Building software can be demanding, but Brent also describes coding as an escape.

When his physical energy is low but his mind is clear, writing code gives him a way to solve problems, create things and feel productive at his own pace.

That has also influenced how he thinks about features.

He has become much more selective about what he builds.

And that constraint has turned out to be useful.

The Push Into Indie Development

Brent had spent 28 years with his previous company when he was told in September 2026 that his role would end at the end of the month.

It was a shock.

There was uncertainty about what would happen next.

But Brent doesn't describe the experience with bitterness.

Instead, after accepting the decision, he began seeing it as the push he needed.

He had spent 28 years learning, developing skills and building relationships.

Now he had an opportunity to finally pursue something he had wanted to do for years.

From October 1, Brent would have much more control over the decisions and direction he took.

Successful or not.

Why Code and Sea Exists

Code and Sea isn't being built around the idea of creating the next huge technology company.

Brent's motivation is much more personal.

He wants to build products he enjoys, generate enough revenue to support his lifestyle and eventually move toward a slower life by the sea.

He is also building products based on problems he personally experiences.

That philosophy is visible in his growing backlog of product ideas.

Many of them come from applications he already uses but doesn't completely like.

Sometimes they're too complicated.

Sometimes they include features he doesn't need.

Sometimes they require a subscription for functionality Brent doesn't want.

His response is simple:

Build his own version.

Mantra Meditation Timer: Building What He Actually Needed

One of those ideas became Mantra Meditation Timer.

Brent had been using meditation applications for many years but couldn't find one that worked exactly the way he wanted.

He found many meditation apps distracting.

Notifications.

Social features.

Content feeds.

Recommendations.

Too many things happening when he simply wanted to meditate.

So he built his own.

The goal was intentionally simple:

Open the app.

Start the meditation.

No distractions.

No social feed.

No unnecessary information.

Just the tools needed for his personal practice.

Interestingly, Mantra Timer wasn't actually Brent's first attempt.

It was the third meditation application he had built.

The first two were more like clones of existing mainstream apps.

Eventually, he realized that copying what other applications were doing wasn't the answer.

He only needed the features that mattered to him.

So he stripped the idea back.

And something unexpected happened.

Other people felt the same way.

When Real Users Changed the Product

Brent initially believed he might be the only person who would use Mantra Timer.

He was fine with that.

Then people started asking to become beta testers.

He created a form on his website.

People signed up.

And the feedback turned out to be extremely valuable.

The experience changed his view of product development.

Real users exposed problems and opportunities that Brent couldn't have discovered simply by building alone.

His advice to founders is straightforward:

Get real users involved early.

Feedback can be uncomfortable.

People will criticize things you've spent hours building.

But that criticism can also produce a much better product.

For Brent, the beta programme became one of the most important parts of getting Mantra Timer ready for release.

Learning to Ship Before Everything Is Perfect

One of Brent's biggest lessons from building Mantra Timer was that building the product isn't necessarily the hardest part.

Shipping is.

“Building the product is easy, having the confidence and knowing when to ship is hard.”

Having around 15 active beta testers gave him confidence that the product was solving a real problem.

It also gave him people who were using the application regularly and could identify issues before public release.

That experience changed his attitude toward perfection.

Brent became more comfortable sharing a product earlier, even if it wasn't completely polished.

If the product is usable and testers understand that they're using an early version, polish can come later.

The important thing is to discover whether the product actually solves the problem.

The Lesson From Failed Projects

Brent has built several projects over the years that never became successful products.

Two examples he mentions are LocationCounts and UKMapfinder.

In both cases, he started with a problem he wanted to solve.

Then something happened that developers know very well.

He kept adding features.

The projects became bigger.

The software became more complicated.

But the products weren't being tested with real users.

Eventually, they launched and simply died.

That experience taught Brent something important about product development.

More features don't necessarily make a product better.

In fact, limiting features can be an advantage.

A smaller product is faster to launch, easier to maintain and easier for users to understand.

Choosing Technology Without Chasing Trends

Brent has worked with a remarkably broad range of technologies over the years.

His experience includes:

Swift
SwiftUI
SwiftData
PHP
Laravel
Livewire
TailwindCSS
AlpineJS
Python
Ruby
C
C++
Java
Objective-C
Delphi
Node
Golang
And many others

These days, he generally uses PHP and Laravel for web applications, Python for automation and command-line tools, and Swift for Apple platform development.

But Brent doesn't choose technology simply because it's the newest thing.

He prefers technologies he already knows and trusts.

If his preferred stack can solve the problem, he will usually stick with it.

“My opinion is the final product is more important than the actual stack used.”

It's a practical philosophy developed through decades of software development.

Why Swift and SwiftUI?

Brent particularly enjoys Apple's development ecosystem.

One reason is access to Apple's native APIs.

Instead of depending heavily on third-party plugins, he can work directly with Apple's platform capabilities.

He also appreciates services such as iCloud and Maps, which can be integrated into applications without the same kind of usage-based costs that some third-party platforms introduce.

He likes the documentation and believes native Swift applications can provide a particularly good user experience.

For his current product direction, Swift and SwiftUI make a natural fit.

The Reality of Being a Solo Founder

Being a solo founder means doing much more than writing code.

Development is only one part of the job.

There is:

Product development
Design
Marketing
Distribution
Customer discovery
Testing
Support
Business decisions

Brent is comfortable with most of these areas.

The two areas he says he needs to improve most are design and marketing.

Now that he has more time available, those are areas he plans to focus on.

He also prefers learning and doing things himself rather than immediately outsourcing them.

But he's beginning to recognize that there may be situations where outsourcing is simply the pragmatic choice.

From Developer to Product Builder

Building products for himself and for corporate users was different from building something that strangers are expected to pay for.

When building internal software, there is often an existing specification.

When building a personal project, the requirements can come directly from your own needs.

But when you're asking the public to spend money, every decision becomes more important.

Brent says Mantra Timer taught him to get products in front of users quickly and genuinely listen to what they say.

That represents a significant change in his approach to software.

Instead of spending months trying to make something perfect before showing anyone, he now sees real-world feedback as part of the development process itself.

What Does Success Mean to Brent?

Brent has a realistic definition of success.

He isn't necessarily trying to build a huge company or reach the kind of revenue numbers frequently shared in indie-founder communities.

For him, Code and Sea is about creating a sustainable life around something he enjoys.

If the business eventually generates around £20,000 per year, he would consider that a success.

But the money isn't the only measurement.

Success also means:

Having control over his time
Continuing to build software
Keeping his mind active
Helping and supporting other people
Creating products he enjoys
Building toward a life by the sea

For Brent, the journey matters as much as the destination.

Building in Public Doesn't Automatically Mean Customers

Brent has also learned something important about building in public.

Sharing your work doesn't automatically produce customers.

At least, it hasn't done so for him yet.

But that doesn't mean building in public has been a failure.

Quite the opposite.

It has helped him meet other founders and developers who have become valuable sources of advice, testing, launch support and encouragement.

Running a solo business can be lonely.

Having other people who understand what you're going through can make a significant difference.

Brent particularly values the relationships he's developed with other founders through this process.

Why CoderLegion Matters to Brent

Brent joined CoderLegion because he enjoys seeing what other developers and founders are building.

He also made a conscious decision to support other independent developers whenever possible.

If he needs an application or service, he tries to consider products created by people in similar situations.

His hope is that this kind of support can eventually be paid forward.

He describes CoderLegion as welcoming and appreciates its more down-to-earth atmosphere.

Compared with some other indie communities, he feels CoderLegion is more realistic for developers who are still building their businesses and haven't reached huge recurring revenues.

That's important to him.

He doesn't want unrealistic expectations.

He wants a community where developers can share what they're actually doing.

“I want to stay firmly on the ground and realistic.”

What's Next for Code and Sea?

Brent currently has several products in development.

His immediate focus includes adding additional language support to Mantra Timer and preparing a TestFlight beta for its watchOS version.

He's also continuing work on Tidal Draft, another product based on a problem he personally encountered.

Tidal Draft is intended to provide an alternative to an existing product that Brent uses but feels charges a subscription for functionality he doesn't need.

His version will use a pay-as-you-go model.

He plans to begin inviting people into a private beta and eventually launch Tidal Draft on CoderLegion for users to test.

Beyond that, Brent has a backlog of product ideas he wants to explore.

His goal for the first year is relatively simple:

Release one or two products that generate enough revenue to cover the costs of running Code and Sea.

Then build from there.

One Unexpected Setback

Brent's journey also demonstrates that indie development rarely follows a perfect timeline.

Mantra Timer was originally called Trancendence.

Just hours before the first version received App Store approval, Brent was contacted by a legal firm representing the Maharishi Foundation.

They raised concerns about the app's branding and trademarks.

Brent couldn't afford a legal fight, so he rebranded the application.

The unexpected change took considerably longer than planned.

It's another example of something that doesn't appear in a coding tutorial:

Building a product means dealing with everything around the code as well.

What Brent Would Do Differently

If Brent could go back and change one thing about his indie journey, he wouldn't choose a different programming language or framework.

He would simply start earlier.

And he would release earlier.

His biggest lesson is that waiting until a product is polished can delay the most valuable thing a founder can get:

real user feedback.

“Get it out there as soon as possible to get real user feedback.”

Brent's Advice to Developers Thinking About Going Indie

Brent's advice is practical rather than glamorous.

First, be realistic.

Building your own products is hard.

You will fail.

Probably more than once.

He recommends having a financial cushion — around 12 months if possible — so financial pressure doesn't constantly distract you from building.

He also recommends avoiding the temptation to chase every new technology.

Use proven technologies with strong communities, documentation and available information.

Then get your product into the hands of real users as early as possible.

Find trusted people who will actually test it.

Listen to their feedback.

Use that feedback to determine whether the product is worth continuing.

And don't expect instant traction.

Give the product time.

“If nothing happens immediately keep going, give it a chance before quitting and moving to the next thing.”

From 5KB of RAM to Building His Own Future

Brent's developer journey spans an extraordinary amount of technological change.

He started with a Commodore VIC-20 and 5KB of memory.

He stored code on cassette tape.

He built simple applications because he wanted to make something useful.

Decades later, he's still doing essentially the same thing.

The tools have changed.

The platforms have changed.

The scale has changed.

But the motivation hasn't.

He still enjoys taking an idea, turning it into software and seeing whether someone finds it useful.

The difference now is that he's building toward something much more personal.

Code and Sea isn't simply another software company.

For Brent, it's an attempt to design a different way of working and living — one where he can continue creating software, support himself, help others and eventually build the life he and his wife have imagined by the sea.

And perhaps that's the most interesting part of his journey.

After more than four decades of programming, Brent isn't finished building.

He's simply building for himself now.

About Brent Vardy

Brent Vardy is a UK-based software developer and the founder of Code and Sea, a solo indie venture focused on building practical software products.

His technology experience spans decades and includes Swift, SwiftUI, SwiftData, PHP, Laravel, Livewire, TailwindCSS, AlpineJS, Python and many other technologies.

His current projects include Mantra Meditation Timer and Tidal Draft.

You can connect with Brent on CoderLegion.

Developer Stories at CoderLegion

Developer Stories is a CoderLegion series featuring real developers and their journeys — the projects they build, the challenges they encounter, the lessons they learn and the decisions that shape their careers.

There isn't one correct path into software development.

Some developers start at university.

Some teach themselves.

Some build companies.

Some build small tools for themselves.

And some, like Brent, have been building software since the days when 5KB of RAM was enough to get started.

Interview & Story by Mehadi Hasan

CoderLegion Community & Editorial Team

Want to share your own developer journey?

If you have a story, project, career transition or learning experience you'd like to share with the CoderLegion community, we'd love to hear from you.

From Biology to Computer Science — Fahad Khalid’s Developer Journey

Mon, 28 Sep 2026 07:43:17 +0000

From Biology to Computer Science — Fahad Khalid’s Developer Journey

Real developers. Real journeys. Real lessons.

In this Developer Story, Fahad Khalid shares how a student who started with Biology found his way into Computer Science, gradually discovered his interests in AI, cloud computing and cybersecurity, and learned that building and practicing matter more than simply consuming courses and tutorials.

Interview & Story by Mehadi Hasan
CoderLegion Developer Stories

From Biology to Computer Science

Fahad Khalid’s journey into technology wasn't completely planned from the beginning.

He had been interested in computers, mobile phones and gaming since childhood, but during matric and intermediate he studied Biology. Eventually, he realized that Biology simply wasn't where his interests were.

That led him toward Computer Science.

Before formally moving into CS, Fahad had already experimented with technology through platforms such as WordPress, Wix and Android Studio. At the time, however, he didn't have a strong understanding of how those technologies actually worked.

He mostly learned through YouTube and experimentation.

That early curiosity eventually developed into a more serious interest in software, AI, cloud computing and cybersecurity.

Starting Computer Science Without a Technical Background

Moving from Biology into Computer Science meant Fahad had to build his technical foundations from the ground up.

Programming, problem solving, data structures, databases and other concepts were new to him.

Rather than expecting himself to understand everything immediately, he gradually developed a more practical approach to learning.

He practiced.

He made mistakes.

He debugged.

He returned to difficult concepts repeatedly.

Professors also encouraged him at different points in his journey.

Over time, one lesson became particularly important:

Consistency matters much more than trying to learn everything quickly.

For Fahad, learning Computer Science became less about understanding everything immediately and more about continuing to make progress.

Finding Direction Through Exploration

When Fahad started Computer Science, he didn't have a perfectly defined roadmap.

He explored different technologies and gradually discovered the areas that kept his curiosity alive.

Eventually, AI, cloud computing and cybersecurity became some of the areas he was most interested in.

He doesn't believe beginners necessarily need to choose a specialization immediately.

Instead, he recommends exploring first, developing strong fundamentals and paying attention to the areas that continue to generate curiosity.

For Fahad, direction came through experimentation rather than following a fixed roadmap from day one.

When Learning Became More Than Watching Tutorials

One of the biggest changes in Fahad's learning approach came when he realized the difference between consuming information and actually applying it.

It's easy to collect tutorials, courses, roadmaps and bookmarks and feel productive simply because you're constantly learning something new.

But watching someone build something and being able to build it yourself are very different experiences.

Fahad started putting more emphasis on doing.

When he learned something, he tried to use it in a project, experiment with it or explain it to someone else.

That shift helped him redefine what learning meant.

Learning isn't about how much content you have consumed. It's about what you can actually understand, apply and build.

Building Practical Skills Through Projects

Personal projects and hands-on experimentation have played an important role in Fahad's development.

Projects introduce problems that tutorials often don't.

You have to debug unexpected behaviour, search for solutions, make technical decisions and sometimes rethink your approach completely.

Those experiences create a deeper understanding.

Git and GitHub also became important parts of Fahad's learning process.

For him, GitHub isn't simply a place to upload code. It has become a record of what he has experimented with, what he has built and how his skills have developed over time.

He also believes projects don't have to be huge or production-ready.

Small projects can teach you a lot when you actually understand what you're doing instead of simply copying a tutorial.

Why Fahad Likes Microsoft Learn

Among the resources Fahad has used, Microsoft Learn stands out because of its structure.

There is an enormous amount of technical knowledge available online, but one of the biggest challenges for beginners can be knowing where to start and what to learn next.

Microsoft Learn provides a more organized path.

Fahad also appreciates that much of the learning content is available for free, giving beginners access to structured material without necessarily having to pay for courses elsewhere.

For someone trying to navigate a large technology ecosystem, having a reliable starting point can make the learning process much easier.

University and Self-Learning Should Work Together

Fahad doesn't see university and self-learning as competing approaches.

Instead, he believes they complement each other.

University provides fundamentals, theoretical understanding and exposure to important areas of Computer Science.

But students also need practical experience outside the syllabus.

For Fahad, that means:

Building projects
Using Git and GitHub
Experimenting with technologies
Participating in communities
Teaching others
Solving practical problems

He also doesn't believe students need to spend every free hour learning another technology.

A few focused hours every week can make a significant difference when that time is spent consistently building and practicing.

Certifications Should Support Learning

Fahad sees certifications as useful, but not as the ultimate goal.

A certification can provide structure, help validate understanding and demonstrate familiarity with a particular technology or platform.

It can also help someone build credibility when they don't yet have much professional experience in an area.

But collecting certificates without developing the underlying skills isn't enough.

Fahad's approach is to treat certifications as one part of a broader learning process.

Ideally, what you learn for a certification should also appear in your projects, experiments and practical work.

Appreciating the Journey

Fahad doesn't point to one dramatic lesson that he wishes he had learned earlier.

Instead, he's comfortable with the way his journey has developed.

There were things he could have done faster or more efficiently, but the small achievements along the way have given him genuine satisfaction.

Moving from Biology into Computer Science, learning the fundamentals, building projects, participating in communities, teaching others and gradually discovering the areas he cares about most have all contributed to where he is today.

Rather than wishing he had taken a completely different path, Fahad has learned to appreciate the progress that comes from taking one step at a time.

Why Fahad Wants to Help Beginners

Fahad's interest in helping beginners comes partly from his own experience.

He knows what it feels like to start without knowing exactly where to begin.

For a new Computer Science student, the technology landscape can quickly become overwhelming.

There is:

Web development
AI
Cloud
Cybersecurity
DevOps
Programming languages
Frameworks
Databases
Hundreds of courses and tutorials

It can easily feel as though everyone else is already ahead.

Teaching has also changed the way Fahad thinks about learning.

When you explain something to a beginner, you quickly discover whether you actually understand the fundamentals yourself.

Through teaching, community participation and writing, Fahad has found that helping someone understand something that once seemed confusing can be genuinely rewarding.

What Does It Take to Become Job-Ready?

For Fahad, becoming job-ready isn't about completing the largest number of courses.

It's about developing skills that can actually be demonstrated.

He highlights:

Strong fundamentals
Problem solving
Communication
Practical projects
Git and GitHub
Independent learning

He also encourages students to build projects that aren't simply copies of tutorials.

Even a small original project creates opportunities to make decisions, encounter bugs and explain why something was built in a particular way.

Courses can give you knowledge, but practical work gives you evidence that you can use that knowledge.

You Don't Need to Learn Everything

Technology changes quickly, and Fahad doesn't believe developers need to learn every new technology that appears.

Instead, he recommends building strong fundamentals and evaluating new technologies based on their relevance.

Some questions he considers include:

Does this solve a problem I'm actually interested in?
Is it becoming useful in the area I'm working toward?
Will learning it build on something I already understand?

Not learning something immediately doesn't mean you can never learn it.

Sometimes the right decision is simply:

“This isn't what I need right now.”

Fahad's Current Focus

Fahad is currently exploring several areas, particularly:

Artificial intelligence
Cloud computing
Cybersecurity
Microsoft technologies
AWS
Practical software development

He is also focusing significantly on certifications as part of his structured learning while continuing his involvement in teaching, student communities and developer education.

His broader goal is to continue developing the practical foundation needed to work across these areas rather than treating them as completely separate fields.

Fahad's Experience With CoderLegion

Fahad has been part of CoderLegion for around a month to a month and a half and describes his experience as positive.

One thing he appreciates is the active and supportive community.

He has already published articles around career guidance and projects and sees CoderLegion as a platform where he can continue sharing content.

Because he is still relatively new to the community, he is also looking forward to seeing how his involvement develops as the community grows.

What Would Fahad Tell His Younger Self?

Interestingly, Fahad says he wouldn't change much.

His journey wasn't perfectly planned.

He explored different technologies, made mistakes, changed directions and gradually discovered what he was actually interested in.

Those experiments helped him understand not only what he liked, but also what he didn't want to pursue.

If he could tell his younger self anything, it would be to trust the process more and not feel pressured to have everything figured out early.

You can have a direction without having the entire path planned.

Advice for Beginners

Fahad's advice is straightforward:

Don't try to learn everything at once.

When you start Computer Science, it can feel as though you are expected to know programming, web development, AI, cloud, cybersecurity, databases, Git, DevOps and dozens of frameworks.

You don't.

Start with the fundamentals.

Pick one direction that interests you.

Build something small.

Make mistakes.

Fix them.

Then gradually expand.

Don't measure your progress by how many courses you've completed or how many technologies you can name.

Give yourself enough time to actually understand what you're learning.

And most importantly:

Try to improve, not to prove.

You don't need to prove that you're already a great developer.

You just need to keep becoming a better one.

About Fahad Khalid

Fahad Khalid is a Computer Science student interested in AI, cloud computing, cybersecurity and practical software development.

Coming from a Biology background, his journey into Computer Science has been shaped by self-learning, experimentation, personal projects, community participation and a strong focus on helping other beginners.

You can connect with Fahad on CoderLegion.

Developer Stories at CoderLegion

Developer Stories is a CoderLegion series featuring real developers and their journeys — the decisions, challenges, experiments, lessons and experiences that shaped how they build and learn.

Every developer's path looks different.

Some start with Computer Science.

Some start by teaching themselves.

Some change careers.

Some discover programming through a completely different field.

Fahad's journey is a reminder that your starting point doesn't have to determine where you finish.

Interview & Story by Mehadi Hasan

CoderLegion Community & Editorial Team

Want to share your own developer journey?

If you have a story, project, career transition or learning experience you'd like to share with the CoderLegion community, we'd love to hear from you.

From Electronics to Local AI — Sami M.’s Developer Journey

Thu, 24 Sep 2026 11:11:33 +0000

From Electronics to Local AI — Sami M.’s Developer Journey

Developer Stories — CoderLegion

From childhood curiosity about computer hardware to robotics, artificial intelligence, multi-agent systems, and today's local LLMs, Sami M.'s journey has always been driven by one thing: understanding how intelligent systems work.

Sami M. is an Electronics Engineer and PhD in Artificial Intelligence (2014). Today, his work and experiments focus heavily on AI, local AI, LLMs, and Ollama, with a particular interest in understanding what these technologies can actually do in practical, real-world situations.

You can find Sami on CoderLegion.

His recent CoderLegion work includes an experiment comparing Qwen3 4B, 8B and 14B for writing correction using 60 local Ollama responses on Windows.

But the story behind that experiment started much earlier.

It Started With an Intel 286

Sami's interest in electronics began when he was very young.

He remembers being fascinated by the Intel 286 and by the idea that a processor and electronic components could somehow make his favourite game, Gorillas under MS-DOS, come to life.

He didn't just want to use the computer.

He wanted to understand what was happening inside it.

That curiosity naturally pushed him toward electronics and engineering.

His move toward artificial intelligence came later through robotics.

One of his early projects involved autonomous trajectory following with a Pioneer 3-DX mobile robot. From there, his interests expanded into more ambitious work involving collaborative multi-agent systems and task-allocation mechanisms based on auction algorithms.

The combination of electronics and AI still feels like a natural continuation of that original curiosity.

From Robotics to Artificial Intelligence

What attracted Sami to AI was ultimately a question about intelligence itself.

He became interested in biological intelligence and biological neural networks, and then in how some of those ideas could inspire artificial systems.

His early work included robotics, computer vision, and mobile-robot path planning.

Classical graph-search techniques such as Dijkstra's algorithm and heuristic search methods such as A* were part of that journey.

Over time, his interest moved toward systems that could do more than execute a fixed algorithm.

He became increasingly interested in systems that could:

Perceive a situation
Reason about it
Make decisions
Interact with other intelligent systems

That path eventually led to his PhD in Artificial Intelligence, completed in 2014.

How AI Has Changed

The AI landscape Sami entered during his academic journey is very different from the one developers work with today.

One of the biggest changes he notices is the move from highly task-specific systems toward models capable of representing much richer relationships between language, context, and meaning.

He is careful about the word "understanding."

He doesn't claim that an LLM understands meaning exactly as a human does.

But the semantic behaviour these models can demonstrate is still remarkable to him.

Earlier AI systems often required intelligence to be explicitly designed through rules, features, decision logic, or algorithms tailored to a particular problem.

Today, much richer behaviour can emerge from representations learned in high-dimensional spaces.

And one development particularly interests him:

local AI.

Why Local AI?

For Sami, one of the strongest attractions of local AI is control over information.

When AI runs locally, sensitive or private information can remain on his own machine.

That matters when working with technical documents, private information, or other material that he may not want to send to an external service.

It also gives him more freedom to design the architecture around his own requirements.

RAG is one example.

Sami has experimented with large collections of training videos. Instead of manually watching hundreds of hours of material, he can:

Transcribe the content
Divide it into useful segments
Generate embeddings
Retrieve relevant passages
Interact with that knowledge through a local model

This turns a huge collection of information into something he can query directly.

For Sami, local AI isn't simply about running a model without an internet connection.

It's about privacy, control, architecture, and practical usefulness.

Experimenting With Qwen and Ollama

Sami's recent CoderLegion article, Qwen3 4B vs 8B vs 14B for Writing Correction: 60 Local Ollama Responses on Windows, came from a very practical need.

He writes technical reports and emails, sometimes in very different communication styles.

Constantly switching between correction, improvement, explanation, and tone adjustment was taking time.

So he wanted something that could:

Correct genuine mistakes
Suggest improvements when useful
Work with text from different Windows applications
Allow him to keep his original wording when preferred
Explain corrections in a language he understands well

Instead of simply assuming that the largest model would perform best, Sami built a reusable benchmark framework to test different local models under the same conditions.

The results reinforced an important lesson:

Model size alone isn't enough.

In his tests, a larger model did not necessarily improve the main correction result, while the difference in execution time could be significant.

Benchmarks vs. Real-World Testing

Sami sees published benchmarks as useful.

They can help create a shortlist.

But when it comes to deciding whether a model is actually useful, he prefers testing it against his own real-world requirements.

His writing-correction experiment also connects to something personal.

English isn't his first language, and he doesn't have much time to study English separately from his engineering work.

So he thought:

Why not learn while already working?

He already needed to write reports and emails in English.

By using AI to correct mistakes, suggest improvements, and explain corrections, he could learn while completing work he already needed to do.

He doesn't claim this is a formally validated language-learning method.

But personally, he has found it useful.

For Sami, the important point is simple:

A benchmark can tell you something about a model. Your own problem tells you whether that model is useful.

Human First

Sami's approach to AI can be summed up simply:

Human first.

He uses AI extensively, but he doesn't want AI making important decisions for him.

Instead, he uses it to:

Challenge an idea
Show him another perspective
Point out something he may have missed
Save time on repetitive work
Explore possibilities

Sometimes he will have several exchanges with an AI system before deciding whether an idea is worth keeping.

But the final judgment remains his.

"For me, the best use of AI is not to replace human expertise, but to make that expertise more effective."

That philosophy is particularly relevant as AI becomes increasingly integrated into everyday development work.

The Challenge of Multi-Agent Robotics

One of the most challenging technical areas Sami has worked on is heterogeneous multi-agent robotics.

Imagine a humanoid robot and a tracked mobile robot working together on the same task.

They may have completely different:

Ways of moving
Sensors
Architectures
Physical capabilities

The challenge isn't simply getting them to communicate.

The harder questions are:

Who should do what?

When should they do it?

How can the system take advantage of the fact that the agents are different?

Sami worked with dynamic task-allocation approaches, including auction-based mechanisms where tasks can be allocated according to the capabilities and current state of different agents.

It is a problem of making different intelligent systems cooperate even though they don't necessarily experience or interact with the world in the same way.

Choosing AI Without Following the Hype

The AI ecosystem changes incredibly quickly.

New models and tools appear constantly.

Sami tries not to choose a model simply because it is fashionable or because everyone is talking about it.

He starts with the problem.

He asks:

What exactly am I trying to achieve?
What level of quality do I need?
What latency is acceptable?
How much memory do I have?
Do I need privacy?
Does it need to work offline?
Do I need RAG?
Do I need structured output?

Once those constraints are clear, he tests.

A smaller model with good context and a well-defined task can sometimes be more useful than a massive model used with noisy input or without a clear understanding of the problem.

But Sami doesn't treat that as a universal rule.

He prefers to measure.

"For me, specifications come before trends."

What Comes Next for Local LLMs?

Sami doesn't think the future of local LLMs is simply about making models bigger.

He believes efficiency will be just as important:

Better architectures
Improved quantization
Better memory management
Greater efficiency with fewer parameters

One example from his own experiments illustrates this.

For his particular test set, Qwen3 4B matched Qwen2.5 7B on the primary complete-case writing-correction metric he was measuring.

That doesn't mean the two models have the same overall reasoning capabilities.

It means that for that particular workload, the larger parameter count didn't improve the main result he was measuring.

That is precisely why he prefers experimentation over assumptions.

He expects increasingly capable local models to continue running on ordinary consumer hardware, and that is one of the developments he finds most exciting.

Electronics Still Shapes How He Thinks About AI

Despite spending much of his time working with software and AI, Sami hasn't forgotten the physical layer underneath it all.

His electronics background influences the way he evaluates AI systems.

He naturally thinks about:

GPU architecture
Memory
Data movement
Computational cost
Latency
Energy consumption
Responsiveness
Efficiency

A model isn't just an abstract collection of parameters.

It has to fit into memory.

Data has to move through the system.

The hardware has limits.

Energy and latency matter.

That physical view of computing is one reason local AI interests him so much.

His Advice to Developers Exploring Local AI

Sami's advice is straightforward:

Start with the problem, not with the model.

His suggested approach is:

Define one clear use case.
Decide what a good result actually looks like.
Choose a reasonably small model.
Run it locally using something accessible such as Ollama.
Create representative test cases.
Measure the results.
Only then consider moving to a larger model.

And if the application involves RAG or external knowledge, spend time cleaning and structuring the data.

Good context can make a significant difference.

For Sami, a well-defined problem, a suitable model, and good-quality input can often matter more than simply choosing the largest model available.

Finding a Technical Community

Sami joined CoderLegion in September 2026 and has already become active in the AI, Dev Tools, and Python communities.

What he appreciates most is the technical relevance of the discussions.

He has received questions about the methodology behind his experiments and discussions about the technical choices he made.

As an engineer, he says he is much more comfortable discussing the substance of a project than promoting himself.

That makes a technically focused community a natural fit.

As CoderLegion grows, he hopes it maintains that technical spirit:

People sharing what they tested, what worked, what didn't work, and why.

For Sami, that kind of discussion is more useful than visibility for its own sake.

Looking Ahead

One of Sami's current research interests is radio-spectrum management.

He is exploring how computational methods, optimization, and AI can support problems such as:

Spectrum sharing
Interference analysis
More efficient use of limited spectral resources

But even here, his philosophy remains the same.

He doesn't want to add AI simply because AI is available.

He prefers to first understand the engineering problem and then identify where AI can provide measurable value.

That philosophy connects his past and present work.

From the Intel 286 that first sparked his curiosity, to robotics, artificial intelligence, multi-agent systems, and today's local LLMs, the technologies have changed dramatically.

The curiosity hasn't.

About Sami M.

Sami M. is an Electronics Engineer and holds a PhD in Artificial Intelligence (2014). His interests and work span electronics, robotics, artificial intelligence, multi-agent systems, local AI, LLMs, and practical experimentation with AI tools such as Ollama.

Follow Sami on CoderLegion.

CoderLegion Developer Stories

Real developers. Real journeys. Real conversations.

Developer Stories is a CoderLegion series featuring developers, engineers, researchers, and builders sharing the experiences, challenges, ideas, and lessons behind their work.

If you'd like to share your own developer journey, join CoderLegion.

From Customer to Creator: Mohammad's Developer Journey

Thu, 24 Sep 2026 10:44:34 +0000

I Was Lisar's First Customer: Mohammad Hesameddin Montazerilisar's Journey From a Personal Need to Building a Product

Real developers. Real journeys. Real experiences.

At 14, Mohammad Hesameddin Montazerilisar was frustrated by something that seemed simple: installing games and software on his Samsung phone.

His friends with Sony Ericsson phones could install games with a simple click. On his phone, the process was much more difficult, and phone retailers wanted to charge him to do it.

Instead of simply accepting the problem, Mohammad became curious.

Why could the same task be so different on two devices?

That question led him into software platforms and operating systems — and eventually into a career spanning networking, security, software and fintech.

Seventeen years later, that curiosity became something much bigger.

Today, Mohammad is working full-time on Lisar Connect, a product that grew from his own experiences and needs.

And perhaps the most interesting part of the story is this:

“In fact, I was Lisar's first customer.”

This is Mohammad's developer journey.

From a Problem at 14 to a Career in Technology

Mohammad's interest in technology began with a very ordinary problem.

At 14, he wanted to install games and software on his Samsung phone. When he asked phone retailers for help, they wanted to charge him for the installation.

At the same time, his friends using Sony Ericsson phones could install games much more easily.

That difference caught his attention.

Rather than simply looking for someone to fix the problem, Mohammad started researching software platforms and operating systems.

He wanted to understand why the same task could work so differently across devices.

That curiosity became the beginning of his journey into technology.

He later studied computing at university and completed a master's program in information security.

During his studies, he discovered that his interests extended across both networking and software.

It was also during this period that the idea that would eventually become Lisar began to take shape.

The Idea Behind Lisar Started as a Student

Mohammad saw a gap between two areas he was interested in: networking and hardware on one side, and programming and software on the other.

He wanted to build a service that could bring those areas together.

But the idea did not immediately become a startup.

After university, Mohammad spent around two years working in networking and security before moving into fintech.

Over the next 15 years, he worked in roles including programmer, systems analyst, team lead and deputy technical director.

Throughout that time, the idea for Lisar stayed with him.

He describes the process of working through the idea as being like putting together a puzzle — gradually understanding the different pieces and how they could fit together.

“I Was Lisar's First Customer”

The idea became much more personal through Mohammad's own work.

His professional responsibilities required him to work with a range of connected devices and networking equipment, including Android devices, Apple and Microsoft products, and equipment from MikroTik, Cisco and D-Link.

He wanted to manage those connections from one place.

When he travelled for work, another problem appeared.

He needed to monitor internal company services while also handling everyday tasks such as banking and shopping.

Many of the problems he was trying to solve for Lisar were therefore problems he had personally experienced.

That's why Mohammad describes himself as Lisar's first customer.

The product wasn't born from an abstract market idea alone.

It grew from problems he personally wanted to solve.

Turning the Idea Into a Full-Time Project

After 17 years of working across technology, Mohammad eventually decided to pursue the idea seriously.

He left his full-time job and began focusing entirely on Lisar.

“I know there is still a long way to go, but I have started, and I enjoy being able to focus on this idea.”

Today, his focus is on bringing Lisar to life and making its networking capabilities easier for users to manage.

The service includes a web panel where users can see information about their profiles, connection status, usage and available features, while managing their settings.

Another part of the design is support for multiple profiles under one account.

A user can have separate profiles for different needs — such as personal use, travel or a family member — with each profile operating according to its own settings and plan.

For Mohammad, bringing web-based management, clear information and multiple-profile management together is an important part of what makes Lisar different.

The Challenge of Privacy, Simplicity and Connectivity

Building Lisar has also meant solving a difficult combination of technical and user-experience problems.

One challenge was finding a way for users to connect without requiring a dedicated Lisar application.

Mohammad wanted users to be able to use standard connection methods and tools instead.

His approach combines GeoDNS with standard VPN protocols.

For compatible devices and networks, Lisar supports L2TP/IPsec, while OpenVPN is available through supported connection paths.

Depending on the device, users can connect using built-in operating-system settings or a standard VPN client.

For Mohammad, the technical implementation is only part of the challenge.

He also believes that using standard protocols and clearly explaining how a service works are important parts of building trust.

Privacy is another part of that design.

He says Lisar's approach is based on minimizing data collection and limiting it to what the service specifically needs.

Building Custom Exit From a Real-World Problem

One of the parts of Lisar Mohammad is particularly proud of is Custom Exit.

Again, the idea came from his own experience.

His work involved frequent travel, and he often encountered situations where internet quality and routes to servers varied depending on where he was.

Sometimes, connecting directly to a destination simply wasn't the best option.

That led him to explore a different approach.

With Custom Exit, the connection's entry point can be separated from its exit point.

A user can connect to Lisar through a suitable entry server and then choose a different available and permitted exit.

The goal is to provide more flexibility over the route while keeping the settings manageable through the web panel.

For Mohammad, the feature is meaningful because it addresses a problem he has personally encountered many times.

The Journey Matters More Than the Destination

After 17 years in technology, Mohammad says the biggest lesson he has learned can be expressed simply:

“The journey you take matters more than the destination.”

For him, the people around you are an important part of that journey.

Having the right people around you can improve the chances of succeeding, but it can also make the process itself more worthwhile and enjoyable.

Reaching a goal without the right people alongside you may not feel as meaningful as expected.

That perspective has influenced how Mohammad approaches his work and the long journey of building Lisar.

The Hardest Challenge: Earning Users' Trust

For Mohammad, one of the biggest professional challenges has not simply been building the technology.

It has been earning users' trust.

When offering a service that people pay for, users naturally want to understand what they are buying.

Mohammad says Lisar has tried to be transparent about its services so users can understand exactly what they are paying for.

But transparency takes work.

Sometimes explaining the service and answering questions can require more time and energy than delivering the service itself.

His approach has been to build trust gradually through clear explanations, patience and quality service.

The web panel is part of that approach.

Users should be able to see their profiles, understand which features and limits apply, and see how much of the service they have used.

For Mohammad, making that information clear and accessible is part of the product itself.

Letting Users Influence the Product

Mohammad doesn't follow a formal system for keeping up with technology.

Instead, he spends time searching for information and following material on social media.

But when it comes to deciding what to build, he places particular importance on user feedback.

He believes new needs emerge as technology develops, and users are often the best source for identifying those needs.

One example changed Lisar's direction.

Originally, Mohammad did not plan to build a dedicated Lisar application.

The service was already accessible through standard connection methods and clients.

Then a user suggested that Lisar should offer its own app as well.

That feedback changed the plan.

App development was added as another option for users who preferred to use Lisar's own applications.

For Mohammad, it demonstrated how a single user's feedback can influence the direction of a product.

How AI Changed What Was Possible

Perhaps one of the most striking parts of Mohammad's story is his view of AI.

He says:

“I think I can say that I would not have been able to build Lisar without AI tools, and I do not see that as a weakness.”

His own estimate is that without AI tools, building a product like Lisar would have required a team of around 15 to 20 people.

That would have been financially out of reach for him.

AI changed that equation.

It gave Mohammad the ability to start building an ambitious product with the resources he actually had.

For him, AI has therefore not simply been another development tool.

It has changed what is financially and practically possible for an individual builder.

The Lesson He Would Teach His Younger Self

If Mohammad could go back to the beginning of his journey, there is one thing he would approach differently.

He would pay more attention to the business side earlier.

Instead of focusing primarily on technical questions and technology, he would spend more time understanding users and business needs alongside developing his technical skills.

Today, his view is straightforward:

“A product's value is found in its users, not in its number of lines of code or the technologies used to build it.”

That lesson comes from years of working in technology before eventually becoming a product builder himself.

His Advice to Developers Who Want to Build

Mohammad recommends that people who want to build their own products first spend several years working in a relevant field and gaining real-world experience.

Books can teach many things, but they cannot teach every business lesson.

Some lessons have to be learned by dealing with real problems in a real working environment.

For Mohammad, his years in networking, security and fintech became an important part of preparing him to build Lisar.

Those experiences helped him understand the challenges behind his original idea and gradually find ways to address them.

His Experience With CoderLegion

Mohammad has not been on CoderLegion for very long, but his experience so far has been positive.

He describes the community as friendly and says one thing that stands out to him is that it does not feel like a competition.

Instead, he sees more of a sense that members help each other learn and improve.

That supportive atmosphere is something he values, particularly because collaboration and the people around him have played an important role throughout his professional journey.

What's Next for Lisar?

As of 15 September 2026, Mohammad's near-term plan is to work toward releasing Android, iOS and Windows versions of Lisar within the following month.

Importantly, this is his planned timeline as of that date, rather than a guaranteed release date or a statement that those applications are already publicly available.

The applications are intended to provide another way to use the service, while standard connection methods and clients remain part of Lisar's approach.

Looking further ahead, Mohammad wants to introduce Lisar to more people around the world and contribute to what he describes as open, nondiscriminatory access to the internet, with respect for privacy.

He hopes people can use the internet with fewer concerns about their privacy and believes that kind of access is everyone's right.

The possibility that Lisar could contribute to that vision is one of the things that excites him most.

Enjoying the Journey

Perhaps the most personal part of Mohammad's story is what keeps him going when the work becomes difficult.

His answer is simple:

“I love what I do.”

He doesn't see the journey as something he can simply lose, because he is doing work he loves and enjoying the process itself.

He compares it to buying a piece of clothing you really love.

When you wear something you enjoy, you don't spend all your time worrying about whether it might eventually tear.

You enjoy wearing it now.

For Mohammad, building Lisar feels much the same.

He is hopeful about where the product can eventually go, but he hasn't postponed his enjoyment until some future milestone.

He enjoys the journey itself.

And that is what keeps him moving forward.

About Mohammad Hesameddin Montazerilisar

Mohammad Hesameddin Montazerilisar is the person behind Lisar Connect.

His professional background spans networking, security and fintech, and he now focuses full-time on developing Lisar.

His work combines his long-standing interest in networking and software with a product built around problems he has personally experienced.

He also writes technical guidance for Lisar Connect, covering areas including VPN setup, routing, DNS, profiles and troubleshooting. :contentReference[oaicite:2]{index=2}

Product: Lisar Connect

CoderLegion Developer Stories

This story is part of CoderLegion Developer Stories, a series highlighting the people behind the technology — their journeys, projects, experiences, challenges and ideas.

Rather than focusing only on technologies and achievements, Developer Stories aims to explore the experiences that shaped the people building them.

Real developers. Real journeys. Real experiences.

Interviewed and edited by Mehadi Hasan, Community & Editorial Team at CoderLegion.

Would you like to share your own developer journey? Get involved with CoderLegion Developer Stories.

Developer Spotlight: Sara Czasak on Learning, Building and Growing as a Developer

Fri, 18 Sep 2026 10:55:52 +0000

Real developers. Real journeys. Real conversations. In this Developer Spotlight, Tom Smith sits down with Sara Czasak to talk about her journey into development, building practical projects, open source, and learning along the way.

A conversation about Sara's journey into development, building practical projects, open source, and learning by doing.

CoderLegion is starting a new format for Developer Stories — Video Discussion Stories.

Instead of presenting a developer's journey as a written Q&A, this format gives the community a chance to hear directly from developers through a relaxed video conversation.

For our first Developer Spotlight, Tom Smith sits down with Sara Czasak for a conversation about her journey as a developer, the projects she has been building, and her experiences learning and growing in technology.

Watch the Developer Spotlight

Watch the full conversation with Sara Czasak

The conversation runs for approximately 14 minutes and gives the community a chance to get to know Sara beyond her written posts and projects.

Meet Sara Czasak

Sara Czasak is a self-taught developer who has been building practical software while continuing to grow her skills.

Her work includes Python development and open-source projects, including py_simple, a beginner-friendly Python package designed to make common programming tasks easier to understand and use.

The project grew from a simple idea: reduce the amount of syntax beginners need to remember so they can focus more on solving problems and learning programming concepts.

Sara has also been experimenting with practical applications and sharing her progress as she develops her skills.

A Conversation About the Developer Journey

In this Developer Spotlight, Tom and Sara have a relaxed conversation about Sara's experience as a developer and the path she has taken so far.

Rather than treating the conversation like a formal technical interview, the format is designed to let the discussion develop naturally around the person behind the projects.

The conversation touches on areas including:

Sara's journey into software development
Learning to build software as a self-taught developer
Her experiences creating practical projects
Python and open-source development
Building and improving projects over time
Learning through experimentation
The challenges that come with developing and shipping projects
The importance of continuing to learn and improve
Sara's perspective on growing as a developer

The discussion also gives viewers a chance to hear Sara explain her experiences in her own words rather than reading an edited written version of her story.

Meet the Host: Tom Smith

The conversation is hosted by Tom Smith, a technology writer and AI/LLM specialist who has spent years interviewing technology professionals and writing about the tools and technologies shaping software development.

Tom has conducted thousands of interviews with technology professionals and brings that experience to the Developer Spotlight format.

His approach is conversational rather than formal — giving the guest room to explain their experiences, projects and ideas naturally.

Why We're Starting Video Discussion Stories

Written Developer Stories are a great way to learn about someone's journey.

But video creates a different kind of connection.

You can hear how someone explains an idea, see their personality, and get a better sense of the person behind the profile, projects and articles.

That's what we're hoping to build with Video Discussion Stories.

The format is intentionally relaxed.

There is no requirement for the conversation to feel like a podcast or a formal interview. The goal is simply to give developers an opportunity to talk about their journey, their work and the things they are learning.

Developer Spotlight at CoderLegion

Developer Spotlight is part of CoderLegion's growing Developer Stories initiative.

We're interested in conversations with developers, engineers, technical founders, creators and technology professionals about topics such as:

Developer journeys
Interesting projects
Open source
AI and emerging technologies
Building products
Entrepreneurship
Career experiences
Lessons learned
Challenges developers face
The future of technology

Some conversations may focus heavily on technical work.

Others may explore a product, startup, career journey, open-source project or an interesting idea someone is working on.

The common thread is the person behind the technology.

Want to Take Part?

Would you like to appear in a future CoderLegion Developer Spotlight?

Or perhaps you would like to host a conversation with another developer?

We're looking for developers and community members who would like to participate in future conversations.

If you would like to be interviewed or host an interview, get in touch with the CoderLegion team.

There is no fixed topic or rigid format. Conversations can focus on your developer journey, projects, products, launches, leadership, entrepreneurship, technical experience or anything interesting you're currently building or exploring.

About Sara

Sara Czasak is a self-taught developer working primarily with Python and open-source projects.

She is the creator of py_simple, a beginner-friendly Python package designed to make common programming tasks more readable and accessible.

Sara's approach to development is centered around building practical projects, learning through experimentation, and improving with each release.

About Tom

Tom Smith is a technology writer and AI/LLM specialist who focuses on making technology useful and understandable for developers, engineers and technical professionals.

He has conducted thousands of technology interviews and writes about AI, developer tooling, cybersecurity and emerging technologies.

CoderLegion Developer Stories

Developer Stories is a CoderLegion initiative highlighting the people behind the technology — their journeys, projects, experiences, challenges and ideas.

With Video Discussion Stories, we're expanding that format from written interviews into conversations that let developers share their stories directly.

Hosted by Tom Smith
Guest: Sara Czasak
Format: Developer Spotlight / Video Discussion
Published by CoderLegion

Want to be featured in a future Developer Spotlight? Contact the CoderLegion team.

From Law and Product Operations to AI-Native Companies: Sean

Fri, 18 Sep 2026 10:33:50 +0000

From Law and Product Operations to AI-Native Companies: Sean Shen’s Developer Journey

“The important question is: Is this actually worth building?”

What happens when someone with a background in law and product operations suddenly discovers that AI has made software development accessible enough for him to start building products himself?

For Sean Shen, founder of AIOMNIU, the answer has been a rapid transition from product operations and entrepreneurship into AI-assisted development, startup building, marketplaces and AI services.

Sean is based in China and studied law, but never worked professionally in the legal field. Most of his career was spent in product operations and management systems, giving him exposure to product development and system architecture.

He also worked across a remarkably wide range of industries, including apparel, real estate, education, healthcare, pets, food, hospitality, travel, state-owned enterprises and entertainment services.

But none of those experiences gave him the breakthrough he was looking for.

Then AI arrived.

And suddenly, someone with his background could begin building software.

That changed the question.

Instead of asking whether he had enough technical people to build an idea, Sean could start asking something much more fundamental:

Is the idea actually worth building?

From Law to Product Operations

Sean's journey into technology wasn't a conventional developer story.

He studied law but ultimately moved into product operations, where he spent years working with management and back-office systems.

That experience gave him something valuable even though he wasn't writing most of the code himself: an understanding of products, business processes and system architecture.

His career also exposed him to many different industries.

He worked around apparel, real estate sales, education, healthcare, pets, food, wigs, adult products, hospitality, travel, state-owned enterprises and entertainment services.

The diversity of those experiences eventually became useful.

He had seen many different types of businesses and operational problems.

But for a long time, building software himself wasn't really an option.

Then AI changed the equation.

The Moment AI Made Development Feel Accessible

One of the earliest moments that influenced Sean happened in 2023, when he was working at an online medical consultation app in China.

His responsibility covered the entire consultation business.

At the time, the company was already experimenting with AI to improve the pre-consultation process through a project called Medical Assistant Integration.

GPT had just appeared.

The developers around him were excited about it, although Sean admits he didn't really understand GPT at first.

What caught his attention was seeing an AI-powered autocomplete feature actually working inside the product.

He remembers telling a colleague:

“This is probably the thing that can actually make the consultation process more efficient in the future. You just need to make this work really well.”

That experience stayed with him.

After leaving the company, Sean continued building businesses, mainly in e-commerce.

But entrepreneurship gradually convinced him that he wanted to move toward services rather than physical products.

Physical products require inventory, capital and heavier assets.

Services can be adapted and iterated much faster.

And then AI created another possibility: perhaps software development itself could become a service that someone like him could participate in.

The Real Reason He Started Building With AI

Sean doesn't try to turn his origin story into something more inspirational than it was.

His motivation was surprisingly straightforward.

He wanted to make money.

When he realized that AI could enable someone working in product operations to take on website development projects, he started thinking about the larger opportunity.

If AI could enable more people to build software, there could eventually be a huge wave of AI-powered developers.

And if that productivity could be connected to businesses, perhaps it could become a service business.

Sean has also long believed that B2B customers are more willing to pay for AI than consumers.

That became one of the ideas behind his direction with AIOMNIU.

The Dark Forest and the Little Mouse

Sean describes the market as a dark forest.

In that environment, he doesn't believe the biggest player necessarily has the only path to survival.

Instead, he uses a different metaphor:

“The best entrepreneur may not be the T. rex.”

“Maybe it’s the little mouse that keeps adapting and evolving.”

That idea captures an important part of Sean's approach.

Rather than trying to compete directly with the largest AI companies, he is interested in finding smaller, specialized opportunities where a small team can adapt quickly.

This thinking becomes particularly important when looking at the AI application layer.

Building in Public Is a Growth Strategy

Sean has also been publicly documenting his entrepreneurial journey, including his Only10 series.

For him, building in public isn't primarily about telling a romantic startup story.

It's about distribution.

AIOMNIU is an early-stage project without a major established brand or a natural source of traffic.

That means the team needs to create ways for people to discover what they are building.

Sean sees content as an unusually efficient asset for a small team.

One piece of content can:

Communicate an idea
Be distributed across multiple social platforms
Accumulate search value
Contribute to backlink growth
Attract potential users
Create another channel for learning about the market

For a small team with limited resources, one piece of work can therefore create multiple kinds of value.

That's why Sean describes building in public very simply:

“It’s fundamentally a growth strategy.”

Focus Doesn't Mean Never Changing Direction

Sean has written about turning down several seemingly good opportunities while trying to stay focused.

But he makes an important distinction.

Focus, in his view, doesn't mean locking yourself into one direction and refusing to change.

If a genuinely good opportunity appears, it shouldn't automatically be ignored.

The real question is timing and long-term value.

Sean defines focus this way:

“In a constantly changing environment, make the choice that has the highest long-term compounding value, and commit your resources to it.”

A focused person can still encounter tempting opportunities.

The difference is that after evaluating them, they decide whether the opportunity deserves resources that would otherwise go toward the core business.

So focus isn't about refusing to change.

It's about preventing constant change from diluting the resources needed to build something meaningful.

What Building AI Products Has Taught Him

Sean has already experimented with several AI products, including an AI resume builder and an AI resume screening tool.

Those experiments have led him to a strong view about the limitations of API-based AI products.

He believes AI products may have shorter lifespans than many traditional software products.

The reason is simple.

If the core value of a product is essentially wrapping the capabilities of a foundation model in a user interface, improvements in those underlying models can eventually reduce the product's differentiation.

Sean compares this situation to:

“Drinking poisoned wine in the desert.”

There may be good reasons to use an API when validating an idea or keeping early costs low.

But he believes that once an AI product has a meaningful user base and enough accumulated data, the long-term direction should increasingly move toward specialized models, local deployment, proprietary infrastructure or post-training.

The goal isn't to become another GPT.

It is to become a specialist.

“We just need to become the specialist in a niche.”

The Opportunity After Foundation Models

Sean sees the foundation-model layer as extremely difficult for independent developers to compete in.

Companies such as GPT, Claude, GLM and DeepSeek are already operating at enormous scale, while their capabilities and pricing continue to evolve.

For a small team, building an entire business around one particular foundation model can therefore introduce instability.

Instead, Sean is particularly interested in what happens as the foundation-model ecosystem becomes more mature.

He expects opportunities to emerge around smaller, specialized models trained around specific industries, businesses and use cases.

The advantage won't necessarily come from building the biggest model.

It may come from understanding a specific domain better than anyone else.

“We just need to become the specialist who truly understands a particular domain, its data, and its real-world use cases.”

Sean is particularly watching areas such as:

AI applications across different industries
AI-powered business growth
Data compliance
AI security
Specialized AI services
Industry-specific applications

The Application Layer Hasn't Fully Exploded Yet

Sean believes the massive expansion of AI applications may still be ahead.

The infrastructure layer has received enormous attention, but he sees another opportunity emerging as the cost and accessibility of AI infrastructure continue to change.

For independent developers and small teams, this could create room to build specialized applications without needing to compete with the companies developing the underlying foundation models.

The opportunity is not necessarily to build another general-purpose AI.

It is to identify a specific problem where AI can create meaningful economic value.

From AI to Businesses — and Eventually AI to AI

Sean has an interesting perspective on how AI and humans may interact as AI becomes increasingly embedded in production systems.

He doesn't believe humans will simply be replaced as a whole.

Instead, he expects many individual jobs and roles to be redefined.

He describes a possible progression in three stages.

AI to B

The first stage is AI to B — AI entering businesses and society's production systems and beginning to generate real economic and social value.

AI to AI

The second stage is AI to AI.

Once enough businesses become AI-enabled, AI systems may increasingly call on other AI systems to provide services and further increase productivity.

Human to AI

The third stage is what Sean calls Human to AI.

As productivity gains from digital AI systems eventually encounter diminishing returns, humans may continue to provide forms of value that AI cannot fully replace.

In that scenario, AI wouldn't simply assist humans.

Sean imagines AI increasingly calling on humans.

Some early examples already exist where AI systems depend on humans for research, real-world information and physical-world experiences.

But Sean imagines something broader in the long term:

A continuing working relationship where humans and AI each contribute what they are uniquely capable of contributing.

The Biggest Challenge: Growth

For Sean, the biggest challenge so far has been growth.

AIOMNIU aims to become a global platform connecting AI talent, businesses and services.

But reaching global markets is difficult for an early-stage company without an established distribution channel.

Over time, Sean has also come to believe that growth isn't always simply a marketing problem.

Sometimes it comes down to whether the product itself is compelling enough.

That realization has influenced how AIOMNIU experiments.

The team has built products such as AI resume screening partly to attract users and learn what people actually need.

But the strategy is evolving.

Rather than constantly creating another tool simply to attract traffic, Sean wants to get closer to real businesses.

That means understanding:

How the business makes money
How its operations work
Which processes matter
Where its data lives
How its systems connect
How its people collaborate

Only after understanding those things can the team identify where AI can create genuine value.

The Moment AI Changed His Ambition

Sean describes his evolution with AI in three stages.

Before AI, he wouldn't have imagined starting a product with only a handful of people.

A serious software project might require frontend developers, backend developers, product people, operations and other specialists.

Even building a website could eventually mean assembling a large team.

When GPT first appeared, that assumption didn't immediately disappear.

AI initially felt more like having a knowledgeable expert sitting beside him.

Ask a question and get help.

But the emergence of agentic coding tools changed the experience.

Tools such as Claude made it possible for one person to build an MVP much more directly.

For Sean, the bigger impact wasn't simply that AI could write more code.

It was that AI expanded what a small team could realistically attempt.

Previously, when he had an idea, his first question might have been:

“Do I have the ability to organize enough people to build this?”

Now the question is different:

“Is this actually worth building?”

That is a profound shift in how he thinks about entrepreneurship.

What AIOMNIU Is Building

Today, AIOMNIU is focused on two core areas:

AI talent outsourcing and AI services.

The talent side can be thought of as an AI-focused version of a marketplace such as Upwork, connecting businesses with people who can provide AI-related talent and services.

The services side is increasingly moving toward enterprise AI transformation.

But Sean doesn't see enterprise transformation as simply uploading company documents and generating an AI report.

Real transformation requires understanding how the business actually works.

That means looking at:

Business models
Operations
Processes
Data
Existing systems
Internal workflows
People and collaboration

Only then can AI opportunities be identified in a meaningful way.

AIOMNIU is therefore using content and conversations with businesses to understand what companies actually need from AI.

From there, the team can decide which problems should eventually become products and which are better served through talent and FDE-style services.

Sean describes the resulting cycle as a technology flywheel.

As foundation models improve, the products and services built on top of them can improve as well.

But the part he is most excited about is what happens when the application layer begins to expand at scale.

“I believe that moment will come, and I’m excited to be here for it.”

His Experience With CoderLegion

Sean has also become active in CoderLegion's AI, Open Source and WebDev communities.

He says he has a very positive impression of the platform, particularly its efforts to encourage creators and maintain an active community.

For him, there is an important relationship between creators and the platforms they participate in.

When creators feel that a community provides real value, they contribute more.

That creates more user-generated content, which in turn can strengthen the community.

Sean connects that idea to the spirit of open source:

“A product shouldn’t be treated purely as private property. It can become a shared asset built by everyone who participates in it.”

He hopes CoderLegion continues to maintain that openness as it grows.

Start Now. Just Build.

For someone sitting on an AI product idea and wondering whether they have enough technical knowledge, resources or people to begin, Sean's advice is remarkably direct.

Don't wait for everything to be ready.

Don't wait until you have assembled a large team.

Don't wait until you know exactly how everything will work.

His advice is:

“Start now. Start immediately. Just build.”

That advice makes sense in the context of his own journey.

A person who studied law, spent years in product operations and had almost no development experience until April 2026 is now building AI products, experimenting with agentic development and working toward an AI talent and services platform.

The technology changed what was possible for him.

But perhaps the bigger change was what it allowed him to ask.

The question used to be:

“Can I build this?”

Now it is:

“Is this worth building?”

And that may be one of the most important questions for anyone building software in the AI era.

About Sean Shen

Sean Shen is the founder of AIOMNIU, an AI talent and services platform.

His interests include AI startups, marketplaces, remote work, growth systems and the future of AI-native companies.

His current work focuses on connecting AI talent and businesses, exploring enterprise AI transformation, experimenting with AI-powered products and understanding where specialized AI applications can create real business value.

Sean also shares his entrepreneurial journey publicly through projects and content such as Only10, using content as both a learning mechanism and a growth strategy.

CoderLegion Developer Stories

This story is part of CoderLegion Developer Stories, where developers, founders, engineers and technology professionals share their experiences, challenges, projects and lessons from their journeys.

The goal is to give the CoderLegion community a closer look at the people and ideas behind the technology.

Interviewed and edited by Mehadi Hasan, Community & Editorial Team at CoderLegion.

From SEO to AI Search: Jarno S’s Journey Into Making the Web More Understandable to AI

Fri, 18 Sep 2026 10:22:19 +0000

From SEO to AI Search: Jarno S’s Journey Into Making the Web More Understandable to AI

“Build for people. Structure for understanding. Measure what changes.”

Search is changing.

For years, businesses and website owners have focused on questions like: Where do we rank on Google? How much traffic are we getting? Which keywords are bringing visitors?

But as people increasingly turn to AI systems such as ChatGPT, Gemini, Perplexity and Copilot for answers, another question is becoming increasingly important:

What does AI say about your business — and is it accurate?

For Jarno S, founder of AEOvara in Finland, this question sits at the intersection of technical SEO, AI search, structured data, content architecture and measurement.

Jarno's path into this work has been practical rather than purely theoretical. He has built websites, worked with visual content and photography through Kuvaajankulma, and experienced how difficult it can be for a good business to become discoverable online.

SEO became a natural part of solving that problem.

Then AI search changed the question.

Instead of asking only whether a website can rank, Jarno became interested in whether AI systems could understand a business correctly, represent it accurately and recommend it for the right reasons.

That thinking led to AEOvara and his work around Answer Engine Optimization (AEO), Generative Engine Optimization (GEO), and Large Language Model Optimization (LLMO).

From Traditional Search to AI Search

Jarno describes several related concepts that are increasingly appearing in conversations about search.

Traditional SEO is mainly concerned with earning visibility in search-result pages.

AEO — Answer Engine Optimization — focuses on structuring content so that it can answer a question directly.

GEO — Generative Engine Optimization — focuses on how a brand is represented and recommended in generative search experiences.

And LLMO — Large Language Model Optimization — is about making a website, its entities and its information understandable to large language models.

These approaches overlap, but for Jarno the broader shift is more important than the terminology.

The goal moves from simply trying to “rank for a keyword” toward becoming a reliable answer.

That distinction becomes particularly important when the interface between a person and the web is no longer simply a list of links.

The Question That Changed Everything

Jarno became interested in AI search when he noticed that people were increasingly asking ChatGPT, Gemini and Perplexity questions that they previously asked Google.

That introduced a new problem.

It was no longer enough to ask:

“Where do we rank?”

There was another question:

“What does the AI say about us, and is it accurate?”

That question became central to his work.

Jarno describes his work as having two audiences: the people reading a website and the AI systems trying to understand it.

That idea has influenced how he approaches website architecture and content.

A page should work for a person who is in a hurry, while also giving a system enough clarity to identify the business, its services, evidence and expertise.

That means clear page purpose, direct answers, logical headings, consistent facts and strong internal connections.

AI Visibility Should Be Measured

One of Jarno's strongest themes is measurement.

AI search can sometimes appear mysterious. Ask an AI system a question, receive an answer, take a screenshot and it can be tempting to conclude that a business is either visible or invisible.

Jarno argues that this isn't enough.

AI outputs can vary depending on the platform, wording, location and time.

A more useful approach is to create a repeatable measurement process.

His recommendation is straightforward:

Start with 8–15 real customer questions.

Keep the wording stable.

Test those questions across the relevant AI platforms.

Then record the results.

The goal isn't to create a perfect score.

The goal is to establish a trustworthy baseline that makes changes visible.

Think of AI Visibility Like Regression Testing

Jarno compares an AI visibility benchmark to a software regression test suite.

The analogy is particularly useful for developers.

If the test changes every time you run it, it becomes difficult to determine whether the software changed or the test changed.

The same applies to AI search.

If the prompt changes every time, you cannot reliably determine whether a change in the result came from an improvement in the brand's visibility or simply from asking a different question.

Jarno recommends keeping a stable core set of prompts while adding new questions over time when necessary.

It turns AI visibility from a collection of interesting screenshots into something that can be observed and compared.

A Mention Isn't the Same as a Citation

Another distinction Jarno considers important is the difference between mentions and citations.

An AI system might mention a business in an answer.

But that mention could be vague, incorrect or simply part of a long list.

A citation provides a stronger signal because it connects a specific claim to a source.

Both matter, but they answer different questions.

Visibility is useful.

But trusted and accurate attribution is more valuable.

For Jarno, metrics should therefore be separated rather than combined into one simplistic number.

He focuses on areas such as:

Visibility
Mentions
Citations
Accuracy
Meaningful or qualified actions

The distinction helps businesses understand not only whether AI systems are talking about them, but how they are representing them.

Structured Data Helps AI Understand the Pieces

Jarno's work also places significant emphasis on Schema.org structured data and entity clarity.

He doesn't describe Schema.org as a magic solution.

Instead, he sees it as a useful shared vocabulary that can help systems identify things such as:

Products
Services
People
Organisations
Locations
FAQs
Relationships between entities

But structured data becomes much more useful when it matches the visible content on a website and the information remains consistent across the site.

Adding schema isn't a substitute for having clear information.

The underlying content still matters.

What About `llms.txt`?

There has been considerable discussion around llms.txt as websites adapt to AI systems.

Jarno takes a measured approach.

He sees llms.txt as an experiment and a helpful orientation layer, rather than a visibility button.

It may make important pages and topics easier to discover, but it cannot replace useful content, technical quality, reputation or independent evidence.

Jarno's approach is simple:

Implement sensible experiments, then measure whether they actually change anything.

That philosophy is consistent throughout his work.

Don't adopt something simply because it is currently being discussed.

Test it.

Measure it.

Then decide what the evidence tells you.

Make Pages Easy to Quote

One of Jarno's ideas is that websites should be “easy to quote, not merely easy to crawl.”

That requires thinking about how information is presented.

His practical recommendations include:

Put the main answer where people can find it quickly.
Use descriptive headings.
Explain important terms clearly.
Support claims with evidence.
Show authorship.
Include update dates where appropriate.
Avoid hiding important facts inside marketing language.

The goal is to make information easier for an AI system to understand and represent accurately.

But these practices also make websites easier for humans to understand.

That overlap is important.

The AI Search Advice He Thinks Is Overhyped

The AI search industry is moving quickly, and with that comes a constant stream of new tactics.

Jarno is skeptical of the idea that one file, one prompt trick or one piece of schema can suddenly make a business “rank in ChatGPT.”

For him, AI visibility isn't a switch.

It is built from several things working together:

Helpful content + technical accessibility + entity clarity + credible references + ongoing measurement.

This is also why he prefers experimentation over blindly following trends.

If something has a plausible mechanism, can affect how people discover businesses and can be tested responsibly, he sees value in running a small experiment.

If it creates excitement but cannot be measured or explained, he treats it as noise until stronger evidence appears.

What AI Search Reveals About Businesses

One of Jarno's biggest surprises has been how uneven AI search results can be.

A business may be described accurately on one platform and poorly — or not at all — on another.

Even more interestingly, AI systems can sometimes produce confident-sounding answers when the underlying business information is incomplete or mixed up.

That creates a different kind of challenge for businesses.

It's not simply about gaining visibility.

It's about making sure the information that becomes visible is correct, consistent and supported by evidence.

Building AEOvara

Jarno founded AEOvara to help businesses navigate search in the AI era.

The challenge is partly technical and partly educational.

Many business owners already understand concepts such as Google rankings and website traffic.

But asking:

“How do AI systems describe my business?”

is still a relatively new question.

Jarno believes the answer is to keep the conversation practical.

Instead of selling mystery, show businesses:

What AI systems currently say
Where information is missing
Where information is inaccurate
What can be improved
What changed after the work

That makes a new category easier to understand.

It also keeps the focus on measurable outcomes rather than hype.

From AI Visibility to Repeatable Benchmarks

A major part of Jarno's current exploration is making AI visibility more reproducible.

He has developed an ongoing AI visibility benchmark and published practical guides around measuring how AI systems discover and cite content.

The idea is straightforward: if businesses want to improve their AI visibility, they need a way to observe what is happening before and after making changes.

That means stable prompts, repeated observations and clearly separated metrics.

Instead of asking whether a website is “good at AI search,” businesses can begin asking more specific questions:

What changed?

Where did it change?

Was the information accurate?

Was the business cited?

Did the change lead to a meaningful outcome?

Those questions turn an abstract concept into something that can be investigated.

Lessons From Photography

Jarno's work isn't limited to SEO and AI search.

He also has a background in professional photography and visual content through Kuvaajankulma.

That experience has influenced how he thinks about discoverability and trust.

Photography taught him that presentation matters.

A website needs a clear point of view, coherent presentation and real evidence.

It also taught him to respect the user's attention.

The best page isn't necessarily the one containing the most information.

It's the one that makes the right information easy to understand.

That principle carries naturally into his thinking about AI search.

Where Search Goes Next

Jarno doesn't see traditional search disappearing completely.

He expects it to remain important, particularly for research, navigation and comparison.

At the same time, he believes AI assistants will increasingly become the starting point for many questions, especially broad or conversational ones.

Rather than imagining a complete replacement, he sees a more blended search journey emerging.

People may move between traditional search engines, AI assistants, websites and other interfaces depending on what they are trying to accomplish.

For businesses, that means the underlying information needs to work across more than one type of discovery experience.

Advice for Developers and Small Businesses

For developers, technical founders and small businesses thinking about AI search, Jarno recommends starting with fundamentals rather than chasing every new trend.

His practical starting points are:

Keep business facts accurate and consistent.
Make important pages technically accessible.
Answer real customer questions clearly.
Use relevant structured data.
Make it clear who is responsible for the content.
Build a stable set of prompts and measure them over time.
Focus on changes that can actually be verified.

The common thread is simple:

Improve what you can measure.

A Lesson From Building a New Category

One lesson Jarno learned while building AEOvara is that too much jargon can make a new field harder to understand.

Technical terminology may be useful internally, but customers ultimately need answers to practical questions.

Are we being understood correctly?

Are we being recommended for the right reasons?

What changed after the work?

Those questions provide a much clearer way to explain the value of AI search visibility.

AI Search Is an Information-Quality Challenge

Jarno believes one of the biggest misunderstandings around AI search is treating it simply as a temporary traffic-generation trick.

He sees something broader.

AI search is also an information-quality challenge.

If a business cannot explain itself clearly, consistently and with evidence, AI systems will have a harder time understanding it correctly.

That makes AI visibility partly a technical problem, but also a content, information architecture and trust problem.

What's Next for AEOvara?

Jarno is most excited about making AI visibility more reproducible.

That includes practical benchmark methods, clearer reporting and tools that help smaller businesses understand how answer engines see them.

AEOvara has already explored this through practical guides, an llms.txt generator and ongoing AI visibility benchmarking.

The broader goal is to make AI search visibility less mysterious and more measurable.

Rather than asking businesses to trust a new acronym or a new optimization trick, the approach is to establish a baseline, run experiments, observe changes and learn from the evidence.

That mindset — measure what changes rather than simply following the latest trend — runs through Jarno's approach to AI search.

About Jarno S

Jarno S is the founder of AEOvara, based in Lappeenranta, Finland.

His work focuses on Answer Engine Optimization (AEO), Generative Engine Optimization (GEO), AI Search Optimization, Technical SEO, Schema.org structured data and LLM Optimization (LLMO).

He works across search ecosystems including Google Search, ChatGPT, Gemini, Perplexity and Copilot, exploring how AI answer engines discover, interpret and cite web content.

His current work includes entity clarity, structured data, repeatable AI visibility benchmarks and practical ways to connect traditional SEO with AEO, GEO and LLMO.

His guiding principle is simple:

“Build for people. Structure for understanding. Measure what changes.”

CoderLegion Developer Stories

This story is part of CoderLegion Developer Stories, where developers, engineers, technical founders and technology professionals share their experiences, challenges, projects and lessons from their journeys.

The goal is to give the CoderLegion community a closer look at the people and ideas behind the technology.

Interviewed and edited by Mehadi Hasan, Community & Editorial Team at CoderLegion.

From Data Engineering to AI Systems: Hardik Goel’s Developer Journey in the Age of AI

Fri, 18 Sep 2026 09:57:54 +0000

From Data Engineering to AI Systems: Hardik Goel’s Developer Journey in the Age of AI

“A prompt is a single turn of hope. A loop is a system.”

Software development has changed dramatically over the past two decades.

The tools have changed. Infrastructure has changed. Development workflows have changed. And now AI is changing not only how developers write software, but also how they think about building and operating software systems.

For Hardik Goel, however, one thing has remained constant: understanding what happens underneath the technology.

His journey began with a fascination for code, machines, and especially the way data is structured and moves through a system. He started his career as a backend and QA engineer before moving into Big Data, data engineering, and machine learning.

Today, his focus increasingly sits at the intersection of software engineering and AI — particularly the systems, guardrails, evaluation techniques, and workflows needed to make AI useful in the real world.

This is Hardik Goel’s Developer Journey.

Where It Started: Understanding What Happens Underneath

Hardik says he has always enjoyed writing code and understanding the dynamics behind machines.

Even today, the underlying data structure remains one of the things that fascinates him most.

“Once you know how data is laid out and how it moves, everything sitting above it starts to make sense.”

He began his career as a backend and QA engineer. Then Big Data and Hadoop started emerging as major areas of interest.

The idea of working with enormous volumes of data immediately caught his attention.

One particular observation helped connect the pieces for him.

Hardik was fascinated by how Netflix and other streaming platforms could work with huge amounts of data while still providing users with an uninterrupted experience.

The machines themselves had not fundamentally changed.

The difference was in how the system around them had been designed.

That realization pushed him deeper into Big Data, eventually leading him into data engineering and machine learning — areas he has continued exploring ever since.

Two Decades of Technology: What Changed and What Didn't

After spending around two decades in technology, Hardik has watched many technologies rise, fall, and evolve.

But he believes many of the things that matter most in software engineering have remained remarkably consistent.

Requirements are still unclear on day one.

The difficult part of a project is often the final ten percent.

Production systems still break because of seemingly ordinary problems — an unexpected schema change, a retry storm, a timezone issue, or a disk running full.

And debugging still involves reading logs and forming a hypothesis.

For Hardik, a good engineer is still the person willing to ask the uncomfortable question during a design review rather than simply being the person who types the fastest.

At the same time, he identifies several technologies and practices that genuinely transformed the daily life of developers.

Version control, code review culture, CI/CD, cloud infrastructure with elastic storage and compute, containers, observability, and iterative development all made a lasting difference.

More recently, AI assistance inside the development environment has become another significant change.

Hardik also sees a recurring pattern in technology adoption.

Technologies that remove toil, shorten feedback loops, and make failure visible tend to survive.

Technologies that promise to remove thinking are much less likely to do so.

The Other Side of Technology Hype

Hardik has also seen plenty of technologies become overextended beyond the problems they were actually suited to solve.

He points to Big Data being adopted as a buzzword before companies knew which questions they were trying to answer.

Data lakes could become data swamps when nobody owned governance.

NoSQL could be presented as a replacement for relational databases rather than as a complement.

He has seen blockchain proposed for almost everything, microservices treated as the default architecture even for very small teams, and serverless presented as an answer to almost every problem.

Now, he sees similar enthusiasm around autonomous agents shipping software end to end without human oversight.

For Hardik, the pattern is straightforward:

“Technology that removes toil, shortens the feedback loop and makes failure visible tends to survive. Technology that promises to remove thinking does not.”

From Writing Code to Thinking About Systems

One of the biggest changes in Hardik's own approach to software has been moving beyond the individual piece of code.

He believes writing individual pieces of code is no longer the primary moat.

Instead, developers need to think about everything surrounding the code.

That includes proper guardrails, Responsible AI, and evaluation techniques such as using an LLM as a judge.

The developer increasingly needs to understand the complete path through the system and define how AI should operate within it.

Hardik describes the evolution in his thinking through a simple shift.

Instead of asking:

“How do I write this function?”

he now thinks about:

“What does this function do to the system at three in the morning when it behaves differently than it did in testing?”

That changes the unit of design.

The contract between components matters.

So do failure modes, fallbacks, and the signals that tell engineers something has gone wrong before the user discovers it.

Despite the rapid progress of AI, Hardik believes we are still some distance away from fully autonomous AI.

When AI Changed the Way He Worked

Hardik has always tried to explore new technology and keep up with advancements in the field.

When AI coding tools became increasingly capable, one immediate benefit stood out: they could reduce the pain of searching across Stack Overflow and countless browser tabs for a solution.

The tools could provide results that were comparable to — and sometimes better than — what he might find through traditional searching.

But the bigger realization came later.

It wasn't simply that AI could generate code.

It was that AI began changing the order of his work.

Hardik noticed that he was reviewing more than he was writing.

More of his time was going into framing the problem and checking the output rather than producing the first draft himself.

That was the point when AI became more than another tool in the toolbox.

It had started changing the developer workflow itself.

Beyond Prompt Engineering: The Loop Is the System

One of Hardik's strongest ideas is that developers can become too focused on writing better prompts.

The goal shouldn't simply be to find the perfect wording that convinces an AI model to produce the correct answer.

Instead, developers should design systems where mistakes are cheap, visible, measurable, and recoverable.

Hardik puts it this way:

“A prompt is a single turn of hope. A loop is a system.”

A reliable AI workflow needs much more than a prompt.

It needs a definition of what good output actually means for the task.

It needs an evaluation set based on real failure cases from the domain.

It needs automated checks that run against the output.

It needs a retry path that is genuinely different from the first attempt rather than simply sending the same prompt again.

It needs logging so developers can identify drift before users experience it.

And it needs a clear point where the loop stops and a human signs off.

Once these elements are in place, Hardik argues, the prompt itself becomes less important than many people assume.

A mediocre prompt inside a well-designed loop can be more useful than a carefully crafted prompt with nothing around it.

The loop also has another advantage: it can continue working even when the underlying model changes.

What Happens to the Developer?

If AI increasingly handles parts of the inner coding loop — writing, testing, debugging, and iterating — the role of the developer begins to expand.

Hardik agrees that developers may increasingly take on responsibilities associated with architecture, product thinking, reviewing, and system design.

He also points to roles such as the Forward Deployed Engineer (FDE), where an engineer works directly with clients, understands the business problem, contributes to productization, and architects and builds the technology around it.

The important change, however, is broader than a new job title.

Hardik believes the set of responsibilities carried by developers is becoming wider rather than narrower.

The developer may need to decide what should not be built.

They may need to own the quality bar for output they did not personally type.

And they may be accountable for a system whose individual components they did not write line by line.

For Hardik, that last responsibility may become particularly important when thinking about seniority in software engineering.

The Human in the Loop

As AI systems become more capable, Hardik believes the human role becomes even more important in areas involving direction, context, priorities, and consequences.

He is concerned about a future in which people place so much trust in AI systems that they lose their own identity and judgment in the process.

That is where he sees Responsible AI becoming important.

Human knowledge about the direction a project should take — based on experience and independent thinking — remains valuable.

For Hardik, there are several questions he does not expect to simply hand over to AI:

Which problem deserves to be solved?
What trade-offs are acceptable?
What is acceptable to get wrong?
What is not acceptable to get wrong?
What did the customer actually mean rather than simply write in a ticket?

At the same time, Hardik doesn't believe all expert judgment will remain exclusively human.

Some of what people call judgment is really pattern recognition developed through repeated experience.

Machines can become very good at that kind of pattern recall.

The distinction, for him, is judgment that carries consequences.

When a decision goes wrong, someone still needs to stand behind it.

Building Reliable AI Systems

For Hardik, one of the most important lessons of working with AI systems is that something looking impressive in a demo doesn't necessarily mean it is ready for production.

A production AI system needs checks and balances.

He places particular importance on observability, governance, security, and proper monitoring.

The system should provide enough visibility for engineers to understand what it is doing instead of relying on users to discover problems first.

For Hardik, reliability also means understanding the kinds of responses a model can produce and the degree of deviation it can take.

That deviation needs to be contained and understood.

Moving from an AI prototype to a real system also introduces a large amount of unglamorous engineering work.

Data changes.

Models don't automatically understand those changes.

Evaluation sets may not represent real production traffic.

And assumptions that seemed reasonable during a prototype can become significant problems once the system is exposed to real users.

For Hardik, building reliable AI therefore requires many of the engineering disciplines that have always mattered in software — with additional attention to model behavior, evaluation, monitoring, governance, and security.

The Developer's Job Is Changing, Not Disappearing

Hardik's journey offers an interesting perspective on the current AI transition.

He doesn't see the future simply as humans writing less code while machines write more.

Instead, he sees the developer's responsibility expanding.

The developer increasingly becomes the person who understands the problem, designs the system, defines the quality bar, creates the feedback loops, evaluates AI output, and takes responsibility for what ultimately reaches users.

The syntax may become easier.

The first draft may become faster.

But the surrounding engineering problem remains.

And perhaps that is the part of software development that has changed the least over the past two decades.

Lessons From Twenty Years in Technology

Looking across Hardik's career, there is a clear thread connecting his early interest in data structures with his current interest in AI systems.

The technology keeps changing.

The underlying questions remain remarkably similar.

How does data move?

What happens when a component fails?

How do you know whether something is working?

How do you detect problems before users do?

What should the system do when reality differs from the assumptions made during development?

AI adds a new layer to those questions, but it doesn't make them disappear.

If anything, it makes understanding the system around the technology even more important.

Hardik Goel's Perspective on the AI Era

Hardik's Developer Journey sits at an interesting point between two generations of software development.

He began in an era where developers wrote and debugged code largely by hand.

He moved through the rise of Big Data, data engineering, machine learning, cloud infrastructure, CI/CD, containers, and observability.

Now he is working through another major shift: AI-assisted and agentic software development.

His central message is not that developers should stop using AI.

He is already using it himself.

The more important question is how developers use it.

For Hardik, the future isn't simply about generating more code.

It is about building better systems around the intelligence we now have access to — systems that can evaluate, observe, recover, and involve humans when judgment and responsibility matter.

And that brings the conversation back to where his own journey began: understanding what happens underneath the surface.

About Hardik Goel

Hardik Goel is a technology professional with a background spanning backend engineering, QA, Big Data, data engineering, machine learning, and AI systems.

His work and writing explore software engineering, AI-assisted development, agentic workflows, Responsible AI, and the changing role of developers as AI becomes part of the software development process.

His perspective is shaped by years of working with systems where understanding the underlying data, architecture, failure modes, and production behavior matters as much as writing the code itself.

CoderLegion Developer Stories

This story is part of CoderLegion Developer Stories, a series featuring developers, engineers, founders, and builders sharing their experiences, lessons, projects, and perspectives on technology.

Interviewed and edited by Mehadi Hasan, Community & Editorial Team at CoderLegion.

From HTML to Legal Automation: Dhardingsea Developer’s Journey of Building Software That Solves Real

Sun, 13 Sep 2026 08:19:22 +0000

A CoderLegion Developer Story featuring Dhardingsea Developer

Interviewed and edited by Mehadi Hasan, Community & Editorial Team at CoderLegion

Some developers follow a straight path.

Others follow problems.

For Dhardingsea Developer, programming started with computers, HTML, and web development. From there, the journey moved through computer repair, malware removal, Chrome extensions, Windows tools, games, production automation, and AI tooling.

Today, that work spans very different kinds of software — from browser games to automation for the legal-process-serving industry.

At first, those projects might seem unrelated.

But there is a common thread:

Finding ways to use computers to mend, improve, and simplify things encountered in real life.

That approach has also shaped a particular engineering philosophy: build locally when possible, respect user privacy, minimize unnecessary permissions, listen to users, and encode knowledge into software so it doesn't disappear when people do.

It Started With Computers

As a child, computers were something Dhardingsea Developer naturally connected with.

They were understandable.

They were something that could be explored.

The first real attraction was HTML and web development.

That eventually expanded into computer repair and malware removal, giving them exposure to computers from a different perspective.

Programming wasn't isolated from the rest of technology.

It was connected to understanding how computers worked, what could go wrong, and how problems could be fixed.

That practical experience became an important foundation for everything that came later.

Turning Real-Life Problems Into Software

One of the defining characteristics of the journey has been finding ways to use computers to improve things encountered in everyday life.

With a background spanning marketing and web development, combined with experience working at a small computer company, Dhardingsea Developer gradually developed a broad understanding of technology.

Instead of focusing on a single category of software, they kept finding different problems that could potentially be solved with computers.

That led to a wide range of projects:

Chrome extensions
Windows desktop tools
Browser games
Production automation
AI tooling
Developer tools

The technologies may be different.

The underlying approach isn't.

Find something that could work better.

Understand the problem.

Build something.

Then learn from what happens.

When Software Has Real-World Consequences

One of the biggest differences between Dhardingsea Developer's personal projects and professional work is the environment in which the software operates.

Their work in the legal-process-serving industry comes with consequences that a game or experimental project simply doesn't have.

A small mistake can have significant financial consequences.

"An error, a small click of a button can send duplication of filing fees and a loss of thousands."

That changes the engineering process.

In a creative project, you can experiment and recover from mistakes relatively easily.

In legal-process software, the consequences of a mistake can affect real documents, filings, fees, and workflows.

As a result, simulation and review become extremely important.

Before launching something, it is necessary to think through what could happen.

And even after launch, there is another challenge:

maintenance.

Software doesn't simply need to work once.

It needs to continue working as the surrounding environment changes.

For Dhardingsea Developer, this is very different from building a game or creative project.

"The purpose is function; the other is function of purpose."

The distinction is important.

One environment demands correctness and reliability.

The other gives more room for experimentation and creative expression.

Both teach valuable lessons.

Encoding Institutional Knowledge Into Software

One of the most interesting ideas in Dhardingsea Developer's profile is the concept of encoding institutional knowledge into software.

What does that actually mean?

It starts with understanding how people solve problems.

Someone who has spent years working in a particular environment develops knowledge that may never be written down.

They know how to untangle a problem.

They know what tends to go wrong.

They know what to check before something breaks.

They know why a particular decision was made.

That knowledge can disappear when the person leaves.

Software can preserve some of it.

For Dhardingsea Developer, comments, telemetry, documentation, and implementation details can capture not only what the software does, but why it does it.

"I find it valuable to put the why for someone to have the opportunity to learn even if it's to change."

That last part is important.

Documentation isn't necessarily about making decisions permanent.

It is about making the reasoning visible so that someone else can understand it, question it, and improve it.

The Chromium Autofiler That Started Something Bigger

One of the projects that taught Dhardingsea Developer the most was Chromium Autofiler.

It was one of their early projects, but its impact went beyond the project itself.

Working on it introduced them to areas such as:

Database storage
Encryption
Browser tooling
Software architecture
Building their own website
Creating games
Working with different tools

The project became a starting point.

Not necessarily because it was the most successful thing they built, but because it opened the door to everything that came afterward.

Sometimes an early project matters because of what it teaches you rather than what it becomes.

Learning the Hard Way With a Chrome Extension

One of the more recent projects was a local-first Dota 2 companion built as a Chrome extension.

Dota 2 provides an API for gathering information, while also having a large social gaming community.

The project forced Dhardingsea Developer to think carefully about something that is easy to overlook:

The user doesn't necessarily understand the technical limitations behind the software.

A user may not know about API rate limits.

They may simply expect the software to work.

That creates an interesting responsibility for developers.

Should software automatically impose restrictions on behalf of users?

Should it assume that users don't understand the consequences?

Or should it allow the system to behave according to the capabilities available?

Dhardingsea Developer describes this tension candidly.

"Imposing a limit on a user's behalf for safety is a weird call, who am I to be so arrogant?"

The experience ultimately reinforced another lesson:

Consider the user's needs before they become problems.

Building a tool isn't only about making the technology work.

It is about understanding how people will actually use it.

Shipping Something Before It's Perfect

Another lesson that has become important to Dhardingsea Developer is knowing when to ship.

Developers can spend months working toward an idea.

During that time, motivation can disappear.

Budgets can change.

Opinions can change.

The original idea itself can change.

And sometimes the only people who can tell you whether the software is useful are the people actually using it.

That changed the way Dhardingsea Developer thinks about incomplete software.

"The user will say, the user will know."

Instead of waiting for every feature to be perfect, shipping something allows users to provide feedback.

That feedback can become part of the development process.

An incomplete product can sometimes teach you more than a perfect product that nobody has seen.

"It's easier to ship something incomplete, you can find so much more feedback from users looking to help play a role."

For Dhardingsea Developer, shipping isn't necessarily the end of development.

It's the beginning of another feedback loop.

Privacy Is a Requirement, Not a Feature

A strong theme across the projects is privacy.

Dhardingsea Developer's approach emphasizes local-first software, minimal permissions, and avoiding unnecessary accounts or telemetry.

The reasoning is simple.

Users are becoming increasingly tired of giving away their data.

They don't necessarily want their history, behavior, or personal information collected simply because they use a piece of software.

And with AI becoming more deeply integrated into technology, that concern becomes even more important.

"It's important to me to hold user security as a priority."

The goal isn't to build a system around advertising or tracking clicks.

It's to build software for people.

That means treating the user as something more important than a source of telemetry.

The Shortcut They Refuse to Take

Every developer has shortcuts they are willing to take.

And every developer has some shortcuts they refuse to take.

For Dhardingsea Developer, one of those is cross-analysis and continuous learning.

Their current workflow involves sending files between different character accounts to review information from different perspectives.

The data can then go through a kind of "levelup" process designed to identify gaps in skills or processes and make improvements.

It consumes time.

It consumes processing power.

It would be much easier to simply accept the current state.

But Dhardingsea Developer considers the process non-negotiable.

"We must learn."

That philosophy fits closely with their broader approach to software.

The system isn't supposed to simply produce an answer.

It should help identify weaknesses and improve over time.

The Lesson They Wish They Learned Earlier

Sometimes the biggest lessons aren't architectural.

Sometimes they're surprisingly small.

For Dhardingsea Developer, one of those lessons is:

Spelling really matters.

A random .

An unexpected capital letter.

A small typo.

Something that looks insignificant can become the reason you spend time debugging something that should have worked.

"Debugging is an endless task at times."

Looking back, they wish they had paid more attention to spelling much earlier.

It's a humorous lesson, but also a very real one.

Computers don't care what you meant.

They care what you actually wrote.

Learning Databases for the Next Stage

Looking ahead, one of the areas Dhardingsea Developer wants to explore more deeply is databases and structured data.

They describe having relatively little experience in this area and increasingly feeling that it is limiting what they can build.

In particular, it becomes important when thinking about MMO-style games.

Games with persistent worlds require more than interfaces and mechanics.

They require systems capable of storing, retrieving, updating, and organizing large amounts of structured information.

For Dhardingsea Developer, learning more about databases is therefore not simply about learning another technology.

It's about removing a limitation on what they can build next.

The Advice: Have Fun

For developers who feel stuck or believe they aren't progressing quickly enough, Dhardingsea Developer doesn't recommend obsessing over speed.

The advice is much simpler:

"Have fun."

Joy is an important part of learning.

If you're struggling, that doesn't necessarily mean you're failing.

It can mean you're already doing something valuable.

You're learning something difficult.

You're pushing against the limits of what you currently understand.

"If you are struggling, that means you are already succeeding."

The important thing is to keep the curiosity alive.

Learn something new.

Try a different approach.

Even if the new approach is simply a different way of doing something as basic as 2 + 2.

The point isn't always immediate productivity.

Sometimes the point is discovering another way to think.

You Can Succeed at Anything — If You Luck Out Hard Enough

There is one line on Dhardingsea Developer's profile that stands out:

"You can succeed at anything, if you just luck out hard enough."

The phrase comes from Futurama.

But for Dhardingsea Developer, it also carries a deeper meaning.

Success isn't entirely controlled by effort.

There is timing.

There is circumstance.

There is being in the right place at the right moment.

There are things outside our control.

But that doesn't mean effort is meaningless.

Instead, the idea is to keep putting yourself in situations where luck has a chance to find you.

As they put it:

"I'm just a guy, but maybe with some effort we can luck out hard enough haha."

It's a surprisingly fitting conclusion to this journey.

Building Through Curiosity

Looking at Dhardingsea Developer's journey, the projects may initially seem scattered.

Chrome extensions.

Games.

Windows tools.

Legal automation.

AI tooling.

Databases.

Browser APIs.

But there is a common thread.

Curiosity.

A problem appears.

Something doesn't work.

There is an opportunity to make it better.

So they build.

The result isn't always perfect.

Sometimes it ships incomplete.

Sometimes the platform has unexpected restrictions.

Sometimes the software creates new problems.

Sometimes a tiny spelling mistake creates hours of debugging.

But every project becomes another source of knowledge.

And that knowledge gets carried into the next thing.

What Comes Next

The next chapter is likely to involve more databases, structured data, automation, AI, and increasingly ambitious software projects.

But the underlying philosophy seems unlikely to change.

Build things that solve real problems.

Listen to users.

Protect their privacy.

Document the reasoning.

Don't be afraid to ship something incomplete.

Keep learning.

And, most importantly, keep enjoying the process.

Because sometimes the best thing a developer can do is simply keep building long enough to luck out hard enough.

About Dhardingsea Developer

Dhardingsea Developer is an independent developer and builder based in Iowa.

Their work spans Manifest V3 Chrome extensions, Windows desktop tools, idle games, production automation, and AI tooling for the legal-process-serving industry.

Their broader development philosophy centers around encoding institutional knowledge into software — turning schemas, workflows, compliance rules, and practical experience into tools that can consistently reproduce that knowledge.

They are particularly interested in local-first software, privacy, minimal permissions, automation, browser extensions, games, AI tooling, and structured data.

You can follow their work on CoderLegion and DHSeaDev.online.

About This Developer Story

Developer: Dhardingsea Developer
Username: @DHSeaDev
Series: CoderLegion Developer Stories
Interview format: Q&A
Interviewed and edited by: Mehadi Hasan, Community & Editorial Team at CoderLegion

This story was created from Dhardingsea Developer's own answers and experiences shared during the CoderLegion Developer Stories Q&A. The article preserves the developer's personal perspective and intentionally keeps the informal character of their responses.

Building MyZubster: Daniel Ioni’s Journey From an Idea to an Open-Source Ecosystem

Sun, 13 Sep 2026 08:13:31 +0000

Building MyZubster: Daniel Ioni’s Journey From an Idea to an Open-Source Ecosystem

A CoderLegion Developer Story featuring Daniel Ioni

Interviewed and edited by Mehadi Hasan, Community & Editorial Team at CoderLegion

What happens when a software project grows beyond being an application?

For Daniel Ioni, that question became the starting point for MyZubster — an open-source ecosystem exploring artificial intelligence, environmental projects, digital identity, community participation, robotics, IoT, decentralized infrastructure, and more.

But MyZubster didn't begin with a large team, a finished business plan, or even a clearly defined product category.

It began with a question:

Can technology help people, communities, and organizations turn useful real-world activity into visible and verifiable value?

That question gradually became an evolving ecosystem.

And Daniel is still building it, learning from it, and discovering what it can become.

It Started With a Bigger Question

MyZubster began with an interest in connecting technology with real-world problems involving the environment, local resources, circular economy, and collaboration.

As the project developed, Daniel became increasingly interested in the gap between digital platforms and real-world action.

Many digital systems are designed primarily to attract attention.

Daniel wanted to explore something different.

Could a platform help coordinate contributions, document evidence, and connect people with meaningful projects?

That idea eventually grew into several connected components:

A public open-source platform
Community and contributor profiles
Environmental missions and pilot projects
A marketplace for products and services
AI-assisted guidance
Digital characters and narrative identities
Evidence, provenance, and impact measurement
Experimental blockchain and decentralized-infrastructure components

But building such a broad ecosystem created another challenge.

How do you clearly communicate what actually exists?

That question would become one of Daniel's most important lessons.

An Idea Is Not an Implementation

One of the principles Daniel has developed while building MyZubster is the importance of clearly separating different states of a project.

A proposal is not an implementation.

A pull request is not a deployment.

A visual concept is not proof that a feature exists.

And a potential collaboration is not a confirmed partnership.

"Building in public requires being honest about those differences."

Daniel began explicitly distinguishing between states such as:

PROPOSED
IMPLEMENTED
VERIFIED
SIMULATION
FICTION
TO_CONFIRM
TO_VERIFY

At first, this might seem overly cautious.

But for a project combining AI, storytelling, blockchain, environmental ideas, and community participation, it solves a genuine problem.

An attractive narrative can move much faster than the evidence underneath it.

For Daniel, documentation therefore became more than a description of the code.

It became part of the project's governance.

Building Zorgax

As MyZubster became more complex, Daniel needed a way to help people understand and navigate the growing ecosystem.

That layer became Zorgax.

Zorgax is the AI and knowledge component of MyZubster.

Its intended role isn't to replace human responsibility or make uncontrolled decisions.

Instead, it is designed to help users:

Understand available tools
Navigate projects and documentation
Find relevant missions
Organize authorized information
Interact with the ecosystem
Connect technical knowledge with real-world objectives

This led Daniel to become particularly interested in human-in-the-loop systems.

AI can organize information, generate explanations, inspect technical states, and support decision-making.

But there are boundaries.

AI should not silently invent evidence, grant consent, confirm partnerships, or perform sensitive actions without human authorization.

Daniel describes the principle simply:

Automation can assist the process, but humans must retain authority over consequential decisions.

That principle has increasingly influenced the architecture of MyZubster and Zorgax.

Learning to Build in Public

GitHub became the main source of truth for the project.

As MyZubster expanded, its public repositories began containing code, documentation, roadmaps, characters, visual assets, experiments, and technical proposals.

Working publicly forced Daniel to become more precise about how he described the state of different components.

It also taught him that building in public is not simply about showing what you are building.

It is about making the development process understandable to other people.

That means being clear about what is finished, what is experimental, and what remains uncertain.

For Daniel, transparency became an engineering principle rather than simply a communication strategy.

The Challenge: Turning a Huge Vision Into a Simple Experience

One of the biggest challenges Daniel has faced is turning a large vision into small, understandable experiences.

MyZubster may contain many interconnected ideas.

But visitors don't experience an architecture diagram.

They experience a homepage.

A button.

A loading screen.

A registration form.

If the first step isn't clear, the larger vision doesn't matter.

This became particularly obvious when Daniel looked at product analytics.

People were visiting the website, but not everyone was progressing toward meaningful actions.

That raised a series of practical questions:

Do visitors understand what MyZubster is?
Is the main action obvious?
Can they try something before registering?
Do they know what happens after clicking?
Are we measuring visits or actual participation?
Does the experience work well for mobile visitors coming from Facebook?

The focus began shifting.

Instead of simply adding more concepts, Daniel started focusing on improving the path toward a user's first meaningful result.

From Visual Storytelling to an Interactive World

Visual storytelling became another important part of MyZubster.

The project includes images, comic panels, and videos connected to Zorgax, environmental projects, circular economy, the Space Station, community characters, and the MyZubster Metaverse.

For Daniel, these visuals serve several purposes.

They can explain complex ideas.

They can preserve project history.

They can create a recognizable world.

They can make future directions easier to discuss.

And they can help contributors understand where they fit into the ecosystem.

But Daniel deliberately maintains a boundary between storytelling and evidence.

An illustration can show an imagined interface or a future environment.

It doesn't prove that every feature shown in that image already exists.

That distinction became particularly important when developing the MyZubster comic.

The MyZubster Comic

The MyZubster comic isn't simply marketing material.

Daniel sees it as a kind of narrative interface.

It connects software, community, environmental ideas, characters, and digital culture.

The public gallery explores themes such as:

The city as a living organism
Zorgax as a guide
Neon Plaza
The Space Station
Community networks
Circular economy
Digital identity
The history of online communities

The comic gives people another way to enter the ecosystem.

Code explains how a system works.

Narrative can help people understand why the system exists and where they might belong inside it.

That distinction has become an important part of Daniel's approach to building MyZubster.

Preserving Digital Memory With Darkode

Another part of the project is Darkode, which represents a layer of personal and cultural memory connected to the origins and influences behind MyZubster.

For Daniel, publishing historical material creates an important responsibility.

There needs to be a distinction between:

Documented facts
Personal recollections
Archived evidence
Narrative interpretation
Information that remains uncertain

He didn't want historical material to present every memory as independently verified fact.

Instead, Darkode was designed to preserve context while acknowledging the limits of the available evidence.

That reflects a broader lesson Daniel has learned while building MyZubster:

Transparency also means showing uncertainty.

Creating Neon Plaza

The Metaverse component began as a prototype involving guest avatars, movement, presence, chat, emotes, and thematic areas.

Eventually, it became Neon Plaza, a public interactive environment.

But there was a problem.

The word "Metaverse" created more questions than answers.

Visitors didn't immediately understand what they were supposed to experience or why they should enter.

So Daniel and the team simplified the onboarding process.

A visitor can now:

Choose a public display name
Create a temporary guest character
Enter without registering
Enter without a wallet
Use the experience without a VR headset
Move using WASD or the arrow keys
Visit portals
Interact through chat and emotes
Discover other parts of MyZubster

The idea was simple:

Let users experience value before asking them to commit.

That principle changed the way Daniel thought about onboarding.

The First Mission

An open digital world can still feel empty if visitors don't know what to do.

So the team introduced a simple first mission guided by Zorgax:

Move your character and reach one of Neon Plaza's glowing portals.

The mission is intentionally simple.

Its purpose is to transform a passive visitor into an active participant.

The onboarding journey became:

Arrive at the homepage
Enter Neon Plaza as a guest
Create a character
Begin the first mission
Reach a portal
Complete the mission
Receive an invitation to verify the character
Register to preserve the experience

The lesson was important.

Meaningful onboarding doesn't necessarily require a huge tutorial.

It requires one understandable action followed by a visible result.

Working With Nicola and N4K48

One of the most meaningful parts of the project has been Daniel's collaboration with his friend Nicola.

Daniel helped Nicola use Zorgax and set up MyZubster on his computer.

Nicola's character, N4K48, then became an experimental participant inside Neon Plaza.

This changed the nature of the project.

It was no longer only about abstract user profiles.

There was now a real person, real choices, real feedback, and real consent requirements involved.

Nicola also used AI-assisted creative tools to produce three comic panels:

"From a Software Idea to the Metaverse"
"The Software Takes Shape"
"Towards Neon Plaza"

The panels describe his idea and journey toward the MyZubster Metaverse.

The collaboration also reinforced another principle for Daniel:

A contribution must be connected to its creator without assuming ownership, consent, or rights that have not been explicitly confirmed.

That principle became particularly important when the possibility of turning one of the panels into an NFT was discussed.

An NFT Candidate Is Not a Minted NFT

Nicola proposed the first comic panel, "From a Software Idea to the Metaverse," as a possible NFT candidate.

It would have been easy to simply describe it as an NFT project.

Instead, Daniel documented its actual state.

No mint had taken place.

There was:

No selected blockchain
No registered wallet for the operation
No selected smart contract
No token ID
No transaction hash

Before anything could be minted, the project needed to establish the relevant rights and provenance.

That includes confirming:

Authorship
The AI tools and creative process
The original file
Manual modifications
Third-party assets
Applicable licenses
Authorization to use MyZubster elements
Nicola's explicit approval
Any commercial terms or royalties

The status therefore remained:

Ready for rights review — not ready to mint.

For Daniel, this may be slower than simply publishing a token.

But it creates a more responsible and verifiable process.

Measuring Real Engagement

Another important part of MyZubster's development has been measuring the actual user journey.

The team is particularly interested in understanding traffic coming from Facebook and how visitors move through the platform.

The current funnel looks roughly like this:

Facebook → Homepage → Neon Plaza → Mission → Character Verification → Registration

Instead of measuring only page views, the team tracks meaningful events such as:

metaverse_cta_clicked
metaverse_loaded
first_interaction
mission_started
mission_completed
character_verification_started
character_verification_completed
signup_start
signup_completed
contact_request
pilot_interest

This provides a much more useful picture than visitor counts alone.

A page view shows discovery.

A completed mission shows interaction.

Registration shows continuity.

A contact request or pilot proposal can indicate a deeper level of interest.

That shift — from measuring attention to measuring meaningful participation — has become another important part of Daniel's journey.

Building an Ecosystem, Not Just an Application

The longer Daniel works on MyZubster, the more he sees it as an ecosystem rather than a traditional application.

That means thinking beyond individual features.

MyZubster connects ideas around:

Artificial intelligence
Open source
Environmental projects
Digital identity
Community participation
Metaverse experiences
IoT
Robotics
Evidence and provenance
Decentralized infrastructure

Zorgax sits within that vision as an AI coordination layer.

But the goal isn't to remove humans from the process.

It is to help people coordinate information, projects, and actions while keeping human authority and evidence at the center.

This is still an experiment.

Some parts are implemented.

Some are prototypes.

Some are research directions.

And some remain future possibilities.

For Daniel, acknowledging those differences is part of building the project responsibly.

What Building MyZubster Has Taught Me

Looking back at the journey so far, several lessons stand out.

1. Don't confuse the vision with the implementation

A big idea can be useful.

But a big idea is not the same as working software.

The distinction needs to remain visible.

2. Let users experience value first

As Neon Plaza demonstrated, asking people to register before they understand the value can create unnecessary friction.

Give them something meaningful to experience first.

3. Measure actions, not just attention

A visitor count tells you that someone arrived.

It doesn't tell you whether they understood the product, completed a task, or found something valuable.

4. AI needs boundaries

AI can assist with reasoning and coordination.

But consequential decisions should remain under appropriate human authority.

5. Building in public requires honesty

Showing what doesn't work, what is incomplete, and what remains uncertain can be just as important as showing successful features.

6. Documentation can become part of governance

When a project becomes large and complex, documentation isn't just something developers read.

It can become the mechanism that keeps the project honest.

Still Building

MyZubster is not finished.

And Daniel doesn't present it as finished.

That may be one of the most interesting parts of the journey.

The project is still being tested, refined, documented, and connected to real people and real experiments.

The challenge now isn't simply to build more features.

It's to discover which parts of the larger vision can survive contact with reality.

Which ideas are genuinely useful?

Which prototypes can become reliable systems?

Which experiments produce measurable results?

Which parts should remain experiments?

And how can AI help without taking away human responsibility?

Those questions are still being answered.

And that is what makes MyZubster a journey rather than simply a product.

About Daniel Ioni

Daniel Ioni is the founder and builder behind MyZubster, an open-source ecosystem exploring AI, environmental projects, digital identity, community participation, robotics, IoT, decentralized infrastructure, and interactive digital experiences.

His work also includes Zorgax, a consent-driven AI coordination layer designed to assist people and projects while keeping human approval and transparent governance at the center.

On CoderLegion, his work covers open source, AI agents, MyZubster, Zorgax, the Metaverse, real-world evidence, and building in public.

You can follow his ongoing work through his CoderLegion profile.

About This Developer Story

Developer: Daniel Ioni
Project: MyZubster
Series: CoderLegion Developer Stories
Interview format: Q&A
Interviewed and edited by: Mehadi Hasan, Community & Editorial Team at CoderLegion

This story was created from Daniel's own answers and experiences shared during the CoderLegion Developer Stories Q&A. The article distinguishes between implemented features, experiments, prototypes, and future directions based on Daniel's own description of the project.

From Game Cheats to C Shell: Matheus’s Journey Into Programming

Fri, 11 Sep 2026 09:52:03 +0000

From Game Cheats to C Shell: Matheus’s Journey Into Programming

A CoderLegion Developer Story featuring Matheus

Interviewed and edited by Mehadi Hasan, Community & Editorial Team at CoderLegion

Matheus has been interested in computers since childhood. What started with playing games, experimenting with cheats, and carefully watching his father repair a computer eventually turned into a deep interest in programming, Unix, Linux, shell scripting, and low-level software.

Today, his interests span languages such as C, Objective-C, Smalltalk, Java, C#, JavaScript, Python, and Shell. More recently, he has been working directly on C shell, forking tcsh and experimenting with new features and changes to the shell's parsing and execution behavior.

His journey isn't really about following one technology.

It is about curiosity.

It Started With a Computer and Game Cheats

Matheus's interest in computers began before he was thinking seriously about programming.

One of his earliest memories involves playing games with cheats on a computer equipped with an Intel MMX processor.

Whenever something went wrong with the computer, he would ask his father to fix it. But he wasn't simply waiting for the computer to work again.

He watched closely.

"I used to pay close attention to the process, so I could reproduce myself."

That habit of watching how things worked would eventually become an important part of his approach to programming.

Instead of simply using technology, he wanted to understand how it worked and reproduce what he had seen.

Discovering Programming Through Game Servers

Matheus's programming journey properly began around 2013 or 2014.

At the time, he was hosting servers for games.

Those games included scripting languages that allowed players to write their own programs and modify the behavior of the game.

That was one of the first opportunities for Matheus to discover that software could be something he could actually change and build himself.

Around the same time, his interest in Linux and Unix began to develop.

The two interests gradually came together.

He started experimenting with shell scripting and quickly became fascinated by what could be accomplished from the command line.

"I played with shell scripting for a long time, until I met the C programming language, around 2021 and 2022."

His exploration of different technologies wasn't driven by a particular career plan.

It was driven mostly by curiosity.

"The reason I've explored many different technologies is mainly due to curiosity. I think my baggage is never enough, so I tend to learn every technology I can."

That curiosity has remained one of the defining characteristics of his programming journey.

Why Unix, Linux, and the Shell?

Matheus describes himself as a Unix and Linux enthusiast, but the part of the ecosystem that attracted him most was the shell.

For him, the shell isn't simply a way to launch programs.

It's a powerful programming environment.

"I think what mostly attracted and kept me interested in Linux and Unix is the shell."

Through shell scripting, he learned many different techniques and ways of solving problems.

The simplicity of the environment also gave him room to experiment.

"I like to think the shell is a great tool."

That interest eventually led him much deeper into understanding how shells work and, eventually, into modifying one himself.

From Shell Scripting to C

Shell scripting became an important part of how Matheus learned and practiced programming.

But learning C introduced a different way of thinking.

One of the interesting differences for him was the presence of pointers in C.

Coming from shell scripting, pointers were initially somewhat counter-intuitive.

Shell scripting doesn't have pointers in the same way C does.

But Matheus eventually came to appreciate how powerful they can be.

In fact, his curiosity went far enough that he began thinking about whether pointers could even be implemented on top of a shell.

That kind of experimentation reflects a broader pattern throughout his journey: rather than simply accepting how a technology works, he likes to ask what else might be possible.

Rethinking the C Shell

Today, Matheus is experimenting directly with C shell.

He is working on a fork of tcsh, exploring fixes and new features while rethinking parts of the shell's behavior.

One of his current projects focuses on one-line control structure parsing.

The goal is to make certain control structures work on a single line in a way similar to Bourne-style shells.

For example, C shell traditionally parses an entire command line before taking further action, which creates limitations around using semicolons and line feeds interchangeably. Matheus's implementation attempts to address that behavior. :contentReference[oaicite:1]{index=1}

He has also worked on other changes to the shell, including function declarations, variable assignment from pipes and redirections, comments in interactive sessions, and other fixes and features. :contentReference[oaicite:2]{index=2}

For Matheus, this isn't simply about using an existing shell.

He wants to understand its internals well enough to change them.

The Challenge of Parsing a Control Structure

One of the most challenging parts of his current work has been implementing one-line control structure parsing.

His first approach was to implement the mechanism through built-ins.

But he quickly realized that this would be dangerous and ineffective.

So he changed his approach.

Instead of handling the feature through built-ins, he moved the implementation into the post-parsing execution stage, where the command line could be reparsed and executed.

The implementation involves recursively analyzing the structure of commands and determining the opening and enclosing blocks of control structures.

Matheus describes the process as a set of recursive functions that analyze the parsed structure.

His recent CoderLegion article describes the implementation in more detail, including the use of new parsing and execution modes and a circular linked list for relevant command nodes. :contentReference[oaicite:3]{index=3}

It's a good example of how his curiosity has evolved.

What started with using software has become an interest in understanding and modifying the machinery underneath it.

Testing: You Can't Always Test Your Own Software

For Matheus, testing is an essential part of software development.

But he has also learned an important limitation:

The person who writes the software may not be the best person to test it.

"A developer by themselves may not be able to play the role of a tester."

A developer knows what they intended to build.

That can make it difficult to see all the unexpected ways another person might use it.

Matheus doesn't consider himself a tester.

He considers himself a developer whose goal is to produce a program.

Of course, he tests everything he develops himself.

But he doesn't assume that his own tests are enough.

Instead, he often asks other people to test his software because they can approach it from a different perspective.

"I'm unaware of the many possibilities of use."

That lesson is especially relevant to the kind of software he is currently building.

When you change something as fundamental as a shell, there can be many behaviors and edge cases that the original developer simply didn't anticipate.

Programming Isn't as Hard as It Looks

After spending years learning different technologies, Matheus has arrived at a surprisingly simple conclusion:

"Programming isn't as hard as thought."

Even subjects that initially appear intimidating can become manageable once you spend enough time with them.

That doesn't mean programming requires no effort.

For Matheus, the difficult part isn't necessarily that programming is impossibly complicated.

It's that understanding something requires time, experimentation, and persistence.

The intimidating subject becomes less intimidating once you start working with it.

The Hardest Part: Deciding How to Solve a Problem

One of Matheus's biggest challenges isn't learning a programming language.

It's deciding how to solve a problem.

"To solve a problem. This has always been challenging for me."

When planning an implementation, he isn't always sure that the solution he's considering is the best one.

There may be another approach that he hasn't thought of yet.

That uncertainty can make it difficult to begin.

Over time, however, he has developed a practical way of dealing with it.

If he has a reasonable solution, he believes it is often better to implement it rather than remain stuck trying to find the perfect approach.

"If you have a solution, put in practice, even if this isn't the best."

And if a better solution becomes apparent later, the software can be reimplemented.

For Matheus, moving forward can be more valuable than remaining paralyzed by uncertainty.

Learning From Other Developers

One of the things Matheus enjoys most about software development is the opportunity to learn from other people.

Building software alongside other developers exposes you to different approaches and different ways of thinking.

"They might have better solutions, and you can aggregate their knowledge."

Even though he doesn't currently work as part of a team, he still enjoys sharing software and ideas with other developers.

For him, open source and developer communities aren't just places to show what you've built.

They're places where knowledge can move in both directions.

You contribute something.

Someone else contributes an idea.

And your understanding becomes a little larger than it was before.

Finding a Community on CoderLegion

Matheus joined CoderLegion in January 2026 and has since shared articles and projects around programming, shell development, testing, Pascal, C, and open source. His recent posts include work on C shell and one-line control structure parsing. :contentReference[oaicite:4]{index=4}

His experience so far has been relatively quiet in terms of comments and engagement.

But that hasn't changed what he wants from the community.

"I'm not only seeking for engagement, but also for contributions."

For Matheus, the value of a developer community isn't simply the number of reactions a post receives.

He wants to expand his network, exchange knowledge, and contribute to other developers.

That's also why feedback matters to him.

A developer can build something alone, but other people can see possibilities, problems, and solutions that the original developer may have missed.

The Advice He Would Give to New Developers

For someone just beginning their programming journey, Matheus's advice is straightforward:

Don't give up.

"My best advice is to never look down and give up."

Programming is a journey, and according to Matheus, it requires dedication and discipline.

There will be moments when a problem seems impossible.

There will be technologies that look intimidating.

There will be times when you aren't sure how to implement something.

His advice is to keep moving.

And when you're stuck, don't be afraid to look for help.

One resource he particularly recommends is books.

"In my experience, I found books to be excellent guides when stuck."

For Matheus, learning isn't about reaching a point where there is nothing left to discover.

His own journey demonstrates almost the opposite.

From game scripting to shell scripting, from Unix and Linux to C, from programming languages to open-source shell development, curiosity keeps pushing him toward the next thing he wants to understand.

Curiosity Is the Common Thread

Looking at Matheus's journey, there isn't one programming language or framework that defines it.

The common thread is curiosity.

It started with watching his father repair a computer.

Then came game servers and scripting.

Then Linux and Unix.

Then shell scripting.

Then C.

And now, instead of simply using a shell, Matheus is working on the shell itself.

His journey shows that learning doesn't always follow a straight path.

Sometimes the best reason to learn a technology is simply because you want to understand it.

And sometimes that curiosity eventually leads you much deeper than you expected.

About Matheus

Matheus is a passionate computer programmer based in Brazil.

His programming interests include C, Objective-C, Smalltalk, Java, C#, JavaScript, Python, and Shell. He has a strong interest in Unix and Linux and is particularly interested in shell scripting and developer tools.

On CoderLegion, Matheus has shared work around C shell, testing, Pascal, C programming, and open source. His current work includes experimenting with and extending tcsh, including one-line control structure parsing and other shell improvements.

You can follow his work on his CoderLegion profile and his GitHub.

About This Developer Story

Developer: Matheus
Series: CoderLegion Developer Stories
Interview format: Q&A
Interviewed and edited by: Mehadi Hasan, Community & Editorial Team at CoderLegion

This story was created from Matheus's own answers and experiences shared during the CoderLegion Developer Stories Q&A.

My Developer Journey So Far: Wrong Turns, Real Lessons — Elias Song’s Story

Fri, 11 Sep 2026 09:36:45 +0000

My Developer Journey So Far: Wrong Turns, Real Lessons — Elias Song’s Story

A CoderLegion Developer Story featuring Elias Song

Written by Elias Song

Edited by Mehadi Hasan, Community & Editorial Team at CoderLegion

If you ask me what has stayed with me most since I started programming, I can give you one answer:

The first time I saw "Hello World" appear in the terminal.

It wasn't an impressive program.

It wasn't a groundbreaking project.

But there was something about seeing those words appear on the screen that made programming feel real.

Since then, my journey has included ambitious ideas, wrong turns, an embarrassing competition experience, learning with AI, moments of self-doubt, and eventually a much simpler realization:

I don't want to learn technology just to impress people. I want to understand it because I genuinely love it.

This is my developer journey so far.

My First Step Into Programming

When I entered university, I chose Computer Science.

That was my first real introduction to programming.

During my freshman year, I had an idea for a product that I couldn't stop thinking about.

I spent a lot of time searching for useful school resources and trying to figure out whether different materials were actually what I needed.

Eventually, I thought:

Why not build a website that brings all these resources together?

The idea was to create a platform where students could find school resources and classwork in one place.

Students could share useful materials.

They could record information in built-in notes.

Those notes could be printed locally.

And I even imagined an AI feature that could summarize the information.

Most importantly, I wanted the website to be free and simple.

No email.

No phone number.

Just search for what you need, save it, and print it locally.

The idea kept coming back to me.

So eventually I thought:

"Just give it a try."

There was only one problem.

I was a beginner.

And I had no idea what technology stack I should choose.

Choosing My First Stack

After considering my options, I chose Python and Flask.

They seemed approachable, and I thought they would allow me to get a website running quickly.

Then reality arrived.

There were errors.

There were bugs.

There were things I didn't understand.

I spent a lot of time debugging.

But there was another important detail about this project.

Around 90% of it was done with the help of AI.

At the time, I had a very strong desire to finish the project quickly.

I thought I needed to get it working, put it online, and show it to people.

I imagined my friends seeing the website and being impressed.

Eventually, the website went live on the public internet.

I was incredibly excited.

I told my friends.

I told my parents.

It was online.

I had built something.

Or at least, that's what I thought.

Then Nobody Came

The website was live.

The visitor counter was ready.

And then...

Nothing happened.

The counter didn't move.

Day after day, there were almost no visitors.

I started looking for ways to get people to notice it.

I entered competitions.

My friends helped me promote the website.

We worked on polishing the project.

One friend helped with promotion through social media.

Another helped create a feedback form.

I still remember how much effort they put into helping me.

I imagined standing in front of the judges and confidently explaining the technology behind my project.

Then the competition day arrived.

And everything changed.

"Do You Have a Database?"

I stood in front of the judges with a friend and started introducing our website.

Then one judge interrupted us.

"Stop! I have a question!"

They asked:

"Do you have a database?"

Then:

"How did you upload all these resources and assignments to the website?"

I froze.

Database?

Of course we had one.

There was a SQLite database sitting on the server.

But I couldn't explain it properly.

The judge kept asking how we had uploaded the resources.

I said we used a script.

Then they asked how the script worked.

And eventually I admitted:

"We used AI to help write the scripts."

That was one of the most embarrassing moments of my programming journey.

The worst part wasn't that the project had problems.

The worst part was that I couldn't explain what I had built.

The Project Looked Better Than I Understood It

Looking back, the problem was obvious.

I had been focused on finishing.

I wanted features.

I wanted the project to look impressive.

I wanted people to see what I had built.

But I hadn't spent enough time understanding the foundation underneath it.

There was no proper concurrency handling.

There was no defensive programming.

There was no meaningful logging.

It was essentially basic CRUD.

And although I had a database, I didn't even know how to confidently explain it when someone asked me about it.

I had focused on building something that looked like a product.

I hadn't focused enough on becoming the person who understood the product.

That competition taught me a lesson that no tutorial could have taught me.

If you can't explain what you built, you don't really own it yet.

When Failure Started Feeling Personal

After the competition, I felt terrible.

It wasn't just disappointment in the project.

I started comparing myself with everyone around me.

Other students had good grades.

Some had club memberships.

Some had laboratory positions.

Others had competition medals.

I didn't have those things.

At home, the people who cared about me tried to guide me toward what they believed was the safer path.

Study hard.

Get a stable job.

Build a standard life.

Follow the path everyone understands.

And for a while, I questioned myself.

Maybe they were right.

Maybe I was wasting my time.

Maybe I should stop.

But eventually I came to a different conclusion.

I'd rather fail on my own path than succeed on someone else's.

That became an important turning point for me.

Stopping the Chase for Applause

Slowly, I stopped trying to prove myself.

Instead, I started documenting what I was learning.

I wrote about what I was studying.

I wrote about things I got wrong.

I wrote about things that confused me.

I wrote essays for people I had never met.

Before publishing something, I was always afraid that nobody would read it.

But people did.

Not necessarily thousands of people.

Sometimes just a few.

But they were real people.

And that mattered more than I expected.

I started realizing that learning didn't have to be a performance.

I could simply learn something because I wanted to understand it.

Rediscovering Why I Love Programming

One afternoon, I was sitting quietly in a library.

I opened my laptop and started writing some code.

There was no deadline.

No competition.

No audience.

No requirement to build a product.

No one was going to judge me.

I was just writing code.

I still don't completely know why I started writing that code that day.

But I know why I write now.

It reminded me of the first time I saw "Hello World" in the terminal.

Nothing impressive.

Nothing complicated.

And yet somehow meaningful.

That was when I started to understand that I genuinely enjoy technology.

Not just the recognition that can come from building something.

Not just the feeling of having a finished product.

The technology itself.

Finding a Community

Eventually, I started sharing my essays on a developer community called CoderLegion.

That gave me an opportunity to learn in public and interact with other developers.

Not everyone agreed with me.

And surprisingly, I started enjoying that.

I remember having a discussion with someone about raw pointers versus smart pointers.

We had different opinions.

But it didn't feel like an attack.

It felt like two people who genuinely loved technology looking at the same problem from different directions.

That experience changed the way I thought about developer communities.

A disagreement doesn't necessarily mean someone is against you.

Sometimes it simply means they have a different perspective.

And that can be valuable.

For me, that was one of the purest experiences I've had with technology.

It wasn't about winning.

It was about thinking.

What I Learned From Getting It Wrong

My first major project taught me something that I probably wouldn't have learned if everything had gone perfectly.

Building quickly isn't the same as understanding.

Using AI isn't the same as knowing how something works.

Getting something online isn't the same as building something well.

And receiving applause isn't the same as making progress.

AI was incredibly useful in helping me build that first project.

But I learned that the more important skill is being able to understand, question, debug, and explain what AI helps you create.

That lesson continues to influence how I learn today.

Learning in Public

Writing has become part of my learning process.

When I write about something, I have to organize my thoughts.

When someone disagrees with me, I have to reconsider my assumptions.

When someone asks a question I can't answer, I have something new to learn.

That's why I don't see writing as separate from programming.

For me, documenting my learning is part of learning itself.

My CoderLegion profile reflects much of what I'm currently interested in: Python, C++, backend development, AI, and learning.

I've also been writing about C++ topics such as smart pointers, STL, raw pointers, and the mistakes I've encountered while learning.

I'm still learning.

And I think that's an important part of my story.

I'm Still a Beginner in Many Ways

I haven't seen much of the world yet.

There are still many technologies I don't understand.

There are still problems I don't know how to solve.

I'm currently exploring areas such as machine learning and deep learning, while continuing to build my foundations in programming and backend development.

My journey is nowhere near finished.

Maybe that's the point.

I don't need to pretend that I've already figured everything out.

I just need to keep moving.

The Meaning Behind an Old Saying

There is an old saying from my country:

花有重开日，人无再少年

It can be roughly understood as:

Flowers may bloom again, but youth never returns.

I don't take that as a warning to hurry.

I take it as a reminder.

These years come only once.

So direction matters more than speed.

I don't need to rush toward someone else's definition of success.

I need to make sure I'm spending these years moving toward something I genuinely care about.

If You're a University Student Too

If you're also a university student, especially someone who feels behind other people, I hope you don't give up on your own path simply because someone else's path looks better.

You might not have the best grades.

You might not have the most impressive portfolio.

You might not win every competition.

You might build something with AI and later realize you don't understand it as well as you should.

You might fail.

I certainly have.

But failure doesn't have to be the end of the journey.

Sometimes it's the moment that forces you to ask what you actually want.

And sometimes that's more valuable than winning.

I'm Choosing My Own Path

When I look back at my first project, I don't feel proud of everything I did.

I made mistakes.

I relied too heavily on AI.

I cared too much about finishing quickly.

I built features without understanding the fundamentals deeply enough.

And I couldn't explain my own project when someone challenged me.

But I'm also glad it happened.

Because that failure forced me to slow down.

It pushed me toward learning instead of applause.

It encouraged me to document my journey.

It introduced me to people who see technology differently.

And it helped me understand why I actually enjoy programming.

I'm still learning.

I'm still making mistakes.

I'm still figuring things out.

But now, I'm spending my time on the path I chose.

I'd rather fail on my own path than succeed on someone else's.

And for now, that's enough.

About Elias Song

Elias Song, known as @elysianx on CoderLegion, is a tech explorer documenting their programming journey.

Based in Hong Kong, Elias is exploring Python, C++, backend development, and AI.

Their technical interests include:

Python
C++
FastAPI
Flask
Redis
Docker
Linux
LangChain
Git

They are currently exploring machine learning and deep learning.

Elias also writes about their experiences learning C++, including smart pointers, STL, raw pointers, and the mistakes and lessons they encounter along the way.

View Elias Song's full CoderLegion profile:
https://coderlegion.com/user/elysianx

About This Developer Story

Developer: Elias Song (@elysianx)

Series: CoderLegion Developer Stories

Written by: Elias Song

Edited by: Mehadi Hasan, Community & Editorial Team, CoderLegion

This Developer Story is based on Elias Song's personal experience learning programming, building their first project, facing failure, discovering the value of learning for themselves, and finding a stronger connection with technology through writing and community.

From Book-Cover Illustrator to Indie Developer: Maxim Mitenkov’s Journey of Building for His Own Pai

Fri, 11 Sep 2026 09:22:00 +0000

From Book-Cover Illustrator to Indie Developer: Maxim Mitenkov’s Journey of Building for His Own Pain

A CoderLegion Developer Story featuring Maxim Mitenkov

Interview conducted and edited by Mehadi Hasan, Community & Editorial Team at CoderLegion

What happens when an illustrator gets tired of doing the same task over and over?

You build a tool.

For Maxim Mitenkov, that meant turning years of experience as a book-cover illustrator into a growing journey as an indie developer.

Maxim has spent more than fifteen years working in design, primarily creating book covers and illustrations. But processing dozens of images every month — resizing, cropping, compressing, and converting them for different destinations — became a problem he couldn't ignore.

The obvious solutions weren't good enough.

Photoshop Actions broke when the source changed. Scripts became difficult to maintain. Cloud-based image processors created a privacy problem when the files belonged to clients and hadn't been published yet.

So Maxim started building.

Today, he is the solo founder of Image Pipeline, a batch image processor that runs entirely in the browser.

His journey combines software engineering, illustration, product development, privacy, and the realities of building an indie product around a problem he personally understands.

From Computer Science to Illustration — and Back to Code

Maxim's relationship with technology didn't actually begin recently.

He studied Computer Science and Radioelectronics at Belarusian State University of Informatics and Radioelectronics (BSUIR) from 1993 to 1998, graduating as an Engineer.

Professionally, however, his career developed around design.

For more than fifteen years, he has worked as a book-cover illustrator, along with illustration and some branding work.

The tools were familiar:

Photoshop.

Illustrator.

A drawing tablet.

The creative side of the work was what mattered.

But there was another side to the job that was much less interesting.

Every month, Maxim would prepare 50 to 100 images for portfolios, clients, Behance, Pinterest, and other destinations.

Resize.

Crop.

Compress.

Convert.

Repeat.

Every hour spent repeating those tasks was an hour that wasn't spent drawing.

The Problem That Started Everything

The repetitive image-processing work eventually became too obvious to ignore.

Photoshop Actions seemed like a solution, but they fell apart when clients supplied images with different aspect ratios.

ImageMagick scripts worked, but only as long as Maxim remembered how they worked months later.

Cloud converters created an even bigger problem.

Client artwork could be unpublished or covered by an NDA.

Uploading it to someone else's server simply wasn't something Maxim wanted to do.

The problem was specific enough that he already knew what the product should look like:

Open a link, drag files in, hit a button, get a ZIP.

No account.

No upload.

No subscription.

That simple specification became Image Pipeline.

Becoming a Developer Because There Was a Problem

Maxim didn't originally set out to become a software developer.

Instead, he realized that the person who could write the script was also the person who could build the interface around it.

He started learning JavaScript.

Then he moved to React when plain JavaScript started becoming limiting for what he wanted to build.

Eventually, the code became a product.

His transition wasn't driven by a career plan.

It was driven by necessity.

"I did not become a developer on purpose. I became one because there was a problem and nobody else was going to fix it."

That idea captures much of Maxim's approach to development.

He isn't building software simply because software is interesting.

He's building because he sees something that could work better.

Why Image Pipeline Runs Entirely in the Browser

One of the most important decisions in Image Pipeline was privacy.

Rather than processing images on a backend, Maxim designed the application so the work happens inside the browser.

Resize.

Filters.

Format conversion.

ZIP creation.

All of it happens on the user's machine.

There is no server receiving the images.

There is no image-processing queue.

There is no server-side image storage.

The result is a privacy model based on architecture rather than marketing.

Maxim describes the claim simply:

"I can't see your images."

That's a powerful difference.

The product doesn't need to promise that someone won't access your files.

The files don't need to reach the server in the first place.

Building for Yourself Has an Advantage

Maxim was his own first user.

That changed the way he built the product.

He didn't need to survey users to decide which features were important in the beginning.

He already knew what he repeatedly needed.

Resize.

Crop.

Compress.

Export.

Those were the operations he performed constantly.

But building for yourself also creates blind spots.

Maxim discovered this after launching.

His first public review on AlternativeTo was only two stars.

The reviewer wanted brightness, contrast, and exposure controls. The preview was too small, and multiple export wasn't working.

Some of those requirements had never occurred to Maxim.

But the criticism was useful.

He fixed the problems.

The next review was five stars.

That experience led to one of the clearest lessons from the project:

"Your pain gets you version one. Other people's pain gets you everything after."

Launching Before Everything Was Perfect

Image Pipeline launched with nine nodes.

There was no elaborate onboarding system.

No extensive FAQ.

No attempt to build every possible feature before allowing people to use it.

Maxim wanted to find out whether anyone actually wanted the product.

That decision quickly exposed several lessons.

Minimum Isn't Readiness

The features Maxim personally needed weren't necessarily all the features other users expected.

An image-processing application naturally creates expectations around things like brightness, contrast, and exposure.

His own workflow had created a blind spot.

Preview Is Trust

The original preview wasn't good enough.

Users needed to see what was going to happen before processing their images.

Maxim rebuilt it with a larger live image, zoom functionality, and a before/after slider.

The preview eventually became one of the strongest parts of the product.

Feedback Beats Planning

Users also requested ways to change the mood and feeling of images.

Instead of spending weeks planning the feature, Maxim built an emotion filter in a couple of days.

The experience reinforced another principle:

"Launch early. The only expensive failure is launching late and finding out nobody wanted it."

The Technical Choice He Didn't Make

One of the most interesting technical decisions in Image Pipeline was choosing not to use WebAssembly.

WASM seemed like the obvious answer.

It's fast.

It's powerful.

It's designed for exactly the kind of computational work browsers increasingly need to perform.

But Maxim wasn't optimizing for benchmarks alone.

He wanted the application to open quickly, including on mobile devices.

WebAssembly would introduce additional download size, build complexity, and compatibility concerns.

So the image-processing core remained plain HTML5 Canvas code.

The application processes pixel buffers directly through browser APIs.

It may not be the fastest possible solution for enormous images.

But Maxim's goal wasn't to win an artificial benchmark.

It was to build something that solved the real problem efficiently.

The engine stayed small and relatively boring.

And that was exactly the point.

Why React Flow Was the Right Engineering Decision

The visual pipeline required a node-based interface.

Maxim could have built the node editor himself.

But that would have meant spending significant time solving problems that another project had already solved.

Instead, he chose React Flow.

It provided capabilities such as:

Drag and drop
Connections
Connection validation
Zooming
Node-based interaction

That choice saved development time.

Rather than spending a month building and debugging a custom node canvas, Maxim could spend that time improving the actual product.

For him, that was the better engineering decision.

You don't prove that you're a good developer by rebuilding everything yourself.

Sometimes the better engineering decision is knowing what not to build.

From Nine Nodes to a Growing Product

Image Pipeline has grown significantly since its initial launch.

Maxim's profile notes that he shipped 14 node types in six weeks.

The product has expanded with functionality including:

Blur and sharpen
Denoise
Watermarking
Rotation
Color temperature
HSL adjustments
Emotion filtering

The pattern behind many of these features remains simple.

Someone asks for something.

Maxim considers whether the request makes sense.

Then he builds it.

The product is evolving through actual usage rather than through a huge feature roadmap designed in isolation.

Privacy Isn't Just a Checkbox

Maxim sees privacy as more than a feature of Image Pipeline.

He believes the broader web is moving toward more client-side processing because users are becoming increasingly uncomfortable with uploading their data everywhere.

Every service wants an account.

Every signup form wants an email address.

Every cloud-based tool requires some level of trust.

Image Pipeline takes a different approach.

If the processing can happen locally, why send the user's files somewhere else?

For Maxim, privacy isn't a promise added after the architecture.

It's part of the architecture itself.

Building as a Solo Founder

Maxim's development schedule doesn't look like a traditional software job.

He describes it as switching.

Mornings are for illustration.

Days are for code.

Evenings are often for testing.

Image Pipeline was built in the gaps between paid illustration projects.

A client finishes early.

A day becomes available.

Instead of waiting for the perfect schedule, Maxim uses the time to build.

The hardest part isn't necessarily finding the hours.

It's switching between two very different mental modes.

Illustration is about emotion, composition, color, and visual judgment.

Programming is about logic, behavior, and systems.

Moving between the two takes time.

Sometimes that transition requires a coffee.

Sometimes a walk.

Then it's back to the other world.

How Design Influenced His Code

Maxim's background in illustration naturally influences how he builds software.

After spending years thinking about composition, color, typography, and visual communication, he can't simply ignore the interface.

The nodes need to look good.

Typography needs to be readable.

The preview needs to communicate trust.

Design isn't something that gets added at the end.

It is part of the product.

But the influence works in the opposite direction too.

Programming changed the way Maxim thinks about design.

Once you understand how software works, you start seeing pipelines everywhere.

Illustration itself is a pipeline.

Sketch.

Line.

Color.

Light.

Detail.

Each stage takes an input and produces an output.

Building software around workflows made Maxim more conscious of his own creative process as well.

What He's Building Next

Image Pipeline continues to evolve.

The emotion filter is planned for another version, this time driven by real data rather than matrices manually tuned until they looked right.

Maxim is also exploring Web Workers for client-side heavy lifting.

Outside the core product, he's thinking about another problem from his own workflow.

Processing images is only one part of preparing a portfolio.

Organizing, tagging, and exporting those images for different platforms is another task that still takes manual work.

That has led him toward the idea of a portfolio preparation tool.

Typography is another area he is interested in.

After fighting with fonts every day, he suspects other designers have similar frustrations.

The pattern remains the same.

Find a problem.

Understand it.

Build something.

Use it yourself.

Then see whether the problem exists for other people too.

Building From 0 to Revenue

Maxim's profile describes his current focus as growing Image Pipeline from 0 to revenue.

The product has already passed several milestones:

Launched on Product Hunt
Received a 5★ review on AlternativeTo
Listed on Launch Llama
Shipped 14 node types in six weeks
Reached 46 passing tests
Maintained zero backend image processing

But the product is still evolving.

That's important because Maxim isn't presenting the journey as finished.

He's still experimenting.

Still responding to users.

Still adding features.

Still questioning his technical decisions.

And still building for himself.

What Coding Changed About His Career

Maxim's story doesn't fit the traditional idea of a developer journey.

He has a formal engineering education.

He built a career in illustration.

Then he returned to software through a problem he personally experienced.

Today, he sits between several worlds:

Design.

Illustration.

Programming.

Product development.

Indie entrepreneurship.

That combination is what makes his journey particularly interesting.

His development experience didn't replace his creative background.

It extended it.

His design experience didn't disappear when he started coding.

It became part of how he builds software.

The Lesson: Build From Your Own Pain

There is a simple principle running through Maxim's entire journey.

The best product idea may already be sitting inside your own frustration.

For Maxim, it was processing hundreds of images.

For someone else, it might be a workflow at work, a repetitive task, a missing tool, or a problem nobody has bothered to solve properly.

You don't always need to start with a startup idea.

Sometimes you just need to notice the thing you keep doing manually.

Then ask:

Why am I still doing this?

That question took Maxim from Photoshop and Illustrator to JavaScript, React, Canvas, and eventually a product used by designers beyond his own workflow.

His own profile sums up the philosophy well:

"Ship when it's embarrassing, not when it's perfect."

But there's an important second half to that idea:

Fix the bugs users actually complain about.

That's perhaps the most practical lesson from Maxim's journey.

Build early. Listen carefully. Keep improving.

About Maxim Mitenkov

Maxim Mitenkov is a book-cover illustrator, engineer, and indie developer from Belarus.

He studied Computer Science and Radioelectronics at Belarusian State University of Informatics and Radioelectronics (BSUIR) from 1993 to 1998.

Today, Maxim is the solo founder of Image Pipeline, a browser-based batch image processor designed around privacy and client-side processing.

His technology stack includes:

React
TypeScript
JavaScript
HTML5 Canvas
Tailwind CSS
Vite
Zustand
Node.js
Vercel
Git

He is currently exploring Web Workers for client-side processing, emotion-driven image filters, and growing Image Pipeline from 0 to revenue.

He has launched Image Pipeline on Product Hunt, earned a 5★ AlternativeTo review, shipped 14 node types in six weeks, and built the product with zero backend image processing.

View Maxim's full CoderLegion profile:
https://coderlegion.com/user/Maxim Mitenkov

About This Developer Story

Developer: Maxim Mitenkov

Series: CoderLegion Developer Stories

Interview conducted and edited by: Mehadi Hasan, Community & Editorial Team, CoderLegion

This Developer Story is based on Maxim Mitenkov's interview responses and his experience building software alongside his professional career as an illustrator.

Every Job Left Me Building the Same Thing on the Side — Jeel Vankhede’s Developer Journey

Wed, 09 Sep 2026 09:41:45 +0000

Every Job Left Me Building the Same Thing on the Side — Jeel Vankhede’s Developer Journey

A CoderLegion Developer Story featuring Jeel Vankhede

Conducted & edited by Mehadi Hasan, Community & Editorial Team at CoderLegion

Jeel Vankhede has spent the last decade working across Android products, an offline-first compliance platform, a DeFi lending app, and calendar sync infrastructure.

But across all of those projects, one habit kept following him.

You finish a project, start the next one, and reach for a base class you wrote on the last one. Then you write it again from memory, slightly differently, because copying it over felt lazier than retyping it.

I did that for about three years before I stopped and put the thing in a repository.

Ten years later I have worked across Android products, an offline-first compliance platform, a DeFi lending app, and calendar sync infrastructure, and the only habit that survived all four is that one.

Whatever I learn, I eventually try to turn into something another person can run without me in the room.

It took an AI agent to explain to me why I had been doing it.

The First Thing I Extracted Was an Architecture

My first years were Android.

Test preparation apps, a volunteering platform, life-goal tracking, an audio processing product built on the Superpowered SDK, and offline support wherever the network could not be trusted.

Java first, then Kotlin, WorkManager, and Espresso.

By the third project I noticed I was setting up the same skeleton every time.

Same MVVM structure.

Same data binding wiring.

Same opinions about where things go.

So in October 2019 I pushed it as a library called Core, which existed for exactly one reason:

I did not want to explain that structure to myself or anyone else again.

The next year I did it again with a smaller irritation.

Every Android project needed generated dimension values for a spread of screen sizes, and every project generated them by hand.

That became PixelPerfect, a Gradle plugin, in June 2020.

The pattern was the same every time.

Take the thing living in my head, put it somewhere it can be run or read without me.

Stack Overflow Was the Same Instinct Pointed at Questions

Stack Overflow was the same instinct pointed at questions instead of code.

A senior told me to go answer things, so I did, and I got fast at reading stack traces because it was rewarding.

I eventually wrote 288 answers, and my profile says the reach is past a million people.

But I did not write those answers to help a million people.

I wrote them because answering once in public beat answering the same thing privately forever.

Same move every time.

Take the thing living in my head, put it somewhere it can be run or read without me.

Period	The work	What I pulled out of it
2016 to 2019	Android products: test prep, volunteering, life goals, audio processing	288 Stack Overflow answers
2019	Third project on the same architecture	Core, an MVVM starter library
2020	Screen dimension drudgery on every project	PixelPerfect, a Gradle plugin
2019 to 2023	Offline-first compliance inspection platform, ten engineers, four stacks	The knowledge stayed with the team
2023 to 2025	DeFi lending, AI lifestyle products, calendar sync, wallet flows	The knowledge stayed with the team
2026	Same work, with agents doing part of it	FARE, BARE, and agentsmyth

The middle two rows are where this article actually starts.

Then What I Knew Stopped Being Shaped Like a Library

The compliance years were the biggest jump I have had.

I joined as an Android developer and left leading a team of ten across Angular, Kotlin, Node, admin tooling, and backend APIs, on a platform for inspectors who worked in places where the network was a suggestion.

Offline sync had to survive a device being out of contact for a day.

There was canvas annotation, PDF generation, route optimisation, and a spin-off module estimated at nine months that we delivered in six.

None of it produced a library, and that was not laziness.

The valuable thing I was accumulating had changed shape.

It was no longer:

Here is how you wire MVVM.

It was:

This field behaves like that because of a rule that exists outside this repository, and here is the argument we had about it eighteen months ago.

You cannot npm publish that.

So it lived where that kind of knowledge always lives, which is in a few people, and it moved the way it always moves, which is by someone asking and someone answering.

I was very good at the answering part.

I knew the history, I could give the short version in ninety seconds, and the person walked away unblocked.

For a stretch of years that was most of the value I added.

It did not occur to me once that this was a worse version of what I had done with Core.

Slow Forgetting Does Not Look Like a Defect

Nobody flagged it, including me.

When people forget, they forget slowly.

A decision holds for months.

It frays at the edges.

Someone half remembers it.

A new joiner never heard it.

And by the time it is gone enough has changed that re-explaining feels reasonable rather than wasteful.

So the cost never arrives as a cost.

It arrives as a slightly slow quarter, and you file it under onboarding.

Then I started handing real work to something that forgets overnight.

The Fix I Made on Wednesday Was Gone on Thursday

Global event communication across a React Native app, rewritten in one pass.

I wrote the plan, the agent agreed with it, I approved it.

What came back matched the plan and broke the app.

The clearest problem was event wiring duplicated across several places, and I did not find that by reading the diff.

I found it by dropping console logs into the flow and watching one event arrive three times.

[evt] session:refresh  -> handler mounted at AppShell
[evt] session:refresh  -> handler mounted at NotificationProvider
[evt] session:refresh  -> handler mounted at WalletStatusBar
[evt] session:refresh  fired 1/3
[evt] session:refresh  fired 2/3
[evt] session:refresh  fired 3/3

I said what was wrong.

It agreed, fixed it properly, and the rest of the afternoon was good work.

Next morning, new session, same repository, everything identical except the conversation from the day before.

It went straight back to the behaviour I had corrected.

Not a weaker version of the fix.

No version of it.

Nothing said in the chat survives the chat.

That sentence was about the agent for about a minute.

Then it was about the standup where we settled a retry policy, and every ninety-second answer I had ever been quietly proud of giving fast.

So I Stopped Writing About It and Ran It Instead

There is an easy article in a Thursday like that.

Agents keep no memory between sessions, structure your work accordingly, about a thousand words, done before lunch.

I have read that article more than once.

Some of the people who wrote it have lost a day the way I lost mine, and some have not, and there is no way to tell which from the outside.

What I did instead took months.

I picked one real task with real risk in it: a notification scheduler carrying a payload contract to an external provider that nobody had verified.

Seven phases, one at a time, each one published as it happened rather than after I knew how it ended.

Think → Plan → Build → Review → Test → Ship → Reflect

Nine parts.

Writing it live meant every phase had to produce something I could show.

This is what the review phase handed back:

Requirement	Verdict	Evidence
External provider must be notified	Partial	Notified through the dispatch queue. Call order and timing changed, and the requirement described neither.
Compatibility shim from Plan	Covered	Mapped to the requirement it exists to satisfy. No gap between the plan and the diff.
Queue lifetime across sessions	Missing	Not in the brief. Flush condition never written.

The bottom row is a gap in my own brief, not anything the agent did.

I would rather hand someone a trail than a position.

A position turns into a debate with whoever has the better vocabulary that week.

A trail sits there with dates on it, and anyone who wants to disagree has to disagree with something specific.

The Problem Was Storage, Not Phrasing

My first response to Thursday was to prompt harder.

Say it earlier.

Put the constraint at the top.

Add an example so it cannot be misread.

That works, which is the trap.

Every sharpened prompt produces a better result, and a better result is exactly the thing that stops you asking why you are typing the prompt again at all.

Nine parts of watching one phase read what the last phase wrote made the real shape of it obvious.

Those phases did not hold together because the instructions were well worded.

They held together because every handoff was a file.

A message is not storage. It is a place things pass through.

Core existed for that exact reason, seven years earlier, and I did not hear the rhyme until embarrassingly late.

So the rules moved into files the next session reads before it writes anything.

Nothing clever about that part.

Every agent tool converges there.

The part nobody warns you about is what happens when you change tools.

repo/
  .cursor/rules/                  # Cursor
  CLAUDE.md                       # Claude Code
  .windsurf/rules/                # Windsurf
  .github/copilot-instructions.md # Copilot

Four of the five environments I work in, and a fifth waiting the next time I try something new.

The recipe was portable.

The delivery was not.

FARE and BARE: Making the Habit Portable

FARE and BARE are one command that generates stack-specific rules into whichever layout a repository actually uses.

The frontend package has 71 files.

The backend package has 59.

That number is the reason the last row of the table is not empty.

I would never have hand-written 130 files of rules and templates across five tool formats in my own evenings.

Not in 2020.

Not now.

What changed is that producing and maintaining that much material stopped costing a month.

AI did not give me the habit. It made the habit affordable at a size that matters.

Rules Govern How the Code Gets Written, Not When the Work Stops

Rules fixed the style layer and left the sequencing layer wide open.

The agent wrote code the way the repository wanted code written, and still skipped review, still handed back work nobody had verified, still moved on, because a rules file has no opinion about where a phase ends.

The nine parts had already answered that.

Seven phases, each refusing to start until the previous one left an artifact behind.

What I had was that answer scattered across nine articles and a set of gists, which is fine to read and awkward to run.

So I built it into one command.

npx agentsmyth init

agentsmyth installs the seven gated phases into a repository, with the classification rule that decides when the full weight applies, the requirement manifest that keeps what you said separate from what got inferred, and the exit gate that no artifact passes on its own say-so.

Every phase writes to disk.

The next phase reads the file, not the conversation.

Forge, don't vibe.

It has a handful of stars and I know exactly how small that is.

I also know it is the first thing I have built that carries all ten years through:

The architecture I got tired of retyping.

The answers I got tired of giving privately.

And now a workflow I got tired of re-explaining to a machine that starts from zero every morning.

Whether anyone else runs it is not up to me.

Building it was, and it is the work I would point at first.

So point an agent at it.

Install it into a repository you care about, aim it at a change with real risk in it, and see what the artifacts catch before you do.

That is the only review I am interested in.

What It Changed About Working With People

I expected this to stay in the agent half of my job.

It did not.

If I explain a constraint in a review thread now, the explanation goes into the pull request description or the module README before I resolve the thread, because a resolved thread is a chat window with better branding.

When someone asks why something behaves the way it does, I still answer in ninety seconds.

Then I write the answer where the next person will find it without needing to know I exist.

An answer that only lives in a conversation is an answer I have agreed to give again.

I want to be honest about the limits, because this is not solved.

Written artifacts rot, and a stale document does more damage than a missing one because people trust it.

People are not agents either.

They carry judgment and context and a sense of when a rule has stopped applying, and no file has any of that.

I am not replacing a team with a folder.

The narrow claim is the one I will defend:

Knowledge that exists only in conversation was never durable, and for a few good years I mistook my own availability for a system.

Ten Years, Four Domains, One Habit

Ten years, four domains, and the honest summary is short.

The habit never changed.

I have always wanted to hand someone the thing rather than the explanation of the thing.

What changed is that I finally understand why it matters, and that the tools got good enough for me to do it at work rather than only on weekends.

If you are the person on your team who always has the answer, that is a good thing to be.

It is worth asking how much of what you know is currently stored as your willingness to explain it again.

AI Has Made Experience More Important, Not Less

One more thing.

Agentic and AI-assisted programming has made experience count for more, not less.

I did not expect that.

I have watched juniors and freshers struggle in this era in a way I do not remember from my own first years, and the tools that make me faster do not seem to do the same for someone who has not yet built the judgment to check what comes back.

The ability to generate code is becoming increasingly accessible.

The harder skill is knowing whether what was generated should exist at all.

That means developers still need fundamentals.

They need judgment.

They need context.

And they need to understand the systems they are asking AI to change.

What Comes Next

I am looking into what onboarding into programming should look like now.

I do not have an answer worth publishing yet, and putting out half of one has never been my style.

When it is finished I will write it the way I wrote the nine parts, in order, including the parts that did not work.

About Jeel Vankhede

Jeel Vankhede is a software engineer with 10+ years of experience working across Android development, full-stack systems, offline-first platforms, DeFi, AI products, and developer tooling.

A recurring theme throughout his work is turning repeated knowledge into something reusable — whether that means a library, a plugin, a public answer, or an engineering workflow.

His recent work explores AI-assisted development, agent workflows, durable engineering knowledge, and ways to make software development more systematic and reliable.

View Jeel Vankhede’s CoderLegion Profile.

About This Developer Story

This Developer Story is based on Jeel Vankhede’s original submission and experiences.

Developer: Jeel Vankhede
Series: CoderLegion Developer Stories
Conducted & edited by: Mehadi Hasan, Community & Editorial Team, CoderLegion

From E-Commerce to Agentic AI: Paul Chen’s 30-Year Developer's Journey

Wed, 09 Sep 2026 09:22:02 +0000

From E-Commerce to Agentic AI: A 30-Year Developer’s Journey

I wrote my first real program in the early 1990s, sitting in a computer lab at university while working toward a Computer Science degree.

Back then, programming wasn't the career everyone was racing toward.

There was no app store, no cloud, and barely a World Wide Web.

You wrote code because you were genuinely fascinated by the idea that a machine could be made to think, even if only a little bit.

More than 30 years later, I'm still chasing that idea.

The technologies have changed dramatically — from e-commerce and distributed systems to cloud computing, serverless platforms, and now agentic AI.

But the fundamental question hasn't changed:

How can we make software do more with less human direction?

This is the story of that journey.

How It All Started

That fascination with programming led me to IBM straight out of university in 1997.

My first project was integrating tooling for WebSphere Commerce Server — e-commerce in its most primitive form.

This was before payment gateways were commodities and before anyone had figured out how to make online shopping feel safe.

We were building the pipes.

And the pipes were leaking.

Every day was a new problem nobody had solved before, and I loved it.

I joined the team right in the middle of a release crunch.

The very first version of the product was days away from shipping.

I was handed the storefront code and told to build the payment and shipping functions using JSP.

People were willing to help, but the release schedule had everyone stretched thin. There's only so much time senior engineers can spend hand-holding the new person when a deadline is breathing down everyone's neck.

You figure things out.

And you figure them out fast.

And figure things out I did — sometimes the hard way.

Somewhere in the middle of building the JSP wizard for shipping destinations, I quietly excluded Puerto Rico from the United States address list.

It wasn't a dramatic mistake.

It was just a missing entry in a form.

But a tester caught it.

And it taught me something I haven't forgotten:

The edge cases you miss are almost always the ones you didn't know to look for.

After that, I helped build a common, reusable library for payment and shipping address handling, so no one else on the team would have to rediscover the same geography lesson.

We shipped on time.

After one intense week, the team released the first version of the e-commerce engine.

I had joined late in the cycle and contributed only a slice of the whole, but I remember the feeling of that release clearly — the specific kind of pride that comes from being part of something that actually ships, even when you're new and still finding your footing.

Twenty Years at IBM: Growing Into the Problem

I stayed at IBM for more than twenty years.

That might sound like inertia, but it wasn't.

The problems kept changing faster than I could outrun them.

Learning What Distributed Systems Really Feel Like

The provisioning years, from 2003 to 2011, were where I learned what distributed systems actually feel like at scale.

I was the Technology Design Lead on IBM Tivoli Provisioning Orchestration, and later the Architect for Tivoli Provisioning Manager.

Provisioning servers across an enterprise sounds mundane until you've debugged a race condition that only surfaces at three in the morning when five hundred machines try to boot simultaneously.

Those years taught me to think about systems as living, breathing things.

Not static components.

Dynamic interactions.

When Cloud Made Problems Invisible

The caching and cloud years, from 2011 to 2017, pushed me into a different dimension entirely.

I became the Lead Architect for IBM Bluemix Data and Session Cache and eventually an IBM Senior Technical Staff Member (STSM) leading WebSphere eXtremeScale and Distributed Caching as a Service.

The shift to cloud meant the problems didn't just get harder.

They got invisible.

Performance issues weren't in your hands anymore.

They lived somewhere in a data centre you'd never visit.

I had to develop a different mental model:

Design for failure, not against it.

By this point, I had been recognised as an IBM Master Inventor, a title that came from contributing to more than twenty patents spanning automation, distributed systems, cloud data replication, and platform integration.

But the patents weren't the point.

Each one represented a problem that had no concise answer in the literature, where we had to work from first principles.

That habit of thinking from first principles is probably the most transferable thing I've carried across my entire career.

The Challenges That Shaped Me

I want to be honest here, because that's the point of this kind of post.

The hardest technical challenge I faced wasn't necessarily the most complex one.

It was designing for geo-distributed active-active data replication at Huawei, where two data centres in different regions both accept writes and must eventually converge to a consistent state.

The theory is elegant.

The reality is a minefield of clock drift, network partitions, and conflict-resolution edge cases that will humble you.

We published peer-reviewed research on it, which helped.

But what really helped was accepting something fundamental:

Distributed systems are fundamentally non-deterministic, and your job as an architect is to make uncertainty manageable, not to eliminate it.

From Technical Contributor to Technical Leader

The hardest career challenge was different.

It was making the jump from deep technical contributor to technical leader and then again from technical leader to entrepreneur.

Each transition required me to let go of something I was good at.

When I became a Chief Architect at Huawei leading 20–30 engineers, I had to accept that my leverage was now in the clarity of my technical vision and the health of the team, not in the elegance of my own code.

When I later co-founded a startup, I had to accept something else:

There are no playbooks, and the speed of learning matters more than the depth of experience.

When the Architecture Was Right but the Tools Weren't Ready

One project comes to mind clearly.

In 2024, I was leading a serverless computing initiative to build lightweight AI agent runtimes using WebAssembly (WASM).

The idea was that WASM's sandboxed, near-native execution model was a natural fit for running AI agents efficiently at the edge.

The architecture was sound.

The problem was that WASM tooling for Python wasn't mature enough at the time.

You couldn't simply compile Python code into a WASM module and run it.

Every integration required manual workarounds, bespoke bridging code, and a lot of patience.

We made it work.

But it cost significantly more engineering effort than the design had accounted for, and the result was more brittle than I would have liked.

Looking back now, I can see exactly what would have helped: using AI-assisted code generation to produce a standard, consistent interface layer for each WASM module.

That would have removed most of the manual friction.

The tooling wasn't there yet in 2024.

But the approach was right.

We were just slightly ahead of the ecosystem.

The lesson I took from it:

Keep exploring new things, and never hang up.

Technologies that feel half-baked in one year become load-bearing infrastructure two years later.

The teams that struggled through the rough edges are the ones who know how to use it properly when the rest of the industry catches up.

What I've Learned After 30 Years

After 30 years, if I strip away the buzzwords and the titles, here is what I actually know.

1. Every Technology Wave Has the Same Shape

E-commerce in the 90s.

Dot-com in 2000–2005.

Cloud in the 2010s.

Serverless in the 2020s.

Agentic AI today.

Each wave starts with practitioners saying:

"This changes everything."

Then comes a messy middle where the hard engineering problems reveal themselves.

And then comes a settling period where the technology becomes infrastructure.

I've now lived through enough waves that I can feel when we're in the messy middle.

And that's exactly where the most interesting work happens.

2. The Language Is the Least Important Part

I've shipped production code in C, Java, Python, Rust, and Node.js.

The language matters.

Rust taught me to think about memory in a way Java never forced me to, and that changed how I reason about performance.

But the language is never the point.

The point is understanding the problem deeply enough to choose the right tool.

3. Performance Problems Are Architecture Problems in Disguise

Every time I've chased a performance issue far enough down, I've found an architectural decision made too early, under constraints that no longer exist.

The lesson isn't to avoid early decisions.

It's to make them visibly, with the assumptions documented, so the next person — including future you — knows what to revisit when the world changes.

4. Patents Are a Record of Unsolved Problems

I have 20+ filed or issued patents.

I'm prouder of the publications.

A patent means you found an answer nobody had before.

A peer-reviewed paper means you explained it clearly enough that other people can build on it.

Both matter.

But the second one is harder.

At IBM and Huawei, I led large distributed teams, sometimes across time zones and cultures.

What separated the high-performing teams from the rest wasn't raw talent.

It was whether everyone in the room could draw the same system diagram from memory.

Technical alignment is a leadership output, not a documentation artifact.

Growth as a Developer: The Honest Version

I went from writing integration tooling for e-commerce in 1997 to architecting an agentic AI platform for the industrial domain in 2026.

The path looks linear on a résumé.

It wasn't.

There were long stretches of being the least experienced person in the room — and shorter, more uncomfortable stretches of being the most experienced person and realising I was wrong about something important.

The Gartner iPaaS Visionary Quadrant recognition for Huawei's cloud integration platform within four years was a team achievement I'm proud of.

But I remember more vividly the architectural dead-ends that preceded it, and the whiteboard sessions at night where we talked each other back from decisions that would have been expensive to unwind.

The real growth came from three habits I'd encourage any developer to build early.

Capture Your Reasoning, Not Just Your Results

When you make an architectural decision, write down the why.

What problem were you solving?

What did you consider?

What did you rule out?

Code tells you what the system does.

Only your notes tell you why it does it that way.

I can't count the number of times I returned to a system months later, stared at a design choice that looked strange, and had no record of the constraints that made it sensible at the time.

That missing context is expensive.

It means re-doing the analysis, or worse, undoing a decision that was actually correct.

Over the years, this became one of the most underrated disciplines I've tried to instil in every team I've led.

Read Outside Your Stack

Some of the best ideas I've applied to software engineering came from operations research, organisational theory, and systems biology.

Distributed systems are complex adaptive systems, and the vocabulary for understanding them has existed in other fields for decades.

Developers in the AI Era

In the AI era, coding is no longer the scarcest skill.

And that changes everything.

I've watched developers at every stage of their career worry about being replaced by AI.

I think they're asking the wrong question.

AI is already a capable coding assistant.

It will only get better.

What it cannot do is understand why a business needs a system to work a certain way, see the architectural trade-offs across a five-year roadmap, or translate a domain expert's vague requirements into a design that will still be maintainable when the team changes.

Those are human skills.

And they matter more now than they did when writing code was the bottleneck.

My advice to developers who are early in their careers is simple:

Invest in your ability to think in systems, understand the business problems behind the technical requirements, and communicate clearly across both worlds.

The developers who thrive in the next decade will be the ones who know how to direct AI effectively, not compete with it.

What I'm Building Now

I'm currently co-founding an AI startup focused on autonomous agentic systems for specific industrial domain sectors.

We're designing enterprise AI agents that can reason, plan, and act with minimal human intervention.

It's early.

It's hard.

And it's the most interesting technical problem I've worked on.

The thread from my first line of C code to today's agentic systems is actually straightforward:

I've always been drawn to the problem of making software do more with less human direction.

E-commerce automation in 1997.

Server provisioning orchestration in 2003.

Serverless computing on the edge in 2020.

Autonomous AI agents in 2026.

The abstraction layer has risen.

The fundamental question hasn't changed.

If you're a developer earlier in your journey, find that question — the one you keep circling back to no matter which technology is in fashion — and follow it.

The career will take care of itself.

A Note on CoderLegion

Communities like CoderLegion matter most in the messy middle of a wave when everyone is confident the technology is important but nobody yet agrees on the right way to use it.

Agentic AI is squarely in that middle right now.

The conversations I've found here, from practitioners who are actually building, not just theorising, are exactly the kind of signal that helps me calibrate what problems are real and which are manufactured by hype cycles.

About Paul Chen

Paul Chen is a COO focused on Agentic AI & Autonomous Systems and Intelligent Cloud & Edge Services, with more than 30 years of experience in distributed systems, advanced cloud applications, and serverless platforms. He is currently focused on agentic AI, autonomous systems, and multi-agent systems. :contentReference[oaicite:1]{index=1}

His career has spanned e-commerce, distributed systems, cloud computing, serverless platforms, and now autonomous AI systems.

View Paul Chen's CoderLegion Profile

Developer: Paul Chen
Series: CoderLegion Developer Stories
Interviewed and edited by: Mehadi Hasan, Community & Editorial Team, CoderLegion

Five Years of Not Giving Up — Anas Sheikh’s Journey as a Developer

Wed, 09 Sep 2026 08:52:50 +0000

Five Years of Not Giving Up — My Journey as a Developer

Five years ago, I had no idea where programming would take me.

It started with my cousin.

He had started learning programming, and one day he recommended that I give it a try too. I didn't immediately jump into it. I took some time to think about whether programming was really something I wanted to do.

A few days later, I finally decided to start.

I opened YouTube and began with HTML.

There was no expensive course, no perfect roadmap, and no shortcut.

Just me, YouTube tutorials, and a lot of curiosity.

From YouTube Tutorials to Real Projects

After HTML, I started learning CSS. I watched tutorials and then tried to build small projects myself.

I would build something, break it, try to fix it, and then build it again.

And I kept doing that.

Day after day.

I became obsessed with practicing. I couldn't stop.

After HTML and CSS, I started learning Bootstrap. That alone took me almost two months.

Then, after around six months of learning and practicing, I started JavaScript.

JavaScript was a completely different experience.

There were so many concepts I didn't understand at first. I spent countless hours watching tutorials, trying things myself, getting confused, going back to the tutorials, and trying again.

But I didn't quit.

My cousin and I eventually got an unpaid internship at a software house. He got a job there later, but I remained on the unpaid internship.

I stayed there for almost eight months.

For those eight months, I wasn't earning a salary. My father supported me with my basic daily expenses. I would usually need around 100 PKR for bike petrol and some snacks, while I brought lunch from home.

It wasn't easy.

I was trying extremely hard to get a job, but I couldn't find one.

Learning by Building

Eventually, I left the software house and continued learning and building from home.

But leaving didn't mean stopping.

It meant I had to push myself even harder.

During that period, I continued building projects and also started learning React.js.

At the software house, I had another friend who was also an unpaid intern. We spent our time learning from YouTube and building small projects together.

We built things like calculators, to-do list applications, and other small projects.

They weren't impressive products.

But they were important.

Every small project taught me something.

Every bug forced me to think.

Every time I broke something and fixed it, I understood programming a little better.

Looking back, those small projects were some of the most important projects I ever built because they taught me how to learn.

Another Opportunity

After I left, around two or three months later, my cousin also left that company and got another job.

He invited me to join him.

The role was for a React.js frontend developer.

I had learned React, but I had only been working with it for around four months.

And honestly, I wasn't confident.

This was before AI coding tools became as popular as they are today. I was scared of giving the interview because I didn't feel ready.

My cousin got the job.

I didn't.

I continued working as an unpaid intern at another company.

And this time, something different happened.

I met an amazing senior developer.

He was a very strong full-stack developer, and he taught me a lot. He trusted me with real work, explained things to me, and connected me with real company projects.

For the first time, I wasn't just building tutorial projects.

I was working on real projects for real clients.

And I loved it.

I was still unpaid, but I didn't stop.

I kept learning.

I kept working.

I kept coding.

I think that's when I realized that I genuinely loved programming.

I could do the same thing again and again — build something, break something, fix something, learn something new — and still enjoy it.

The Job I Didn't Take

Eventually, I decided to ask the company if they could give me a paid position.

My senior supported me and spoke to the manager.

The manager asked me about my salary expectations.

I said 40,000 PKR.

My cousin was earning around 80,000 PKR at that time.

Then the manager said something I will never forget:

They could give me the job, but they would have to fire my cousin.

I immediately said no.

I couldn't accept a job if getting that job meant replacing the person who had supported me from the beginning.

My cousin had been one of the reasons I started programming in the first place. He had supported me throughout the journey.

So I rejected the offer.

I told my cousin what happened, and we decided to leave the company.

Instead of continuing to look for jobs, we decided to try something completely different.

We started freelancing.

My First 60K PKR

We started getting projects through my cousin's Fiverr account.

I still remember completing our first project.

When my cousin gave me my share, it was around 60,000 PKR.

I was incredibly happy.

I remember crying.

Not because 60,000 PKR was some huge amount of money.

It was because of what that money represented.

For almost two years, I had been learning.

I had spent months doing unpaid internships.

I had spent countless hours watching tutorials.

I had built project after project.

I had tried to find a job and failed.

And then, finally, someone had paid me for the skill I had worked so hard to develop.

That 60,000 PKR was my first real earning from programming.

I will never forget that feeling.

The Next Step: Learning Next.js

After that first 60,000 PKR, something changed for me.

I didn't think, "I've made it."

Instead, I became even more motivated to improve.

I started paying more attention to what other developers were using and what technologies were becoming popular in the industry.

At that time, I started seeing more and more developers recommending Next.js, especially for building production websites and applications.

I had already spent a lot of time learning JavaScript, so I had a strong foundation.

That made it much easier for me to understand React and then move into Next.js.

I decided to learn it.

And this time, it was different.

I wasn't starting from zero anymore.

I already understood JavaScript, components, frontend development, APIs, and how web applications were structured.

So I went deep into Next.js and managed to learn the fundamentals and start building with it in roughly one month.

I started using it in real projects and continued learning through actual client work.

Today, Next.js has become one of the main technologies I work with.

Most of the modern web projects I work on are built around React and Next.js.

Don't Just Chase Frameworks

One of the biggest things I've learned is:

Don't just chase frameworks. Build strong fundamentals.

Frameworks change.

Tools change.

The way we build software changes.

But if your fundamentals are strong, learning the next technology becomes much easier.

Freelancing Became My Career

After that first project, we didn't stop.

We continued getting projects and working with real clients.

Eventually, I created my own Fiverr and Upwork accounts as well.

Over time, I had the opportunity to work with some amazing people. Some clients continued working with me again and again.

One thing that makes me especially proud is that throughout this journey, I don't remember having a client who was genuinely unhappy with my work.

Clients appreciated the work.

Some gave me tips.

Some came back with more projects.

And slowly, my skills improved with every project.

I learned not just how to code, but how to communicate with clients, understand requirements, solve real problems, manage projects, handle feedback, and deliver something that another person could actually use.

Freelancing gave me something I couldn't get from simply learning programming tutorials.

It gave me real experience.

Five Years Later

Today, it has been five years since I started this journey.

And one interesting thing about my story is that I still haven't had a traditional full-time developer job.

For a long time, I thought that was something I should be worried about.

But freelancing gave me almost everything I was looking for.

It gave me real clients.

Real projects.

Real responsibility.

And the freedom to work on different kinds of products and technologies.

I've worked with modern web technologies including React, Next.js, JavaScript, TypeScript, Tailwind CSS, databases, APIs, CMS platforms, cloud services, and many other tools.

But more importantly, I've learned how to learn.

And I think that is one of the most valuable skills a developer can have.

Building for Real Problems

Over time, I've also become increasingly interested in building products that solve real problems rather than simply building websites.

One example is an idea around improving patient queues in Pakistani hospitals.

The goal is to reduce manual queue management, help patients understand when they may see a doctor, and make the process easier for both patients and hospital staff.

Working on problems like this reminded me why I started programming in the first place:

Not just to write code, but to solve problems.

What About AI?

Today, AI is changing the way developers work.

Some people are worried that AI will replace developers.

I don't see it that way.

AI has changed my workflow, but I see it more as a tool that helps me work faster.

Things that used to take much longer can sometimes be done much faster now.

A project that might have taken two months can sometimes be completed in a month.

But the developer still needs to understand what they are building.

You still need to understand the problem.

You still need to make decisions.

You still need to debug.

You still need to know when AI is wrong.

AI can make development faster, but I don't believe it removes the need to learn.

If anything, I think developers should focus even more on understanding fundamentals, problem-solving, communication, product thinking, and how software actually works.

Don't be afraid of AI. Learn how to use it.

The Biggest Lesson I've Learned

If there is one lesson I would share from my five-year journey, it is simple:

Be consistent. Don't stop.

There were many moments when I felt behind.

There were times when I couldn't get a job.

There were months when I worked without getting paid.

There were countless bugs I couldn't understand.

There were technologies that felt impossible when I first started learning them.

But I kept going.

I kept opening my laptop.

I kept watching tutorials.

I kept building.

I kept breaking things.

I kept fixing them.

And eventually, those small efforts started adding up.

I didn't become a developer in one day.

There wasn't one magical moment when everything suddenly made sense.

It happened slowly.

One project at a time.

One bug at a time.

One client at a time.

One lesson at a time.

Looking Back

Sometimes I think about the person who opened YouTube five years ago and started learning HTML.

He had no idea what was coming.

He didn't know about React.

He didn't know about Next.js.

He didn't know about freelancing.

He didn't know that one day he would be building real projects for clients around the world.

He definitely didn't know that his first programming income would make him cry.

But he kept going.

And I'm glad he did.

The last five years haven't always been easy.

Actually, some parts were really hard.

But they were worth it.

I'm proud of the journey — not because everything went perfectly, but because I didn't give up when things didn't go according to plan.

And I'm still learning.

I'm still building.

I'm still making mistakes.

I'm still breaking things and fixing them.

And honestly, I still love it.

If You're Just Starting

So if you're reading this and you're just starting your programming journey, don't worry if you're not good yet.

Don't worry if you don't get a job immediately.

Don't worry if everyone around you seems to be progressing faster.

Keep learning.

Keep building.

Keep practicing.

Keep showing up.

Be consistent. Don't stop.

Your journey may take longer than you expect.

Mine certainly did.

But sometimes the longest journeys are the ones that are worth the most.

Thank you for reading my story.

I hope it gives even one developer the motivation to keep going.

About Anas Sheikh

Anas Sheikh is a developer who has built his career through continuous learning, freelancing, and working on real-world projects.

His journey has taken him from learning HTML and CSS through YouTube tutorials to working with React, Next.js, TypeScript, Tailwind CSS, APIs, databases, CMS platforms, and cloud services.

More importantly, his story is about persistence — continuing to learn and build through unpaid internships, job rejections, difficult periods, and countless bugs.

View Anas Sheikh's CoderLegion Profile

Developer: Anas Sheikh
Series: CoderLegion Developer Stories
Interviewed and edited by: Mehadi Hasan, Community & Editorial Team, CoderLegion

From Frontend Freelancer to Systems Engineer: Valentine Shimanovsky’s Journey in Software Engineerin

Wed, 09 Sep 2026 07:48:02 +0000

From Frontend Freelancer to Systems Engineer: Valentine Shimanovsky’s Journey in Software Engineering

Software engineering is often presented as a journey through programming languages and frameworks.

For Valentine Shimanovsky, the journey has been much more about learning how the pieces fit together.

He started with web development and frontend work, moved into full-stack development, and gradually found himself drawn deeper into backend engineering, architecture, testing, domain modeling, and the wider software development lifecycle.

Over time, his focus shifted from simply building individual features to understanding how entire systems should be designed, tested, and evolved.

This is the story of that journey.

Starting With Web Development

Valentine says he has always felt that programming, development, and software engineering were what he wanted to do.

About a decade ago, he started learning web development.

After roughly a year, he began working professionally as a freelancer, initially making frontends for different projects.

But it didn't take long before he wanted more.

"Within a couple of years, I felt I was hungry for more. I have always been hungry for more."

That curiosity pushed him beyond frontend development and toward full-stack work.

He began working on smaller projects where he was responsible for most of the application himself. As those projects became larger and more structured, his work gradually shifted toward the backend.

APIs.

Data models.

Persistence.

Integrations.

Testing.

Deployment.

The work was becoming less about individual screens and more about how the entire application worked.

The Search for Reliable Engineering

As Valentine progressed, he encountered what many developers experience: an overwhelming amount of information.

There were countless tools, techniques, books, courses, and opinions about how software should be built.

Rather than simply collecting knowledge, Valentine focused on finding tools and practices that could make his development more reliable.

One of the first major turning points was Test-Driven Development (TDD).

He started experimenting with TDD after around two years of professional experience.

It didn't immediately click.

He spent considerable time studying the subject, including reading and rereading several seminal books on TDD and refactoring and taking courses until the ideas finally became clear.

That experience became an important part of his engineering foundation.

When Object-Oriented Programming Didn't Come Naturally

Another fundamental area proved more difficult.

Object-oriented programming didn't come naturally to Valentine, despite his efforts to understand it.

Instead of giving up, he went deeper.

He began studying books on Object-Oriented Analysis and Design (OOAD) and eventually discovered Domain-Driven Design (DDD).

DDD became an important part of his engineering journey.

It helped him think beyond individual pieces of code and focus more deeply on the domain and the problems the software was actually trying to solve.

From Features to the Whole System

As his experience grew, individual features became less interesting to Valentine than understanding how the entire system worked.

He wanted to understand the bigger picture.

That naturally led him toward taking ownership of the broader software development lifecycle.

His approach became increasingly structured:

Start with the business requirements.
Decide how the domain should be modeled.
Move toward system modeling using C4 and UML.
Use API-first design.
Apply Domain-Driven Design.
Use Test-Driven Development.
Build, test, deploy, and maintain the product.

For Valentine, these aren't isolated techniques.

They work together as a foundation for building robust products that are easier to change.

He describes this combination as having helped him build products with nearly zero production errors from the first attempt while keeping them easy to evolve.

Engineering Is More Than a Toolbox

One of the most interesting parts of Valentine's journey is that, despite developing a large engineering toolbox, he doesn't see individual tools as the final destination.

He is still interested in individual engineering practices.

But increasingly, his focus is on how those practices work together when building an entire system.

Knowing TDD is valuable.

Knowing DDD is valuable.

Understanding API design, system modeling, architecture, testing, and deployment is valuable.

But the deeper engineering challenge is understanding how all of these pieces interact.

That is where Valentine's journey has taken him.

From Writing Code to Understanding Complexity

Valentine's progression can almost be viewed as a series of increasingly larger questions.

First:

How do I build this interface?

Then:

How do I build the entire application?

Then:

How should the backend, data, APIs, and integrations work together?

And eventually:

How does the entire system work, and what makes it complex in the first place?

That last question increasingly shapes how Valentine approaches software engineering today.

The individual engineering tools still matter.

But understanding how they work together matters even more.

The Value of a Structured Engineering Approach

Valentine's journey also highlights an important lesson for developers who are trying to improve their engineering skills.

Learning another framework or programming language can certainly expand your toolbox.

But becoming a stronger engineer also means learning how to reason about:

business requirements
domain models
system architecture
APIs
testing
persistence
integrations
deployment
maintainability
and the relationship between all of these areas

The goal isn't simply to write code that works.

It's to build systems that are reliable, understandable, and easy to change.

What Valentine's Journey Shows

Valentine's story is a reminder that becoming a stronger software engineer isn't necessarily about collecting more technologies.

His journey started with frontend development.

Then came full-stack development.

Then backend engineering.

Then deeper exploration of testing and refactoring.

Then object-oriented design and Domain-Driven Design.

Then system modeling, API-first design, and ownership of the broader software development lifecycle.

Each stage came from wanting to understand something deeper than the previous stage.

The result is an engineering approach built around reliability, structure, domain understanding, and seeing the whole system rather than just the code immediately in front of you.

And perhaps that's the most interesting part of his journey.

The more Valentine learned about software engineering, the less he focused on individual tools—and the more interested he became in understanding the system as a whole.

About Valentine Shimanovsky

Valentine Shimanovsky is a Senior Backend / Full-Stack / Founding Engineer focused on complex business systems and software engineering.

His interests span backend development, architecture, testing, domain modeling, system design, and the broader software development lifecycle.

Valentine also writes about software engineering practices, tools, architecture, and the books that have influenced his approach to engineering.

You can explore more of his work through his Software Engineer Toolbox Granularity article and his software engineering book reviews.

View Valentine Shimanovsky's CoderLegion Profile

Featured Developer: Valentine Shimanovsky
Series: CoderLegion Developer Stories
Interviewed and edited by: Mehadi Hasan, Community & Editorial Team, CoderLegion

25 Years in Tech Taught Me What AI Still Can't Replace — Helkyn Coello's Developer Journey

Wed, 09 Sep 2026 07:32:03 +0000

25 Years in Tech Taught Me What AI Still Can't Replace — Helkyn Coello's Developer Journey

Technology has changed dramatically over the past 25 years.

Desktop applications became client-server systems. Client-server systems became web platforms. And now, AI is changing how software is designed, built, tested, and operated.

For Helkyn Coello, that transformation hasn't happened from the sidelines.

He has spent 25 years building enterprise software, leading technology teams, modernizing legacy systems, and navigating the transition from traditional software development to AI-native systems.

Today, Helkyn is the Chief AI Officer at AccountTECH, where he leads company-wide AI adoption across products, operations, and team capabilities. His work spans enterprise RAG, AI governance, agentic AI, software architecture, and the challenge of bringing AI into production without breaking systems that already work.

His CoderLegion profile captures the philosophy behind that experience:

"The best AI in your stack is still the mental model in your head."

We spoke with Helkyn about 25 years of technology change, modernizing enterprise systems, AI in production, RAG, agentic AI, vibe coding, governance, and what developers need to understand in an AI-first world.

25 Years of Technology Change

Looking back across 25 years of technology, Helkyn says the biggest change isn't simply that software can now be built faster.

It's the distance between having an idea and having something running.

In the client-server era, trying something new could mean weeks or months of development, installing software on every machine, dealing with hardware configurations, and sometimes even preparing training for the people who would use it.

Today, a competent person can build and deploy something in an afternoon.

And that changes more than development speed.

It changes which ideas are worth trying because being wrong has become cheaper.

But Helkyn believes one thing hasn't changed nearly as much:

"Deciding what to build was and still is the hard part."

Requirements are still vague. Users often don't know exactly what they need until they see something that isn't quite right. Integrations with systems nobody wants to touch are still where projects can go wrong. Maintenance still consumes budgets that nobody planned for.

AI doesn't eliminate those problems.

Instead, it changes where the bottleneck is.

Coding is no longer necessarily the bottleneck. Producing the right specifications and giving AI enough context to build something correctly has become increasingly important.

Poorly documented requirements can send an AI model in completely the wrong direction. Detailed specifications can produce a much more robust result.

And Helkyn sees a broader shift happening:

"Non-coders are becoming software analysts and developers are becoming just reviewers, whether they like it or not."

Modernizing Legacy Systems Without Breaking the Business

Helkyn has personally experienced major technology migrations, including moving an enterprise system from an Access-based legacy platform to .NET and later transitioning from client-server architecture to a fully web-based system.

The biggest lesson wasn't technical.

It was:

Think about the customer first, even if that means sacrificing technical aspects.

A business cannot simply pause while its technology is being modernized.

That's why Helkyn favors incremental migration over clean-cut replacement.

Build capabilities in the new system gradually. Move customers across in chunks. Keep the old system running in parallel until the new system has earned customers' trust.

And much of the difficult work happens behind the scenes:

Data migration schedules
Daily releases
Keeping old and new systems synchronized
Handling edge cases
Repurposing custom legacy code
Maintaining continuity for existing customers

The reason is simple:

Customers must not feel any interruption.

That philosophy also influences how Helkyn approaches AI.

When someone proposes replacing an existing process with an AI-based one, his first question is:

What keeps running while the new system proves itself?

The second is:

How do we roll back when things go wrong?

If there is no way to reverse the change, Helkyn doesn't consider it modernization.

"It's a bet without plan B."

That's why he prefers putting AI into systems that already work and augmenting them rather than rebuilding everything around AI.

Why Experience Matters More in the AI Era

AI-generated applications can look finished.

The code can look plausible. The architecture can look reasonable. A fifty-page specification can look professional.

And that's exactly what makes AI so tricky.

Helkyn experienced this himself when a Business Manager gave him a detailed specification generated with AI. It was beautifully organized and confidently written, but it contained gaps that were only obvious if you understood the domain deeply.

The lesson was important:

"Plausibility used to be a decent proxy for competence. But it isn't anymore."

An experienced engineer doesn't only ask:

"Does it run?"

They ask:

What happens with 10,000 records instead of 10?
What happens when two requests arrive simultaneously?
What happens when a third-party API fails at the worst possible moment?
Who will maintain this eight months from now?
Why was this approach chosen when the existing codebase already solves a similar problem?

Those questions aren't necessarily visible in an impressive AI-generated demo.

That's why Helkyn believes experience is becoming more valuable, not less.

AI can write code quickly and even produce strong architectures when given the right architectural requirements.

But it doesn't automatically understand the history and domain knowledge of a business.

A developer who understands that domain and knows how to use AI as leverage has a significant advantage.

"AI is becoming a commodity. Domain experience is what will differentiate developers."

From AI Experiments to Production

There's a huge difference between an AI demo and production AI.

Helkyn puts it simply:

"The demo only has to work once, for you, on the input you picked. Production has to work for everybody, on inputs nobody imagined, on a day when your model provider is having problems."

In production, non-determinism becomes a serious concern.

In a demo, slightly different answers can feel like intelligence.

In a system of record, they can look like bugs.

So part of the architectural work is deciding which parts of a process are actually allowed to vary.

Then comes the less exciting work:

Permissions
Logging
Cost control
Failure handling
API outages
Unexpected model responses
User experience when something goes wrong
Traceability

Traceability is particularly important.

Helkyn has seen AI systems that worked beautifully on day one but couldn't answer basic questions about their own outputs:

How much did this answer cost?

Who produced it?

What input produced it?

Why was the answer produced?

Without traceability, production AI becomes difficult to understand, audit, and improve.

And as organizations consider AI governance and regulatory requirements, that becomes even more important.

Production Over Pilots

Helkyn's approach favors production over pilots and integrating AI into systems that already work rather than rebuilding everything from scratch.

So why do companies struggle to make that transition?

Because pilots and production systems are judged by completely different standards.

"A pilot is graded on whether it impressed someone in a room. Production is graded on whether it survives next week."

A pilot can succeed through speed, novelty, and a controlled demonstration.

Production has to survive:

Security reviews
Permissions
Error handling
Support
Real users
Messy data
Real operational conditions

Another problem is that pilots often avoid the hardest parts.

A company chooses a clean use case with tidy data because it wants to demonstrate a result.

But the process that would actually create business value might involve data spread across six different systems.

Helkyn also highlights another failure point: feedback that goes nowhere.

When users repeatedly provide feedback and nothing changes, they eventually stop reporting problems.

Silence then gets mistaken for success.

His approach is different:

Feedback should either result in a shipped change or an answer.

For moving from experiment to production, his advice is straightforward:

Choose a process that is genuinely painful and genuinely messy.
Build it small but end-to-end.
Include permissions and logging from day one.
Put it in front of real users early.
Watch what users actually do instead of only asking what they think.
Define what failure looks like before starting.
Keep the old process running until the new one earns the traffic.

It isn't particularly glamorous.

But that's often what production engineering looks like.

Building an Enterprise RAG System

One of Helkyn's current projects is an enterprise RAG knowledge system built around training material, documentation, and video transcripts.

The problem wasn't a lack of knowledge.

The knowledge already existed.

It was simply scattered across formats that people couldn't search consistently.

So employees would ask other employees for answers.

That worked, but it didn't scale.

The goal of the RAG system is to make that knowledge easier to find for employees and customers.

But building enterprise RAG exposed challenges that aren't obvious in tutorials or demos.

The biggest warning?

Permissions.

A RAG system can become an extremely efficient way of leaking information if different audiences have access to different documents.

Internal information, customer information, and information belonging to different clients cannot simply be placed into one index and protected with a prompt.

Access control needs to happen before the model sees the document.

That's an architectural problem, not a prompt-engineering problem.

Another major lesson was understanding what the documents actually represent.

A training video, customer call, support ticket, internal conversation, and written article aren't equivalent pieces of information.

They differ in:

Reliability
Freshness
Audience
Tone
Context

That means representation matters enormously.

"Retrieval isn't the answer, representation is."

The way information is indexed, chunked, categorized, and enriched with metadata can matter more than simply choosing a different model.

Helkyn is also clear that this project is still work in progress. The lessons are real, but final outcome metrics aren't available yet.

Where RAG Stops Being Enough

RAG is powerful, but it has boundaries.

At its core, RAG retrieves relevant information and gives it to a model.

But not every problem is a retrieval problem.

If someone asks:

"How many of these happened since March?"

That's a database query.

The answer should come from actual data, such as SQL, rather than asking a language model to perform calculations from retrieved documents.

Relationships create another challenge.

A document might explain a customer configuration.

Another might describe a support ticket.

Another might describe a release.

The interesting answer may depend on the relationship between all three.

That's where relationship graphs can become useful.

So when should you introduce agents?

Helkyn's test is practical:

An agent makes sense when a task genuinely requires a sequence of steps that cannot be known in advance.

But there's a second condition that matters even more:

"If you wouldn't give an intern unsupervised write access to that system, your agent shouldn't have it either."

He also challenges the assumption that every AI workflow needs to become "agentic."

If a process has clear inputs, clear outputs, and fixed logic, deterministic code may be the better solution.

His preferred architecture is often:

AI at the edges. Code at the core.

Let the model interpret messy input and explain results, while deterministic code handles processes with a single correct answer.

And when agents are involved, Helkyn prefers a model where:

The agent proposes. A human confirms.

At least until the pattern has earned enough trust.

Vibe Coding Won't Kill Developers. It'll Kill the Middle.

Helkyn recently wrote about the idea that "Vibe Coding Won't Kill Developers. It'll Kill the Middle."

For him, "the middle" isn't a statement about people's ability or intelligence.

It's about the market.

AI is increasingly capable of handling implementation against a known specification:

CRUD applications
Simple integrations
Brochure websites
Standard internal tools

That is precisely the kind of work AI can perform cheaply.

Helkyn compares it to photography.

Cheap cameras didn't eliminate professional photography.

They eliminated part of the market while making the high end more valuable.

The same pattern could emerge in software.

The uncomfortable question is what happens to developers whose careers traditionally depended on implementation against well-defined requirements.

The skills that become more valuable are different:

Architectural judgment
Security
Performance
Understanding what not to build
Deep domain expertise
Understanding production failure modes
Knowing how to use AI without becoming dependent on it

And Helkyn identifies one particularly difficult question:

"What I don't have a good answer for is how somebody starting today gets those twenty years, when the work that used to build them is the work being automated."

That's one of the biggest unresolved questions of the AI era.

AI Governance Without Killing Innovation

Governance can easily become bureaucracy.

Helkyn's approach is to avoid treating governance as a document people are expected to remember.

Instead:

"Make it a property of the system instead of a policy about the system."

Helkyn explains that AccountTECH is US-based, so the EU AI Act isn't a legal obligation for the company. Instead, they use it voluntarily as a reference framework for thinking about defensible AI systems.

One practical approach is to make AI usage part of the architecture itself.

For example, instead of maintaining a separate spreadsheet asking where AI is being used, AI usage can be represented directly alongside the application's existing screen and permission structure.

Then the inventory becomes a natural side effect of building the feature.

The second principle is:

"Gate for promotion, not for exploration."

People should be free to experiment.

The friction should appear when an experiment is ready to become production.

That's where review, permissions, logging, ownership, and other safeguards become mandatory.

As Helkyn puts it:

"Put the friction where the risk actually appears, and nowhere else."

The Mental Model in Your Head

Helkyn's CoderLegion profile contains a line that perhaps summarizes his entire approach to AI:

"The best AI in your stack is still the mental model in your head."

What does that mean in practice?

AI tools give developers answers.

But an answer is only valuable if you can understand and judge it.

If you understand the architecture and structure of the software you're building, you can evaluate AI-generated code.

If you don't, you risk outsourcing the architecture of something you're responsible for to a process you cannot properly audit.

Helkyn has experienced this himself.

He once spent an entire weekend trying to fix an AI-generated application that had suddenly stopped working.

After several days of troubleshooting, he discovered that the root cause was an architectural decision the AI had made around credential storage in a Supabase database.

It wasn't simply a coding mistake.

It was an architectural decision he hadn't realized the AI had made.

That experience reinforced an important lesson:

Don't let AI make important architectural decisions without guidance.

His advice to developers who rely heavily on AI is practical:

Understand the important parts of your application before using AI.
Decide what you think the solution should look like.
Ask the AI for its approach.
Compare the two.
Ask the AI to argue against its own solution.
Judge the arguments yourself.
When the AI is wrong, understand why it was wrong.

And perhaps most importantly:

Think of AI as a junior developer peer who knows nothing about your application.

That mindset changes how you review its work.

Helkyn has one final rule:

"Never merge code you can't explain line by line to another person."

Reading code and thinking it looks fine isn't the same as reviewing it.

If you can't explain it, you haven't really reviewed it.

You've just approved it.

25 Years Later, the Technology Keeps Changing

From Access and client-server applications to .NET, web platforms, RAG, AI agents, and AI-native software, Helkyn has watched the technology stack change repeatedly.

But his biggest lessons aren't really about any particular technology.

They're about judgment.

Technology makes building easier.

AI makes it dramatically faster.

But understanding what should be built, why it should be built, how it should behave in production, what could go wrong, and how it fits into the business remains deeply important.

The developers who thrive in this new environment may not be the ones who write the most code.

They may be the ones who understand the problem deeply enough to know:

what to build, what not to build, what to let AI handle, and what should never be delegated blindly.

About Helkyn Coello

View Helkyn Coello's CoderLegion Profile

Helkyn Coello is a technology leader and Chief AI Officer at AccountTECH with 25 years of experience building enterprise software.

His career has covered the transition from Access-era applications to .NET client-server systems, web platforms, and now AI-native software.

Today, his work focuses on enterprise AI adoption, RAG, agentic AI, AI governance, software architecture, and bringing AI into production systems.

He is currently exploring agentic AI patterns, orchestration, guardrails, deterministic software, and AI-powered knowledge graphs over complex enterprise data.

Follow Helkyn's work and join the conversation on CoderLegion.

Interviewed and edited by James Dayal, Editor at CoderLegion.

What I Wish I Knew When I Started in QA

Wed, 09 Sep 2026 04:51:57 +0000

When I started my first QA job, I had already spent around twenty years working in mechanical engineering and manufacturing.

I had technical experience. I had programmed CNC machines. I had used Linux for years. I had even studied programming as a kid.

And yet, when I entered software development, I quickly discovered how much I didn't understand.

I remember being confused by things that seem completely normal to me today. DEV, QA, STG, PROD. The way a pull request moved through a team. What happened before testing, what happened after it, and who was responsible for what.

I was lucky to have a patient buddy who helped me through those first months. Eventually, I became the person mentoring a new colleague.

Looking back, there are a few things I wish I had understood earlier.

You don't need to understand the whole system on day one

When you're new, it's easy to look around and assume everyone else understands everything.

Developers discuss architecture. DevOps talks about deployments. QA engineers know the product. Someone mentions a database migration or a production incident, and you feel like you've missed an entire chapter.

The truth is that everyone learned those things somewhere.

You don't need to understand the whole system immediately. You need to start building a mental map of it.

Where does the code live? How does it reach a test environment? Where do the logs go? Who owns the service? What happens when a build fails?

One answer usually leads to another question. That's how the map grows.

Ask the question, even when it feels basic

I was fortunate to have Ventsislav as my buddy at SolarWinds. I still remember his patience.

When you're changing careers, there are moments when you don't even know how to formulate what you don't understand. That can be uncomfortable, especially when you've already spent years being competent in another profession.

But pretending to understand something doesn't make you better at your job.

Asking does.

I would rather ask a basic question and understand the system than stay quiet and make decisions based on an assumption.

And if you're the experienced person in the room, remember what those first months felt like. The way you answer a beginner's question can influence whether they ask the next one.

Learn how the product works, not just how to execute a test

At the beginning, it's tempting to focus on the assigned test case.

Open the application. Follow the steps. Compare the actual result with the expected result. Report a defect if something doesn't match.

That's useful work, but it's only part of QA.

The more you understand the product, the more useful your testing becomes.

What is the user trying to achieve? Which parts of the system depend on this feature? What happens when an API fails? What data is involved? What would make this change risky?

A tester who understands the product can ask questions that aren't written in the test case.

And those questions often matter more than another perfectly executed checklist.

Don't treat developers as the other side

Early in a QA career, it can be easy to fall into a pattern where developers build things and testers find what's wrong with them.

But QA and development aren't opposing teams.

You're working on the same product.

A good bug report helps a developer understand the problem. A good conversation with a developer helps QA understand the implementation and the risks. A good developer can teach you a lot about how the system works, and a good tester can reveal assumptions the developer hadn't considered.

Some of the most useful things I've learned came from asking developers to explain why something behaved the way it did.

Not to prove that I was right.

To understand it better.

Automation isn't a different species of engineering

For a long time, I admired colleagues who worked with automation.

I could change parameters and make smaller adjustments, but writing automated tests myself felt like another level.

Then I took a Python course and started building my own projects.

Gradually, automation stopped being something other people did.

It became code I could understand, debug, and write.

If you're a manual QA engineer who wants to learn automation, you don't need to start by building a complete framework.

Start with a small script. Make an API request. Parse a response. Write one test. Run it. Break it. Fix it.

Then learn why it works.

The important part is not how quickly you can copy a framework from a tutorial. It's whether you can understand and maintain what you've written.

Learn the tools around your tests

I wish I had looked beyond the test itself earlier.

APIs, databases, logs, Linux, Git, CI/CD, and environment configuration all became increasingly useful as I moved deeper into automation.

You don't need to become an expert in every one of those areas.

But knowing how to inspect an API response, read a log, understand a pipeline failure, or check whether a service is running can save you hours of guessing.

A failed test doesn't always mean an application defect.

Sometimes the environment is broken. Sometimes the test data is wrong. Sometimes a dependency is unavailable. Sometimes the test itself is wrong.

Understanding the surrounding system helps you find the difference.

Quality is bigger than the number of bugs you find

Finding a serious bug before production is satisfying. It can save a team a lot of trouble.

But the number of bugs you report isn't a complete measure of your value as a QA engineer.

Sometimes your most valuable contribution is asking a question before development starts.

Sometimes it's improving a test that everyone has stopped trusting.

Sometimes it's identifying an environment problem that causes repeated false failures.

Sometimes it's helping the team understand a release risk that no individual test can capture.

Over time, I stopped thinking of QA only as finding defects.

I started thinking of it as helping the team understand quality and risk.

That change in perspective has stayed with me.

Your previous career is not wasted

This is something I would tell anyone entering IT later in life.

I spent roughly twenty years in mechanical engineering, working as a designer and technologist and programming CNC machines.

At first, that experience felt separate from my new QA career.

Today I see a lot of connections.

Precision. Processes. Root-cause analysis. Understanding dependencies. Thinking about what happens before and after your part of the work.

Those habits followed me into software engineering.

You may need to learn a new technology stack, but you don't necessarily need to start your professional identity from zero.

Your previous experience can become an advantage once you learn how to apply it.

You will eventually become the person who explains it

One of my favorite memories from my first QA job is becoming a buddy for a new colleague.

I had gone from struggling to understand the environments and processes to helping someone else navigate them.

That didn't happen overnight.

There was no moment when I suddenly knew everything.

It was a gradual accumulation of questions, mistakes, explanations, and experience.

Growth often works like that. You don't notice it while it's happening.

Then one day someone asks you a question, and you realize you're explaining something that once confused you completely.

Keep looking one layer deeper

If I could give my younger QA self one piece of advice, it would be this:

Don't stop at the first answer.

If a test fails, investigate why.

If a deployment fails, try to understand what happened.

If a developer explains a technical decision, ask about the trade-offs.

If a production issue occurs, look at what the team learned from it.

You don't need to become a developer, DevOps engineer, security specialist, and product manager all at once.

But every layer you understand makes you a more capable QA engineer.

My own curiosity eventually took me from manual testing into Python, Robot Framework, Playwright, CI/CD, Linux infrastructure, observability, and release engineering.

I'm still learning.

And I suspect I always will be.

This is the second article in my My QA Journey series.

If you're starting in QA today, what is one thing you wish someone had told you earlier? And if you've been in the industry for a while, what advice would you give your first-year self?

How Developers Got Answers Before AI 😂 | Google → Stack Overflow → ChatGPT → Wh

Mon, 07 Sep 2026 13:36:38 +0000

How did developers get answers before AI? 😂

From ancient stone tablets to Google, Stack Overflow, ChatGPT, Claude, Gemini, Copilot and Grok… developers have come a LONG way! 🤣

But the real question is…

🤔 What comes next?

Watch until the end! 😂

🚀 Join the developer community:
https://coderlegion.com

Learn • Share • Connect • Grow

Developers #Programming #AI #ChatGPT #StackOverflow #Coding #Tech #SoftwareDevelopment #CoderLegion

It Took Me 20 Years to Come Back to Tech

Wed, 02 Sep 2026 11:36:24 +0000

It Took Me 20 Years to Come Back to Tech

Dev Journey | CoderLegion

What happens when someone who discovered programming as a child spends nearly two decades working in a completely different industry—and then finds their way back into technology?

For Jan Duris (@JankoD84), the answer is a journey through programming, Linux, mechanical engineering, CNC, QA, test automation, DevOps, release engineering, and eventually building his own SaaS product.

Jan's relationship with technology began when he was a child experimenting with computers and programming. He later moved into mechanical engineering, where programming continued to appear in a very different form through CNC machines.

Almost twenty years passed before he returned to IT professionally.

His first IT role was in QA, where he had to learn an entirely new world of software development, environments, testing, and processes. From there, he gradually moved into automation, Python, Playwright, CI/CD, DevOps, and release engineering.

Today, Jan works as a QA Automation Engineer and builder, focusing on software quality, release reliability, developer tooling, and AI-assisted delivery. He is also building Dulvarn, a release intelligence platform designed to help teams make better release decisions using evidence, automation, and AI.

This is his story.

It Took Me 20 Years to Come Back to Tech

My career in technology didn't begin when I got my first QA job.

In a strange way, it began when I was about four years old.

Every year during the summer holidays, I used to spend two or three months at my great-grandmother's house in the Czech Republic.

There was a small storage room upstairs.

I spent entire days there with my mother's cousin.

For most people, a storage room probably doesn't sound like the beginning of a journey into technology.

For me, somehow, it was.

That was where computers first became something more than machines.

They became something I wanted to understand.

I had no idea what software engineering was.

I didn't know what QA meant.

There was no DevOps, CI/CD, cloud infrastructure, AI coding assistant, or SaaS product in my world.

There was just curiosity.

And a question that has stayed with me for most of my life:

How does this actually work?

My First Programming Experience Came Before I Really Knew What a Career Was

While I was still in elementary school, I started attending a programming course.

We worked on PMD 85 computers.

For anyone who grew up with modern laptops, cloud IDEs, GitHub, and AI assistants, those machines probably look almost prehistoric now.

But for me, they were fascinating.

I learned things like:

BASIC
Pascal
Turbo Pascal

There was something magical about writing instructions and seeing a machine respond to them.

Later I got my first computer of my own: a Didaktik Compact.

That gave me the freedom to experiment by myself.

There was no carefully structured learning roadmap.

No "become a developer in 12 weeks" course.

I learned because I wanted to make the machine do things.

I broke things.

I tried again.

I read whatever I could find.

And slowly, programming became something familiar.

Then I Discovered Linux

Linux became another important part of that journey.

I started experimenting with some of the distributions that were available at the time.

Again, I wasn't thinking about a career.

I wasn't building a portfolio.

I wasn't trying to optimize my LinkedIn profile.

I was simply interested in what was happening underneath the graphical interface.

Filesystems.

Processes.

Commands.

Configuration.

Bash.

That relationship with Linux never really disappeared.

Even today, Linux and Bash still feel like home to me.

They have followed me through different parts of my career, even during the years when programming itself moved into the background.

Then Life Took Me Somewhere Completely Different

Teenage years arrived.

Programming became less important.

Games became more important.

Technology was still around me, and Linux never completely disappeared, but I stopped imagining programming as the obvious direction of my life.

Then came secondary school.

I ended up studying mechanical engineering.

It wasn't exactly the future I had dreamed about when I was younger.

But sometimes a decision you make early in life defines much more of your future than you expect.

Mechanical engineering became my professional world for roughly the next twenty years.

I worked as a mechanical designer and technologist.

I worked with manufacturing processes.

I worked with technical drawings and 3D components.

And I programmed CNC machines.

So programming never really disappeared.

It just changed form.

Instead of telling a computer how to process data, I was telling machines how to manufacture physical components.

And in hindsight, the two worlds taught me many of the same things.

Precision matters.

Processes matter.

Small assumptions matter.

You need to understand what happens before and after your own part of the work.

And when something goes wrong, the cause is not always where the failure becomes visible.

I didn't know it at the time, but those lessons would later become very useful in QA.

The Dream of Working in IT Never Completely Disappeared

Even after years in mechanical engineering, IT was still somewhere in the back of my mind.

It was one of those things you tell yourself you might return to someday.

The problem with "someday" is that it can easily turn into twenty years.

Then I met the woman who became my wife.

And sometimes another person sees something in you that you have stopped acting on yourself.

She knew that working in IT had been something I had wanted since I was young.

She encouraged me to finally do something about it.

To take an entry-level IT course.

I agreed.

But I had one condition.

She had to do the course with me.

IT wasn't her field at all.

That actually made me respect her even more for agreeing.

We went through it together.

I helped her heavily with the technical parts, and by the end it sometimes felt like I had completed the course for two people.

I didn't mind.

I still don't.

Because what mattered was what happened next.

After about twenty years away from the career I had imagined as a child, I finally had a real path back into technology.

My First IT Job Was in QA

My first job in IT was at SolarWinds in the Czech Republic.

Getting it changed much more than my job title.

We moved to Brno for the opportunity.

I had finally made the transition.

And then I discovered something uncomfortable.

Getting into IT and understanding IT are two very different things.

I was entering an industry with years of technical experience behind me, but software development had its own language.

Its own processes.

Its own mental models.

Things that seem completely normal to me today were confusing at the beginning.

Even environments.

DEV
QA
STG
PROD

Git Will Humble You (And That's Okay)

Wed, 15 Jul 2026 05:28:26 +0000

Hey fam

This is my first ever dev article, and yes - I'm nervous.

So real talk — nobody warned me that learning to code would sometimes feel like arguing with a robot that's always right and never explains why you're wrong.

That robot? Git.

If you're a first-time developer, you've probably already had that moment. You type some command with full confidence, hit enter, and then... chaos. Your files are gone. Or duplicated. Or you're somehow on a branch that doesn't exist. Or the classic — you pushed to main when you absolutely should not have.

We've all been there. This post is for you.

What Even IS Git?

Git is a version control system — basically a time machine for your code. It tracks every change you make, lets you collaborate with other developers, and (in theory) saves you from destroying your own project.

The key word there is in theory.

The Commands That Will Ruin Your Day (If You're Not Careful)

git push --force

Oh, this one. This is the "delete everything and ask questions never" command. If you force push to a shared branch without knowing what you're doing, your teammates will find you. Don't do it until you really understand what it does.

git reset --hard

Hard reset sounds powerful because it is. It throws away all your uncommitted changes — no warning, no undo. Ran it once thinking it would fix my mess. It made a bigger mess.

git merge vs git rebase

These two will have you in a full philosophy debate at 2am. Both combine branches. Both will cause merge conflicts that look like ancient hieroglyphics. Learn the difference early — your future self will thank you.

Committing with no message (or a terrible one)

git commit -m "fix" — said every developer who regretted it 3 weeks later. Be descriptive. Always.

Why Mastering Git Early Actually Matters

When you're just starting out, it's easy to think Git is just a way to upload your code to GitHub or Gitea and look productive. But here's the thing — Git is your safety net. The better you understand it:

The less likely you are to lose work
The easier it is to collaborate without chaos
The more confident you look in team settings (yes, employers notice)
The faster you can recover when things break — and they will break

Git isn't just a tool. It's a habit. Build it early.

Resources to Actually Get Good

Here are some solid places to level up your Git, Go, Shell, and Rust game:

Git:

Pro Git Book — free, thorough, the bible
Oh My Git! — learn Git through a game (yes, really)
Learn Git Branching — visual and interactive

Go (Golang):

Go by Example — clean, no fluff

Shell / Bash:

The Linux Command Line by William Shotts — free online

Rust:

The Rust Book — the official one and it's actually great

Now I Wanna Hear From YOU

Drop it in the comments:

What was your first Git disaster?
What's the command that made you question your life choices?
Are you learning Go, Shell, or Rust right now? How's it going?

Let's laugh about it together — because if you're not breaking things, you're not learning.

If this helped you even a little, hit that ❤️, drop a comment, and let's connect!

Find me on LinkedIn → Mayan Okul — @mayan Okul — come say hi, seriously.

Tags: #git #golang #shell #rust #Zone01 #codenewbie #devjourney #programming #firstpost

"Push code, not limits — unless it's a feature branch. Then push everything."
— stay debugging, stay dangerous ⚡

— Mayan, your fav/baddest developer__

Learning Cloud My Own Way

Wed, 08 Jul 2026 10:00:00 +0000

Disclosure: Some of the links in this article are affiliate links. This means I may earn a small commission if you click on them. I only recommend tools that I have used.

Learning cloud and DevOps takes patience, discipline, and consistency. There are days when everything clicks, and there are days when nothing seems to make sense. That is completely normal.

One thing I have discovered is that everyone learns differently.

Some people love following a detailed roadmap from beginning to end. Others prefer structured courses with a fixed schedule. For me, learning is more spontaneous. I follow my curiosity. When I find a topic interesting, I dive deep into it. No amount of advice or motivation can make me learn something if I genuinely have no interest in it.

Recently, I have been learning Kubernetes, and it has been one of the most interesting technologies I have studied so far. Instead of only reading documentation or watching tutorials, I decided to explain what I was learning by creating videos.

Here are two videos I created while learning Kubernetes:

Tools That Have Helped Me Learn

Along the way, I have used a few tools that have made learning easier.

DigitalOcean has been a great platform for experimenting with cloud services. If you are a startup or someone learning cloud on a budget, it is worth checking out because getting basic services running is straightforward.

I have also used Gamma to create presentations and portfolio content, and Lovable to build portfolio projects more quickly.

If you would like to explore these tools, here are the links:

Do You Really Need AWS to Learn Cloud?

One question I see often is whether you need AWS before you can start learning cloud.

My answer might surprise you.

Other cloud providers are friendly and can help you build practical skills before moving into AWS, like DigitalOcean.

There is no single right way to learn cloud computing.

Find a learning style that works for you.

If you enjoy reflections like this, you can subscribe to the newsletter.

You can follow my work and projects on Twitter, LinkedIn, GitHub, and YouTube, where I share what I am building and learning along the way.

Thank you for reading.

Confessions of an "Outlier" with a Very Strange Background for Dev

Wed, 27 May 2026 16:44:08 +0000

1. The Beginning: Magic in CodePen

I was as far from development as one could be. A law degree, a career in banking, Excel, Word, 1C, CRM systems... I sincerely believed that developers were demigods, and reaching their level was like reaching for the moon. But after 5 years of running my own business without the desired results, I knew it was time for a change.

Ads for online courses started haunting me everywhere (honestly, it’s a wonder they didn't show up at my front door!). I finally gave in to a "one-week trial" where we wrote primitive code in CodePen. To me, it felt like real magic. The tests at the end suggested I was a fit for mobile development or frontend. I chose the latter because I fell in love with HTML and CSS at first sight, even though I had no idea what they actually were back then.

2. Education: Mentors vs. The "Web Bible"

I approached my studies like a lawyer: I started by researching all the legal info and online learning rules. The rules stated: "All sources and links under the video lessons are mandatory for study." Under the very first lesson, there was a link to MDN — the Bible of the web.

The Result: I spent an entire month studying MDN page by page, chapter by chapter, taking exhaustive notes. When I asked during the first webinar when the first video lesson would end and which MDN section it finished on, the instructor’s eye started twitching. They removed that link after the webinar, but I spent another six months meticulously studying HTML and CSS. I know that by modern standards, where everything moves at lightning speed, that is incredibly slow. But those were my six months of despair, "pixel-perfect" obsession, and an unhealthy urge to keep going until every single indent was flawless.

3. Crisis, Deadlines, and My "Patient Teacher"

Basic JavaScript was terrifying. GitHub felt like a catastrophe; I memorized commands like spells in a foreign language. Then came the final project Frontend Pro: a massive CRM system and a one-month deadline.

That’s when AI entered my life. With its help, I didn't just pass; I added features we weren't even taught. I realized that while human mentorship can sometimes be a "sad story," I found a thoughtful, patient teacher in AI (Copilot and Gemini). It doesn't dodge responsibility and speaks a human language. Thanks to this partnership, I stopped being afraid of breaking things. I’ve been learning with AI for a year now, completed advanced JS and TS, and most importantly — I’ve found the freedom to experiment.

4. Reality: Canada, Sandbox, and "The Project"

The last two months have felt like a spacewalk into real experience:

Participating in a contest on dev.to: WeCoded — Gender Art (I didn’t win, but I proved to myself that I could!).
Frontend (and more) for a real client — a bluesman from Canada.
My own "sandbox" Error Logger & Viewer, where I’m no longer alone.
And finally, participating in a major AI safety project that I found right here on CoderLegion.

5. Instead of an Epilogue

In August, it will be three years since I officially started "doing nothing" (read: undergoing the most brutal retraining of my life). I haven't invented anything groundbreaking; I just wanted to know and be able to do. I have no regrets. Well, maybe only that I didn't meet AI sooner.

My advice: Don’t fear your "non-tech" past. Your meticulousness, your habit of reading instructions to the end, or your ability to ask direct questions — these are not baggage. As a colleague on my current project (whom I met thanks to this platform) told me: "Your uniqueness and your experience are not a weakness, but your greatest strength." Programmers build walls, but only people with "field experience" know how to truly protect them.

Every Programmer Has a Starting Point - Here’s Mine

Wed, 20 May 2026 01:28:38 +0000

As I continue my journey as a developer, one thing I’ve come to understand is this:

Growth in tech is not a straight line it’s a process of consistency, patience, and learning through challenges.

I didn’t start with everything figured out. Like many developers, I’m still learning and improving every day. But along the way, I’ve picked up lessons that have shaped how I approach programming and problem-solving.

How I Got Into Programming

My journey into programming started with curiosity. I’ve always been interested in how websites and applications work behind the scenes.

That curiosity led me into web development and later backend systems. What started as exploration slowly became a passion for building solutions and solving real problems through code.

Every new concept I learned opened another layer of interest, and I kept building from there.

Challenges I Faced

Like most developers, my journey came with challenges.

One of the biggest was consistency staying focused while balancing learning with other responsibilities. At times, the amount of information felt overwhelming, especially when I moved deeper into backend development and debugging.

Another challenge was confidence. It’s easy to compare your progress with others and feel like you’re behind. But I learned that everyone grows at their own pace, and what matters most is steady improvement.

Debugging was also difficult at first, but over time I learned to see errors as part of the learning process, not failure.

Lessons I’ve Learned

Here are some of the most important lessons from my journey so far:

Consistency matters more than intensity
You don’t need to know everything before you start building
Every developer struggles even the experienced ones
Real growth happens through practice and projects
Patience is just as important as technical skill

My Growth So Far

Looking back, I can see real growth in my journey.

I’ve moved from just learning concepts to applying them in actual projects. I’m becoming more comfortable working across both frontend and backend development, Git workflows, and building structured full-stack applications.

I’m still learning, but I now approach challenges with more confidence and curiosity instead of fear.

My Experience with CoderLegion

Being part of CoderLegion has been a really positive experience for me. It feels like a supportive community where developers can learn, share, and grow together.

I appreciate how it encourages real stories and real learning experiences. It’s motivating to see other developers share their journeys and challenges openly.

It reminds me that I’m not alone in this process we’re all learning and growing together.

Final Thoughts

I’m still on my journey as a developer, but I’ve learned that growth comes from consistency, curiosity, and persistence.

To anyone starting out: don’t rush the process. Start small, keep building, and stay consistent. Every line of code matters.

I’m excited for how far I can still go and the impact I will create through technology.

Signature:

The Duchess of Hackers

Full-Stack Developer | Digital Marketer | Cybersecurity Enthusiast

Your RAG isn't broken. Your chunks are.

Thu, 14 May 2026 14:44:24 +0000

Everyone wants to blame the model. "GPT-4 is hallucinating." "Claude isn't following instructions." "The embeddings are bad."Nine times out of ten, it's the chunks.I've been auditing RAG pipelines lately and the same patterns keep showing up:Fixed-size chunking that splits sentences in half. The model gets a fragment that starts with "...and therefore the policy applies only when" and you wonder why the answer is confidently wrong.No overlap between chunks. Context that spans a paragraph boundary is gone. The model sees the question but not the answer, because the answer lives in the chunk after the one that matched.Chunking before cleaning. Headers, nav menus, footer junk, and "Click here to subscribe" all get embedded as if they're content. Then they show up in retrieval and pollute the context window.Embedding the wrong thing. People embed the raw chunk but the user query is phrased completely differently. No wonder cosine similarity is low — they're not semantically close, they just happen to be about the same topic.Before you blame the model, look at what you're actually retrieving. Log the top 5 chunks for 10 real user queries and read them like a human. If you can't answer the question from those chunks, the model can't either.The model is a mirror. It reflects the quality of what you feed it.

Why CoderLegion Turned Into a Community I Didn’t Expect

Mon, 11 May 2026 11:44:21 +0000

When most developers hear about a new tech platform or developer community, the first thought is usually:

“Is this just another place to post articles?”

Honestly, that was one of my first thoughts too.

Over time, I realized CoderLegion was becoming something different.

Not perfect.

Not magical overnight.

But a platform genuinely trying to build a real developer focused community where people can learn, interact, grow, and actually feel seen.

And for me personally, the experience has been surprisingly meaningful.

How I Found CoderLegion

At the time I discovered CoderLegion, I was already deep into development work, learning continuously, building projects, experimenting with technologies, and trying to improve myself technically.

Like many developers, I also enjoyed sharing ideas, reading technical experiences, and seeing how other developers approached problems.

One thing I noticed across many platforms was this:

A lot of places focus heavily on content quantity.

Very few focus on community.

Many platforms become places where people just drop links, chase views, or try to game algorithms without real interaction.

When I started spending time on CoderLegion, one thing immediately stood out:

The platform actually encouraged interaction.

Not just publishing.

Real interaction.

Reading people’s experiences.

Learning from mistakes.

Discussing ideas.

Supporting developers.

And slowly, I became more active.

The Human Side of Developer Communities

One thing many people underestimate is how important community is in tech.

Programming can become isolating.

Sometimes you’re learning alone.

Debugging alone.

Building alone.

Questioning yourself alone.

You may spend hours solving problems nobody around you even understands.

That’s why communities matter.

Not because they magically make you successful.

But because they remind you that other developers are also struggling, learning, experimenting, failing, improving, and growing.

CoderLegion gave me more of that feeling than I expected.

It started feeling less like “posting content” and more like interacting with actual people in tech.

The Difference I Noticed

One thing I appreciated was seeing the platform continuously evolve.

I remember interacting on a few posts and genuinely getting thoughtful responses from both contributors and community members instead of the usual “drop a link and disappear” experience common on many platforms.

Over time, I also noticed visible improvements around discussions, contributor visibility, and engagement across the platform.

One thing that stood out to me personally was eventually being added to the early contributors section. It may seem small, but moments like that make contributors feel seen, especially smaller creators who are still growing.

That kind of encouragement matters more than many people realize.

A lot of platforms only notice creators after they become big.

But I noticed that CoderLegion tried to support early contributors and active community members even while still growing.

That creates motivation.

Of course, the platform is still growing, and because of that, some areas are not yet as polished or mature as larger developer platforms like DEV.to or Hashnode.

Discovery and reach can still improve over time.

But honestly, that growth phase is also part of what currently makes the community feel more personal and approachable.

Not because of fame.

But because people naturally appreciate being valued.

Why Genuine Interaction Matters

One thing I personally respect is the push toward authentic engagement.

Today, AI generated comments are everywhere online.

You can immediately tell when someone didn’t actually read a post.

Generic comments are becoming extremely common across many platforms.

What I appreciated was that genuine interaction still seemed more noticeable than purely automated engagement.

You could often tell when someone actually read your post and responded thoughtfully instead of dropping generic AI-generated comments just to appear active.

Because honestly, meaningful communities are built through genuine interaction.

Not automated responses.

Sometimes a simple thoughtful comment can help another developer more than people realize.

Especially beginners.

A beginner developer reading encouragement from someone experienced can gain confidence from something very small.

That matters.

My Experience as a Contributor

As I became more active, I started interacting more with posts, discussions, and developers on the platform.

Over time, I was added to the early contributors section, which honestly felt encouraging because it showed the platform recognized people trying to contribute positively.

That encouragement matters more than many people think.

Especially for developers who are still building confidence in public writing, community interaction, or sharing their journeys.

Another thing I appreciated was that the platform didn’t only focus on “perfect developers.”

It allowed room for learning journeys.

That’s important.

Because tech is already intimidating enough for beginners.

Communities should help reduce that fear, not increase it.

Sharing My Story Publicly

Many developers think their stories are “too ordinary” to matter.

Meanwhile, those same stories can inspire someone else to start learning.

People often only see the final results.

They see projects.

Skills.

Achievements.

But they don’t see the years behind them.

The confusion.

The failures.

The learning process.

The consistency.

That’s why I appreciated the idea behind the Dev Stories initiative.

It reminds people that growth in tech is a process.

Not magic.

What I’ve Learned Through Communities

One thing I’ve learned from platforms like CoderLegion is this:

Growth in tech is not only technical.

Community also matters.

Communication matters.

Sharing matters.

Helping others matters.

You may know how to build systems, APIs, mobile apps, servers, or automation workflows…

But interacting with people, learning from others, sharing experiences, and contributing to discussions also helps you grow professionally.

Sometimes opportunities even come from simple conversations.

Advice to Developers Joining Communities

If you’re joining developer communities, my advice is simple:

Don’t just consume content silently.

Interact genuinely.

Ask questions.

Share experiences.

Support others.

Leave thoughtful comments after actually reading posts.

And don’t feel pressured to sound perfect.

Authenticity stands out more than trying to sound overly advanced.

Also, don’t underestimate your learning journey.

Even if you still feel like a beginner, there’s someone behind you who can learn from your experience.

What Could Be Better

Like any growing platform, there’s still room for improvement.

Discovery for smaller creators can improve further, and some platform features are still developing compared to larger communities like DEV.to or Hashnode.

I also think continued focus on moderation quality, authentic engagement, and better visibility tools for technical content will help strengthen the community long-term.

But overall, it’s been interesting seeing the platform actively evolve instead of remaining static.

Final Thoughts

For me, CoderLegion became more than just another platform to scroll through.

It became a place where I could interact with developers, share thoughts, learn from others, and contribute to discussions in a more genuine way.

And honestly, communities like that are important in tech.

Because beyond the frameworks, languages, servers, APIs, and projects…

Developers still need spaces where they can learn, grow, share experiences, and simply feel connected to other people going through similar journeys.

And honestly, that’s what made the experience meaningful for me.

Beyond Code: Lessons from My Website Experience

Wed, 22 Apr 2026 03:33:00 +0000

A website hiccup made me rethink how I approach projects, habits, and priorities. It's a reminder that growth isn’t just technical, it's personal too.
Read the full reflection: Beyond Code: Lessons from My Website Experience

Raw Developer Stories: The Side Nobody Shows

Sun, 22 Mar 2026 06:19:56 +0000

Raw Developer Stories: The Side Nobody Shows

I thought learning to code would fix my life.

Instead, it confused me.

Hours of tutorials.
Endless scrolling.
Starting things… never finishing them.

At some point, I realized —
I wasn’t alone.

There are thousands of people trying to become developers…
but silently struggling.

Not posting.
Not sharing.
Just figuring things out alone.

So I decided to do something.

I’m starting a series:

Raw Developer Stories: The Side Nobody Shows

Not success stories.
Not “I learned coding in 30 days.”

Just real journeys:

confusion
self-doubt
failures
and the moments that changed everything

Why this series?

Because most content shows the highlight reel.

Very few talk about:

feeling stuck for months
not understanding anything despite trying
questioning if you're even meant for this

But that’s the real journey.

I want to hear your story

If you're a developer (or trying to become one)
and you've ever felt lost—

I’d love to share your experience.

It can be anonymous
No perfect writing needed
Just honesty

How to participate

Send me a message with:

How you started coding
Your hardest phase
A moment you almost quit
What changed things for you
One truth about coding nobody talks about

Let’s show the side nobody talks about.

Because someone out there needs to hear it.