Why I don't trust AI code completion
alemi2023-10-28 17:14
While I could be making cheap points about how Copilot suggests copyrighted or vulnerable code, I want to focus more on the Developer Experience.
Searching but faster
AI assistants are usually just search engines in your editor. They don't produce new algorithms or solutions, instead fitting other's work to your specific case.
LLMs have incredible potential as writing aids: I never know how to end an email and getting the machine to write those for me is pure bliss.
But when used as search-engine replacements, I believe they are more an issue than a tool.
Context Matters
Searching on the web is an art. Knowing some Google tricks will make your searches way easier, and discarding machine-generated results just from the results list is becoming extremely necessary.
But even once you find your solution, it's important to vet the authenticity. Is this a blog post? Who wrote it? How long ago? Maybe it's a tutorial instead, made by the library maintainer.
Or maybe it's some step-by-step guide which glosses over unknown details. Context matters! Many times I find a result which looks sort of valid, and then discover that many API functions/endpoints don't exist anymore. Or maybe a guide on how to set up a specific toolchain, which changed so much in just 1 year that the guide makes no sense anymore (cough Android cough) Or maybe the solution itself is not perfect, and somebody left a comment improving it, but it gets skipped by the LLM and you never actually read it.
It could as well be some "eight-hand tutorial", from someone with very limited understanding repeating what they saw in another "seventh-hand tutorial".
Separating the reply from its context removes very important information, which may save some later debugging.
Some very popular libraries may be new and hyped, with good documentations and few releases, but something like Java has so much material written and so many changes over the years that you better make sure which version is the target of the article you're reading!
Skipping parts makes it harder
It may sound very convenient when asking "how to compile my program" to read gcc -o a.out <your_file.c>. But that strips away the learning, and as soon as you want to link in pthreads or math you're back googling.
Spending time learning more than exactly the answer you need will dramatically improve your efficiency down the line, because you will know how it works and how to debug things.
Adding more layers of tooling or libraries increases the project complexity dramatically, and the biggest cost you are going to pay down the line is maintainability.
Learning what you're adopting when you're adopting it is imperative if you plan to also maintain your project, because learning how your middleware library works once you have all the auth handlers hooked and solidified will drive you mad.
Convenience isn't enough of a reason
A superficial point might be that with the time saved by googling, you can try more solutions and see which one works.
This is a very valid approach for quick prototypes, like some backend boilerplate, but I'd argue that using a language/framework with less boilerplate would be cutting the issue at the root, rather than throwing a new tool at it.
If your go-to framework requires you to write a lot of useless lines and configuration to get going, consider trying something with more batteries included: prototyping with flask is incredibly fast, and you can later swap it with FastAPI or (if you really need to get fast) something like axum.
If you often find yourself writing isOdd() or pickRandom() or formatTime() you probably should be using a language with a richer standard library for your prototyping.
Don't make copilot reinvent the wheel for you every time! Very qualified and experienced people already wrote excellent software you can leverage.
I don't think a code assistant should help you prototype, it's a bandaid on an underlying problem, and once you are writing production software, a code assistant cannot be held responsible for its mistakes, do the plumbing yourself!
Am I a Luddite?
Maybe. I really dislike code-assistants because they are trained on public code. There's way more bad code than good code, I really don't trust software by default.
This may sound elitist, but I say it without judgement: just like some art is great and some is average, not all code must be great, but losing the ability to judge and evaluate is not acceptable for me.
I read some articles about how a "modern AI-powered junior engineer" beats a "senior experienced software architect" because it gets it done incredibly faster, but maintenance is weirdly never considered in these articles. I don't need to throw in "AI" to make the same statement: an inexperienced junior engineer could be able to make a proof of concept way faster, ignoring problems and edge cases which will blow in their face later on. An experience software architect may take their time, but will probably be able to identify pain points, and address them early.
Should you use code-assistants?
You tell me, I just hope I convinced you to not trust them blindly and to stop recommending copilot to me (: