DEV Community: Yaroslav Klochnyk

190,000 Star Systems and a Million Planets: How I'm Building GalaxyAtlas with AI Agents

Yaroslav Klochnyk — Fri, 16 Oct 2026 16:55:42 +0000

Hi! My name is Yaroslav, and I work as an Agentic Engineering Architect at SoftServe. In my spare time, I enjoy experimenting with AI and trying out ideas at home that may seem completely absurd or impossible at first glance. Today, I'd like to tell you about one of those experiments: GalaxyAtlas.

It's a browser-based 3D galaxy with approximately 190,000 star systems and 1,000,000 procedurally generated planets. It features spaceships, the ability to land on planetary surfaces, explore worlds, add, edit, and customize planets, encounter different creatures, or simply complete the main mission: searching for an ancient artifact.
One important distinction: the 195,000 stars on the map are not 195,000 fully simulated star systems. Some are used to visualize the galaxy's structure, while detailed planet generation is tied to a catalog of objects.
In the game, you can select a star, enter its planetary system, pilot a spaceship, land, step onto the surface, and explore vegetation, creatures, weather phenomena, and individually customized worlds.
And all of this runs without a separate game client. You just need to open a browser.

But for me, the most interesting part of this project isn't the galaxy itself. Above all, GalaxyAtlas is an experiment in how far you can go when developing a complex software product if you change the engineering process itself with AI.

How It All Started
In early September 2026, I was actively experimenting with GPT-6 Astra. It was a good opportunity to test not only the model's capabilities but also how it behaves when working on complex tasks over an extended period. I'd already encountered some problems in earlier experiments. A large model can generate mountains of AI slop, but that doesn't mean it can automatically turn what it generated into a stable, working system. In one experiment, prolonged work on an autonomous simulation exhausted the available limits very quickly. Repeated cycles of generation, testing, and fixing taught me a painful lesson: without very clear criteria, an agent can burn through a substantial budget on endless improvements. So I decided to make my next experiment more focused.

GPT Sites: From an Idea to a Working Prototype
One of the first tools I used for the experiment was GPT Sites. For me, it was a way to validate an idea quickly without having to manually set up the entire publishing process. At an early stage, I managed to build a browser-based atlas using data on more than 109,000 real stars from the HYG catalog and a procedural model of the galaxy. The most important result wasn't the number of stars but the speed at which I went from a concept to an interactive system. Even in the early iterations, it became clear that the prototype could go much further: flights, planets, surfaces, physical environments, different biomes, and gameplay mechanics. But rapid prototyping and long-term product development are two different challenges.
Once a project includes dozens of interdependent mechanics, you need to manage versions, regressions, code structure, performance, and rules for making changes. Eventually, the project evolved into GalaxyAtlas and got its own domain.

Real Astronomical Data
The early model was based on HYG Database v4.1, which contains information about real stars. The first configuration used data on 109,401 stars. This made it possible to display objects from a real stellar catalog with their coordinates and characteristics. But the actual Milky Way contains hundreds of billions of stars, so a single catalog isn't enough to create a visually convincing galaxy. That's why I decided to add procedural generation of the galactic structure—a mathematical model that shapes the galaxy itself.
One early configuration used a disk radius of approximately 15.3 kiloparsecs, a spiral-arm pitch angle of 13°, and a central bar orientation of 27°. To visualize rotation, I used a simplified model in which velocity depends on distance from the center. This isn't a full N-body simulation that calculates gravitational interactions among hundreds of thousands of bodies. It's a mathematically controlled procedural model that creates a galactic structure without requiring extremely expensive physics calculations. This is where I encountered an interesting architectural challenge. If hundreds of thousands of stars are on screen, you can't treat each one as a fully independent game object whose every detail is calculated continuously. So a core principle of development became moving away from full detail across the entire scene and toward rendering only the detail the user needs at a particular moment.

As GalaxyAtlas evolved, its scale increased to approximately 190,000–195,000 accessible star systems. Let me explain what 'generated' actually means.
It doesn't mean there are a million ready-made 3D planet models sitting on a server somewhere. Storing, transferring, and rendering that much information simultaneously would be extremely expensive. Instead, the project uses a procedural approach: the properties of systems and planets can be reconstructed from a set of parameters and rules.
When a user selects a particular star, the system can construct its planetary environment. As the user approaches a planet, more detail is required. Upon landing, the system needs a surface, vegetation, an atmosphere, creatures, and interactive objects. You don't need the entire galaxy to be fully generated all the time. You need to be able to reconstruct the required part of the world when it's needed. Stable identifiers and seed-based generation are particularly important here. If generation is deterministic, the same seed produces the same result as long as the rules remain unchanged. That lets you revisit the same planet rather than get an entirely new world on every visit. There is, however, a trade-off: changing the generation algorithm can accidentally alter worlds users already know.
That's why generator versioning and the challenges of keeping procedural seeds stable have become a separate architectural problem for me. I'll describe this in another article someday.

