Rebol games by open source LLMs

Last night I tested a new LLM API provider (cline-pass), by having each of the available open source LLMs create a game using Rebol R2 language. The entirely open ended prompt in Pi coding agent was the same for every model: 'Please provide a game in the Rebol R2 language'. All the generated games are available here: https://com-pute.com/nick/rebol_games_by_open_source_LLMs.zip The Rebol R2 interpreter needed to run them is available here: https://www.rebol.com/downloads.html The successful code generation results were interesting because at the beginning of 2025, none of the frontier LLMs could reliably write any Rebol code whatsoever, and Rebol R2 language & dialects have now been legacy and unsupported for more than a decade, so no new code or documentation examples would be expected to be included in the training corpora of any new model. Most of the models successfully created working Rebol applications, and a few completed the task first shot. I was particularly surprised by the Snake game created by Qwen 3.7 Max, which was built using the Rebol Draw dialect. It responds to keyboard controls, and includes fully working game logic. It's a simple result by any modern LLM coding standards, but impressive because Qwen built this code from scratch, and fixed errors entirely by reading Rebol2's cryptic debug output (which doesn't even include line numbers). Kimi 2.7 created a little 'fractal tree' draw demo, and a simple Tic Tac Toe game using Rebol2's VID UI dialect. It was the only model to work first shot for every output example, without any errors in the code. GLM 5.2 created a text based hangman game, which included a simple visual text rendering of the man hanging on the gallows, whenever the user chose incorrect letters, and its game play features work correctly. GLM 5.2 used a lot of tokens, with a lot of iterations, and would have cost the most on a pay-by-token API. Mimo 2.5 Pro created a text based choose-your-own-adventure/exploration game called Dungeon Adventure, with 21k of story text, and working game logic in the Rebol2 console. Mimi 2.5 generated a text based tic-tac-toe game with the logic needed to beat a person who's not paying attention to the game play. Deepseek V4 Pro very quickly built a snake game using Draw dialect. It completed nearly first shot. There were other simpler entries including variations of snake and tic-tac-toe, number guessing games, and another text based adventure game. Minimax M3 and Qwen 3.7 Plus were the only models to fail before I gave up on iterations of a snake game. Deepseek V4 Flash failed on a snake example (I only tried a few iterations), but it succeeded with 2 other simple example text based console games. It's clear that the bigger models have more working world knowledge, even about old deprecated topics such as Rebol R2, and that they are capable of using that knowledge to effectively reason through novel tasks. I'll try this with Fable at some point - I expect it can achieve very challenging tasks with Rebol 2. I've seen Fable create phenomenally good 3D games using only the native Windows XP API, and complete other amazing tasks, entirely from the knowledge in its parameters. The Rebol game examples here were all created in a single casual sitting of just under an hour and a half.

I have been using the free version of google and claude with Rebol 3 Oldes and they are doing great. Mostly database crud stuff.

I first show it some demo scripts I have and point it to https://raw.githubusercontent.com/Siskin-framework/Rebol-SQLite/refs/heads/main/ci-test.r3 so it can learn and then I ask it to do db scripts

just tried the free chat.deepseek.com and it's working but you need to show a lot of example to make it work it correctly

for example deepseek just told me for the second time: The error is with the else keyword which isn't valid in REBOL 3. Let me fix the diagnostic script

I do everything in Pi coding agent. With an agent, you can store all that required context in local files, so that that sort of manual in-context learning preparation isn't required every time.

My point with the examples above was to check how well each of the LLMs had been pretrained on Rebol, and how well they could reason through anything that pre-training hadn't baked into their understandings. Working with a coding agent like Pi is much more effective than working in a chat interface, because the agent can iterate automatically: write code and tests, launch the interpreter and run everything automatically, read debug output, make changes to code based on error messages, etc., all in an unattended automatic loop until the goal is accomplished. Copy/pasting code from a chat, and managing that process manually is orders of magnitude less efficient, unless the chat system has a working environment where it can build, install, and iterate agentically (like ChatGPT does with Python). It's easy to set up Pi: https://aibynick.com/thread/29 You can set up an account with OpenRouter to use basically any LLM with Pi (or any other coding agent), but my favorite lately has been https://cline.bot/cline-pass Cline-pass costs $4.99 for the first month, and you get an absolutely massive volume of tokens. If you use deepseek-v4-flash, which has become my default daily driver for virtually every sort of common development work and agentic task, I think it would be hard to hit your limit, even if you hammered the Cline-pass API all day every day.

