-
🧠 Mindset:
Do mistakes, fix mistakes | Balance DRY <-> KISS | Think like the end user - 💼 Projects: Check out my repos & drop a 🌟
- 🔔 Following me is FREE... 😅
- 💬 Contact: My selfmade linktree
- 🤔 Ask me about: TypeScript, Go, Docker, DevOps, GitHub, Bun.js, Node.js, Web, CLI, or my repos...
🔮 Tech Tips
Here are some technologies I can recommend to try.
I have tried and could recommended many more:
📈 Github stats
With this summary of statistics I want to show you how meaningless they are.I really like this animation: 😊👍 This kind of statistic always seems useless and meaningless to me, as the person may not even use GitHub, may not publish anything, or may have a full-time job in parallel: These trophies are even more meaningless because they hide the value of the above statistics:
❗ Vibe coding guide
(or click here)
...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 merely a tool 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.
The E2E script must 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 the 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 (Example: max. 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 "
- "implement things written like using the following design pattern: "
- "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"
- Tell the AI why it should do something and what your expected result is.
- If possible, give the AI access to test itself so you don't have to relay context.
- Give the AI precise whitelist limitations that tell it which files it is allowed to edit.
-
Know your stuff.
-
Document Thoroughly.
-
An E2E script can autonomously check the codebase.
-
You are the developer; you make it happen! Your tool (the AI) is only good for specific problems.
-
Focus on providing good AI context.