Three.js and Browser Performance
Three.js became the foundation of GalaxyAtlas's 3D rendering.
One of my main requirements was that the project must work without installing a separate game client. A user opens a link and immediately enters the galaxy. That brings a whole set of constraints. In a browser, you have to consider not only polygon counts but also GPU memory usage, material and shader complexity, the number of draw calls, and JavaScript execution on the main thread. GalaxyAtlas isn't a static scene, either. Users can switch between the galactic map, space flight, approaching a planet, and exploring its surface. Each mode has different detail requirements. For example, when viewing the entire galaxy, there's no point in building high-polygon models of every planet. But during landing, you need terrain, atmospheric, and local-environment detail.
For a system like this, I had to analyze and apply several key architectural principles:

Generate only the content that's needed—lazy generation.
Use different levels of detail at different scales—LOD.
Reuse geometry, materials, and textures.
Control the number of active objects and effects.
Release resources when switching between scenes. This isn't just about optimizing a pretty picture. It's a fundamental trade-off between the size of a virtual world and the amount of data you actually need to process. I also experimented with atmospheric effects, fog, particles, surface textures, and lighting. The problem is that adding one more visual effect is fairly easy. Keeping everything running smoothly on an ordinary computer is much harder. So every visual improvement had to be evaluated not only in terms of image quality but also rendering cost.

How I Experiment with Different AI Models
Let's return to the project's main goal. I wasn't interested in simply telling a model to 'make a game' and expecting everything to happen quickly and cheaply. I wanted to understand how to organize development so that AI genuinely helps build and maintain a complex system. In my broader experiments with AI-assisted development, I used and compared different approaches and models: GPT-6 Astra, faster and cheaper models from the GPT family, Claude, and even local models, including Qwen3.
The key thing to remember is that the most expensive and powerful model shouldn't handle every task. Complex architectural analysis, changes across multiple files, testing, and autonomous feature implementation call for one level of reasoning. Generating repetitive structures, preparing simple code snippets, formatting documentation, or making local configuration changes call for quite another.
If you delegate all these tasks to a single expensive model, costs will quickly rise. In large agent sessions, a significant portion of resources is also spent not on writing the final code but on repeatedly reading files, reconstructing context, analyzing logs, attempting unsuccessful fixes, and rerunning tests.
That's exactly what I wanted to improve.

Subagents and Skills Instead of One Giant Prompt
At some point, I began treating GalaxyAtlas development not as one continuous conversation with AI but as a set of distinct engineering processes. Broadly speaking, I divided the system into several areas:

Galaxy & Procedural Generation—working with the star catalog, the galaxy's spatial structure, and the generation of star systems, planets, biomes, and other procedural content.
3D Rendering & Performance—Three.js, shaders, materials, lighting, geometry optimization, memory management, and performance.
Gameplay & World Interaction—space flight, landing, planetary exploration, object interactions, and gameplay scenarios.
Content & Customization—planet stories, biome configurations, unique creatures, themed scenes, and content.
Testing & Quality—checking for regressions, generation stability, scene behavior, and functional acceptance criteria. Why use skills? Skills are a way to formalize recurring engineering procedures. Instead of explaining architectural constraints and change-management rules again in every new session, you can capture them in separate instructions. For example, a procedural-generation skill might specify:
How to keep seed-based generation stable.
Which data contracts must not change without a migration.
How to check whether new generation logic remains compatible with existing worlds.
Which performance criteria need to be considered. A Three.js skill might contain rules for managing GPU resources, cleaning up objects, sharing materials, and checking performance. The idea is fairly simple: knowledge about the system shouldn't exist only in the context window of the current conversation. This approach also helps reuse engineering practices across different tasks and models.

It's Important to Understand That 'Code Generation Isn't Always the Most Expensive Part of AI Development'

