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