Yes, you still need to know fundamentals even with AI

Coding with AI gets stuff done faster. For some areas where I understand how things work but never applied it before, AI can help me realize it, which is great. The rate at which I crank out personal utilities has skyrocketed.

What I've found is that I always have to manually manage a project's folder structure because AI can never get it right, even for very simple stuff. It's especially worse with READMEs produced by AI - it's too verbose and mostly it doesn't provide the intent.

AI is also not omnipresent, contrary to what some people might believe. AI can and does make mistakes. You can do a prompt injection attack where you hide a text from human readers, but AI can see and will comply with it, even when it doesn't make sense. This approach is very effective for catching people cheating with AI.

Since AI is a probability machine (otherwise it wouldn't need a massive amount of training data), some outputs might not contain all the relevant information unless you explicitly include it in the prompt.

When people say they don't need to employ people now because AI can replace them - there's a grain of truth in that. If your job is something AI can do, and it doesn't make too many mistakes and is cheaper to operate, it's more economical to use AI. Which means, if people can do something AI can't do, they are going to be irreplaceable.

These are common themes I've heard people use because they were suggested by AI, and I love debunking why you still need to know the fundamentals, because it's literally staring at you the whole time if you know where to look.

Use client to talk to database

Some database providers provide an SDK you can use to do CRUD. It's possible to embed the API key on the client (frontend, mobile app, etc.). While it's convenient and can let you get by without having a dedicated backend, it can pose a lot of security risks.

Depends on how you configure the API key, but assuming the key can read and write, an attacker can generate a lot of write requests and fill up your database storage. The database provider probably has rate-limiting built-in, but an attacker can always use a proxy farm to rotate my IP, or use a query that writes a lot of generated data to the same effect.

But if you ask AI, this is what it will tell you:

"For database provider that have sdk you can use to talk to it via API, is it safe to use at frontend."

Yes — sometimes. A database SDK can be used safely from the frontend only if the provider is designed for direct client access and you configure authorization correctly.

The key rule is: anything shipped to the frontend should be treated as public. Users can inspect your JavaScript, extract API keys, modify requests, and call the API outside your app.

AI does not provide attack vectors, and it's understandable if their goal is to not provide ideas as to which attacks are possible.

You can look more into this, but mostly the recommended fix is to set row level security, but it would be tied to this database provider - and you are locked in. In the future when you want to migrate away from this provider, by that point a lot of logic would be tightly coupled with the provider, making it very hard to do a clean break. It's not a bad thing, but planning for the eventual break should be in the back of your mind. Even when you don't need to, there's the question of operating cost and break-even point, and that's when you have to evaluate other options.

Use noSQL instead of SQL database

Database type has a large impact on application performance and its stability in the long run. noSQL can make your API faster, but often once it's been in use for a few years, the data model would expand, and downstream or neighboring applications are going to have a hard time from the schema change. But noSQL engines might not have a concept of a schema, which means you are on your own if upstream (read: this API that uses noSQL as a database) changes the schema. Data engineers everywhere have experienced this, and the fix is either keep patching the pipelines and other services so things don't break, or refactor everything to use SQL database, but it will take more time and money.

Asking AI:

"API want database to be serverless. I'm on $cloudProvider, which db should I use"

If you don't already know that you need relational SQL, I'd use $cloudVendorNoSQLOffering On-Demand. $cloudProvider itself describes on-demand mode as its serverless option and recommends it for modern serverless apps that may start small and scale dramatically.

AI can break down pros and cons of noSQL vs. SQL, but it does not elaborate on long-term effects or common pitfalls you'll encounter in a few years.

Use alpine image for final container image layer

Writing Dockerfile is an arcane art - that I agree with. alpine image used to be recommended for the final layer due to its small footprint. However, alpine image still contains a shell, and insecure services might expose a shell access - in turn allowing attackers to escalate the privileges and take control of your infrastructure.

To prevent this, distroless image can be used. The shell is intentionally stripped away. If there's no shell, you can't run commands if the app is exposed. Read more here.

Ask AI and it still recommends alpine image:

"Create dockerfile for production app in golang"

FROM golang:1.25-alpine AS builder
...

FROM alpine:3.22
...

Which isn't exactly great if you want to ramp up security.

Use SSD for kubernetes and don't apply other optimizations

Kubernetes writes a lot to storage. On some edge devices that use SD cards, it is correct that replacing them with SSDs will make it take longer for you to replace the storage.

But there's a storage trick - you can set k3s (a light k8s distribution optimized for edge devices) to store pods and containers log in RAM. It won't touch your disk at all, and this can extend the lifespan of your storage by a lot.

AI can point you to using SSDs which have more write cycles compared to SD cards, but it's not the whole story.

"Run kubernetes on raspberry pi"

A Raspberry Pi is a good fit for a K3s cluster. K3s is a fully conformant Kubernetes distribution designed for resource-constrained environments and supports arm64/aarch64, making it much easier to run on Pis than assembling a standard kubeadm cluster.

For a homelab, I'd use an external USB SSD if possible; K3s specifically recommends SSD storage on Raspberry Pi because Kubernetes datastore writes can wear out SD cards.

AI can help you do more things, but you have to be the one in control. The more you can be explicit, the better AI responses will be. Otherwise if you blindly trust AI, who's the one acting as the final layer between AI and production? If things are well, I'm happy for you. But if things go south, who's the one responsible?

Note: Chat model is GPT-5.6 Sol on 2026-08-11