I got the following question, on another forum about software development:

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 convenient to write apps from scratch ?

Here's my response

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 choses 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 need I've run into, even for projects that you might not expect it to handle so well, such as real-time apps.

For me, it's also very important not to limit the platforms, environments, and institutions where I can install the applications I build. I need 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 Pythong. You'll often see the same LLMs struggle to successfully complete even basic functionalities with lesser known tools, even after repeated bug-fix iterations.

So I use Flask and Python.

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.

Then I got this follow-up question:

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

Here's my response

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.

I got the following question, on another forum about software development:

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 convenient to write apps from scratch ?

Here's my response

I've written a lot about that over the past few years. There's 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 choses 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 need I've run into, even for projects that you might not expect it to handle so well, such as real-time apps.

For me, it's also very important not to limit the platforms, environments, and institutions where I can install the applications I build. I need 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 Pythong. You'll often see the same LLMs struggle to successfully complete even basic functionalities with lesser known tools, even after repeated bug-fix iterations.

So I use Flask and Python.

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.

Then I got this follow-up question

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

Here's my response

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.

I got the following question, on another forum about software development:

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 convenient to write apps from scratch ?

Here's my response

I've written a lot about that over the past few years. There's 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 typically better to have GPT convert them to Flask. The conversion of an entire mid-sized Anvil application to Flask, can typically be performed faster by GPT, than I can manually implement mid-sized full-stack updates to an Anvil app (changes which involve round-trip alterations that include UI layout, calls to back-end logic, and coordinated database schema/query updates). Once the conversion to Flask is complete, making the same sorts of full-stack updates, are typically a few minute process with GPT.

Of course it depends on the model, but most LLMs generally 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):

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 complete lists of requirements which used to take a week of work, in a few minutes. And the LLM is involved in every phase of research, communication with clients and IT staff, server configuration, etc. No framework does that work for you.

The key is to use development tools that the LLMs know how to work with best, and which don't hold you back when developing any of the class of projects you work on. Python has satisfied every need I've run into, for the sort of software I write, even in demanding real-time apps. It's accepted in every environment, and the big LLMs can typically complete virtually every requirement I run into, first shot, in a few minutes.

Developers who don't use Python say that Python is too slow, but the heavy lifting in most data management apps happens in a database. Python developers write queries in a Python language ORM, but the heavy computations happen inside an optimized SQL engine that benefits 50 years of deep, hard core, real-world RDBMS engineering. Flask delivers HTML pages that are composed by Python loops, but they're actually rendered in a browser engine which is backed by several hundred million dollars of research and engineering, to improve performance, and which has been used and stress-tested by 6 billion people, over decades. Python is great for most business purposes.

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

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 the code. You don't even have to write the tests. You don't even need to do all the 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 many years of deep experience to build those sorts of applications, using any language/framework.

Those clients 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 along the way with how to approach engineering challenges, 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 for average computer users).

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 it 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 challenges. Any aspiring vibe coder should take a serious look at:

https://aibynick.com/thread/28#post-58

And then read all that post a second time, before diving into building any sort of project that's planned for use in any demanding production environment, to handle data/processes that are of any critical importance, or which involve any sensitive information.

But LLMs can help ease many of those challenges too, if you know how to engineer software, with all the traditional disciplines required to build applications manually.

Then I got this follow-up question

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

Here's my response

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.

The old saying is that using C to write applications is like using a razor blade to cut your grass. 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 an appropriate purpose and goal for each software development language, tool, and ecosystem. For the work I do, the goal isn't to sculp each blade of grass in my clients' lawns with individual microscopic precision. With that analogy in mind, my role is usually something more like having to build effective mowing machines to cut the 10,000 football fields each of my clients need to manage, as simply and efficiently as possible, so that their clients can run on those fields, and perform all the other activities which occur on those fields. And if you take the analogy 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 otherwise involved in dealing with PHI (personal health information), and they get fined if their data fields aren't perfectly managed according to strict laws. A razor blade isn't the right tool for cutting that grass.

Even though characteristics such as verbosity and productivity have become the least important factors in language choice, 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.).

I spent a solid year profiling and comparing every development tool I'd ever used, and Flask/Python was 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.

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:

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, SQLite should generally be used for every database task that isn'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 - any tasks that would be accomplished with special features of other RDBMSs can be offloaded to Python or whatever language tools you're using. Upgrading your database to handle web scale, from dev to prod for example, should typically mean 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. 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 those basic tools, 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 logic, data processing and back end work, whenever it's appropriate, and web UI for front end interfaces whenever it's appropriate.

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 that 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, and deploy on 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 complicated those other tools are, in comparison to Flask/Python.

So technical simplicity still matters tremendously when it comes to building applications, even 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 needs. There's 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.

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.

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 is best positioned for compiled language optimization.

I'll likely write a long post 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 suite how LLMs work. 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 need to 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 hundreds to thousands of times faster.

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.

I got the following question, on another forum about software development:

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 convenient to write apps from scratch ?

Here's my response

I've written a lot about that over the past few years. There's a summary here:

https://aibynick.com/thread/12

TL;DR: I do almost all my work in the Flask/Python ecosystem. I'm still supporting a long list of production Anvil applications, but when those projects need serious updates, it's typically better to have GPT convert them to Flask. LLMs work really well with Flask projects - with GPT I use a workflow that involves feeding the entire project as a single zip file:

https://aibynick.com/thread/3

Otherwise, I use Pi with Deepseek to write Python/Flask code.

Anvil was a fantastic environment, but no framework can improve productivity in any way that compares to using modern LLMs and coding agents. I complete lists of requirements which used to take a week of work, in a few minutes. And the LLM is involved in every phase of research, communication with clients and IT staff, server config, etc. No framework does that work for you.

