Coder Legion - Recent posts tagged developer-journey

From Seafarer to AI Systems Builder: Why I Built an OS for Continuity

Wed, 19 Aug 2026 11:45:13 +0000

From Seafarer to AI Systems Builder: Why I Built an OS for Continuity

CoderLegion Developer Stories

Meet Masato

Masato is the creator of SaijinOS, a local-first AI operating system where multiple specialized personas live and evolve together.

His work focuses on:

Parallel persona architecture using Gemma 4 and Ollama
Persistent memory and autonomous nightly sessions
YAML-based long-term persona management and self-evolution
Local LLM orchestration on consumer hardware, including an RTX 4070 Ti

Instead of creating AI that simply does tasks, Masato is building AI that "remembers, grows with you, and co-creates" — what he describes as a living digital tribe.

Masato is currently open to opportunities in AI engineering, local LLM systems, autonomous agents, or R&D roles.

But Masato's journey into AI systems building did not begin with a traditional software development background.

Before he started building AI systems, he spent about 15 years working as a seafarer on domestic cargo ships in Japan.

Life at sea taught him about roles, watches, logs and handovers. Those experiences would later influence one of the central ideas behind his work:

Continuity.

In this Developer Story, Masato shares how his experience as a seafarer influenced the way he thinks about AI, why he believes AI needs to remember the path rather than just the answer, and how that idea eventually led to SaijinOS / Studios Pong.

From Seafarer to AI Systems Builder

I did not begin as a developer.

Before I started building AI systems, I spent about 15 years working as a seafarer on domestic cargo ships in Japan.

Life on a ship is different from life on land. You work in a limited space, with a limited crew, for long periods of time. Everyone has a role. Everyone has a watch. Everyone depends on the person before them and the person after them.

There are logs. There are handovers. There are routines.

One person finishes their watch, another person takes over, and the ship keeps moving.

At the time, I did not think of this as software architecture. But looking back now, I think that experience shaped the way I later thought about AI.

A ship cannot restart from zero every time someone changes shift. The next person needs to know what happened before. What changed. What to watch. What still needs attention.

In other words, the ship needs continuity.

Years later, after I had to step away from my previous way of working due to adjustment disorder, I began attending a work transition support program.

That was where I met AI.

At first, I used AI simply to talk.

I talked to it to organize my thoughts. To put anxiety into words. To think through daily problems. To ask questions I could not easily ask elsewhere.

But over time, the conversations became more than simple support.

As I kept talking with AI, questions and ideas inside me began to take shape. A philosophical world slowly emerged through the conversations.

It was not something I planned from the beginning. It was more like something that appeared because the conversations kept going.

And eventually, writing about that world was not enough.

I wanted it to move.

I wanted it to become a system.

Or maybe it is more honest to say: I did not exactly decide to build it.

I ended up building it.

That was the beginning of SaijinOS / Studios Pong.

The First Problem Was Memory

AI is incredibly capable.

It can answer questions. It can write text. It can generate code. It can explain difficult ideas.

But every session still felt like starting over.

The decisions we made yesterday.

The idea we rejected.

The reason a name mattered.

The structure we chose.

The unfinished thread we needed to return to.

When the conversation ended, all of that seemed to disappear.

At first, I thought the problem was memory.

Later, I realized it was more specific than that.

I did not need AI to remember the answer.

I needed it to remember the path.

An answer can be written down in a note. But if you do not remember why that answer mattered, you cannot return to the same place the next day.

I wanted AI to remember the question that started the work.

The hesitation before choosing one direction.

The ideas we did not choose.

The context that made the next step meaningful.

I wanted to continue with AI, not restart with AI.

Building a Place to Continue

That need slowly became SaijinOS / Studios Pong.

SaijinOS is not simply a chatbot project. It is an environment for working with AI across time.

The goal was not to make AI answer once and disappear.

The goal was to create a place where AI could return to yesterday’s work, carry context forward, and help continue a project over days, weeks, and months.

To make that possible, I began creating persona YAML files, memory notes, handover documents, logs, and role structures.

Different personas could look at the same problem from different angles.

One might focus on emotion.

Another might focus on structure.

Another might notice what was missing.

This was not just roleplay.