In earlier experiments with powerful models, I quickly encountered a mountain of burned tokens (and wasted weekly or monthly usage limits). This was especially obvious during large tasks involving many iterations. An agent writes code, runs a check, gets an error, analyzes it, rewrites the code, and runs the check again. At first glance, everything seems to be working as intended. But without clearly defined tasks, a model can keep repeating that cycle far longer than makes economic sense. Sometimes a person would realize in a few minutes that it's time to change the approach instead of making a twentieth attempt to fix the same thing. That experience led to my main rules and recommendations for cost optimization.

It's essential to separate tasks by complexity. Use cheaper models for small, well-defined tasks, and bring in more powerful models when complex reasoning or orchestration is actually needed.
Limit the scope of context. A subagent working on landscape generation shouldn't have to reread the entire project every time, including UI code, localization strings, and spaceship controls.
Pass artifacts, not the entire conversation history. One process might produce a short specification, a diff, an interface, or a set of tests. The next agent needs that result—not thousands of previous messages.
ALWAYS control execution loops. In complex experiments, I've seen agents continue working without making meaningful progress. That's why you need limits—for example, on the number of attempts—and checkpoints, as well as CLEAR, MANDATORY conditions for when a task is considered complete.
Validate results with tools, not just another LLM. If a system property can be checked with an automated test, there's no reason to ask an expensive model to evaluate it from scratch every time. For example, you can test the stability of procedural generation by regenerating a set of fixed seeds. At this stage, I don't want to claim a universal percentage for the savings. But believe me, after optimization, the difference became very noticeable.

What's Next?
GalaxyAtlas isn't a commercial game built by a large team over many years with a multimillion-dollar budget. It's my personal experiment. Over time, I've drawn several conclusions for myself. I'm continuing to experiment, expand planet customization, make procedural worlds more diverse, work on more realistic surfaces and creatures, and add new gameplay scenarios.

Another major area of focus for me is continuing to improve AI-assisted development: refining contracts between agents, experimenting with skills, introducing automated checks, and measuring the real token economics of using different models.
GalaxyAtlas may never become a major commercial game. But the project is already fulfilling its main purpose: it's essentially my at-home experimentation lab. And that's probably the most interesting part. I'd encourage you to try building something similar yourself. In the meantime, come explore—it's free and requires no registration at galaxyatlas.space

Did you know that Your presentation and Your AI knowledge source can be the same file.

Yaroslav Klochnyk — Sun, 20 Sep 2026 09:50:50 +0000

Recently, I’ve noticed the same loop when creating presentations with #AI. Usually, we are asking Claude or CoPilot or ChatGPT to create a PowerPoint presentation, spend tokens generating the PPTX, then spend more tokens adjusting fonts, content and layout. Later, the same presentation in "pptx" format is used as a part of knowledge source for an AI Agent or Workflow. The Agent needs to extract the content from the PPTX presentation before using it. That means more processing and, depending on the workflow, more tokens. If the extracted content isn’t saved for reuse, the same work can happen again and again "Reading - Transforming - Spending tokens".

We had the information. Turned it into slides. Then asked AI to get the information back out.

If we already had the information before we turned it into slides. Why make it harder to use afterward?

That’s why, for personal usage, I built https://mddeck.app/

The idea is simple "Keep Markdown as the source of truth."

It lets me keep Markdown as the main source for a presentation. I can render the .md file as slides for a meeting, then use that same file as a text-based knowledge source for an AI agent. When something changes, I update the source.

I’ve also added two companion skills to help agents to create presentations in MDDeck’s format or convert existing PPTX decks into Markdown.

It has the limitations you’d expect from #Markdown. You won’t get complete freedom over slide layouts. Images need accessible URLs or embedded data, and complex charts often work better as separately prepared assets. Converting an existing deck won’t preserve every visual detail, either. And if important knowledge lives inside an image, you still need a text description or the underlying data.

Your local files and pasted content stay in your browser. MDDeck parses and renders them locally without uploading their contents elsewhere . Remote images and #Markdown links still make requests to their hosting servers.

Agents still spend tokens reading Markdown. What MDDeck avoids is the extra work and extra tokens for unpacking a presentation just to get back to its content. Everything is free. No registration is needed.

AI Agents in the SDLC: Why Task Automation Is No Longer Enough

Yaroslav Klochnyk — Thu, 14 May 2026 09:31:33 +0000

Today, most conversations about AI in software development revolve around one question:

Which tasks can we automate?

An AI agent can help with requirements refinement. It can generate code. It can write unit tests. It can prepare documentation. It can perform code review or help with a deployment checklist.

