AI For Me, But Not For Thee
One of the main reasons why I love working in IT is because it was my hobby before I did it professionally, and I can still treat it as a hobby outside of work. I love trying out new things, learning new tools and applications, deploying and configuring them, managing them, and developing solutions. And AI has been an absolute game changer in IT, because it helps us with trying out these things potentially faster than us doing everything by hand.
I love using AI when it comes to developing. It can make building stuff quite fun.
However, when I find a project on GitHub which seems perfect for the one thing I need, and then I discover that it's been fully vibe coded, I immediately lose almost all faith in the project.
I discussed this with other colleagues who also enjoy using AI, and the agreement seems to be the same. When it comes to using AI on your personal work, we're much happier with using it than when other people expect us to use their work that has been developed with AI assistance.
I had to sit on this thought for a while to really understand why I have this double standard. And I came to realize that the reason why is simply a culmination of the slop that I've seen being pushed on us on a regular basis in the open-source community, or at work.
Work
A colleague was rushing to wrap up a Terraform deployment module at work which he developed, and I helped with with some bits, as he was about to leave for vacation.
Just as he left for his vacation, he messaged me with, "Hey, I wrote some documentation, can you review it please?". I skimmed his PR. +1800 lines of .md with very obviously fully AI generated documentation (!), by the extremely wordy Opus 5. My first reaction was to refuse the PR. Why should I be forced to disproportionately spend hours reviewing technical documentation for my colleague, who certainly did not spend more than 60 seconds to type out the prompt and didn't even bother to check the results himself first?
In the end, I decided that the hassle was not worth it to cause friction, so I applied a proportional amount of effort. I edited the PR with AI, to rework the long documentation to match the tone of the rest of the pre-existing documentation, and to trim it down to only inform developers on how to use it instead of going into deep technical details. (The deep technical details are still important, however this self-service document site for devs was the incorrect place for it).
It cut down the documentation to a much more managable ~300 lines, which I approved and passed it back to my colleague. "I have improved the documentation. Feel free to roll back the changes, or merge as is". Under normal circumstances, I would have preferred to write organic documentation that has been proofread and it is absolutely worth the time investment to write good documentation. But in most cases, AI has enabled people to be lazy, and not in a "we love to automate because we're lazy" kind of way.
Open Source
I love using Karpenter at work for our Kubernetes cluster, and I was playing around with a Kubernetes cluster on Hetzner Cloud in my free time. So, when I saw in the official release notes for Karpenter that there was a new module for Hetzner Cloud, I was immediately excited to try it out.
I installed it in my cluster with the given instructions, only to find out it doesn't work. At all. And it was very easy to see what the problem was from the logs of the controller:
{"level":"ERROR","time":"2026-07-25T20:59:06.106Z","logger":"controller.controller-runtime.source.Kind","message":"if kind is a CRD, it should be installed before calling Start","kind":"NodeClaim.karpenter.sh","error":"no matches for kind \"NodeClaim\" in
version \"karpenter.sh/v1\""}
{"level":"ERROR","time":"2026-07-25T20:59:06.114Z","logger":"controller.controller-runtime.source.Kind","message":"if kind is a CRD, it should be installed before calling Start","kind":"NodePool.karpenter.sh","error":"no matches for kind \"NodePool\" in v
ersion \"karpenter.sh/v1\""}
CRDs missing? Surely it couldn't be that easy. I double checked the installation instructions. I rendered out the chart locally to see what is included, as well checking the repo to see if the files were committed and I missed something, althought that seemed to exactly be the case. In the end, I created an issue, which the owner of the repo fixed rather quickly. But then I took a closer look as the owner of the repo links to their company:
The README of the repository should have been a dead give away already to the nature of how the code was written. But that shouldn't be an immediate reason to not give it a chance at all. But what really ticked me off was that it was immediately broken on installation. How can I trust that there are no other bugs lurking in there? How did the project owner not test the final released chart once? How was this promoted on the Karpenter official repo?
I do not envy anyone in a position of being a maintainer on any popular open source project, especially in the age of AI.
I also noticed that the repo owner started a discussion on a rather mature and well-known project for deploying Talos Linux clusters on Hetzner Cloud:
- Optional Karpenter autoscaling (karpenter-provider-hetzner) as an alternative to Cluster Autoscaler?
Again, the tell tale signs that the text was entirely AI generated. Now, I do not mind that people use AI to generate text. I don't expect that everyone is going to speak perfect English, and AI can be a great tool to help with this kind of thing. My issue is what the main point is: effort. People are expecting their flawed work to be worthy of being used alongside mature projects.
The Problem
Both of the examples that I've given are single examples, but we encounter these issues every day, and it has been only getting worse.
When I work with AI, I like to think that I put in the work, while accepting that I am not infallible. AI is a tool, and so far, the results have never been fully magical for me. If AI generates something that I do not understand, I try not to take it on blind faith that it simply works and call it a day. Because I'm sure all of us with enough experience can agree, when we're generating code in a domain we're familiar with, we can see clear as day that even the best and most expensive AI models make mistakes, and sometimes, we still let these mistakes slip through the cracks, even with vigilant eyes.
And yet, I must also admit that there have been numerous times that I have been too lazy. I have accepted it on good faith that the results are good, and move on with my life. The temptation to be lazy and give in gets stronger, the more we use AI and the more we start trusting the results.
So, what does AI do for us? It can do a great job of planning exactly what it is we are trying to implement and spell out the steps. It can help us define the problem that we're trying to put into words. It can even figure out issues and do troubleshooting much quicker than we can. It can do the implementation, and it can run some tests. But it is still up to us to check the output.
Recently, I've been putting a lot of thought into what my ideal AI workflow looks like from a development standpoint. And most of it boils down to:
- defining and refining the features to be implemented (eg. plan mode)
- having different agents implement those features
- checking the results, testing them further and understanding the changes
And that final step is arguably the most time consuming step for me. So, to truly "save time" and become a seemingly 10x engineer, a lot of people just skip this step. They've given in. They truly trust whatever AI outputs. They have foregone effort. They put the equivalent of a paragraph of text into their work and think the result is worthy work that should be used in your production workloads.
Granted, a lot of this can be prevented with proper CI/CD checks, good QA, but the issue is that in my experience, AI generated tests are atrocious at covering all cases, and I am assuming that most people are like me, who don't have a lot experience with QA engineering.
How this workflow does help in terms of saving time for me is that I can have a laundry list of items that I want to work on, I can plan with the AI on exactly what should be done, and then I can walk away while the agent is doing its thing. And on my own time again, I can check again to see what has been done.
Here Be Dragons
"Here be dragons" ... is a phrase used to indicate dangerous or unexplored territories, in imitation of a medieval practice of putting illustrations of dragons, sea monsters and other mythological creatures on uncharted areas of maps where potential dangers were thought to exist.
Perhaps the most dangerous part of using AI is to use it to generate and use code which is in a language or domain you are entirely unfamiliar with. I have tried this myself many times. On the surface, we might get good looking results. We might even get initial good results. But in the end, maintaining and adding on more to this code purely with AI is usually a disaster waiting to happen.
And I still think that this is an acceptable use for AI. As long as you're generating something you'll use for yourself, and only for yourself. But for developing a product, which you're expecting other people to use and also collaborate on, we might need to approach it a lot more carefully.
Other people might feel differently about this. but every time I have tried AI for generating code in a language I am entirely unfamiliar with, I have felt strongly that I have quickly slid from the domain of "AI-assisted development" into "vibe coded slop". And when I know that there are issues in the generated code, I feel entirely helpless, because I do not know how to properly prompt the AI to push in the right direction. I feel like a Pakled.
Riker: "What brings you so far from home?"
Grebnedlog: "We look for things."
Riker: "What were you looking for?"
Grebnedlog: "Things we need."
Riker: "Can you be more specific?"
Grebnedlog: "Things that make us go. We need help."
Colorized historical event of vibe coding
Perhaps I am biased, given that I make my living from IT. However, these kinds of experiences has over time have made me more resolute in the idea that our jobs are not going anywhere, any time soon. Even when using AI, the know-how, a user's knowledge and understanding makes a huge difference to the quality of the results. I am convinced that this will not change any time soon. The current situation with AI is that we can use it for efficiency gains. But replacing humans with real intelligence and understading of the subject matter is still not quite there.
The Solution?
That is the million dollar question. I still keep trying to improve my AI development workflows, and this part is something that I keep trying to improve upon. Which is to automatically test the generated results. But in my case, I find that it is not so trivial.
The generalized consensus that I read online from other engineers is that if you can define to AI your desired end state clearly, be it spec driven development or even better, test driven development, you'll get the best results. I tend to agree with this.
One tool that I am trying to integrate more and more into my workflows is pre-commit. It is by no means a one tool fixes everything solution, but it is a great way to ensure that:
- linters are run against commited code
- formatting is standardized and fixed before any commit
- code can be scanned for secrets
- vulnerability scans run
- any script or program can be run before the commit
This means that you can programatically define what is allowed to be committed and how it will be commited. This is a great first step for overall consistency. In addition, you can run the checks on a centralized place such as GitHub Actions, where your agent should (hopefully) not have the permissions to overwrite or edit such workflows, and make them required checks. Sure, AI can be guided using something like AGENTS.md, but a programmatic check is far stricter than "make no mistakes".
I would like to improve my workflows further by developing more QA tests. However, QA and testing have not traditionally been my strong suit. I have realised that this needs to change, as AI is here to stay and I believe that high-quality QA testing will become even more important in coding in the future.
In addition, I have been thinking about situations, where I use somebody else's open-source project, and I find a bug that I can get my AI to fix. Or this could be at work, when I want to help a developer integrate better tracing for telemetry data into their application. I can "easily" do it using AI, but the problem is that I might not be familar with the language or framework being used. In such cases, I still think it's OK to open a PR with suggested changes. However, I also think that it needs to be fully transparent that AI was used in the generation of such a fix or addition. I really would like to see a standardized approach to potentially make this more acceptable.