FFAR REACH
INDUSTRIESIN DEVELOPMENT
Developer journal

Developer journal · Building With LLMs

AI Isn’t Building My Game. It’s Changing How I Build It.

How I’m using large language models to accelerate software development and make Far Reach Industries possible as an independent project.

A three-part series exploring the technology, the engineering, and the experience of building Far Reach Industries as an independent developer.

Over the last two articles, I’ve been exploring two related questions.

First, whether today’s large language models deserve the kind of intelligence we tend to associate with the term AI.

And second, whether being able to generate working code means a system can actually engineer software.

My conclusions are fairly straightforward.

LLMs are powerful computational tools, not artificial software developers that should be blindly trusted with a project.

And writing code, regardless of how quickly it can be generated, is only one part of engineering reliable software.

Which raises an obvious question.

If I’m this skeptical of AI, why am I using it to build a game?

Because there’s an enormous difference between believing that an LLM can independently engineer a complete software system and recognizing that it can make an experienced developer substantially more productive.

And that difference is at the heart of how I’m building Far Reach Industries.

Far Reach Industries is a science-fiction colony and industrial simulation game. It’s an ambitious project involving interconnected simulation systems, resource management, power distribution, manufacturing, terrain, rendering, and all the mechanics that make a complex simulation interesting.

It’s also the kind of project that would have been difficult to tackle as a solo developer just a few years ago.

Not because I couldn’t write the code.

But because of the sheer volume and variety of work involved.

I’m doing this largely as a hobby. I wanted to make a game that I would want to play, share it with other people, and hopefully make a little money from something I enjoy creating.

I didn’t start with a development studio, a team of programmers, or a substantial production budget.

I started with an idea and a willingness to see how far I could take it.

That’s eventually what led me to create Crown & Crabapple: a place for the game to live and, perhaps, for other projects in the future.

And LLMs have changed what’s possible along the way.

I use them to explore technical approaches, develop architecture, implement features, investigate bugs, build tests, evaluate performance, and challenge design decisions.

The result isn’t that I’ve stopped being a developer.

It’s that I can spend more of my time making engineering decisions and less of it performing the mechanical work required to implement them.

But working effectively with these tools requires a different kind of discipline.

And that’s the part of AI-assisted programming that I think deserves much more attention.

The Biggest Change Isn’t How Fast I Can Write Code

When people discuss AI-assisted coding, they tend to focus on how quickly an LLM can generate an implementation.

Describe a feature, press Enter, and watch hundreds of lines of code appear.

That’s impressive, but I don’t think it’s the most important change.

For me, the real improvement is how quickly I can move through the development cycle:

Idea → Research → Architecture → Implementation → Testing → Evaluation → Revision.

Before AI, a significant amount of time could be spent researching an unfamiliar library, comparing implementations, constructing a prototype, and writing the supporting code needed to evaluate an idea.

Today, I can work through that cycle much faster.

If I’m considering a new simulation subsystem, I can discuss competing approaches with an LLM, identify potential architectural problems, develop a prototype, and examine the results in a relatively short development session.

And importantly, I can discard an approach without having invested days of work.

That changes how I make decisions.

Instead of committing early to an implementation because of the time required to build it, I can afford to explore multiple possibilities.

AI hasn’t eliminated the need for engineering judgment. It’s made that judgment more valuable because I can put more alternatives in front of it.

My Role Is Shifting From Writing Every Line to Directing the Implementation

I still approach development as an engineer.

I care about architecture, maintainability, performance, and the long-term consequences of technical decisions.

What has changed is how much of the implementation I need to write manually.

When building a feature, I can describe the behavior I need, establish the constraints, identify the systems it must interact with, and have an AI assistant produce an initial implementation.

Then I review the result.

Does it respect the architecture? Does it duplicate existing logic? Has it introduced unnecessary abstractions? Is the data model appropriate? What happens when the workload increases?

These are the same questions I would ask when reviewing another developer’s code.

That comparison is useful because AI-generated code should not receive a lower standard of review simply because a machine produced it.

If anything, the speed of generation makes review more important.

An LLM can produce a remarkable amount of plausible code very quickly. It can also produce a remarkable amount of technical debt just as quickly.

The objective is not to maximize the amount of code AI writes. It’s to minimize the time between identifying a problem and arriving at a well-engineered solution.

Sometimes that requires generating code. Other times it means refactoring, simplifying, benchmarking, or deciding not to implement something at all.

AI Needs to Understand the Architecture, Not Just the Task

One challenge I’ve encountered is that AI coding assistants naturally focus on the problem directly in front of them.

Ask an LLM to implement a feature, and it will generally try to produce a solution.