The key is to use development tools that the LLMs know how to use best, and which don't hold you back at all when developing the class of projects your work on. Python has satisfied every need I've run into, for the sort of software I write, even in demanding real-time apps. It's accepted in every environment, and the big LLMs can complete virtually every requirement with it, first shot, in a few minutes.

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

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 write the code. You don't even have to write the tests. You don't even need to do all the 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 all the details about what was completed in your invoices. You don't even need to write the user documentation...

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 many years of deep experience to build those sorts of applications, using any language, framework, etc. Those clients pass their creations along to me, I perform code reviews and tests, add auth, logging, and other features needed for compliance, perform installs, help along the way with how to approach engineering challenges, etc. In more than 30 years prior, I was only ever able to do that 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 meant for average computer users).

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 apps on top of Baserow databases (some of the biggest projects I've continued to work on in the last year still use it extensively) - but there's hardly even a real need for that any more. 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 have taken days to build schema in Baserow, and I'll have the entire 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 challenges. Any aspiring vibe coder should take a serious look at:

https://aibynick.com/thread/28#post-58

And then read all that a second time.

But LLMs can help ease many of those challenges too.

Then I got this follow-up question

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

Here's my response

C isn't the best choice for any of the applications I build. I don't work on a team whose only 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 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 which helps business operations run efficiently.

The old saying is that using C to write applications is like using a razor blade to cut your grass. 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.

For the work I do, the goal isn't to sculp each blade of grass in my clients' lawns. It's to build machines that mow my client's 10,000 football sized fields as effectively as possible. There's an appropriate purpose and goal for each software development language, tool, and ecosystem.

Even though characteristics such as verbosity and productivity have become the least important factors in language choice, 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 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 some 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.).

I spent a solid year profiling and comparing every development tool I'd ever used, and Flask/Python was 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 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 meant to ease human labor.

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.

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. 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:

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, SQLite should generally be used for every database task that isn'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 - any tasks that would be accomplished with special features of other RDBMSs can be offloaded to Python or whatever language tools you're using. Upgrading your database to handle web scale, from dev to prod for example, should typically mean 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. 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 those basic tools, 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 logic, data processing and back end work, whenever it's appropriate, and web UI for front end interfaces whenever it's appropriate.

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 that 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, and deploy on 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 complicated those other tools are, in comparison to Flask/Python.

So technical simplicity still matters tremendously when it comes to building applications, even 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 needs. There's 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.

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.

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 is best positioned for compiled language optimization.

I'll likely write a long post 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 suite how LLMs work. 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 need to 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 hundreds to thousands of times faster.

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.

I got the following question, on another forum about software development:

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 convenient to write apps from scratch ?

Here's my response

I've written a lot about that over the past few years. There's a summary here:

https://aibynick.com/thread/12

TL;DR: I do almost all my work in the Flask/Python ecosystem. I'm still supporting a long list of production Anvil applications, but when those projects need serious updates, it's typically better to have GPT convert them to Flask. LLMs work really well with Flask projects - with GPT I use a workflow that involves feeding the entire project as a single zip file:

https://aibynick.com/thread/3

Otherwise, I use Pi with Deepseek to write Python/Flask code.

Anvil was a fantastic environment, but no framework can improve productivity in any way that compares to using modern LLMs and coding agents. I complete lists of requirements which used to take a week of work, in a few minutes. And the LLM is involved in every phase of research, communication with clients and IT staff, server config, etc. No framework does that work for you.

The key is to use development tools that the LLMs know how to use best, and which don't hold you back at all when developing the class of projects your work on. Python has satisfied every need I've run into, for the sort of software I write, even in demanding real-time apps. It's accepted in every environment, and the big LLMs can complete virtually every requirement with it, first shot, in a few minutes.

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

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 write the code. You don't even have to write the tests. You don't even need to do all the research about which libraries and tools in an ecosystem are best for your needs. You don't even need to write all the emails to your clients. You don't even need to write all the details about what was completed in your invoices. You don't even need to write the user documentation...

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 beat them all by 100s of times, in terms of productivity.

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 many years of deep experience to build those sorts of applications, using any language, framework, etc. Those clients pass their creations along to me, I perform code reviews and tests, add auth, logging, and other features needed for compliance, perform installs, help along the way with how to approach engineering challenges, etc. I was only ever able to do that 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 meant for average computer users).

Baserow came the closest to being a serious development tool for non-technical users. 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 apps on top of Baserow databases (some of the biggest projects I've continued to work on in the last year still use it) - but there's hardly even a real need for that any more. 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 have taken days to build schema in Baserow, and I'll have the entire 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 challenges. Any aspiring 'vibe coder' should take a serious look at:

https://aibynick.com/thread/28#post-58

And then read all that a second time.

But LLMs can help ease many of those challenges too.

Then I got this follow-up question

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

Here's my response

C isn't the best choice for any of the applications I build. I don't work on a team whose only goal is to optimize a portion of an operating system, or a browser, over decades, to use every CPU cycle and byte of RAM as efficiently as possible. C's purpose is 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 which helps business operations run efficiently.

The old saying is that using C to write applications is like using a razor blade to cut your grass. 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. For the work I do, the goal isn't to sculp each blade of grass in my clients' lawns. It's to build machines that mow my client's 10,000 football sized fields as effectively as possible. There's an appropriate purpose and goal for each software development language, tool, and ecosystem.

Even though characteristics such as verbosity and productivity have become the least important factors in language choice, 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 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 some 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.).

I spent a solid year profiling and comparing every development tool I'd ever used, and Flask/Python was 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 visual UI and DB builders 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 meant to ease human labor.

There's also a ton more code and documentation available online about Flask, than Anvil for example, and Flask is a simple and composable system which LLMs seem to be able to reason about well. The server based Jinja templating system is versatile enough to incorporate any sort of HTML/CSS/JS UI tools - LLMs are also fantastic at writing that sort of code. 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.

And the same is true of SQL and SQLAlchemy, which are first class citizens in Flask. Working with traditional RDBMSs is another lingua franca of LLMs. Prepare your requirements properly, and the 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, SQLite should generally be used for every database task that isn'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 - any tasks that would be accomplished with special features of other RDBMSs can be offloaded to Python or whatever language tools you're using. Upgrading your database to handle web scale, from dev to prod for example, should typically mean 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. Do the math before hand, to know for sure where the limits are for the entire expected lifecycle of your application, but most 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.