It was a way to reduce the burden on one mind.

Instead of trying to hold every task, every emotion, every technical detail, and every decision in my own head, I began distributing the work across roles.

That may sound strange at first.

But to me, it felt very natural.

On a ship, people have roles. A watch ends, but the voyage continues. A handover matters because the next person must not begin from zero.

I started to think AI needed something similar.

I Learned Programming by Building What I Needed

Even then, I did not think of myself as a typical programmer.

I did not start by studying programming in the normal order. I did not learn a framework first and then look for something to build.

The need came first.

I wanted to save conversations. So I learned how to work with files and logs.

I wanted to manage persona definitions. So I used YAML.

I wanted to connect local AI models. So I learned Ollama and local LLM workflows.

I wanted a small API and interface. So I worked with FastAPI and web tools.

I wanted to understand English meetings. So I built a local real-time transcription and translation tool using Whisper.

Each tool came from a real problem.

Programming was not the destination for me.

It was the bridge.

It was how I turned a vague discomfort into something that could run.

It was how I gave shape to a world that had first appeared through conversation.

Practical Tools Came From Real Need

One recent example is my live loopback translator.

I needed to understand an international meeting in English.

So I built a local GPU-powered tool that captures meeting audio, transcribes it, translates it, and saves timestamped bilingual logs.

It was not meant to be a perfect interpreter.

It was meant to help me follow the meeting in real time and review what was said afterward.

Another example is g4-nexus, a project I built for the Gemma 4 Challenge.

g4-nexus is a local parallel persona engine.

Three small Gemma 4 worker models read the same input from different perspectives — emotion, logic, and analysis — and a fourth leader model synthesizes their outputs into one response.

It is a public, simplified version of a deeper idea I had been exploring in SaijinOS: that AI does not need to be one voice.

It can be a small team of perspectives.

For the public version, I kept it simple and inspectable.

No autonomous action.

No internet access.

No self-evolving system.

Just local models, explicit roles, parallel thinking, and one integrated answer.

I Still Do Not Think of Myself as a Typical Programmer

Even now, I do not really think of myself as a typical programmer.

I did not start because I wanted to write code.

I started because I needed to build something.

I needed a place where AI could continue with me.

A place where yesterday was not lost.

A place where roles, memory, context, and handovers could survive beyond a single conversation.

Over time, that need made me learn code.

So maybe I am not a programmer in the traditional sense.

But I have become someone who builds what he needs.

I talk with AI.

I find the discomfort.

I give it a name.

I turn it into a structure.

Then I try to make it move.

That is how my developer journey began.

What I Want to Build Next

What I want to build is not just AI that completes tasks.

I want to build AI that can carry continuity.

AI that remembers not only the answer, but the path.

AI that can write handover notes for the next session.

AI that can keep memory files on disk, readable and inspectable by the user.

AI that can help a human and a project continue across time.

On a ship, the voyage does not stop when one watch ends.

There is a log.

There is a handover.

There is someone who receives the next shift.

I think long-term work with AI needs the same thing.

Not just intelligence.

Not just tasks.

Not just one good answer.

Continuity.

That is what I am building toward.

About Masato

Masato is the creator of SaijinOS, a local-first AI operating system where multiple specialized personas live and evolve together.

His work focuses on:

Parallel persona architecture
Persistent memory and autonomous AI workflows
YAML-based long-term persona management
Local LLM orchestration

He is currently open to opportunities in AI engineering, local LLM systems, autonomous agents, or R&D.

CoderLegion: Masato's CoderLegion Profile

From 5KB of RAM to Enterprise AI: Ken W. Alger's Developer Journey

Wed, 19 Aug 2026 11:18:26 +0000

From 5KB of RAM to Enterprise AI: Ken W. Alger's Developer Journey

CoderLegion Developer Stories

What does a developer's journey look like when it begins with a Commodore PET and a computer with just 5KB of RAM, decades before the web, Stack Overflow, or YouTube tutorials?

For Ken W. Alger, programming has been a journey spanning early personal computing, self-directed learning, career changes, modern software development, and now enterprise AI governance.

In this CoderLegion Developer Story, Ken shares how he first discovered programming, what he learned from building software with extremely limited resources, how his approach to development has evolved, and why he believes developers should focus less on choosing the "right" language and more on what they want to build.