But a solution can be correct locally and still be wrong for the application.

This is particularly dangerous in a simulation game.

Far Reach Industries isn’t a collection of isolated mechanics. Its systems need to operate together.

Power generation affects production. Production requires resources. Resource extraction depends on infrastructure. Infrastructure interacts with terrain. Everything needs to advance within a coherent simulation.

If I ask AI to implement those systems independently, I risk getting several individually reasonable implementations with incompatible assumptions.

One subsystem might maintain its own timing. Another might duplicate resource state. A third might introduce direct dependencies that make future changes difficult.

The code might work, but the architecture gradually deteriorates.

That’s why architectural context is essential.

I want the AI to understand where simulation state belongs, which components own particular responsibilities, how systems communicate, and which boundaries must remain intact.

In practice, that means treating project documentation, architectural constraints, coding standards, and tests as part of the development system itself.

These aren’t just documents written for human developers. They’re also a way to communicate intent to the AI.

The goal is to give coding assistants enough context to implement features without constantly reinventing the architecture.

A Practical Example: Choosing the Right Game Engine

One of the more interesting parts of developing Far Reach Industries has been evaluating the technology needed to support it.

I’ve explored Unity, Unreal Engine, and Godot, looking beyond their feature lists to understand how they perform against the specific requirements of the game.

This is an area where AI has been particularly useful.

Rather than simply asking which engine is best, I’ve used AI-assisted analysis to break the problem into measurable questions.

How efficiently can an engine render thousands of structures? What overhead comes from individual scene objects? How well does instancing scale? What happens when lighting becomes complex? How should the core simulation communicate with the renderer?

In one Godot benchmark, for example, 20,000 separate building nodes built from a 24-piece kit measured approximately 5.20 milliseconds. Using MultiMesh instancing, 50,000 objects measured approximately 1.04 milliseconds.

That distinction tells me something useful about where the costs actually occur.

But it doesn’t mean Godot automatically wins.

There are still questions about terrain deformation, excavation, rendering quality, packaged performance, and how the engine integrates with the larger simulation.

This is where I find AI most valuable: helping identify the important questions, structure experiments, compare results, and challenge assumptions.

I don’t want an LLM to confidently tell me which engine to use.

I want it to help me gather the evidence necessary to make that decision myself.

An AI recommendation is a hypothesis. A working benchmark is evidence.

AI Makes It Easier to Experiment, but Easier to Get Things Wrong

One of the biggest advantages of AI-assisted development is that experimentation becomes cheaper.

I can explore a different architecture, test a new algorithm, or prototype an unfamiliar rendering approach without the same up-front development cost.

That’s incredibly useful.

But there’s a downside.

When code becomes cheap, it’s tempting to keep generating more of it rather than examining what already exists.

The AI proposes a solution. It works well enough. We move on.

Then another feature gets added.

Then another.

Eventually, the codebase contains a series of individually plausible decisions that don’t form a coherent whole.

This is what concerns me most about AI-assisted development: not that an LLM occasionally writes incorrect code, but that it makes architectural inconsistency so easy to accumulate.

Compilation isn’t validation. Passing a small set of tests isn’t proof of scalability. And a feature that works in a prototype isn’t necessarily ready for a production codebase.

I’ve become increasingly interested in using AI for the critical part of the process, not just the constructive part.

Instead of only asking, “How do we implement this?” I also want to ask:

These questions turn AI into more than a code generator.

They make it a useful participant in the engineering review process.

Of course, the model’s answers still need to be validated. An LLM can be just as confident when critiquing an implementation as it was when generating it.

The Developer Becomes the Editor

There’s an idea from design that I think applies equally well to software engineering: when producing something becomes easier, editing becomes more important.

In traditional development, implementation effort creates a natural constraint. You have to prioritize because you can only write so much code.

With AI, you can build more ideas much faster.

That means the difficult decisions increasingly happen after something has been generated.

Should this feature exist? Is the implementation more complex than necessary? Does it fit the rest of the system? Is the abstraction useful, or was it introduced because the model recognized a familiar pattern?

Being able to reject an implementation is becoming just as important as being able to request one.

I don’t need AI to win an argument about why its proposed architecture is correct.

I need it to expose tradeoffs, respond to criticism, and help explore better solutions.

And I need to be willing to throw away generated code.

That’s an important mindset shift.

When implementation is expensive, developers can become attached to the code they’ve written because of the effort invested in it.

When AI makes implementation cheaper, we have an opportunity to be more ruthless about quality.

The fact that code exists is no longer a particularly compelling reason to keep it.

The Goal Was Never to Build an AI-Generated Game

There’s something worth clarifying about this entire experiment.

