frankie-tales

New frontiers of the FOSS contributions.

2026-10-05T12:30:00Z

I recently sent a brief answer to @krille on Mastodon about what managing an average FOSS project looks like in 2026. Christian is the main author of a Flutter app (FluffyChat, a Matrix client). Indeed, this deserves a more extensive discussion.

Currently, there are two kinds of FOSS projects out there: those that do not have an AI policy and those that do. Among those with an AI policy, some do not accept AIAD contributions. In contrast, others accept them under restrictive rules, generally treating man-in-the-loop as a distinctive characteristic for accepting patches. In all cases, projects are currently seriously impacted by indiscriminate submissions of AI-tool-based issues/PRs, with or without respect for the project's policy (if it exists). Curiously, this is especially true for security-related segnalations, which, for some reason, third parties also submit regardless of the project's AI policy.

My thesis is that, in any case, PRs and issues with patch submissions should be deeply reconsidered over the average project lifetime, on both sides of the process — i.e., the maintainer(s) and the contributor(s).

Firstly, if the project does not have an explicit AI policy, the maintainer(s) should reconsider it: this is not the case for Christian’s project, which prohibits AI tooling for both code and documentation (but it should also possibly cover bug submissions, including security-related ones). Nowadays, an explicit policy is mandatory; without it, you risk receiving any kind of contribution (documentation, bug reports, and code) with or without AI use. In practice, many AIADs contributions can be extra-verbose and off-topic, or pure garbage if created without a grain of salt (the so-called slop): the world out there is full of weird individuals. Closing security-related AI-generated reports could seem weird, but I honestly don't see any reason not to, especially when such reports are one-shot, with no decent follow-up or clear use cases/exploits.

I’m often on the AI-tooling with human-in-the-loop side, but I fully respect people who think differently. On my side, I simply avoid sending any AI-tooled contribution when an anti-AI policy is explicit. On my side, if I'm motivated enough, I fork and create my own repositories for my own use, without pretending to force other parties to follow me in my choices. In many respects, that’s also more immediate and manageable for everyone involved (including me: preparing a decent PR proposal takes effort). As I said in a past post, this will probably be the future of most current FOSS projects, deeply changing the code-sharing paradigm.

Indeed, I’m now more convinced of the value of the BSD license compared with the GPL. The FOSS code for most projects out there is now simply a proof of concept to adopt and adapt for your own use, with whatever changes you find necessary and sufficient for your goals, whatever they are. A totally source-level pure commodity to use as a brick in your workflows. With AI tools, the initial barrier to diving into an existing codebase and managing changes to whatever code is extremely low, if not pretending to create the best code at any cost. As such, most of the FOSS code will be inherently low-value/low-interest, what generally could be considered pure personal projects.

The results could be good enough for your own use without pretending to be general or refined. And, like it or not, this could be more than enough for your on-purpose/limited use. Nowadays, I create a lot of write-once-use-and-forget code to solve a specific task, and it is not even written in Perl (ok, I’m joking). I generally publish those in one of my repositories, just to remember them later and back them up. They may or may not be useful to others or even to me later; I don’t worry about that. I don’t expect third-party contributions, and it is totally intentional. Of course, a limited number of prime-time consolidated FOSS projects with large teams and well-selected contributions will also exist in the future, but that’s not the typical case for many of us, now.

At the same time, the inherent value of many categories of FOSS projects is now truly lower than it was in the immediate past. For instance, I now have very little interest in learning and using client-side frameworks or libraries that I use rarely or could reimplement in plain JavaScript for what interests me. I have also stopped using general-purpose CMS and server-side frameworks like Django or Drupal. This is also true for most geospatial webGIS applications, for which a Jamstack architecture with a simple Spatialite database is more than enough for many uses. This approach can maximize the possibility of using AI tools through fast change-and-review cycles. This is true in my case, but I expect it to be true for many developers in multiple fields, and it will impact many projects in the immediate future, resulting in fewer developers, fewer users, and smaller communities per project. I expect many once-first-class projects — created to provide higher levels of abstraction to simplify development — to become legacy software sooner or later, with limited maintenance. Who needs simplified layers of abstraction when AI can reduce complexity on purpose?

At the same time, in the enterprise, AI tools have become the most common and inevitable solution for software management. When people prioritize productivity and results over quality and full understanding of code, this is unavoidable. As I've said in other posts, the AIAD approach isn't black-and-white, but a matter of shades of grey. Of course, the temptation to treat AI tools as a silver bullet for any engineering problem is a real risk in the enterprise environment. Still, AI is unavoidable, and it also impacts team composition and the daily work of most developers, whether they like it or not. You can still decide how to manage your own FOSS personal projects, but when your job depends on adopting certain workflows, I see few options for escaping mainstream tendencies. And, like it or not, AI tools are mainstream by now, and here to stay. For sure, it is totally pointless to be harsh with people who currently have different views about using AI tooling in programming, and I don’t agree with the opposite attitudes of commiseration between the two different schools of thought: there are perfectly reasonable pros/cons on both sides.

We will discover the consequences (in any sense, for better or worse) of such epochal changes in programming and knowledge management at large only in the future.

Using AI tools with proficiency in the right context: an example.

2026-08-31T15:30:00Z

The use of AI tools for development (AI-aided development, AIAD) and intellectual work is a disputed, hot topic. I’m generally on the pragmatic side in that regard. While the environmental impact of AI systems is evident and a reasonable concern, these tools, when used with a grain of salt and a responsible approach, can solve problems that would otherwise be hard to manage. Keep man in the loop, to say it in one sentence, and do not pretend that such tools can fully replace human judgment and capabilities.

This is the chronicle of a little project that quietly waited 12 years before finding a solution, during a week of vacation. My caving group maintained a website since the end of the 90s. As is typical for a non-profit association, volunteers do all the work, and building and maintaining a website is not usually a top concern for the average speleologist. At the very beginning, a single member handled all design and content management. She was not a developer, and in those years many of the websites were amateur products with very few concessions to standards and consistency. Think of most of the Geocities amateur sites, and you've got the idea. That website was not different in those regards: dozens of little icons, navigation buttons, and naive layouts on every sort of page. The good, old, and ugly web content of the past.

The old site was maintained until the beginning of 2014 and contained almost a thousand pages on multiple topics and variously interlinked, all written by hand under Dreamweaver with many tables to align stuff and very little CSS. That was the time of Web 1.0 (or maybe 0.5). That year, I tried what I saw as a big change for the future: moving to the most-used CMS of the time, WordPress. The goal was to involve other members in a collective editorial effort, facilitated by a system that simplified content creation. Unfortunately, after a few pages were migrated by hand from the old site to the new CMS and a few new pieces of content were added, the whole operation continued until this summer with very little success, mostly stalled. The greater part of the old site remained as it was, and the editorial team did not gain members. The main reason is that cavers like caving, and a lot less they love writing anything, including the shopping list...

At the end, we had a totally dead old site and a new one in turn to languish on the same server. The WordPress site also added a concrete problem: the need to migrate from time to time to new versions of the CMS, with a moderate-to-medium load of effort for this purpose, and the prospect of having, in a few years, just another abandonware to manage without prospects: a set of old static pages can always be read in a browser, but a dead CMS is a completely different beast.

In that week of vacation, I finally managed to migrate all the content into a Hugo-based jamstack site, for both the WordPress and the historical old site, including all past pages, converted into a uniform acceptable form for the new site. That was only possible thanks to AI, through successive approximations, with some auxiliary Python scripts and a series of trials, adjustments, and views to check the results. Converting a bunch of one thousand old-fashioned HTML pages is grunt work, so the miracle of completing a migration never done in the past 12 years finally happened, only thanks to the help of the artificial collaborator.

The final result is visible here, and a brief chronicle of the multiple steps followed and choices made is also available. Both are in Italian only, sorry.

A major result is that AI tooling can be proficiently used in well-delimited contexts and with careful supervision. When results can be easily checked and verified, it is even better, and often an under-frontier model is more than sufficient: I completed all tasks using mostly the Claude Sonnet model, not even Opus. I don't own the required hardware, but I’m more than sure a reasonable open-weights local model would have been more than enough for such a website migration project.

So, do you have a grunt task you hate to do that no one will help with because it's totally annoying, a waste of time, and requires no creativity? That’s the perfect job for your preferred AI tool. Good choice and well done.

The only good AI is a dead one: myth and reality of AI tooling for code

2026-05-05T13:00:00Z

Some months ago, I participated in this Mastodon poll. My thesis was that, in general, there is no presumptive quality flag that can be added to a product, whether it was created with AI-aided tools or not. My opinion sparked a small, heated controversy among some readers.