Beyond all those basic tools, 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 logic, data processing and back end work, whenever it's appropriate, and web UI for front end interfaces whenever it's appropriate.

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 APIs and SDKs. Python is the most used and most supported language in that 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, 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, and deploy on 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 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 complicated those other tools are, in comparison with Flask/Python.

So technical simplicity still matters tremendously when it comes to building applications, even 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 needs. There's 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.

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.

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 is best positioned for compiled language optimization.

I'll likely write a long post 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 suite how LLMs work. 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 need to 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 hundreds to thousands of times faster.

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.

I got the following question, on another forum about software development:

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 convenient to write apps from scratch ?

Here's my response

I've written a lot about that over the past few years. There's a summary here:

https://aibynick.com/thread/12

TL;DR: I do almost all my work in the Flask/Python ecosystem. I'm still supporting a long list of production Anvil applications, but when those projects need serious updates, it's typically better to have GPT convert them to Flask. LLMs work really well with Flask projects - with GPT I use a workflow that involves feeding the entire project as a single zip file:

https://aibynick.com/thread/3

Otherwise, I use Pi with Deepseek to write Python/Flask code.

Anvil was a fantastic environment, but no framework can improve productivity in any way that compares to using modern LLMs and coding agents. I complete lists of requirements which used to take a week of work, in a few minutes. And the LLM is involved in every phase of research, communication with clients and IT staff, server config, etc. No framework does that work for you.

The key is to use development tools that the LLMs know how to use best, and which don't hold you back at all when developing the class of projects your work on. Python has satisfied every need I've run into, for the sort of software I write, even in demanding real-time apps. It's accepted in every environment, and the big LLMs can complete virtually every requirement with it, first shot, in a few minutes.

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

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 write the code. You don't even have to write the tests. You don't even need to do all the research about which libraries and tools in an ecosystem are best for your needs. You don't even need to write all the emails to your clients. You don't even need to write all the details about what was completed in your invoices. You don't even need to write the user documentation...

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 beat them all by 100s of times, in terms of productivity.

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 many years of deep experience to build those sorts of applications, using any language, framework, etc. Those clients pass their creations along to me, I perform code reviews and tests, add auth, logging, and other features needed for compliance, perform installs, help along the way with how to approach engineering challenges, etc. I was only ever able to do that 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 meant for average computer users).

Baserow came the closest to being a serious development tool for non-technical users. 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 apps on top of Baserow databases (some of the biggest projects I've continued to work on in the last year still use it) - but there's hardly even a real need for that any more. 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 have taken days to build schema in Baserow, and I'll have the entire 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 challenges. Any aspiring 'vibe coder' should take a serious look at:

https://aibynick.com/thread/28#post-58

And then read all that a second time.

But LLMs can help ease many of those challenges too.

Then I got this follow-up question

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

Here's my response

C isn't the best choice for any of the applications I build. I don't work in a team whose only goal is to optimize a portion of an operating system, or a browser, over decades, to use every CPU cycle and byte of RAM as efficiently as possible. C's purpose is to write the system software which runs the heartbeat of hardware components, network transfers, and other operating system and infrastructure level machinery. I write end-user software which helps business operations run efficiently.

The old saying is that using C to write applications is like using a razor blade to cut your grass. 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. For the work I do, the goal isn't to sculp each blade of grass in my clients' lawns. It's to build machines that mow my client's 10,000 football sized fields as effectively as possible. There's an appropriate purpose and goal for each software development language, tool, and ecosystem.

Even though characteristics such as verbosity and productivity have become the least important factors in language choice, 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 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 some 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.).

I spent a solid year profiling and comparing every development tool I'd ever used, and Flask/Python was 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, because Anvil uses visual UI and DB builders. 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 meant to ease human labor.

There's also a ton more code and documentation available online about Flask, than Anvil for example, and Flask is a simple and composable system which LLMs seem to be able to reason about well. The server based Jinja templating system is versatile enough to incorporate any sort of HTML/CSS/JS UI tools - LLMs are also fantastic at writing that sort of code. 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.

And the same is true of SQL and SQLAlchemy, which are first class citizens in Flask. Working with traditional RDBMSs is another lingua franca of LLMs. Prepare your requirements properly, and the 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, SQLite should generally be used for every database task that isn'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 - any tasks that would be accomplished with special features of other RDBMSs can be offloaded to Python or whatever language tools you're using. Upgrading your database to handle web scale, from dev to prod for example, should typically mean 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. Do the math before hand, to know for sure where the limits are for the entire expected lifecycle of your application, but most 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.

Beyond all those basic tools, 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 logic, data processing and back end work, whenever it's appropriate, and web UI for front end interfaces whenever it's appropriate.

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 APIs and SDKs. Python is the most used and most supported language in that 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, 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, and deploy on 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 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 complicated those other tools are, in comparison with Flask/Python.

So technical simplicity still matters tremendously when it comes to building applications, even 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 needs. There's 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.

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.

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 is best positioned for compiled language optimization.

I'll likely write a long post 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 suite how LLMs work. 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 need to 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 hundreds to thousands of times faster.

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.

I got the following question, on another forum about software development:

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 convenient to write apps from scratch ?

Here's my response

I've written a lot about that over the past few years. There's a summary here:

https://aibynick.com/thread/12

TL;DR: I do almost all my work in the Flask/Python ecosystem. I'm still supporting a long list of production Anvil applications, but when those projects need serious updates, it's typically better to have GPT convert them to Flask. LLMs work really well with Flask projects - with GPT I use a workflow that involves feeding the entire project as a single zip file:

https://aibynick.com/thread/3

Otherwise, I use Pi with Deepseek to write Python/Flask code.

Anvil was a fantastic environment, but no framework can improve productivity in any way that compares to using modern LLMs and coding agents. I complete lists of requirements which used to take a week of work, in a few minutes. And the LLM is involved in every phase of research, communication with clients and IT staff, server config, etc. No framework does that work for you.