And yes, it works.

Teams get results faster. Routine work is reduced. Engineers can move from idea to implementation much quicker. But there is one problem in this approach that we often underestimate. We talk a lot about what an AI agent can do. But we almost never talk about what an AI agent leaves behind.

The problem: AI completed the task, but the context disappeared

Let’s imagine a simple scenario.

An AI agent helped a business analyst decompose a user story. It asked questions during the “interview process”, helped formulate acceptance criteria, identified a few edge cases, and proposed a structure.

But what happened to the context?

For example:

which decisions were made;
which alternatives were rejected;
which edge cases were found;
which assumptions remained;
which questions should be checked next time.

Very often, this context stays inside one chat, one prompt history, or disappears completely after the task is completed. The next agent, or the next engineer, starts almost from zero again.

Again, they ask:

“Why did we choose this approach?”

“Why didn’t we use another library?”

“Which edge cases were already found?”

“What deployment risks appeared before?”

“What is considered a good solution in this project?”

This is exactly where the real cost of AI integration starts to appear.

We are paying not only for tokens
When people talk about cost optimization in AI, they usually mean cheaper models, shorter prompts adapted to 3S principles, or a smaller context window. This is important, but it is only part of the problem. The bigger issue is that the organization keeps paying again and again for the same context discovery.

In other words, an agent spends time and tokens trying to understand things that were already discovered before:

architectural principles;
product constraints;
business rules;
known defects;
typical edge cases;
reasons behind technical trade-offs;
deployment lessons learned.

If every AI interaction ends only with a task output, we get speed, but we do not accumulate knowledge. It is like hiring a very smart consultant who quickly solves a problem, but leaves no notes, no blueprints, and no explanation of why the solution was designed this way.

Yes, the task is done. But the next person will still start over again.

The next stage of AI adoption is not only in automation, but also in context accumulation

In my opinion, the next stage of AI adoption in the SDLC should not be built only around task automation. It should also solve the problem of context accumulation. Every AI-assisted task should create not one, but two results.

The first result is obvious, it is expected result from AI Agent.

For example:

refined user story;
generated code;
test cases;
code review comments;
release notes;
deployment plan;
technical documentation.

The second result is less obvious, but much more important for long-term efficiency.

It is a reusable context asset - a context artifact that can be reused in the future.

For example:

a business rule discovered during refinement;
an architectural decision;
the reason why a certain library was rejected;
a typical acceptance criteria pattern;
a known failure pattern;
a deployment checklist update;
a security constraint;
a test data assumption;
a project-specific coding rule;
an edge case that should be checked in the future.

The idea is simple:

An AI agent should not only complete a task. It should leave behind context that makes the next task cheaper, faster, and better.

How this can look in practice

Requirements agent

Traditional approach:

The agent clarifies the user story and generates acceptance criteria.

Context Accumulation approach:

The agent clarifies the user story, generates acceptance criteria, and also stores reusable context.
For example:

a new business rule;
a list of open questions;
terms and glossary;
decisions made with the stakeholder;
examples of valid and invalid behavior;
a typical pattern for future user stories.

Then the next refinement process does not start from zero. The agent can already use previous business rules and patterns.

Development agent
Traditional approach:

The agent generates or changes code.

Context Accumulation approach:

The agent generates code and captures context that may be useful for future changes.

For example:

which coding pattern was used;
which trade-offs were made;
which dependencies were added and why;
which constraints were considered;
which parts of the solution can be reused;
which areas require caution during future refactoring.

This is especially important for teams where AI helps many engineers in parallel.

Without shared context, each agent may suggest different styles, different approaches, and repeat the same mistakes.

QA agent

Traditional approach:

The agent generates test cases.

Context Accumulation approach:

The agent generates test cases and stores reusable testing knowledge.

For example:

discovered edge cases;
regression scenarios;
test data assumptions;
known failure patterns;
risky product areas;
rules for future checks;
scenarios that must always be tested after changes in a specific module.

Then the next QA cycle becomes faster, because the agent does not generate tests “from nowhere”. It relies on accumulated product context.

Deployment agent

Traditional approach:

The agent helps prepare a release plan or deployment checklist.

Context Accumulation approach:

The agent prepares the deployment plan and captures lessons learned.

For example:

what broke during the previous deployment;
which rollback path worked;
which environment variable was missing;
which alerts should be added;
which manual checks remained;
which risks should be checked before the next release.

Then deployment knowledge is not lost between releases.

