...unless you understand the languages and all the libraries, frameworks, and tooling of what you're using.

Using AI for micro-tasks can be helpful, but remember: it's only a TOOL like a very complex calculator that operates on statistics. It's not an intelligent, critically thinking software engineer.

While you might create something functional, there's a significant risk of building something that backfires. This could happen by the AI misrepresenting information or inadvertently exposing sensitive data.

If your project isn't something the AI has encountered countless times on the internet (like a to-do app, Hello World, or a calculator), then anything novel you invent is also new to the AI. It doesn't possess the foresight of a human developer; instead, it only estimates statistics up to the next immediate milestone.

Make yourself truly aware of the above before reading on, as it will improve your prompts and your understanding of what you're actually working with: a Tool.

The following tips are more for "Cursor"-like development environments. Here are my tips you are here for:

Create a powerful README.md file containing a general description, a simple configuration guide, a user story, and an explanation of the problem that your app is designed to solve. Also, provide a link to a more detailed configuration guide.

This will make you more aware of your app and enable you to quickly provide AI the context it will probably need.

Especially if you're using a "Cursor"-like development environment, an e2e-script or e2e-Makefile-target that the AI can execute itself is very practical. This allows the AI to feed itself context and to relatively autonomously repair or fix individual parts. However, this does not replace human involvement.

ERROR == STOP: If one step has problems or errors the script should stop! This makes the AI automaticly address and fix it. The AI should always execute this exact E2E-script without taking any shortcuts and correcting any errors that occur. However, for complex or important design decisions, it should ask the user for guidance.

The E2E script must at least perform the following actions in a language-appropriate order:

• Load dependencies
• Build the app
• Run unit tests
• Format the codebase
• Run a linter.
• Execute the app
• Test the app against example data

If used linter cannot perform one of the following tasks, an additional tool should be used or programmed to handle it:

• Warn about excessively large files (e.g., max. 240 KB)
• Warn about excessively large function bodies (e.g., 60 lines)
• Warn about unused variables.
• Warn about unused functions.
• Warn about unused files.

Here are some commands and tools you could use:

• bun i --frozen-lockfile
• bun run tsc
• bun test
• bun x prettier --write src eslint.config.mts
• bun x tsr -r src/main.ts
• eslint --max-warnings=0 || ( bun x tsc eslint.config.mts --noEmit --esModuleInterop --module ESNext --target ESNext --moduleResolution bundler --lib ESNext && exit 1 ) (shows eslint config issues directly and doesn't allow any warnings)
• After that, a test environment can be prepared and then tested.

If you have a specific problem in one place, look at it and solve it! If you want something specific, implement it!

However, for unorganized problems, you can write generic prompts that a "Cursor"-like development environment can execute.

Here are a few short versions:

• "find code snippets that look like and fix them like that"
• "implement things written like using the following design pattern: x"
• "split the huge function into sub-functions"
• "refactor all functions so that the main logic is at the first level and not nested in scopes"

You are responsible for the changes and the code that the AI spits out. In the end, you can't blame big companies. If its just a small error, everything is fine and you can fix it or, if the AI can do it, have it fixed.

But if data is lost, data can be manipulated, or a system fails, its your fault! AI is not an excuse, just a TOOL. You wouldnt say:

• "my button was stuck",
• "my calculator calculated it wrong",
• or "the linter and tests didnt tell me".

If everyone followed this rule, no one would have any problems with AI as tool. But unfortunately even I deviate from it in some vibe coding sessions or think to myself when scrolling through code "its fine", only because its easier.

AI can misinterpret foreign documents and texts, failing to recognise context or user prompts.

At best, the AI will use a different tool or implement code slightly differently.

In the worst-case scenario, it misinterprets context loaded from the web or file system as a user prompt. A foreign actor (i.e. a hacker) could inject context that waits for a few user interactions before prompting the user to execute a malicious command. Even worse, the AI could execute some code itself.

AI has an infinite number of vulnerabilities that can never all be resolved, and those that can be fixed are difficult to address. This makes it all the more important to pay attention to where the AI obtains its data, watch out for any strange behaviour and question its actions.

1. Tell the AI why it should do something and what your expected result is.
2. If possible, give the AI access to test itself so you don't have to relay context.
3. Give the AI precise whitelist limitations that tell it which files it is allowed to edit.

0. Know your stuff.

1. Document Thoroughly.

2. An E2E script can autonomously check the codebase.

3. You are the developer; you make it happen! Your tool (the AI) is only good for specific problems.

4. You are responsible!

5. Pay close attention to the AIs behaviour and context.

6. Focus on providing the AI some background context.