The key is to use development tools that the LLMs know how to use best, and which don't hold you back at all when developing the class of projects your work on. Python has satisfied every need I've run into, for the sort of software I write, even in demanding real-time apps. It's accepted in every environment, and the big LLMs can complete virtually every requirement with it, first shot, in a few minutes.

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

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 write the code. You don't even have to write the tests. You don't even need to do all the research about which libraries and tools in an ecosystem are best for your needs. You don't even need to write all the emails to your clients. You don't even need to write all the details about what was completed in your invoices. You don't even need to write the user documentation...

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 beat them all by 100s of times, in terms of productivity.

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 many years of deep experience to build those sorts of applications, using any language, framework, etc. Those clients pass their creations along to me, I perform code reviews and tests, add auth, logging, and other features needed for compliance, perform installs, help along the way with how to approach engineering challenges, etc. I was only ever able to do that 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 meant for average computer users).

Baserow came the closest to being a serious development tool for non-technical users. 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 apps on top of Baserow databases (some of the biggest projects I've continued to work on in the last year still use it) - but there's hardly even a real need for that any more. 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 have taken days to build schema in Baserow, and I'll have the entire 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 challenges. Any aspiring 'vibe coder' should take a serious look at:

https://aibynick.com/thread/28#post-58

And then read all that a second time.

But LLMs can help ease many of those challenges too.

Then I got this follow-up question

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

Here's my response

C isn't the best choice for any of the applications I build. I don't work in a team whose only goal is to optimize a portion of an operating system, or a browser, over decades, to use every CPU cycle and byte of RAM as efficiently as possible. C's purpose is to write the system software which runs the heartbeat of hardware components, network transfers, and other operating system and infrastructure level machinery. I write end-user software which helps business operations run efficiently.

The old saying is that using C to write applications is like using a razor blade to cut your grass. 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. For the work I do, the goal isn't to sculp each blade of grass in my clients' lawns. It's to build machines that mow my client's 10,000 fields as effectively as possible. There's an appropriate purpose and goal for each software development language, tool, and ecosystem.

Even though characteristics such as verbosity and productivity have become the least important factors in language choice, 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 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 some 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.).

I spent a solid year profiling and comparing every development tool I'd ever used, and Flask/Python was 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, because Anvil uses visual UI and DB builders. 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 meant to ease human labor.

There's also a ton more code and documentation available online about Flask, than Anvil for example, and Flask is a simple and composable system which LLMs seem to be able to reason about well. The server based Jinja templating system is versatile enough to incorporate any sort of HTML/CSS/JS UI tools - LLMs are also fantastic at writing that sort of code. 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.

And the same is true of SQL and SQLAlchemy, which are first class citizens in Flask. Working with traditional RDBMSs is another lingua franca of LLMs. Prepare your requirements properly, and the 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.

And LLMs can work with the Python language and 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 ecosystems which the LLM creators have prioritized in training data, is the right choice, if you're building code with LLMs.

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 APIs and SDKs. Python is the most used and most supported language in that industry, and LLMs can make instant use of any tool deployed with a Python interface.

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, and deploy on 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 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 complicated those other tools are, in comparison with Flask/Python.

So technical simplicity still matters tremendously when it comes to building applications, even 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 needs. There's 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.

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.

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 is best positioned for compiled language optimization.

I'll likely write a long post 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 suite how LLMs work. 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 need to 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 hundreds to thousands of times faster.

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.

I got the following question, on another forum about software development:

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 convenient to write apps from scratch ?

Here's my response

I've written a lot about that over the past few years. There's a summary here:

https://aibynick.com/thread/12

TL;DR: I do almost all my work in the Flask/Python ecosystem. I'm still supporting a long list of production Anvil applications, but when those projects need serious updates, it's typically better to have GPT convert them to Flask. LLMs work really well with Flask projects - with GPT I use a workflow that involves feeding the entire project as a single zip file:

https://aibynick.com/thread/3

Otherwise, I use Pi with Deepseek to write Python/Flask code.

Anvil was a fantastic environment, but no framework can improve productivity in any way that compares to using modern LLMs and coding agents. I complete lists of requirements which used to take a week of work, in a few minutes. And the LLM is involved in every phase of research, communication with clients and IT staff, server config, etc. No framework does that work for you.

The key is to use development tools that the LLMs know how to use best, and which don't hold you back at all when developing the class of projects your work on. Python has satisfied every need I've run into, for the sort of software I write, even in demanding real-time apps. It's accepted in every environment, and the big LLMs can complete virtually every requirement with it, first shot, in a few minutes.

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

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 write the code. You don't even have to write the tests. You don't even need to do all the research about which libraries and tools in an ecosystem are best for your needs. You don't even need to write all the emails to your clients. You don't even need to write all the details about what was completed in your invoices. You don't even need to write the user documentation...

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 beat them all by 100s of times, in terms of productivity.

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 many years of deep experience to build those sorts of applications, using any language, framework, etc. Those clients pass their creations along to me, I perform code reviews and tests, add auth, logging, and other features needed for compliance, perform installs, help along the way with how to approach engineering challenges, etc. I was only ever able to do that 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 meant for average computer users).

Baserow came the closest to being a serious development tool for non-technical users. 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 apps on top of Baserow databases (some of the biggest projects I've continued to work on in the last year still use it) - but there's hardly even a real need for that any more. 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 have taken days to build schema in Baserow, and I'll have the entire 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 challenges. Any aspiring 'vibe coder' should take a serious look at:

https://aibynick.com/thread/28#post-58

And then read all that a second time.

But LLMs can help ease many of those challenges too.

Then I got this follow-up question

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

Here's my response

C isn't the best choice for any of the applications I build. I don't work in a team whose only goal is to optimize a portion of an operating system, or a browser, over decades, to use every CPU cycle and byte of RAM as efficiently as possible. C's purpose is to write the system software which runs the heartbeat of hardware components, network transfers, and other operating system and infrastructure level machinery. I write end-user software which helps business operations run efficiently.

The old saying is that using C to write applications is like using a razor blade to cut your grass. 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 and other metal componentry inside a PC. For the work I do, the goal isn't to sculp each blade of grass in my clients' lawns. It's to help clients mow their massive fields as effectively as possible. There's an appropriate purpose and goal for each software development language, tool, and ecosystem.

Even though characteristics such as verbosity and productivity have become the least important factors in language choice, 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 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 some 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.).