it seem so convoluted...! You need to install PI then OpenRouter and then select agents but depends on what you really need it or how much are you willing to spend... is it Cline a competitor to OpenRouter or PI ? so confusing....may be because we are at the beginning of a new world. For example why doesn't OpenRouter incorporate PI or vice versa or Cline then there is Cursor.....? it seems so complicated for no reason

It's not convoluted, there are just a lot of choices between competitive services and software offerings by different companies. Once you get the basics about how agents and LLMs work together, they all basically work the same way. Pi is an agent (one choice of a piece of software called a 'harness'). OpenRouter is an LLM API service provider (one company that provides access to LLMs running on their GPU hardware). The LLM can be thought of as a 'brain', the agent can be thought of as a 'body' which gives the LLM brain access to work on your local computer hardware/OS. You install the harness on your computer and choose what resources it has access to. There are plenty of other popular harnesses (Hermes, Codex, Claude Code, Open Code, Open Claw, Goose, Nanobot, etc. - all software you install to give an LLM brain access to work on your local PC) and there are plenty of other LLM providers (OpenAI (GPT), Anthropic (Claude), Deepseek, Grok, Kimi, GLM, Minimax, etc. - all different brains). All the harnesses and LLMs do essentially the same thing, but there are options to satisfy every need, every type of work (for example, harnesses tuned to help with software development, operating system automation tasks, personal assistant tasks, etc.), every budget, every security profile, every performance level, etc. Some LLM providers also build harness software tuned to work specifically with their particular LLMs (Cursor, Codex, Claude Code, etc.). There are open source and commercial models, small/fast/cheap models, large/slow/expensive models, etc. In the past few months we've gotten models such as Deepseek V4 Flash which can complete most development and agentic tasks at a cost of *18 cents* per million output tokens. Deepseek is free and open source - I run a copy of it on several of my local GPU server machines, and I also run it over APIs served by OpenRouter, Cline-pass, Deepseek, and others. The agent harness is software you install on your PC, your phone, VPS accounts, etc., to enable an LLM (wherever it's running on GPU hardware - locally, or in some data center, over an API) to manipulate your local computing resources, to work unattended in iterative loops to complete software development tasks directly with code and tooling on your computer, and to get work accomplished for you, on systems where you run them (you can choose to provide your harness the credentials needed to log in to your accounts, to summarize and respond to emails/messages, to read and write documents on your system, to configure OS settings, to install software, to perform research about any local project you're working on, etc.) An LLM brain is smart enough to understand it's working on your local machine. The harness tells the LLM brain about its environment, with every request it sends (along with sending the entire conversation you're currently involved in, in every session). The harness program gives the LLM access to read and write files on your hard drive, execute OS commands, install software tools, etc. The harness additionally enables you to create memories and 'skills' about how to perform certain tasks you want to accomplish regularly. Those are typically just text files that you save on your machine. You can share skill files and use skills created by other people. You can also ask the LLM to create and save skill files anytime you successfully complete a task, so you don't have to go through the same long process of having the LLM figure out how to accomplish that goal every time. You can also have the harness save memories, which it loads automatically every session, so that it remembers your preferences and working habits. Pi is a very simple agent, which sends only a minimal amount of information to the LLM every session, but it provides deep capability to not only use skills, but also to branch sessions, and to automatically extend itself with self-created extensions to its own internal software code. It avoids all the typical bloat found in other agent applications, but it's incredibly malleable and capable. You simply prompt it to build extensions - it gives the LLM all the information needed to write working extension code. All the biggest LLM brains typically need to run on very expensive hardware, which may require more electricity than most people have available at their home or business location. So most people use remote LLM service providers, because they don't want own/run the expensive GPUs which are required to perform LLM inference. Users hook up their agent harness software to any provider which offers inference on the models they prefer to use, for fees they prefer to pay. Or they hook up their agents to models running on their local GPU server machines. I have 7 machines with GPUs that get used for local inference (for data processing tasks which require HIPAA compliance, for example, involving personal health info that can't be sent to any public LLM API provider), but it's still very convenient, fast, and cheap for me to use a provider like OpenRouter or Cline-pass for everything else. I set up those LLM services so that agents on my phone and VPS accounts can work with a powerful brain, as long as they have an Internet connection. LLM API service providers make it easy to instantly hook up to a big brain, regardless of the local hardware your agent software runs on. I use OpenRouter because they provide access to 500+ models - basically every commercial and open source LLM available in the industry. You create one account with OpenRouter, and can use models from basically every company that makes LLMs. I also still use OpenAI's LLMs for lots of development pipelines that have been established for months, using their models. And I have a dedicated account with Deepseek, because my favorite V4 Flash model runs at 250 tokens per second at that API (extremely fast). I've started using Cline-pass lately because they provide access to all the most common open source LLMs, for the lowest prices I've seen anywhere. With Cline-pass I can get more token usage on a few of my favorite models, than I could run through, if I ran those models nonstop all day every day all month - and my favorite model runs at 200 tokens per second on that API (it runs much, much slower on my local machines) - all for less than $7 per month. So I choose to use Pi and those commercial LLM provider services, but those configurations are all just my personal choices. Everyone has their own favorite choices. All anyone really needs to do, though, is open an account with OpenRouter, create an API key, and install Pi, or any other single agent software. The link below walks through every detailed step of setting up Pi & OpenRouter, and explains much more about all the other choices you'll find in the LLM ecosystem: https://aibynick.com/thread/29 So, everything you can do with an LLM can be accomplished with an Openrouter API key and Pi. With OpenRouter, you can use *every* well known model, the instant each one becomes available. You don't need a bunch of expensive subscriptions. And you don't need to use expensive models - just use Deepseek for most work. I use the smaller Deepseek model called V4 Flash, for just about everything. It's basically as good as all the most expensive models, for most common tasks. It costs 18 cents per million tokens on most APIs, and it's much cheaper on Cline-pass. Plus it's extremely fast, and uses much less energy than most of the big frontier models. You can use Mimo 2.5 or one of the other inexpensive multimodal models for vision work. I explain everything about using all the other most useful inexpensive models, in the article linked above. None of that has to be convoluted or complicated. With an Openrouter account, it takes less than a second to switch models in Pi (Pi automatically knows all the models available on Openrouter - you just type '/model' to select and switch instantly between them). And to install Pi, it just takes a few seconds of hands-on work. The instructions are completely covered in the link above. I've got Pi running on 20+ PCs, multiple VPS hosting accounts, and my phone. If Pi feels too complicated, try PicoClaw - it requires zero installation on any PC, and they even release a universal APK that runs instantly on any Android device: https://picoclaw.io It's absolutely worth getting past the hump of learning to use an agent and an LLM provider. You can learn all about how to do it in a single sitting, and get completely comfortable with it all, in a day. Agents are made to be easy to use. At this point, my LLM models are involved in helping me accomplish virtually every task I need to complete, every day. Today I had Pi on my phone build a beautiful 49th anniversary animated digital card for my parents, while I was driving to their house, totally hands off, using voice control. That's just one example of thousands of agentic tasks I've had agents perform. LLMs help me much more quickly and easily handle most communications (emails with clients, IT teams, project managers). I have my agents manage all my billing (they summarize all the work I've done, the hours I've worked, and generate the invoices). Software development tasks are now basically fully automated, and each development step/revision in the course of large development projects, typically gets completed instantly. Massively complex applications which would have taken dozens of man-years and cost millions of dollars to complete a few years ago, can now be completed in a few months by a single developer, without any pain or trouble (in many cases, much technical skill is no longer required to build software). I have clients with zero software development experience building and deploying their own real, valuable, customized applications, the likes of which would have been genuine time-consuming challenges for an experienced team of developers just 2 years ago. In comparison, configuring an OpenRouter account and installing a harness application is not even close to being as complicated as writing even a few lines of code by hand, in any programming language.

