AI Is a Tool, Not a Threat: A Textsmith's View
Ishe Chinyoka
- 6 minutes readTable of Contents
When photography first appeared, some painters feared that art had reached its end. When calculators became affordable, some believed students would never learn mathematics again. When computers entered universities, there were mathematicians who regarded them as shortcuts that weakened genuine understanding.
History has a habit of repeating itself.
Today, artificial intelligence occupies the same position. Depending on whom you ask, it is either the greatest productivity tool of our generation or the greatest threat to human creativity. Within parts of the open-source world, the reaction has often been cautious. Some projects reject AI-generated contributions outright. Others require contributors to declare whether AI was involved. Some communities remain openly sceptical of the technology altogether.
Caution is healthy.
Fear is not.
As textsmiths, we should approach AI the same way we approach every other tool: understand what it does well, understand its limitations, and remain responsible for the work we produce.
The Tool Is Not the Work
One of the recurring themes on this blog is that we should focus on the task rather than the application.
Markdown is not the goal.
Git is not the goal.
Shell scripting is not the goal.
Programming languages are not the goal.
The goal is always to communicate, automate, analyse, or solve a problem.
AI belongs in exactly the same category.
It is another tool. A remarkably capable one, certainly, but still a tool.
If an AI assistant helps you write a shell script in five minutes instead of an hour, the important question is not whether AI touched the keyboard. The important question is whether the script is correct, understandable, maintainable, and genuinely solves the problem.
The same principle has guided software engineering for decades. We judge programs by their quality, not by how many hours the programmer spent typing them.
Keep Humans in Charge
Accepting AI does not mean surrendering responsibility.
Quite the opposite.
The person who asks for the code remains responsible for the code.
This is why I have a simple personal rule.
I only ask AI to generate code in languages that I can comfortably read.
Bash?
Certainly.
Python?
Absolutely.
Go?
Gladly.
TypeScript?
Probably not.
Ruby?
Not unless I am prepared to study every line.
The reason is straightforward. If I cannot understand the code, then I cannot confidently maintain it, debug it, improve it, or determine whether it contains mistakes.
AI should accelerate understanding—not replace it.
The danger is not AI-generated code.
The danger is accepting code that nobody on the team understands.
Vibe Coding Needs Verification
The phrase vibe coding has become popular recently. Sometimes it is used affectionately, sometimes mockingly, but the underlying idea is simple: describe what you want, let AI generate the implementation, and iterate from there.
There is nothing inherently wrong with this.
In many ways, it resembles how experienced programmers have always worked. We have copied examples from manuals, adapted snippets from mailing lists, learned from Stack Overflow, and borrowed algorithms from textbooks.
The difference is that AI can generate those examples instantly.
What matters is what happens next.
Did you read the code?
Did you test it?
Did you understand why it works?
Could you explain it to someone else?
If the answer is yes, AI has acted as an assistant.
If the answer is no, AI has become a liability.
Open Source Should Lead
One reaction to AI has been to reject it.
Another is to embrace it without question.
Neither seems particularly wise.
Open source has always excelled at doing something else: understanding technology deeply enough to improve it.
That tradition should continue.
Instead of merely debating whether AI belongs in open source, the community has an opportunity to shape how AI develops.
Open models.
Transparent training methods.
Auditable systems.
Reproducible benchmarks.
Open protocols.
These are precisely the kinds of contributions that the open-source movement has historically made to computing.
The internet itself became successful because of open standards rather than proprietary islands.
It would not be surprising if AI eventually follows a similar path.
Today’s AI ecosystem is fragmented. Models, agents, and tools are evolving rapidly, often independently of one another. As these systems mature, there may well be a growing need for shared conventions, interoperable protocols, and transparent ways of evaluating or connecting AI systems. If that happens, open-source communities are well placed to help shape those foundations.
Rather than standing on the sidelines, they could help define what responsible AI should look like.
The Right Question
Occasionally, someone dismisses a project with a remark such as:
“It’s AI-generated.”
Perhaps.
But what exactly follows from that statement?
If the concern is licensing, let us discuss licensing.
If the concern is security, let us review the code.
If the concern is correctness, let us test it.
If the concern is maintainability, let us inspect the architecture.
These are concrete engineering questions.
Simply pointing out that AI participated in the process tells us remarkably little about the quality of the result.
The origin of an idea is rarely as important as whether the idea survives careful examination.
The Unix Lesson
Unix has always encouraged us to compose small tools into something greater than the sum of their parts.
The shell delegates work to programs.
Scripts delegate work to functions.
Programs delegate work to libraries.
Humans have always delegated work to tools.
AI is another layer in that tradition.
It helps draft documentation.
It suggests regular expressions.
It explains unfamiliar APIs.
It generates repetitive boilerplate.
It reviews code.
It accelerates exploration.
None of these remove the need for judgement.
They simply allow us to spend more time exercising that judgement where it matters.
An Assistant, Not an Author
Perhaps the best way to think about AI is as a very knowledgeable assistant.
You would not sign a contract without reading it simply because your assistant prepared it.
You would not publish a book without proofreading it because someone else typed it.
Likewise, you should not merge code simply because an AI generated it.
Review it.
Question it.
Improve it.
Learn from it.
In doing so, AI becomes something remarkably valuable: not a replacement for human thought, but a catalyst for it.
That, I believe, is the healthiest relationship we can have with this technology.
As textsmiths, our responsibility has never been to avoid tools. It has always been to understand them well enough to use them wisely. AI deserves the same treatment. Embrace it where it helps, challenge it where it falls short, and remember that the final responsibility still belongs to the human who chooses to press Enter.