I didn’t decide to make Far Reach Industries because I wanted to demonstrate what artificial intelligence could do.

I wanted to make the game.

The interest in simulation systems, industrial infrastructure, colony management, and the kinds of complicated interactions that make these games interesting existed independently of LLMs.

The technology simply changed how realistic it was for me to attempt the project.

And I think that’s an important distinction.

There’s a lot of discussion about AI-generated games, automated content, and whether someone can describe a game in a prompt and have a model build it.

That’s not particularly interesting to me.

I’m not trying to remove myself from the creative or engineering process.

I enjoy that process.

I enjoy working through difficult technical questions, designing systems, evaluating competing approaches, and figuring out how to turn an idea into something functional.

What I don’t particularly enjoy is spending weeks implementing supporting code when I already understand what the system needs to do.

LLMs allow me to spend more time on the parts of development I find valuable.

They also let me take on areas of the project that would otherwise require considerably more time to research and implement.

That doesn’t make the game less my creation.

I’m still deciding what to build, how it should behave, which technical approaches to accept, and when something isn’t good enough.

If the game succeeds, it will be because those decisions produced something people enjoy playing.

And if it fails, an LLM won’t be responsible for that either.

AI is part of my development process. It isn’t the reason the game exists.

The Real Benefit for an Independent Developer

All of this has a much larger implication for projects like Far Reach Industries.

A colony simulation is not a small undertaking.

There are simulation algorithms, economic systems, logistics, construction mechanics, power networks, rendering, terrain, user interfaces, save systems, performance optimization, and countless interactions between them.

Each area represents its own body of knowledge and implementation work.

Without AI, building something at this scale independently would require either substantially reducing the scope or accepting a much longer development timeline.

AI changes that calculation.

It allows me to move between disciplines more efficiently, investigate unfamiliar technologies, and implement systems without having to manually write every supporting component.

It also gives me the ability to explore ideas that I might otherwise dismiss because the cost of experimentation would be too high.

That doesn’t mean the project becomes easy.

The underlying engineering problems remain.

But the amount of work I can realistically take on has increased significantly.

And that’s a much more interesting benefit than simply generating code faster.

AI doesn’t just accelerate the projects I could already build. It expands the range of projects I can seriously consider building.

I’m Still Responsible for the Software

There’s a tendency to divide software development into two camps: traditional programming and AI-generated programming.

I don’t find that distinction particularly useful.

The important questions haven’t changed.

Does the software work? Is it reliable? Does it perform adequately? Can it be maintained? Does it solve the intended problem?

The method used to produce the code doesn’t excuse poor results.

If an AI assistant introduces a bug, it’s still a bug in my application.

If it chooses a poor architecture and I accept that architecture, the consequences are mine.

If it generates a feature that doesn’t belong in the game, I can’t blame the model for implementing what I requested.

I remain responsible for understanding the systems I’m building and for the quality of the software I release.

That’s why I don’t see AI as replacing my engineering experience.

I see it as amplifying the value of that experience.

The better I understand the architecture, the more effectively I can direct AI. The better I understand the technical constraints, the easier it is to recognize questionable implementations. And the better I understand what I’m trying to accomplish, the less likely I am to accept a generic solution simply because it works.

Building Something Worth Playing

I started this series by questioning what we really mean when we call something artificial intelligence.

Then I explored the difference between generating code and engineering reliable software.

And now, having explained how I’m using these tools in my own project, I think all three discussions lead to the same conclusion.

The value of an LLM isn’t determined by how intelligent it appears. It’s determined by what it actually helps you accomplish.

For me, that means building Far Reach Industries.

Not generating as much code as possible.

Not proving that a machine can replace a software developer.

Not creating a demonstration of the latest AI technology.

Just building a game I’ve wanted to make, with the hope that eventually other people might want to play it too.

The tools I use are part of that story, but they’re not the whole story.

There are still architectural problems to solve, systems to integrate, performance bottlenecks to investigate, and countless decisions about what will actually make the game enjoyable.

Some of those decisions will be right.

Others will turn out to be mistakes.

And I intend to document both.

That’s part of why I created Crown & Crabapple. I wanted a place for the game to live, somewhere to share what I’m building, and somewhere to write about the process without pretending that every milestone is a breakthrough.

I hope to eventually turn this hobby into something that earns money.

But first, I need to make something worth playing.

LLMs are helping me get there.

AI isn’t building my game. It’s changing what I’m capable of building.

And I think that’s a much more interesting story.

This is Part 3 of Building With LLMs, a series about artificial intelligence, software engineering, and the development of Far Reach Industries.

Read the earlier articles:

Follow the development of Far Reach Industries, a science-fiction colony and industrial simulation game from Crown & Crabapple.