Labeling a product as AI-generated and expecting low-quality results is simplistic and prejudiced. One expects that the resulting product is accepted without review or handcrafted changes, after multiple adjustments to the LLM prompt through an iterative process. This is clearly false in general for coding (vibe coding, per se, is not a black-and-white picture; it is full of shades of grey), but it can also be applied to other creations.

Even the use of AI tooling has hundreds of nuances, especially in many articulated processes of creative production across multiple fields. AI tools or not, the human contribution is still central in the process. One can abdicate to such a role, or be fully responsible for the final result, with accurate changes and handcrafted work based on a rough draft generated by AI. The presumption of labeling AI helper use as a signal of low-quality production negates the importance of the human-in-the-loop. The point is that quality should be considered an objective aspect of any product, with or without human authoring: having a handcrafted product is not necessarily a symptom of quality per se, and the same goes for the opposite if the product used AI tooling at any phase of its creation. At least for programming, we had spaghetti code for ages, well before AI agents.

If you take a walk around GitHub and look at too many projects to enumerate, even without any AI intervention, you will find a lot of half-finished, incomplete, alpha-quality, obsolete, or partially working code that would need a good number of deep refactorings to be considered for production use. That’s not a problem with AI use; it’s simply due to the not-too-recent shift in FOSS coding as the mainstream approach to writing programs. Opening a GitHub portfolio assumed almost the same importance as opening a LinkedIn profile for techies. In many cases, such proof-of-concept products have been sitting on a developer’s shelf for years. Today, they populate their GitHub (or any other hub) repos, instead.

On the opposite side, one could read a recent Antirez’s post, which shows how much a meticulous human-in-the-loop approach for automatic programming can be productive and reasonable. Not secondary; such an approach should be currently considered essential to fully admit a copyrightable contribution to existing or new code, as explained in Simone Aliprandi’s recent book.

In conclusion, pretending that AI tooling produces only slop is clearly prejudicial, not different from past anti-FOSS prejudice that unpaid work done in free time cannot be of good quality. Does it sound familiar? Sure, there are a lot of low-quality projects out there, but again, that’s not necessarily the case, and there are also many very good FOSS projects, created and maintained with great care. Again, a license type and development workflow are not enough metrics to judge software quality, nor is the use of AI sufficient for the same purpose. And that’s true for coding as for other creative works. That’s not that simplistic, dudes.

Guess what? 97% of 3,456 respondents in the Mastodon poll answered that an AI mark on a product is a good idea for a presumptively low-quality design. I’m quite sure most of them are also AI users in some form, of course, and that says a lot about the future of this AI era and human ingenuity.

Is AI driven coding the start of the end of mainstream FOSS?

2026-02-04T20:00:00Z

Someone on Mastodon (I’m sorry, but I don’t remember who exactly) published a short post that pointed to a rather technical economic study of the impact of AI on FOSS software development [1]. It is no secret that the AI debate is highly polarized, and the enthusiasts for the current trend in AI applications in the IT domain are at least as numerous as those who are concerned/skeptical. What is certain is that no one can, in the long term, prospectively evaluate the impact of AI on society, particularly in the IT world.