I spent a solid year profiling and comparing every development tool I'd ever used, and Flask/Python was 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, because Anvil uses visual UI and DB builders. 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 meant to ease human labor.

There's also a ton more code and documentation available online about Flask, than Anvil for example, and Flask is a simple and composable system which LLMs seem to be able to reason about well. The server based Jinja templating system is versatile enough to incorporate any sort of HTML/CSS/JS UI tools - LLMs are also fantastic at writing that sort of code. 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.

And the same is true of SQL and SQLAlchemy, which are first class citizens in Flask. Working with traditional RDBMSs is another lingua franca of LLMs. Prepare your requirements properly, and the 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.

And LLMs can work with the Python language and 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 ecosystems which the LLM creators have prioritized in training data, is the right choice, if you're building code with LLMs.

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 APIs and SDKs. Python is the most used and most supported language in that industry, and LLMs can make instant use of any tool deployed with a Python interface.

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, and deploy on 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 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 complicated those other tools are, in comparison with Flask/Python.

So technical simplicity still matters tremendously when it comes to building applications, even 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 needs. There's 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.

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.

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 is best positioned for compiled language optimization.

I'll likely write a long post 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 suite how LLMs work. 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 need to 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 hundreds to thousands of times faster.

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.

I got the following question:

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 convenient to write apps from scratch ?

Here's my response

I've written a lot about that over the past few years. There's a summary here:

https://aibynick.com/thread/12

TL;DR: I do almost all my work in the Flask/Python ecosystem. I'm still supporting a long list of production Anvil applications, but when those projects need serious updates, it's typically better to have GPT convert them to Flask. LLMs work really well with Flask projects - with GPT I use a workflow that involves feeding the entire project as a single zip file:

https://aibynick.com/thread/3

Otherwise, I use Pi with Deepseek.

Anvil was a fantastic environment, but no framework can improve productivity in any way that compares to using modern LLMs and coding agents. I complete lists of requirements which used to take a week of work, in a few minutes. And the LLM is involved in every phase of research, communication with clients and IT staff, server config, etc. No framework does that work for you.

The key is to use development tools that the LLMs know how to use best, and which don't hold you back at all when developing any sort of project. Python has satisfied every need I've run into, even in demanding real-time apps. It's accepted in every environment, and the big LLMs can complete virtually every requirement with it, first shot, in a few minutes.

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 the post that starts with the words:

'Here's a quick run-thru of how to upload project zip files for flask apps which you've created on a local machine, to a Linux VPS'

at:

https://aibynick.com/thread/29

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 write the code. You don't even have to write the tests. You don't even need to do all the research about which libraries and tools in an ecosystem are best for your needs. You don't even need to write all the emails to your clients. You don't even need to write all the details about what was completed in your invoices. You don't even need to write the user documentation...

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 beat them all by 100s of times, in terms of productivity.

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 many years of deep experience to build those sorts of applications, using any language, framework, etc. Those clients pass their creations along to me, I perform code reviews and tests, add auth, logging, and other features needed for compliance, perform installs, help along the way with how to approach engineering challenges, etc. I was only ever able to do that 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 meant for average computer users).

Baserow came the closest to being a serious development tool for non-technical users. 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 apps on top of Baserow databases (some of the biggest projects I've continued to work on in the last year still use it) - but there's hardly even a real need for that any more. 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 have taken days to build schema in Baserow, and I'll have the entire 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 challenges. Any aspiring 'vibe coder' should take a serious look at:

https://aibynick.com/thread/28#post-58

And then read all that a second time.

But LLMs can help ease many of those challenges too.

Then I got this follow-up question

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

Here's my response

C isn't the best choice for any of the applications I build. I don't work in a team whose only goal is to optimize a portion of an operating system, or a browser, over decades, to use every CPU cycle and byte of RAM as efficiently as possible. C's purpose is to write the system software which runs the heartbeat of hardware components, network transfers, and other operating system and infrastructure level machinery. I write end-user software which helps business operations run efficiently.

The old saying is that using C to write applications is like using a razor blade to cut your grass. 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 and other metal componentry inside a PC. For the work I do, the goal isn't to sculp each blade of grass in my clients' lawns. It's to help clients mow their massive fields as effectively as possible. There's an appropriate purpose and goal for each software development language, tool, and ecosystem.

Even though characteristics such as verbosity and productivity have become the least important factors in language choice, 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 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 some 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.).

I spent a solid year profiling and comparing every development tool I'd ever used, and Flask/Python was 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, because Anvil uses visual UI and DB builders. 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 meant to ease human labor.

There's also a ton more code and documentation available online about Flask, than Anvil for example, and Flask is a simple and composable system which LLMs seem to be able to reason about well. The server based Jinja templating system is versatile enough to incorporate any sort of HTML/CSS/JS UI tools - LLMs are also fantastic at writing that sort of code. 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.

And the same is true of SQL and SQLAlchemy, which are first class citizens in Flask. Working with traditional RDBMSs is another lingua franca of LLMs. Prepare your requirements properly, and the 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.

And LLMs can work with the Python language and 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 ecosystems which the LLM creators have prioritized in training data, is the right choice, if you're building code with LLMs.

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 APIs and SDKs. Python is the most used and most supported language in that industry, and LLMs can make instant use of any tool deployed with a Python interface.

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, and deploy on 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 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 complicated those other tools are, in comparison with Flask/Python.

So technical simplicity still matters tremendously when it comes to building applications, even 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 needs. There's 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.

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.

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 is best positioned for compiled language optimization.

I'll likely write a long post 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 suite how LLMs work. 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 need to 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 hundreds to thousands of times faster.

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.

I got the following question:

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 convenient to write apps from scratch ?

Here's my response

I've written a lot about that over the past few years. There's a summary here:

https://aibynick.com/thread/12

TL;DR: I do almost all my work in the Flask/Python ecosystem. I'm still supporting a long list of production Anvil applications, but when those projects need serious updates, it's typically better to have GPT convert them to Flask. LLMs work really well with Flask projects - with GPT I use a workflow that involves feeding the entire project as a single zip file:

https://aibynick.com/thread/3

