Yes, you still need to know fundamentals even with AI

' data-copy-icon='<br>' id=copy-cfg style=display:none><br>Yes, you still need to know fundamentals even with AI<br>Aug 11, 2026<br>#software-engineering

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<br>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.<br>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.<br>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<br>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.<br>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<br>Writing Dockerfile is an arcane art - that I agree with. alpine image used to be...