The main thesis of the paper is that AI-based code production will end the mainstreaming of FOSS software, as we have learnt over the last 15-20 years. The paper begins with well-known episodes from recent history (specifically, the Tailwind saga [2] and Stack Overflow's near-death experience [3]).

Of course, the paper presents a theoretical economic model to evaluate a possible impact scenario for the FOSS production model, which could or could not come to fruition, depending on the assumptions made.

My honest opinion is that a conscious and accurate use of AI can accelerate development. That is, in a bad and good sense, I mean directly on the basis of the experience and skills of people who use such models. Therefore, we are both seeing slop and high-profile creations with the aid of AI. Maybe slop contributions are more prevalent simply because mediocre developers are the majority, and mediocrity is the backbone of enterprise production (because it is the most replicable and independent of contributors and their capacities).

Like it or not, modern software industries do not need, and fight against, too much creative approaches. Enterprises need aurea mediocritas, not isolated geniuses. Also, depending on third-party creations, it apparently reduces the enterprise's technical debt because it is typically shifted onto someone else's shoulders. Of course, this is an approach that works until it fails miserably when such a third party disappears, changes its license model, changes its mind about the product, changes its APIs, and so on.

That said, one clear consequence of using AI helpers in coding appears to be the progressive disappearance of many packages, modules, and libraries, which can be easily replaced by AI-generated creations tailored to the task. Just to cite one practical example, Tailwind nowadays could be easily replaced by CSS and simple JavaScript components, with the obvious advantage of not depending on yet another third-party-controlled piece of code that could be subject to abrupt changes from one version to another without notice and break existing codebases. At the same time, Tailwind themes can be generated by AI without even consulting its documentation (which apparently had an immediate impact on the company's revenues).

Another advantage is that AI-based, tailored solutions would reduce the amount of code from external dependencies that solve problems for others, instead of focusing on the minimal set of features for your own needs (with all the implications of possible breakages arising from such an anti-minimalistic pattern).

Of course, using AI helpers in this way does not reduce the effort required to understand and create new software, but it probably raises the required competence to a higher level, which could be better in the long term, while encouraging quick-and-dirty approaches in the near term. The so-called vibe coding is not a black-and-white concept; it has a lot of grey tones directly depending on the awareness, responsibility, and skills of the developer: as said, it can accelerate in many senses - even to crash against a wall - increasing in an uncontrolled manner the technical debt when in the hands of the wrong individual. Even about that, Anthropic recognizes that AI abuse can negatively impact coding skills and debugging capabilities [6].

Add to this the current very high infrastructure load many networks are reporting, for which the AI bots currently seem to be the culprit [4]. This seems like very strange behavior for such botnets, given that web crawlers have been around since the 90s and should be able to handle infrastructure load fairly well by now. It seems that AI companies simply aren't fair enough on their own, or that the training phases of neural nets are definitely more demanding. Maybe both?

So, what do I see as the future for FOSS development as a whole? I am not a pessimist as in the cited article. For sure, I see fewer small contributions in the long term. Today, there is a massive production of AI-slop-based contributions to many prime-time projects, but I see this as incidental. In recent years, GitHub-based path of honors has been a major self-promotion channel for junior developers, which explains the drift toward low-quality contributions: devs are (were?) strongly motivated to contribute and find in AI slop an easy path to that, by creating personal portfolios. That’s also true for fake security-related reports (see the well-known Curl project case [5] and others). This is, of course, annoying, but in my view, that’s the result of current AI hype and should normalize in the mid-term.

Also, in the near future, I see less and less relevance in FOSS projects that are not sustained by a strong architectural idea, innovation-grade, a large community, and a consistent development effort (much bigger than a few weeks or months of work). That kind of project will become mainly background noise, let me say. Maybe that could impact whole categories of FOSS software: it is not a secret that many language hubs are full of packages/modules of dubious quality, often used because they are available just a use/import directive away. In many cases, such products will simply be replaced by an AI-based reimplementation. If the final result will be better or worse in average quality, only the future will show. For sure, the AIAD will cause a progressive democratization/popularization of the development process, giving average users access to possibilities once unavailable to them: we will probably see the production of a plethora of small tools and workflows built on agents rather than finished, refined products, like it or not.

The result could be an increase in FOSS products at the cost of lower average generality and code quality, with a few high-end, tailored products for mainstream applications instead. But was this really so different in the past? I don’t think so. The true difference is probably the increase in quantity in both sets of products, as potentiated by AI tools: if one does not do her/his homework, the result is clearly garbage, but that was true before AI, too.

“AI gives us the worst and the best - simultaneously.”

(Daniel Stenberg, the Curl Mantainer)

References

AI training, copyright and the future of contents creation

2026-01-11T21:00:00Z

I have already addressed the implications of modern LLMs, specifically their training, in the context of copyright and licenses for both code and original content. A 'IANAL' disclaimer applies to this post, but my honest opinion is that such training is a legitimate type of reading and learning after study, unless explicitly excluded in licenses among the licensee's rights.

Following the exploitation of LLMs and the AI boom that began in 2022, several lawsuits and litigations emerged among multiple parties, with a few reaching a significant milestone through the first court rulings. Note that every country has a bit different regulations about copyright and fair use, so the current lawsuites could be only the starting point of a long list of legal actions.

While most of the current lawsuits seem to demonstrate that Anthropic or Meta had the right to use books bought (in paper or digital form) for LLMs training (on the basis of the fair use principle), the most problematic aspect instead is the apparent use of pirated books taken from LibGen and other known piracy websites, which - if confirmed - can result in potentially destructive damange for the companies, to compensante authors and pay fees in the order of hundreds of billions.

The same problems are present in the coding parts: again, using FOSS-licensed code for training could fall under fair use, but training using private codebases, as well as proprietary ones, could be equally destructive for the same companies, as well as for GitHub and Microsoft. The key point would be demonstrating, without any doubt, the unfair use of private or pirated content, of course.

Of course, I'm quite sure future licenses for FOSS codebases and documentation could include an explicit exclusion clause for AI training, which could jeopardize the legitimation of use even for future FOSS code. I would expect such a license change, as some projects already explicitly exclude AI-based contributions. My opinion about such a question is that it could represent shooting oneself in the foot, due to the pervasivity of AI tools among developers currently. Adoption of AIAD could represent a boost in development time if adopted with a healthy dose of skepticism (i.e., a human-in-the-loop approach). About that, I'm quite convinced of Linus Torvald's point of view: the point is not who writes the code, but who is technically responsible for it and ensures the required quality review and supervision.

Moreover, an implication of the current polarization in the AI hype is the future (present?) crisis of traditional web content providers. A symptomatic case is the StackOverflow crisis, which will, with high probability, lead to the end of the service as we know it in the near future.

That will have an impact on future AI training, too, for sure, because SO has been for years a huge source of knowledge about multiple fields in IT. What if fewer and fewer people will contribute to Wikipedia and general web content? What if more and more sources of information were to reserve the right to use their information for pure human-driven study? Knowledge has not been static in human history; AI models will need to continuously enrich their training sets and stay up to date.

It would be grotesque if the whole AI hype were brought to a halt by such copyright-based legal questions (even if I'm pretty sure a fully fair training would be possible now for such companies, who knows the impact of a more limited approach on the final result?). Surely, this seems the most serious threat to the future of such companies and the whole AI-based solutions.

The only true solution to such a threat is finally having a true open training model, which details sources and the whole process of training with full transparency, something that even the so-called open AI models are still far to be ready to provide.

References

Again about AI, copyright, uses and abuses

2025-04-29T20:00:00Z

My last post dealt with some ideas about copyright that need more in-depth analysis. First, as it was common in the old good days, IANAL applies to this post and the whole topic. The final results of current litigations in courts that touch on some of the primary companies involved in the whole AI thing could ultimately differ from what is now the common sense point of view (mine). This post could become rapidly obsolete, so another disclaimer is due for this aspect, too.

A nice summary of the matter in the summer of 2024 can be read in [1].

I have to partially fix the assertion I made about copyright by Anthropic/Google and whatever company in a certain sense. At least for US copyright law, anything directly produced by non-humans is (or seems currently) not admissible for copyright coverage [2]. As you know, there are a few differences between different jurisdictions, specifically the US and the rest of the world. That's the reason why, indeed, Joseph Borg and Galyna Podoprikhina by WH Partners [3] say:

Despite the "common" belief that a work can be only be
protected by copyright if it is created by a human, one must
bear in mind that copyright laws are not uniform around the
world, especially when it comes to AI-generated work, or a
work created with the assistance of AI. Currently, apart
from the UK as described above, AI artwork is also subject
to copyright in Ireland, India, and New Zealand.

If a photo taken with a camera is admissible for copyright, the same could be claimed for any other tool, one could say. In the past centuries, even photography would have been indubitably not initially admitted to copyright and the artistic scene: indeed, a painting is a lot different from a photo. A modern photographer would not agree with such mortification of her/his work. Today, the reality is quite different, and photography is fully accepted among modern arts, with all implications about intellectual property and copyright.

Most authors agree with the significance of the human contribution to the work to define a copyrightable work, but how this contribution could be quantified is obscure. The number of prompts and replies, as well as the size of context contributions, are significant and sufficient efforts, or should they be quantified in LOCs and the size of direct patches to the AI artifacts? And in that case, what is the percentage of human-driven contribution that represents the threshold for deciding if the work is copyrightable or not? I'm afraid that the final verdict is something to decide in a court, as in cases of plagiarism.

But for AI, for ages, we also had RAD and no-code/low-code utilities that seemed the future of development for specific applications, with all their limitations (not too different from AI ones, to be fair). Even in those cases, copyright claims could be problematic.

That said, there is also the problem of training possibly performed without authorization. While most of the FOSS software is covered by one of the OSI licenses, not all licenses are compatible with each other, so the resulting LLM model is questionable and possibly unfair. I will ignore, for decency, the eventual use of proprietary content for the purpose of training, which already seems to be the subject of lawsuits by multiple parties in some contexts: see for instance [4] and [5].

As written in [2], the final destination of the whole topic is still foggy and unclear. Multiple parties are involved, and a series of lawsuits and claims are pending. This seems to be the reason why some companies explicitly deny the possibility of using AI tools in their developers' daily work. Due to their pervasive diffusion at multiple levels, this becomes increasingly difficult to avoid. As often in the past, tools are still forward than rules and sh*t could happen in a not so far future.

References

AI artifacts, copyright and electric sheep dreaming

2025-04-22T12:30:00Z

My last post captured the attention of my old fellow Sandro 'strk' Santilli on Mastodon, who sent a provocation about the whole AIAD thing. So, the challenge is accepted.

First and foremost, the whole AIAD issue is a complex and hotly debated topic. The question of whether the training practices of the past and present should be considered fair use is a matter of contention. This is particularly true for existing code bases on well-known repositories and other types of content, a complexity that keeps us all intellectually engaged.

In the specific case of code, the basis for deciding about such a question was formerly stated in the accompanying licenses. Honestly, there is nothing in the current formulation of OSI licenses (BSD and GPL, among others) that precludes such a very special activity. The non-discriminating conditions apply to any human activity, and the neural net training - undoubtedly a human-driven task - is not excluded. The training is a learning type of activity or a sort of.

That said, the NN training is, of course, a massive and intensive kind of learning. But let me consider any artifact created by an AI model as a direct derivative product (this is a forcing of the concept for me, but let me axiomatically accept it). That could be an 'original' product created from scratch (i.e., by direct prompting or by limited documental context) or a direct derivate one (because it is based on previous code proposed as part of the AI context). Suppose you ask any of the big models for a direct clarification of the terms of use. In that case, you will discover that any of their artifacts retain the copyright ownership of the product, but there is a very permissive use that perfectly adheres to the four fundamental freedoms of FOSS licenses. Of course, the results could be based on a previous code base. In that case, its license still applies for such a derivative work, even with the additional copyright of Anthropic, Google, or OpenAI.

This could pose a significant problem if the final software product needs to retain one specific copyright holder, as is the case with most proprietary software or some FOSS ones. Understanding the potential impact of copyright transfer is a key consideration in this context, and it's crucial for us to be fully informed and aware.

Is the process of an AI participating in development really that different from what any average hacker does when participating in FOSS projects? I don't think so. You add your copyright to the existing ones for the parts that are under your direct control and accept conditions of use already defined in a license. The true challenge, in my humble opinion, lies in the changing of licenses. Any ex-post change should start with a note of acceptance by all copyright holders, including Anthropic, Google, etc.

I consider this difficulty a feature, not a bug. I advise against participating in projects with copyright transferring because of the potential for changing the license later when your contributions move out of your control. It happened in the past, and it will happen again.

One should also consider the licenses of many other sources of knowledge and inspiration for developers. How many people know that the default license for StackOverflow code snippets is CC BY-SA? Indeed, how many developers actually add an acknowledgment in their software for such snippets? Or even for snippets taken from sites, blogs, books, or manuals without considering that such sources are even more restrictive for use and creating derivative work? Isn't our full daily work the result of a long learning phase, based on our education and training by books, experiences of others, as well as trial-and-error processes?

That said, let me spend some words about the elephant in the room. In the context of AI and copyright law, the 'elephant' represents the complex nature of AI models and their potential to create original works. Do AI models dream of electric sheep? Well, I don't think current models are pure stochastic parrots, to be honest. I think there are probably dozens or hundreds of cognitive forms that govern what we call generically intelligence, including some emotive and empathic forms that one can also find in a dog, a cat, or a dolphin. One of those forms is probably captured from the neural network model of functional representation, which is also perhaps in common with part of our mind. We are at an average level, much more effective and efficient in those regards, and to be fair, I would also say that hallucinating is a common experience even on the human side. We are much more complete and retain contexts that are wide, like a lifetime. A few people are terrified by this observation and seek refuge in negation or faithful certainties.

We are complex organisms with probably still partially known processes that govern our so-called intelligence, which is physically based on cells and energy in our brains, whether we like it or not. We found a way to mimic part of this complex process, with all limitations of the case. Is this intelligence? I don't know, but at the end of the day, what is intelligence? When none asks me about that, I know perfectly what is, but if you ask me about that, I don't know anymore.

Coding with AI, the good and the bad

2025-04-20T17:40:00Z

Like many other developers, I recently started using some LLM-based AI systems as helpers for coding in a few languages. I'm not a fan of VSCode, and I prefer a more traditional approach to coding: I hate to cope with code completion servers and use one of my preferred editors, Vim or Emacs. Navigating by tags is more than enough for me. That said, this is the summary of my current experience in the new world of AI-aided approach to coding (i.e., AI-aided development or AIAD for brevity).

There's a clear divide among developers when it comes to AI tools: some love them, while others are more skeptical. If you're keen to delve deeper into this topic, Salvatore Sanfilippo, also known as Antirez, shares some insightful perspectives on his YouTube channel. He provides comprehensive evaluations of the leading AI models and systems, offering a balanced view of their strengths and limitations.

Based on my experience, while both Anthropic and Google top models are equally good enough for use, a big difference is due to their relative UX, which is incomparable among various systems. Luckily, things are continuously changing in those areas. Copying and pasting without a clean and accessible per chat/project assets catalog is definitively a pain. The most effective approach is sharing pieces of a git-based code base, which is not always possible with all AI chatbots. Even Salvatore shared a few impressive results about his experiences, and I can definitively assert that, at least currently, some of those systems can be quite helpful for some tasks if (and only if) used with a grain of salt.

First and foremost, the most effective use of AI tools starts from very circumscribed tasks to perform in a step-by-step approach after a well-stated creation of the context to make choices. In other words, any model must be conducted by hand in the right direction. It is crucial to use what Claude AI defines as projects to create a clear context with a general detailed architecture description and key assets for orienteering the linguistic model. It is also essential to maintain order meticulously. Being verbose enough and precise is the key point, and that's typically what a senior profile should be able to do. Each resulting asset needs accurate reviewing and testing; it is simply impossible to assume that a simple change in human terms corresponds to perfectly valid changes in AI assets. What is easy for us could not be for the AI model and viceversa.

The review should be both stylistic and functional because complicated programming patterns could be completely unmatched by the AI model. That is specifically true when documentation about APIs is unprecise or missing the point. The models even tend to generate redundant code or hallucinated code snippets that cannot be compiled or interpreted. Sometimes, the AI model generates incredibly good code at large but presents silly or subtle oversights. At the end of the day, there is not always a gain in development time; it is only something different: you spend more time reviewing and fixing bugs than writing code from scratch. It is essential to cope with the limits of current AI systems to develop a handy way to compose multiple parts together and keep track of improvements and fixes in multiple iterations of the process. During iterations, it could reach the limits of the AI context and get incomplete or truncated files, and it is fundamental to have a way to regain the path with minimal effort. In other words, one has to design a well-formed idea of the resulting products and all intermediate artifacts. That's the reason why seniority and experience are fundamental to using such tools effectively: sorry, Mr. CEO, engineers are still here to stay and being paid for good work.

Tasks that can be easily covered by current AI models are:

Creation of general documentation and/or comments in existing code.
Creation of simple tests from a structured codebase.
Translation of code from one programming language to another, including documental formats, such as XML, JSON, and YAML.
Creation or improvement of auxiliary tools and boilerplates.
Reviewing and improving existing code by steps.
Help in identifying common issues and possibly interesting features.

The average results are good enough for an initial base of successive analysis and development, and I found the AIAD especially helpful with activities that I judge seriously dull and time-consuming. It's a relief to have AI tools that can handle the whole web front-end-related activities, which I personally find less interesting.

Using multiple AI models to cross-review a code base and possibly prepare multiple improvement alternatives while purging the obvious misunderstandings is also an interesting opportunity. At the end of the day, I judge AIAD as effective enough, but for the most significant limitation of having a not-too-extended context size (at least with basic pro/premium profiles). This intrinsic limit is the source of major problems in the UX, along with still rough or incomplete interfaces: if you need to review and modify a large code base, you can easily crash against such limitations and have to apply intensively a divide-and-conquer strategy to govern hundreds of thousands of LOCs (but diving into any unknown big code base is anyway so different?).

Of course, the correct approach is understanding that its use changes programmers from pure creators to reviewers. In those regards, I generally consider AIAD a Stackoverflow with steroids: anyone who used SO in the past found valid and interesting answers to questions along with perfectly misleading suggestions, and that's not different, and mostly better.

Disclaimer: I mostly used Claude and Gemini Pro, much less ChatGPT and Deepseek due to their intrinsic limits for UX.