This is not the same as documentation

Some may say:

“But this is just documentation.”

Not exactly.

Classic documentation is often created after the work is done. The task is already closed, the team has moved to the next sprint, and some details have already been forgotten. Context accumulation works differently. Context is captured during the execution of the task. The agent does not only perform the work. It also extracts small reusable knowledge fragments from it. Not a huge 20-page documents that nobody reads. But short, structured context assets that can be used next time.

For example:

context_asset:
  type: business_rule
  title: Cancellation before invoice generation
  description: Premium users can cancel subscription only before invoice is generated.
  source: requirements_refinement
  status: validated
  reusable_for:
    - requirements_agent
    - qa_agent
    - support_documentation

Or:

context_asset:
  type: failure_pattern
  title: Missing environment variable during ECS deployment
  description: Deployment failed because PAYMENT_API_URL was not configured in the target environment.
  source: deployment_review
  status: validated
  reusable_for:
    - deployment_agent
    - release_checklist
    - infrastructure_review

This is no longer just a note.

This is structured context that has been validated and can be reused.

This is not just agent memory

Another possible reaction is:

“Isn’t this just agent Memory?”

Partially, yes. But there is an important difference. Agent memory usually means that one agent remembers something for its own future interactions. The idea here is broader. The goal is not for one agent to remember something.

The goal is to create shareable context that can be used by:

other agents;
other people;
other teams;
future delivery flows;
onboarding processes;
QA;
DevOps;
architects;
support teams.

In other words, context becomes not the private memory of one agent, but part of the knowledge base.

The model changes

The current model looks roughly like this:

Agent → Task Output → Done

But in this model, the value often ends together with the task.

The Context Accumulation model looks different:

Agent → Task Output + Reusable Context Asset → Shared Context Layer → Next Task Starts Smarter

This is the shift from task automation to context accumulation.

The AI agent does not just complete the task. It adds something to a shared context layer that later helps the next agent during generation/

Why this matters for cost reduction

In practice, cost savings appear not only when we use a cheaper model. They appear when we reduce repetitive work. Less time is spent explaining the same things. Less time is spent on the same clarifications. Less time is spent fixing the same mistakes. Less time is spent starting from zero. Fewer tokens are spent on reloading the same context. There is less risk that different agents will provide different solutions for the same problem. This is no longer just token optimization.

It is an operating model for cost-effective AI adoption.

How to implement it
I would not start with a large enterprise knowledge base.

It is better to start with one SDLC flow.

For example:

Requirements → Development → QA → Deployment
And for each stage, define:

What task output does the agent create?
What reusable context asset should it leave behind?
Who or what validates this context?
Where is it stored?
Which next agent or team can use it?
How do we know that it really reduced cost or improved quality?

The key rule is simple:

Every agent should create not only a work result, but also a result for reuse.

Validation is critical

There is a risk: if an agent starts storing incorrect context, the organization will scale mistakes.

That is why reusable context should not automatically become the source of truth.

It needs validation.

This can be:

human approval;
automated tests;
verification by another agent;
code review;
architecture review;
security review;
statuses such as draft / validated / deprecated.

Without this, the shared context layer can quickly become a shared confusion layer.

That is why it is important to store not just text, but structured context with status, source, and ownership.

Which metrics can be used

If we want to manage this as an adoption model, we should not measure only the number of agents used or lines of code generated.

Possible metrics:

how many AI-assisted tasks created reusable context assets;
how many context assets were validated;
how many times context assets were reused;
whether refinement time decreased;
whether the number of repeated clarification questions decreased;
whether recurring defects decreased;
whether code review consistency improved;
whether onboarding time for a new engineer or agent decreased;
whether the average cost per AI-assisted task decreased.

The main question is:

Did this task make the next task cheaper, faster, or better?

Conclusion

Today, many companies are trying to adopt Agentic AI in the SDLC through automation of individual tasks. This is the right starting point. But if every task ends only with an output, we lose a huge part of valuable information. A mature AI adoption model should look at agents not only as task executors, but also as context producers. Every AI-assisted task should leave something useful for the next task. That is when AI adoption starts working like a flywheel. Each task makes the next one a little cheaper. Each decision reduces future uncertainty. Each discovered edge case improves the next QA cycle. Each deployment lesson learned reduces the risk of the next release.

Maybe it is time to stop thinking only in terms of:

Did the agent complete the task?

And start asking:

Did this task make the next task smarter, cheaper, and faster?