BTW, immediately after posting the message above, I saw that GPT 5.6 became available on Openrouter - I hadn't even seen in the news that it had been released to the public yet. I keep my eyes on https://openrouter.ai/models every day, to see which new models are available. That page is better than any news source, to keep up with all the new models being released by companies around the world. Instead of reading hype about all the models, you can simply try them for yourself. So I popped openai/gpt-5.6-sol into the Jan chat harness (get Jan for free at https://www.jan.ai) and tried the prompt linked below (that prompt has become a favorite of mine for getting a quick sense about how much knowledge a model has about obscure topics). Sol did a great job: https://com-pute.com/nick/sol_first_prompt.txt And to be clear, I just like testing new models quickly in the Jan.ai chat interface, because it only takes a few seconds to set up a new model in Jan (Jan runs locally on your PC and connects automatically to models provided by OpenRouter and other LLM API providers). But I could have done the exact same thing in Pi. You can chat in Pi - you don't necessarily need to use it to work on agentic tasks, or to develop software. Jan is a quick and convenient point & click chat tool that I like to use for short conversation interactions. Notice that Sol is expensive. The response linked above cost 6 cents to generate. A response from Deepseek V4 Flash would typically cost 150-200x less than one from Sol - so I tested the exact same prompt with it and it actually cost even less than that: $.000247 (247x less than Sol). Both responses are included in the link above.