Otherwise, I use Pi with Deepseek.

Anvil was a fantastic environment, but no framework can improve productivity in any way that compares to using modern LLMs and coding agents. I complete lists of requirements which used to take a week of work, in a few minutes. And the LLM is involved in every phase of research, communication with clients and IT staff, server config, etc. No framework does that work for you.

The key is to use development tools that the LLMs know how to use best, and which don't hold you back at all when developing any sort of project. Python has satisfied every need I've run into, even in demanding real-time apps. It's accepted in every environment, and the big LLMs can complete virtually every requirement with it, first shot, in a few minutes.

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 the post that starts with the words:

'Here's a quick run-thru of how to upload project zip files for flask apps which you've created on a local machine, to a Linux VPS'

at:

https://aibynick.com/thread/29

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 write the code. You don't even have to write the tests. You don't even need to do all the research about which libraries and tools in an ecosystem are best for your needs. You don't even need to write all the emails to your clients. You don't even need to write all the details about what was completed in your invoices. You don't even need to write the user documentation...

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 beat them all by 100s of times, in terms of productivity.

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 many years of deep experience to build those sorts of applications, using any language, framework, etc. Those clients pass their creations along to me, I perform code reviews and tests, add auth, logging, and other features needed for compliance, perform installs, help along the way with how to approach engineering challenges, etc. I was only ever able to do that 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 meant for average computer users).

Baserow came the closest to being a serious development tool for non-technical users. 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 apps on top of Baserow databases (some of the biggest projects I've continued to work on in the last year still use it) - but there's hardly even a real need for that any more. 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 have taken days to build schema in Baserow, and I'll have the entire 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 challenges. Take a look at:

https://aibynick.com/thread/28#post-58

But LLMs can help ease many of those challenges too.

Then I got this follow-up question

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

Here's my response

C isn't the best choice for any of the applications I build. I don't work in a team whose only goal is to optimize a portion of an operating system, or a browser, over decades, to use every CPU cycle and byte of RAM as efficiently as possible. C's purpose is to write the system software which runs the heartbeat of hardware components, network transfers, and other operating system and infrastructure level machinery. I write end-user software which helps business operations run efficiently.

The old saying is that using C to write applications is like using a razor blade to cut your grass. 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 and other metal componentry inside a PC. For the work I do, the goal isn't to sculp each blade of grass in my clients' lawns. It's to help clients mow their massive fields as effectively as possible. There's an appropriate purpose and goal for each software development language, tool, and ecosystem.

Even though characteristics such as verbosity and productivity have become the least important factors in language choice, 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 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 some 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.).

I spent a solid year profiling and comparing every development tool I'd ever used, and Flask/Python was 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, because Anvil uses visual UI and DB builders. 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 meant to ease human labor.

There's also a ton more code and documentation available online about Flask, than Anvil for example, and Flask is a simple and composable system which LLMs seem to be able to reason about well. The server based Jinja templating system is versatile enough to incorporate any sort of HTML/CSS/JS UI tools - LLMs are also fantastic at writing that sort of code. 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.

And the same is true of SQL and SQLAlchemy, which are first class citizens in Flask. Working with traditional RDBMSs is another lingua franca of LLMs. Prepare your requirements properly, and the 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.

And LLMs can work with the Python language and 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 ecosystems which the LLM creators have prioritized in training data, is the right choice, if you're building code with LLMs.

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 APIs and SDKs. Python is the most used and most supported language in that industry, and LLMs can make instant use of any tool deployed with a Python interface.

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, and deploy on 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 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 complicated those other tools are, in comparison with Flask/Python.

So technical simplicity still matters tremendously when it comes to building applications, even 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 needs. There's a half century of performance optimization inherent in SQL and relational database systems. And a 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.

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.

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 is best positioned for compiled language optimization.

I'll likely write a long post 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 suite how LLMs work. 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 need to 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 hundreds to thousands of times faster.

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.

I got the following question:

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 convenient to write apps from scratch ?

Here's my response

I've written a lot about that over the past few years. There's a summary here:

https://aibynick.com/thread/12

TL;DR: I do almost all my work in the Flask/Python ecosystem. I'm still supporting a long list of production Anvil applications, but when those projects need serious updates, it's typically better to have GPT convert them to Flask. LLMs work really well with Flask projects - with GPT I use a workflow that involves feeding the entire project as a single zip file:

https://aibynick.com/thread/3

Otherwise, I use Pi with Deepseek.

Anvil was a fantastic environment, but no framework can improve productivity in any way that compares to using modern LLMs and coding agents. I complete lists of requirements which used to take a week of work, in a few minutes. And the LLM is involved in every phase of research, communication with clients and IT staff, server config, etc. No framework does that work for you.

The key is to use development tools that the LLMs know how to use best, and which don't hold you back at all when developing any sort of project. Python has satisfied every need I've run into, even in demanding real-time apps. It's accepted in every environment, and the big LLMs can complete virtually every requirement with it, first shot, in a few minutes.

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 the post that starts with the words:

'Here's a quick run-thru of how to upload project zip files for flask apps which you've created on a local machine, to a Linux VPS'

at:

https://aibynick.com/thread/29

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 write the code. You don't even have to write the tests. You don't even need to do all the research about which libraries and tools in an ecosystem are best for your needs. You don't even need to write all the emails to your clients. You don't even need to write all the details about what was completed in your invoices. You don't even need to write the user documentation...

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 beat them all by 100s of times, in terms of productivity.

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 many years of deep experience to build those sorts of applications, using any language, framework, etc. Those clients pass their creations along to me, I perform code reviews and tests, add auth, logging, and other features needed for compliance, perform installs, help along the way with how to approach engineering challenges, etc. I was only ever able to do that 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 meant for average computer users).