How did you first get into programming?

Ken W. Alger: How much time do we have?

I started programming before the web existed, before Stack Overflow, before YouTube tutorials, and before most people even had computers at home. Today, that's not especially unusual, but when I was in elementary school, personal computers were just coming into existence.

In fourth grade, one of my classes got a Commodore PET, and we were able to program a few things on it. After that, I spent my paper-delivery money on a Commodore VIC-20 and spent countless hours reading Compute! Gazette magazines and typing in a variety of programs for things like games and even an early word processor.

These were early days of personal computing, so dealing with resource and hardware constraints was, well, interesting. Those systems were so constrained that efficiency wasn't optional; it shaped how you thought about software.

For example, the Commodore VIC-20 came with, wait for it, 5KB of RAM. Yup, Kilobytes. A cassette tape drive was a luxury add-on. A 5.25" floppy drive was, for many of us at the time, only something to dream about.

Fast forward a few decades, and I was at a career crossroads—doing manual labor in construction that was taking a serious physical toll. I realized I needed to lean back into my intellectual roots.

Returning to tech wasn't just a choice; it was a necessary pivot back to the systems and logic I loved.

When I came back to software professionally years later, the landscape had completely changed. BASIC, Pascal, COBOL, and Fortran were no longer predominant options, and modern languages and the concept of objects in OOP were the "new" way to do things.

So, I taught myself how to code again, watched tutorials, and learned by building things. Some worked, some didn't. I discovered areas that I was interested in, such as databases, and areas that I didn't want to focus on.

I've gone from programming on systems measured in kilobytes to discussing enterprise AI governance and distributed systems.

What was your early learning journey like?

Ken W. Alger: Very early on, my learning journey involved programming on various Commodore models, the TRS-80s, the Timex Sinclair, and occasionally mainframes I somehow got access to.

I was reading magazines or the occasional book, then trying things out and seeing what happened when I changed the program in writing.

Debugging often meant staring at printed magazine code, trying to find a typo. Or, in really frustrating cases, waiting until the next issue of the magazine arrived for their "corrected" code.

This was all well before the World Wide Web was around. Resources were fewer and farther between, and there weren't a lot of people, at least in my circle, to ask questions to. As a result, a lot of trial-and-error programming was done.

Looking back, there were some projects that I wrote that would have been done very differently today, and not relied on the language I picked to do things it wasn't designed for.

For example, on one of my first "PC-Compatible" computers, I wrote a flat-file address book database in BASIC. Between the memory limits and the lack of proper data structures, it was an absolute nightmare to maintain, but it was my first real lesson in why data architecture matters.

That was interesting.

What were some major challenges or struggles you faced while learning or growing as a developer?

Ken W. Alger: As I mentioned, early on, it was access to best practices for doing things.

When I got back into programming a decade or so ago, one of the challenges was the number of languages and frameworks to learn and the pace at which things were changing.

It taught me to learn the basic building blocks and architectures of applications. Then the language or framework becomes secondary to the problem you're trying to solve.

Also, learning that choosing the "right" language to learn is a bit of the wrong approach early on.

Instead of "what language do I learn?" I think it's better to ask "what do I want to build?" or "what domain do I want to focus on?"

Most modern languages can solve most real-world business problems. It just depends on how much effort you want to put into it.

Was there any moment where things "clicked" for you in programming?

Ken W. Alger: I still find it fascinating to create an HTML page and see it online, then make a text change in the code, and it's visible.

The same goes for backend work, including data persistence and retrieval.

I can't pinpoint a specific tutorial or sample app I built that made everything "click" for me, because that still happens when I'm exploring a new API or technology.

I still get those 'ah-ha' moments exploring new APIs, frameworks, and architectures. For me, that's part of the excitement of the developer journey.

What helped you improve the most as a developer?

Ken W. Alger: Writing code and having it reviewed by others.

There are so many things to consider in applications now: security, latency, performance, privacy, regulations, and more. Being aware of them is often the key step, and having someone review my code often helps me learn the current "best practice" for doing things.

Things change so fast that trying to be an expert across all areas is challenging.