Judging agents+LLMs to be convoluted because they're a complex solution to writing code in Rebol, feels similar to judging excavators and dump trucks to be convoluted tools because they're a complex solution to changing potting soil for a house plant. You don't need an excavator or dump truck to change potting soil for a house plant, but that doesn't mean excavators and dump trucks are therefore simply convoluted tools, from every point of view. Sure, excavators and dump trucks do require some training and maintenance in order to be used well, but then they're potentially tremendously productive and useful, because they dramatically extend native human capabilities for many purposes that are far more challenging than changing potting soil. You certainly wouldn't want to use your raw fingers to do the job of an excavator, especially if you've got 10 big construction jobs to complete. Similarly, you wouldn't want to forego the use of LLMs and agents, if you're a software developer or IT manager with seriously challenging daily demands from clients. There is likely no other tool in all the technology landscape, which provides as much value returned, for the time invested in learning, as LLMs and agents.

Are you still using Anvil ? what about Pocketbase and Sqlpage ? what languages do you use to write apps for clients ? Or at this point is more convinient to write apps from scratch ?

I've written a lot about that over the past few years. There's a bit of a summary here: https://aibynick.com/thread/12 TL;DR: I now deliver most typical web based business applications as Flask/Python projects. I'm still supporting a long list of production Anvil applications, but when those projects need serious updates, it's usually better to have GPT convert them to Flask. The conversion of an entire mid-sized Anvil application to Flask, can normally be performed by GPT faster than I can manually implement a handful of significant full-stack updates to an Anvil app (for example, changes to functionality which involve coordinated alterations to UI layout, back-end logic, and related database schema/query updates). Converting a significant project from Anvil to Flask typically takes 1-2 days, but once a conversion to Flask is complete, performing extensive full-stack updates is typically just a few minute process with GPT. Of course it depends on the model, but most LLMs tend to work really well with Flask projects. With GPT, I use a workflow that involves uploading the entire project as a single zip file, to a chat conversation (I don't use the OpenAI API for these sorts of projects, only the $20/month ChatGPT subscription). I've written a lot about that: https://aibynick.com/thread/3 Otherwise, I typically use Pi coding agent with Deepseek to write Python/Flask code. Anvil was a fantastic environment, but no framework can improve productivity in a way that compares to using modern LLMs and coding agents. I now regularly complete lists of requirements which previously might take a week of work, in just a few minutes. This isn't hyperbole, it's been a daily reality since the beginning of this year. Beyond just writing code, I involve LLMs in every phase of research, communication with clients and IT staff, server configuration, etc. No software development framework *does that work* for you. One of the most important pieces of using LLMs to write code, is understanding which development tools LLMs know how to use best. In my experience, those tools are not always the same as the ones humans use best. I had never chosen Flask as my preferred framework before building with LLMs. But then I spent a solid year testing and comparing every development tool I'd ever used, and Flask/Python came out as the clear winner, by a long shot, over anything I'd used historically, when it came to how successful LLMs were at writing working code. Flask beat out Anvil resoundingly for productivity, precisely because Anvil makes use of integrated visual UI and DB building tools meant to ease development work for humans. LLMs do best when they have *code* to work with all those layers, as opposed to interacting with development tooling that involves any sort of visual interface designed to ease human labor. I would never have said Flask was more productive than Anvil to build full stack applications manually, but I'm hundreds of times more productive writing full stack Flask code with LLMs, than I could ever have been using Anvil's tools manually. There's also a ton more code and documentation available online about Flask, than Anvil, for example. There are endless examples of every common business application functionality, already implemented in Flask. It's important to choose tools that don't limit your capability, when developing the class of projects you work on. For the sorts of work I do, the Python ecosystem has satisfied every requirement I've run into, even for projects that you might not expect it to handle so well, such as real-time apps that require fast performance. For me, it's also very important not to limit the platforms, environments, and institutions where I can install the applications I build. Python is accepted naturally in so many work environments - integration with surrounding infrastructure has always just been a non-issue for me with the Python ecosystem. Developers who don't use Python often suggest that Python is too slow, but the heavy lifting in most data management apps happens in the database system. Python developers write queries in a Python language ORM, but the real computations happen inside an optimized SQL engine which benefits from half a century+ of deep, hard core, real-world tested RDBMS engineering. And the Flask framework delivers HTML pages composed by Python loops, but those UIs are rendered in browser engines which are backed by *billions of dollars* of research and development, and that platform has been stress-tested by billions of people, over decades. That's a solid foundation for real, practical, useful performance, and my experience has been that that architecture does work well in practice (more on performance later...). Python and Flask aren't some obscure little projects - they're tremendously successful and popular. Reddit, Netflix, Pinterest, Patreon, Twilio, Lyft, Airbnb and many others use it at scale in production. And the fact is, big LLMs can typically complete every requirement I run into, first shot, without errors, in just a few minutes, with Flask and Python. You'll often see the same LLMs struggle to successfully complete even basic functionalities with lesser known tools, even after repeated bug-fix iterations. Writing production applications with LLMs every day for the past 3 1/2 years, that's just where I've ended up. For the steps it takes to get a Flask project zip file created by GPT, Pi, or any other agent, and then installed on a server, take a look at: https://aibynick.com/thread/29?page=1#post-128 Compared to developing entirely without LLMs, everything is the same about how an application is conceived, planned, engineered, and built from well prepared requirements, how the application server is managed, how functionality is confirmed with diligent tests, etc. - you just don't have to manually write all the code. You don't even have to write the tests. You don't even need to do all the manual research about which libraries and tools in an ecosystem might be best for a project's requirements. You don't even need to write all the emails to your clients. You don't even need to write most of the user documentation for your apps. You don't even need to write all the details about what was completed, on your invoices... If you have the right background to conceive and orchestrate it all, LLMs can do all that time consuming work better, in a matter of minutes, than a team of 100 professionals could in days. There's not even a close hint of a productivity comparison to what was possible 4 years ago with the best frameworks and tools - and 4 years ago, I was using the most productive tools I had ever experienced, in decades of writing code. Using LLMs to write Flask/Python now beats them all by 100s of times, in terms of productivity. Right now, I have clients who've never written a line of code, creating serious production applications in Flask, with Pi and Deepseek. It would have previously taken those clients many years of deep experience to build those sorts of applications, using any language/framework and writing all the code by hand. Those clients build what they can, then pass their creations along to me, I perform code reviews and tests, add auth, logging, and other features needed for compliance, I perform installs on production servers, help guide them along the way about how to approach engineering challenges which require more planning, etc. In more than 30 years prior to this, I was only ever able to achieve that goal successfully with a small number of clients who learned Rebol, Livecode, Anvil, SQLPage, NS Basic, or any other tool/language/framework (including PHP and all the mainstream tools that were ever meant to enable average computer users to develop software). Baserow came the closest to being a serious development tool for non-technical users. In fact, it didn't just come close, it succeeded brilliantly. Anybody can learn to use it to actually build real production database systems, and I can build complex apps on top of Baserow databases (some of the biggest projects I've continued to work on in the last year still use Baserow extensively). But there's hardly even a real need for that any more, because building databases of any complexity is child's play for any modern LLM. Hand me a requirements doc for a complex piece of business operations software that would've taken days to build schema for in Baserow, and I'll have the entire full stack application completed and running on a server in less than an hour, in Flask, using GPT or Pi+Deepseek. The difference is like comparing snap-pops to nuclear bombs. Don't get me wrong, the differences between 'vibe coding' and real software engineering are still filled with all sorts of deep challenges. Any aspiring vibe coder should take a serious look at: https://aibynick.com/thread/28#post-58 And then read that post a second time, before diving into building any sort of project that's planned for use in a demanding production environment, to handle data & processes which are of any critical importance, or which involve any sensitive information. But LLMs can help ease many of those deep challenges too, especially if you have experience in all the traditional disciplines required to engineer software.