Baserow came the closest to being a serious development tool for non-technical users. 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 apps on top of Baserow databases (some of the biggest projects I've continued to work on in the last year still use it) - but there's hardly even a real need for that any more. 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 have taken days to build schema in Baserow, and I'll have the entire 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 challenges. Take a look at:

https://aibynick.com/thread/28#post-58

But LLMs can help ease many of those challenges too.

Then I got this follow-up question

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

Here's my response

C isn't the best choice for any of the applications I build. I don't work in a team whose only goal is to optimize a portion of an operating system, or a browser, over decades, to use every CPU cycle and byte of RAM as efficiently as possible. C's purpose is to write the system software which runs the heartbeat of hardware components, network transfers, and other operating system and infrastructure level machinery. I write end-user software which helps business operations run efficiently.

The old saying is that using C to write applications is like using a razor blade to cut your grass. To build data management applications which enable business operations, you don't need the same precise control of the flow of bits, that you need to control the operations of metal inside a PC. You don't need to sculp each blade of grass - you need development tools which help you mow the whole lawn effectively. There's an appropriate purpose and goal for each software development language, tool, and ecosystem.

Even though characteristics such as verbosity and productivity have become the least important factors in language choice, 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 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 some 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.).

I spent a solid year profiling and comparing every development tool I'd ever used, and Flask/Python was 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, because Anvil uses visual UI and DB builders. 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 meant to ease human labor.

There's also a ton more code and documentation available online about Flask, than Anvil for example, and Flask is a simple and composable system which LLMs seem to be able to reason about well. The server based Jinja templating system is versatile enough to incorporate any sort of HTML/CSS/JS UI tools - LLMs are also fantastic at writing that sort of code. 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.

And the same is true of SQL and SQLAlchemy, which are first class citizens in Flask. Working with traditional RDBMSs is another lingua franca of LLMs. Prepare your requirements properly, and the LLM can build proper, 100% working schema, foreign keys, 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.

And LLMs can work with Python language and ecosystem just as easily as they can say hello to you. Industry has spent trillions of dollars improving that capability, and it's paid off. Using the ecosystems they've prioritized is the right choice, if you're building with LLMs. 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 APIs and 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.

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, and deploy on 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 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 complicated those other tools are, in comparison with Flask/Python.

So technical simplicity still matters tremendously when it comes to building applications, even 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 needs. There's a half century of performance optimization inherent in SQL and relational database systems. And a 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.

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.

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 is best positioned for compiled language optimization.

I'll likely write a long post 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 suite how LLMs work. 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 need to 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 hundreds to thousands of times faster.

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.

I got the following question:

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 convenient to write apps from scratch ?

Here's my response

I've written a lot about that over the past few years. There's a summary here:

https://aibynick.com/thread/12

TL;DR: I do almost all my work in the Flask/Python ecosystem. I'm still supporting a long list of production Anvil applications, but when those projects need serious updates, it's typically better to have GPT convert them to Flask. LLMs work really well with Flask projects - with GPT I use a workflow that involves feeding the entire project as a single zip file:

https://aibynick.com/thread/3

Otherwise, I use Pi with Deepseek.

Anvil was a fantastic environment, but no framework can improve productivity in any way that compares to using modern LLMs and coding agents. I complete lists of requirements which used to take a week of work, in a few minutes. And the LLM is involved in every phase of research, communication with clients and IT staff, server config, etc. No framework does that work for you.

The key is to use development tools that the LLMs know how to use best, and which don't hold you back at all when developing any sort of project. Python has satisfied every need I've run into, even in demanding real-time apps. It's accepted in every environment, and the big LLMs can complete virtually every requirement with it, first shot, in a few minutes.

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 the post that starts with the words:

'Here's a quick run-thru of how to upload project zip files for flask apps which you've created on a local machine, to a Linux VPS'

at:

https://aibynick.com/thread/29

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 write the code. You don't even have to write the tests. You don't even need to do all the research about which libraries and tools in an ecosystem are best for your needs. You don't even need to write all the emails to your clients. You don't even need to write all the details about what was completed in your invoices. You don't even need to write the user documentation...

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 beat them all by 100s of times, in terms of productivity.

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 many years of deep experience to build those sorts of applications, using any language, framework, etc. Those clients pass their creations along to me, I perform code reviews and tests, add auth, logging, and other features needed for compliance, perform installs, help along the way with how to approach engineering challenges, etc. I was only ever able to do that 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 meant for average computer users).

Baserow came the closest to being a serious development tool for non-technical users. 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 apps on top of Baserow databases (some of the biggest projects I've continued to work on in the last year still use it) - but there's hardly even a real need for that any more. 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 have taken days to build schema in Baserow, and I'll have the entire 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 challenges. Take a look at:

https://aibynick.com/thread/28#post-58

But LLMs can help ease many of those challenges too.

Then I got this follow-up question

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

Here's my response

C isn't the best choice for any of the applications I build.

Even though characteristics such as verbosity and productivity have become the least important factors in language choice, 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 accessible on any client device (Windows, Mac, Linux, Android, iOS, Chromebook, etc.), without lots of installation and 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 much easier to enforce than some 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.).

I spent a solid year profiling and comparing every development tool I'd ever used, and Flask/Python was 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, because Anvil uses visual UI and DB builders - 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 meant to ease human work.

There's also a ton more code and documentation available online about Flask, and Flask is a simple and composable system which LLMs seem to be able to reason about well. The server based Jinja templating system is versatile enough to incorporate any sort of HTML/CSS/JS UI tools - LLMs are also fantastic at writing that sort of code. 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.

And the same is true of SQL and SQLAlchemy, which are first class citizens in Flask. Working with traditional RDBMSs is another lingua franca of LLMs. Prepare your requirements properly, and the LLM can build proper, 100% working schema, foreign keys, and thousands of lines of queries, first shot every time, in minutes. And it can painlessly migrate schema and adjust complex query logic just as quickly.

And LLMs can work with Python language and ecosystem just as easily as they can say hello to you. The Python ecosystem has over 500,000 packages available via the official package index, and the industry generally provides Python support first for an overwhelming percentage of new useful APIs and 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.

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 very simple to integrate with 3rd party systems. Connecting/integrating separate apps written in Flask is more child's play for any frontier LLM.

For all those reasons, and many others, Flask just works for LLM development. 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. 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, and deploy on another. It's lightweight and it works.

The systems used to manage security practices in Flask are well understood, simple to implement, and 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 of 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 complicated those other tools are, in comparison with Flask/Python.