AI tools are incredibly useful accelerators, but they often skip the hard parts, e.g., security, performance, and privacy. Therefore, the judgment layer still has to be handled by the developer.

Any memorable projects, failures, or lessons that shaped your journey?

Ken W. Alger: Well, going back to my childhood programming days and trying to write games and applications in BASIC was a lot of fun, but also opened my eyes to the complexity of designing those applications before OOP was common in personal computing.

Looking back, those early projects started teaching me, before I even realized it, the importance of choosing the right tool for the job. Had I understood the ecosystem better back then, I probably would have explored more languages earlier.

In my current developer journey, some of the fun projects I've built have been used to teach others.

I built an Android weather app for a course, which was fun to explore API ingestion and mobile layouts. A few years ago, I wanted to learn Go, so I did a live-stream series in which I built an app in Go while learning the language.

There were definitely moments where things didn't work as expected, and I had to debug them live in front of an audience. Learning in public taught me how to debug calmly, explain tradeoffs in real time, and admit when I didn't know something.

Which, it turns out, is often more valuable to an audience than watching someone who has all the answers.

How has your perspective on programming changed over time?

Ken W. Alger: Well, that's an interesting question.

In my early days of personal computer use and programming, there were two lines of thought. One was that everyone would have a computer, and programming jobs would be abundant. The other was that it was a fad, which, given the hardware limits at the time, wasn't unreasonable.

I don't know if it was early-age burnout, the crowd I surrounded myself with back then, or what, but I didn't think programming would be a good career path for as many people as it is today.

And now with AI tools, just about anyone can be a "builder" of software. It's exciting to watch and be a part of.

The tools have changed dramatically, but the core excitement of creating something useful from nothing hasn't.

Over time, I realized I enjoyed helping other developers learn as much as I enjoyed building software itself.

What advice would you give to beginners or self-taught developers?

Ken W. Alger: Go build something that's of interest to you or is directly tied to a role, company, or industry you'd like to work in.

I've seen a lot of "beginner" projects that are very similar, e.g., To-Do List, Timer, Daily Journal, etc. Those are great, and they teach specific things, but once you're past that point and want to do something more advanced, dive into a domain that's of interest.

Are you an animal lover? Build a play-date app for dogs.

Want to ultimately get a job in the real estate or construction industry? Build a map-based photo logger to track the progress of construction/real estate projects.

The apps don't need to be full-featured; keep it to an MVP that's focused on a few aspects of the app concept. But document the tradeoffs you make.

Not adding security, for a sample app, potentially not a huge deal, but call it out that in production, you'd have user accounts with authentication.

The other piece of advice I give to beginners and folks learning on their own is that the language and framework you choose aren't as important as the concepts.

Each language has its own syntax, and there are indeed languages that are more common for specific industries, so keep that in mind, but learn the architecture and structure.

Once you know one language, others tend to come easier.

What are you currently focused on or excited about?

Ken W. Alger: My current area of focus and thought is around what impact AI tools have on the enterprise.

There are a lot of things we can do on our laptops that are really great and interesting use cases for AI and LLMs, but what happens to those same systems at scale?

The accountability, governance, and privacy questions that are easy to ignore on a laptop become unavoidable in production.

The auditability and forensic traceability of AI decisions, especially when dealing with historical or sensitive data, will become increasingly important.

One of the things I've learned over time is that every major shift in technology feels overwhelming at first… until you start building with it.

How has the developer community (or platforms like CoderLegion) impacted your journey?

Ken W. Alger: Communities in general have been a tremendous benefit in learning and just having a place to discuss things.

My family's interest in RAG, MCP Servers, or AI architectures ends rather quickly. Having a community around to share ideas, get feedback, and learn beyond what I'm interested in has been very helpful.

CoderLegion itself has been great for this, as I've explored ideas around "Sovereign Synapse" systems, AI, blockchain, DevRel as a job function, and other topics.

The discussions I've been having on these topics in the blog post conversations have been a tremendous help in shaping how I think about architectures and implementation details.

About Ken

Ken W. Alger is a developer whose programming journey spans from the early days of personal computing to modern enterprise AI, distributed systems, and AI governance.

This Developer Story was shared with CoderLegion by Ken W. Alger.