does it make sense anymore the language choice ? could you use C, Rust or Go to write your clients apps with ?

C isn't the best choice for any of the applications I build. I don't work on a team whose main goal is to optimize a portion of an operating system, or a browser, for example, over decades, to use every CPU cycle and byte of RAM as efficiently as possible. C's purpose is generally to write the system software which runs the heartbeat of hardware components, OSs, media decoders, database systems, higher level languages, network transfer protocols, and other foundational tools and infrastructure level machinery. I write end-user software on top of all that infrastructure, to help daily operations run more efficiently in businesses. There's an appropriate purpose and goal for each software development language, tool, and ecosystem. To build data management applications which enable business operations, I don't use the same class of tools which enable precise control of how bits flow through registers and logic gates in a CPU, across caches, and between buses, micro-controllers, I/O devices and other metal componentry inside a PC, in embedded systems, etc. There's a saying that using C to write applications is like using a razor blade to cut your grass. For the work I do, the goal isn't to sculp each blade of grass in my clients' lawns with microscopic precision. My role is usually something more akin to building an effective mowing machine that cuts the grass on 10,000 football fields each of my clients need to manage, as simply and efficiently as possible, so that their clients can run and perform all the other activities which occur on those fields. And if you stretch that analogy a step further, it's as if there are laws which require field owners to keep all their properties perfectly mowed and secure, or they get huge fines. My clients are mostly medical practices, or they're otherwise involved in dealing with PHI and other sensitive data, and they get fined if their data fields aren't perfectly managed according to strict regulations. A razor blade isn't the right tool for trimming back that huge pile of grass. There are bigger machines already built for that purpose. Even though characteristics such as verbosity and productivity have become the least important factors in language choice, when it comes to developing with LLM tools, you still want to use an ecosystem which richly supports the sort of development work you do. The types of apps I write are best done in Python and Flask, compared to everything else I've seen. Every app I build runs on a network connected server (typically deployed on a VPS, or on in-house servers managed by an IT team) and needs to be immediately and securely accessible on any client device (Windows, Mac, Linux, Android, iOS, Chromebook, etc.), without any noticeable installation or maintenance steps. Web UIs are the best for those sorts of apps because they enable instant updates - users don't have to install an app, they just go to a URL, in any modern browser. They always see the most recent version of the app, automatically (Flask makes that easier to enforce than many single-page frameworks). Python has the biggest, most mature ecosystem to accomplish all the common business computing goals (and also goals in AI development/implementation and other important fields). But most important, all the models know how to use Python better than any other ecosystem, and they are absolute whizzes at everything in the Flask ecosystem (SQLAlchemy ORM, Bootstrap/HTML/CSS/JS UI, Flask auth systems, all the add-on libraries in that ecosystem, etc.). And Flask is a simple and composable system which LLMs seem to be able to reason about well. The server based Jinja templating system used in Flask is versatile enough to incorporate *any* sort of HTML/CSS/JS UI tools - LLMs are also fantastic at writing that sort of code. If you need to add *any* imaginable complex visual layout design, interactive graphic system, datatable control, beautiful visual styling, or even 3D graphics - those things aren't even a speed bump for LLMs. See the post below about a UI building experience I had with Flask, using ChatGPT to implement the complex layout features made by a professional visual design artist (without affecting any functionality): https://aibynick.com/thread/10#post-16 The same is true of Flask's relationship with SQL, SQLAlchemy, and database systems. SQLAlchemy is a first class citizen in Flask, and working with traditional RDBMSs is another lingua franca of LLMs. Prepare your requirements properly, and an LLM can build 100% working schema, foreign key relationships, and thousands of lines of queries, first shot every time, in minutes. And it can painlessly migrate schema, and adjust complex ORM/SQL query logic just as quickly. SQL query edits which may take an experienced developer hours of painstaking detailed work to complete, can be completed by LLMs in a few seconds. BTW, it's my opinion that SQLite should generally be used for most database tasks that aren't web scale. It's fast, outrageously lightweight, works universally across every common platform, works without any installation, stores everything in a single file which can be included directly in your project zip files - so your LLM can actually see and interact with your data, whenever that's appropriate. SQLite files can be moved instantly between servers, they're easily backed up by downloading a single file, etc. Also, SQLite support is built in natively to Python (and most other languages), and it's the default RDBMS of choice for SQLAlchemy and most other ORMs. LLMs assume you're using it by default. You can even use SQLite in memory, for ethereal tasks. SQLite should be your default *data store* - and any functionalities that would be accomplished with special features of other RDBMSs can be offloaded to Python or whatever language tools you're using. Upgrading a SQLite database to handle web scale, from dev to prod for example, typically means just changing the connection string used by your ORM. And many big database ecosystems such as Postgres have simple to use tools which easily import/migrate legacy SQLite database files. It's much harder to go backwards. Use SQLite until you run into a situation where can't. Of course do the math before hand, to know for sure where the limits are for the entire expected lifecycle of your application, but most in-house business apps don't require regularly shoveling terabytes of data into a database. I've been running serious apps in production, for years, which handle thousands of real-time encrypted transactions per day. That's normal for most business apps, and SQLite won't bat an eye at that sort of load. Use WAL when an organization full of people may be making simultaneous writes to the data throughout the day. You'll be absolutely amazed how far SQLite can be pushed, if you haven't trusted it for real work in the past (see this interview with DHH for more about that topic: https://www.youtube.com/watch?v=0rlATWBNvMw). Beyond all the core tools such as SQL databases and web UIs, LLMs can work with the Python language and the rest of its ecosystem just as easily as they can say hello to you. The LLM industry has spent trillions of dollars improving that capability, and it's paid off. Using the particular ecosystems which the LLM creators have prioritized in training data, is the right choice, if you're building code with LLMs. That means using Python for back end logic, whenever it's appropriate, SQL databases for data storage & manipulation, and web UIs for front end interfaces whenever it's appropriate. You don't need use Flask, it's just what I've found LLMs work best with in all my tests and practical work. But if you're not using Python, consider looking into it more deeply. The Python ecosystem has over 500,000 packages available via the official package index, and the application development industry generally provides *Python support first* for an overwhelming percentage of new useful REST APIs and native platform SDKs. Python is the most used and most supported language in the industry, and LLMs can make instant use of any tool deployed with a Python interface. Web UI frameworks (everything based on traditional static HTML, CSS, JS, which can be integrated into Flask templates, plus all the reactive frameworks) are the defaults for user interface. Flask supports all those tooling choices natively, but that's not it. Flask's traditional server based routing, with multi-page server side rendering is just so easy to work with. The entire system is based on a simple REST API architecture which is easy to reason about, and which makes it so natural to integrate with 3rd party systems. Connecting/integrating separate apps written in Flask is just more child's play for any frontier LLM. And the need for that sort of connectivity is ever-present in the kinds of software that get built to support business operations. One of the biggest constant requirements in business software is the ability to connect with existing systems, data sources, APIs, etc. For all those reasons, and many others, Flask just works for the sort of development I do with LLMs. It's a ridiculously versatile, simple, deeply supported, extendable framework, and the application code tends to be tiny - even the biggest projects can be entirely contained in zip files of no more than a few hundred kilobytes. Flask apps can be installed in a few minutes in almost any environment, from cheap VPSs, to in-house servers managed by IT teams, to a home computer, to even a phone (I use Termux constantly on my Android devices). Python support exists absolutely everywhere, on virtually every platform in common use, and if it doesn't exist by default, it's typically a super quick install that takes less than a minute. You can build on one platform infrastructure, and deploy to another. It's lightweight and it *works* for so many purposes. It doesn't just work well, it absolutely rocks at completing a tremendous percentage of the sorts of tasks which make businesses run. The foundations used to manage security practices in Flask are fully understood, simple to implement, and they enable solution patterns that are well established. I've never experienced a situation where the Python ecosystem wasn't accepted, even in the most rigorous IT environments, working on government projects, and even in environments where the entire organization strictly enforced Microsoft-only tooling. Python integrates perfectly, everywhere. I regularly watch entire ecosystems of developers struggle to create applications with LLMs. I see simple apps developed in Next.js and React, for example, which end up being several hundred times bigger and more complicated than the Flask conversions I make of those apps. Those sorts of experiences are testaments to how internally complicated those other tools are, in comparison to Flask/Python. So the technical simplicity of tooling still matters tremendously when it comes to building applications with LLMs, but most important, when coding with LLMs, the volume of material in a model's training corpora really makes the greatest difference, along with the size and breadth of capability inherent in a chosen language's ecosystem. That's why Python basically wins as the language of choice for most of the coding I do with LLMs, and Web UIs win for most front end work, and SQL/SQLAlchemy wins for persistence & structured data. There's more than a half century of performance optimization inherent in SQL and relational database systems. And to accomplish virtually any high-level goal, the Python ecosystem wins for breadth of existing libraries. You're not cutting your grass with a razor blade when you use Python. And what matters so much to LLMs that are built from existing patterns in data, is that Python, SQL, and web UIs are surrounded by absolutely massive ecosystems, with many billions of lines of available code and billions of pages of documentation for LLMs to train on. > Of course Python and Flask are just my own preferences, which have proven themselves effective for the sorts of work I do If I was doing commercial 3D game development, I'd be working with an entirely different set of development tools: Unity, Unreal, Godot, etc. If I were building shiny marketing web sites, I'd probably end up using some visual layout frameworks centered around React, Vue, and other web development ecosystems that are most richly endowed with tooling for that sort of work. The LLMs know how to use all those tools well, even if they are a mess for humans to use. > Golang The only ecosystem I'd personally like to do more work with is Go, for applications that need low-level performance optimization. When it comes to coding with LLMs, for user applications, Go seems to best positioned for compiled language optimization. I'll likely write a long post at some point about why Go will be my choice for LLM development work that requires performance optimization, but for many of the same reasons, it's just perfectly suited for LLMs to be able to work with. It's a language and an ecosystem that suit how LLMs work. Plus, the web frameworks available in Go are likely the best target to convert directly from Flask, compared to Rust, Zig, and other interesting performance oriented languages. If I were building web applications that needed to scale to millions of concurrent users, a switch to Go would be a no-brainer. But that sort of work is not my current market. I currently write mostly internal tools used at hospitals, government organizations, and in various medical service fields. The software I currently write is critical for business operations, and they often do need to be optimized for performance on a small scale, but the applications I deliver are generally not intended to handle huge web scale traffic. I can write a real-time messaging system in Flask which performs fast enough for a team of physical therapists and clinicians in a mid-sized company, to communicate instantly all day every day, no problem. But if I were building a web based real-time messaging systems for millions of concurrent users, I'd switch away from Flask, and would choose Go for that job. Go's structure and ecosystem provide the best mix of usability and scalability, for LLMs to pop out working code that performs dozens of times faster on the same hardware resources. At this point, for me, making a move to Go would basically be about spending a few weeks/months really getting to know the Go ecosystem. I'd want to be intimately familiar with all the most common libraries, all the basics of the language, its compiler tools, test tools, etc. I might even still choose to prototype in Flask, and then convert to Go... And sure, if you want to develop with Rust, C, or any other popular ecosystem, I expect that all the frontier AI models are likely very capable at writing code in those languages too. You just need to be deeply familiar with each ecosystem, and established software development practices in those ecosystems, to work with them well.