Building Products with AI, Part 2: From Code to 3D

When I wrote my original Building Products with AI post, most of my focus was on software development.

At the time, I was using tools such as Cursor, Claude, Grok and GPT to help turn ideas into applications, FiveM scripts and working products. Since then, that workflow has continued to evolve considerably.

AI is no longer something I simply use to generate code.

It has become part of a much broader development workflow that now covers software architecture, debugging, research, planning, 3D development and even interacting directly with tools such as Blender.

At the same time, I've deliberately continued learning the underlying tools myself.

The result has been an interesting balance between learning technical skills traditionally and using AI to dramatically increase what I can build with them.

800,000+ Lines of AI-Assisted Code

One of the easiest ways for me to understand how much my development workflow has grown is simply looking at its scale.

Across my projects, I've now worked through more than 800,000 lines of AI-assisted code using Cursor, primarily with Claude and Grok.

I deliberately describe this as AI-assisted code rather than saying I've personally written 800,000 lines.

I haven't.

AI generates a significant amount of the implementation.

My role increasingly looks more like:

Idea → Requirements → Planning → Implementation → Review → Debugging → Testing → Iteration → Release

I'll define what I want a system to do, break larger features into manageable pieces and provide the AI with the context it needs to implement them.

From there, I review what has changed, run the application, identify problems, trace errors, modify smaller sections myself where necessary and continue iterating with the model.

The more I've worked this way, the more important I've found context and planning to be.

A good model with poor context can produce terrible results.

Giving it a clear understanding of the existing project, constraints, database structure, expected behaviour and previous decisions can make an enormous difference.

I've therefore moved away from simply asking:

"Can you build this feature?"

towards much more structured development workflows.

For larger changes, I'll often spend considerably more time planning the implementation with the model before allowing it to touch the code.

AI Doesn't Remove the Need to Understand What You're Building

One thing that has become much clearer as my projects have grown is that AI-generated code still needs someone responsible for it.

When you're experimenting with a small script, it's relatively easy to generate something and see whether it works.

When you're dealing with a much larger application containing databases, APIs, authentication, frontend state, backend services and thousands of interconnected files, that approach quickly falls apart.

I've encountered plenty of situations where an AI has:

misunderstood existing architecture
fixed one issue while introducing another
created unnecessary duplicate functionality
made incorrect assumptions about an API or framework
over-engineered something that should have been simple
or produced code that looked completely reasonable but didn't actually work

The human part of AI-assisted development becomes less about remembering syntax and more about judgement.

Does this solution actually make sense?

Does it fit the rest of the application?

What changed?

Why did it change?

How can I prove that it works?

Those questions have become much more important to my workflow than simply being able to type the implementation manually.

Moving Beyond Code

Probably the biggest change since Part 1 is that my use of AI has expanded beyond software.

I've spent a significant amount of time learning Blender and 3D development, particularly around creating assets and environments for GTA V/FiveM.

Unlike my software workflow, I wanted to properly learn the fundamentals of Blender myself.

That has meant learning modelling, topology, UV mapping, materials, texturing, normals, collisions, optimisation and the various processes involved in getting an asset from Blender into a game engine.

AI hasn't replaced that learning process.

Instead, I've been using it to accelerate it.

If I encounter a shading problem, strange topology, an export issue or something I don't understand about Blender, I can describe exactly what I'm seeing and work through the problem interactively rather than spending hours searching through unrelated tutorials.

That has dramatically reduced the feedback loop when learning.

Connecting AI Directly to Blender with MCP

One of the more interesting things I've experimented with recently is MCP (Model Context Protocol).

Rather than AI simply telling me what buttons to press in Blender, MCP allows an AI system to interact with tools and information much more directly.

I've experimented with connecting AI workflows into Blender so that the model can assist with actions inside the software itself.

That changes the relationship considerably.

Instead of:

Me → AI → Instructions → Me → Blender

we're beginning to move towards:

Me → AI → Blender

For example, I can describe something I want to create or modify and use AI-assisted tooling to help perform parts of that process directly.

It isn't magic, and it certainly doesn't eliminate the need to understand Blender. In fact, understanding Blender becomes even more important because I need to recognise when the generated result is wrong.

But it demonstrates where I think AI-assisted creative tooling is heading.

Combining AI, Code and 3D

FiveM development has become a particularly useful playground for combining all of these skills.

A single project can now involve:

Lua / JavaScript / TypeScript

↓

Database & backend logic

↓

React-based UI

↓

Blender 3D assets

↓

Game integration

↓

Testing and optimisation

AI can assist at practically every stage, but I'm still responsible for making all of those pieces actually work together.

I've also started using image-generation and 3D-generation tools as part of the asset-development pipeline.

An idea can begin as a description, become a visual concept, move into a 3D model, get cleaned up and optimised in Blender and eventually become an asset running inside GTA V.

That means AI isn't just accelerating individual tasks anymore.

It's helping connect different disciplines that traditionally would have required several different skill sets.

Building Real Products Changes Everything

Something else I've learned since my original post is that there's a massive difference between generating something impressive and maintaining a product people actually use.

Through my FiveM work and digital store, I've had to deal with the less glamorous parts too:

customer reports, bugs, updates, compatibility issues, optimisation, documentation and releases.

AI can help solve a problem, but ultimately the customer doesn't care whether Claude wrote a function or I typed it manually.

They care whether the product works.

That creates a useful reality check for AI-assisted development.

If the code crashes, performs badly or doesn't do what the customer expects, saying "the AI generated it" isn't an excuse.

I'm still responsible for the finished product.

What I've Actually Learned

The biggest lesson from the last year isn't that AI can write lots of code.

We already know that.

What interests me more is how much one person can now realistically learn and build when these tools are used effectively.

My professional background is primarily networking and infrastructure.

I've then studied Computer Science, built software, created FiveM resources, learned Blender, produced game-ready 3D assets and experimented with connecting AI directly into creative software.

I'm certainly not an expert in every one of those areas.

That's actually the point.

AI has allowed me to move between disciplines much faster while still gradually building my own understanding underneath it.

The limiting factor is increasingly becoming how well I can understand a problem, communicate it, evaluate the result and keep learning, rather than how much syntax I can remember.

Where I Think This Is Going

My original post ended by saying that the distance between an idea and a finished product was shrinking.

A year later, I believe that even more strongly.

But I think the bigger change is that the boundaries between different technical roles are beginning to blur.

A single person can increasingly move between:

software development → infrastructure → AI → automation → design → 3D → product development

without needing to become a world-class specialist in every individual discipline first.

The people who benefit most from these tools won't necessarily be those who can generate the most code.

I think they'll be the people who can understand problems, learn quickly, give AI the right context, recognise when it's wrong and ultimately turn its output into something useful.

That's the skill I've been trying to develop.

And after more than 800,000 lines of AI-assisted code, numerous software projects, commercial FiveM products and an entirely new journey into 3D development, I'm still finding new ways to use these tools.

Part 1 was about learning how to build software with AI.

Part 2 has been about learning how much further that idea can go.