The Line I Introduce Myself With
"AI is just a tool, it is all in how you use it" hands away the one moment a builder's responsibility is real. A critique I mostly agree with made me redraw my own line.
Summary. A critique of AI's harms, most of which I second, forced me to revise the sentence I open every introduction with. Neutrality belongs to the discovery; responsibility to whoever encloses it into a system. And these tools raise the value of the fundamentals even higher.
"I am a technologist, and I believe technology is inherently neutral; it is the use we make of it that decides good or ill".
People who have worked with me over the past few years, or sat across from me in an interview or a prospect call, may recognise this sentence. It has been a central piece of my introduction spiel, mostly unchanged, give or take a small adjustment for mood or season.
And for me, this is genuinely true; that's the underlying reason why I would rather work for socially impactful organisations, and the motivation behind my joining Think-it in the first place.
But a few days ago, I read an article by Frank Elavsky[1] , and I was thrown off balance. It landed hard, like a direct attack: "Federico, you cannot be so naïve; you are an active party in making this situation worse", I heard the author telling me. It hit sharply, leading me to stop and re-examine where I actually stand, by forcing me to refine a half-examined conviction I had been carrying for years.
This post is about that refinement, and it is as good a way as any to begin writing here: by telling you who I am and what I am working towards.
Before going further, I will share a few words on my stake here. I use AI, and I use a lot of it. Research, planning, risk management and actual implementation; the whole nine yards (more on it in a future post). While last year I reached out only for the trivial and tedious, nowadays it is deeply embedded in my workflow. And that is why the piece stung.
On most of his points, Elavsky is unequivocally right, plain and simple. The environmental cost, the scraping of everything that could be scraped, without consent or compensation, and the slop; those are all real concerns, and so is the way these tools make us lazy. But granted all of that, I notice a small, but important flaw in the subject of the argument. Every single one of these harms is a complaint about how systems are built and run. None of them is a complaint about the underlying technology itself. Environmental cost is a fact about how the models are trained and served; theft is about how the corpus was assembled, and the slop and the flattening are facts about how the products invite us to use them. Not one of them is a property of the mathematics.
That distinction is where I had to slow down, because I think we use "technology" and "tool" as if they were the same thing, and they are not. Is the transformer architecture really the root of all evil? Nuclear fission is not the nuclear bomb. Fission is physics; the bomb and the power station are two different acts of building something from it, and the ethics enter at the building, not at the physics. A discovery describes what is possible and prescribes nothing. The moment it stops being neutral is the moment someone encloses it into a system: chooses the training data, tunes the behaviour, designs the interface, picks the business model.
Relocating neutrality up to the discovery puts the builder squarely on the hook. If the ethics enter at enclosure, and I am the person doing the enclosing, then "it is all in how you use it" quietly hands away the one moment where my responsibility is real. My old sentence deferred the ethics downstream, to whoever eventually used the thing.
There is a fair objection worth mentioning. Capabilities almost never arrive truly unenclosed; fission's practical life was nearly inseparable from the Manhattan Project. That, only sharpens the point. If the pure-discovery moment is often vanishingly brief, then enclosure is where nearly all the action lives, and so is nearly all the responsibility. Even the choice of what to chase, what to publish, and how to portray it is an act of enclosing; there is no unenclosed first link, only the first one we agree to call "discovery".
So, what can we do about the harms? Policies and guardrails are definitely necessary. But I do not agree that the answer is to hide the technology behind a bureaucratic wall only a few are permitted to cross. We all have seen this dichotomy before, in the long argument over strong encryption: should it be forbidden because a few will use it for harm? It is a never-ending debate, which is still very much alive to this day[2] . Forbidding a capability does not remove it. It concentrates it in the hands of whoever is willing to ignore the ban, and turns a shared thing into an oligarchy of the worst actors.
This is why I do not think we serve anyone by offloading the whole duty of control to regulators, or even worse, by shrinking away from the conversation entirely. Policy is reactive; innovation is proactive. Governaments will likely trail the frontier, and if the people who understand these systems cannot or refuse to sit at the table, the enclosure gets shaped by whoever is left there, or captured by a handful of vendors who would like to be the sole trusted gatekeepers. We do not get to wash our hands and hide behind the excuse that we are too small to change the status quo. We, builders, are precisely the people who can. So we must participate, share, collaborate, and educate.
The morning after, I read Jeremy Theocharis's "The LLM Critics Are Right. I Use LLMs Anyway."[3] , and it was a relief: others sitting in the same dissonance, using these tools daily and agreeing with almost every criticism all the same. It gave me the nerve to sit inside a contradiction here rather than tidy it away, because tidying it away would be an evasion, and trust is the only currency these arguments run on. The tool I am praising as a way to stand on the work of thousands of engineers was itself built by enclosing a commons without consent. My own work depends on it. Over the past year at Kaphera we have been building an open deployment stack for sovereign data sharing, and I could not have got us to where we are without AI; there is simply not enough time in a life to have learned all of it by hand in such a compressed timeline. So I hold the tension openly: the harm the critique names is real, I use the tool all the same, and the response I can stand behind is to build the next enclosures better than the one I am standing on.
Which brings me to the part I care about most, and the reason "let us get together" is more than a warm gesture. What I am asking us to build is a human-centric way of using these tools: one that helps us think rather than thinks for us, one where we know the output is ours because it genuinely is, and we can stand behind it. An enhancer of our capabilities, not a substitute for them. And here is the claim I hold most firmly, because it runs against the usual worry: now, more than ever, deepening the craft matters more. The tool only elevates someone who already has a floor to stand on. I could navigate Kubernetes with it because I already understood the basics; someone who never learns the basics cannot navigate anything, and can only accept whatever the model hands them. So the arrival of the tool raises the value of the fundamentals.
That has a direct consequence for how we treat the people coming up behind us. We have to teach our peers, our juniors, that using AI is not outsourcing your thinking and calling it a day. The old canon has not lost a shred of its relevance: the pragmatic-development books, the craftsmanship literature, algorithms, design patterns, the kata we return to because they are the foundation. We need to build in a way that elevates us, not one that takes our place. If there is an enclosure that decides everything downstream, it is this one, and it is pedagogical. It is how a craft keeps itself alive.
None of this arrived under the article's pressure. It is the oldest belief I hold; discovering it was the answer to the newest problem. I have spent fifteen years arguing that collaboration is positive-sum when trust is structured well, that leadership is the guardrail that elevates people rather than the hand that directs them, that you share what you know without surrendering control of it. That position predates AI; the technology only raised its stakes. And money is no villain here; the trouble begins when it becomes the sole driver of enclosure. Being paid to enclose well is a sound model, and extraction dressed up as enclosure is the failure.
So the sentence has grown. It begins where it always did, but it now says plainly what it is about, and it draws the line I had once left blurred.
"I am a technologist, and I believe technological discoveries are neutral; it is how we enclose them into systems, and then how we use those systems, that decides good or ill".
References
- [1]
- Elavsky, F. (2025) Stop saying that AI is just a tool and it only matters how it is used. Available at: https://www.frank.computer/blog/2025/05/just-a-tool.html (Accessed: 16 July 2026).
- [2]
- Breyer, P. (2026) EU Parliament greenlights Chat Control 1.0 – Breyer: "Our children lose out". Available at: https://www.patrick-breyer.de/en/eu-parliament-greenlights-chat-control-1-0-breyer-our-children-lose-out/ (Accessed: 17 July 2026).
- [3]
- Theocharis, J. (2026) The LLM Critics Are Right. I Use LLMs Anyway.. Available at: https://www.theocharis.dev/blog/llm-critics-are-right-i-use-llms-anyway/ (Accessed: 17 July 2026).