So technical simplicity still matters tremendously when it comes to building applications, even with LLMs, but most important, when coding with LLMs, the volume of material in a model's training corpora is 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 LLM coding, and Web UIs win for most front end work, and SQL/SQLAlchemy wins for databases needs. The Python ecosystem wins for breadth of existing libraries. 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.

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.

The only ecosystem I'd personally like to do more with is Go, for applications that need low-level performance optimization. When it comes to coding with LLMs, Go is best positioned for compiled language optimization.

I'll likely write a long post about why Go would be my choice for LLM development work, but for many of the same reasons, it's just perfectly suited for LLMs to be able to work with. 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's 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 are critical for business operations, and they often need to be deeply optimized for performance, but they're 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 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 need to 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 fast.

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, to work with them well.

I got the following question:

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 convenient to write apps from scratch ?

Here's my response

I've written a lot about that over the past few years. There's a summary here:

https://aibynick.com/thread/12

TL;DR: I do almost all my work in the Flask/Python ecosystem. I'm still supporting a long list of production Anvil applications, but when those projects need serious updates, it's typically better to have GPT convert them to Flask. LLMs work really well with Flask projects - with GPT I use a workflow that involves feeding the entire project as a single zip file:

https://aibynick.com/thread/3

Otherwise, I use Pi with Deepseek.

Anvil was a fantastic environment, but no framework can improve productivity in any way that compares to using modern LLMs and coding agents. I complete lists of requirements which used to take a week of work, in a few minutes. And the LLM is involved in every phase or research, communication with clients and IT staff, server config, etc. No framework does that work for you. The key is to use development tools that the LLMs know how to use best, and which don't hold you back at all when developing any sort of project. Python has satisfied every need I've run into, even in demanding real-time apps, it's accepted in every environment, and the big LLMs can complete virtually every requirement with it, first shot, in a few minutes.

For the steps it takes to get a Flask project zip file created by GPT, Pi, or any other agent, take a look at the post that starts with 'Here's a quick run-thru of how to upload project zip files for flask apps which you've created on a local machine, to a Linux VPS' at:

https://aibynick.com/thread/29

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 write the code. You don't even have to write the tests. You don't even need to do all the research about which libraries and tools in an ecosystem are best for your needs. You don't even need to write all the emails to your clients. You don't even need to write all the details about what was completed in your invoices. You don't even need to write the user documentation...

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.

I have clients who've never written a line of code, creating serious production applications with Pi and Deepseek. It would have previously taken many years of serious experience to build those sorts of applications, using any language, framework, etc. Those clients pass their creations along to me, I perform code reviews and tests, add auth, logging, and other features needed for compliance, perform installs, help along the way with how to approach engineering challenges, etc. I was only ever able to do that successfully with a small number of clients who learned Rebol, Anvil, or any other tool/language/framework.

Baserow came the closest to being a serious development tool for non-technical users. 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 apps on Baserow databases (some of the biggest projects I've continued to work on in the last year still use it) - but there's hardly even a real need for that any more. 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 have taken days to build schema for in Baserow, and I'll have the entire application completed and running on a server in less than an hour, using GPT or Pi+Deepseek. The difference is like comparing snap-pops to nuclear bombs.

Then I got this follow-up question

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

Here's my response

C isn't the best choice for any of the applications I build.

Even though characteristics such as verbosity and productivity have become the least important factors in language choice, 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 accessible on any client device (Windows, Mac, Linux, Android, iOS, Chromebook, etc.). 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.

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, real time libraries in that ecosystem, etc.).

I spent a solid year profiling every development tool I'd ever used, and Flask/Python was 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, because Anvil uses visual UI and DB builders - 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 to ease human work.

There's also a ton more code and documentation available online about Flask, and Flask is a simple and composable system which LLMs seem to be able to reason about well. The server based Jinja templating system is versatile enough to incorporate any sort of HTML/CSS/JS UI tools - LLMs are also fantastic at writing that sort of code. Need to add any imaginable complex visual layout design, interactive graphic system, datatable controls, beautiful visual styling, or even 3D graphics - those things aren't even a speed bump for LLMs.

And the same is true of SQL and SQLAlchemy, which are first class citizens in Flask. Working with traditional RDBMSs is another lingua franca of LLMs. Prepare your requirements properly, and the LLM can build proper, 100% working schema, foreign keys, and thousands of lines of queries, first shot every time, in a few minutes. And it can painlessly migrate schema and adjust logic just as quickly.

And LLMs can work with Python language and ecosystem just as easily as they can say hello to you. The Python ecosystem has over 500,000 packages available via the official package index, and the industry generally provides Python support first for the overwhelming percentage of new useful interfaces.

And 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 very simple to integrate with 3rd party systems.

For all those reasons, and many others, Flask just works for LLM development. It's ridiculously versatile, 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 total. They 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. Python support is absolutely everywhere, natively.

The systems used to manage security practices in Flask are well understood, simple to implement, and 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 still see simple apps developed in Next.js and React, for example, by vibe coders, which end of being several hundred times bigger and more complicated than the Flask conversions I make of those apps.

Most important, when coding with LLMs, the volume of material in a model's training corpora is what matters, along with the size and breadth of capability in the chosen language's ecosystem. That's why Python basically wins as the language of choice for most LLM coding, and Web UIs win for most front end work, and SQL/SQLAlchemy wins for databases needs, and the Python ecosystem wins for existing libraries. Those tools have absolutely massive ecosystems, with many billions of lines of available code and billions of pages of documentation for LLMs to train on.

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 the React, Vue, and other web development ecosystems that are used most for that sort of work. The LLMs know how to use all those tools well.

The only ecosystem I'd personally like to do more with is Go, for applications that need low level performance optimization. When it comes to coding with LLMs, Go is best positioned for compiled language optimization. I'll likely write a long post about why Go would be my choice for LLM development work, but for many of the same reasons, it's just perfectly suited for LLMs to be able to work with. The web frameworks available in Go are 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's not my current market. I currently write mostly internal tools used at hospitals, government organizations, and in various medical service fields.

Those tools are critical for business operations, but they're 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 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 need to 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.

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.