Here are some technologies I can recommend to try. I like to solve some problems with them.
There are many other very good alternatives, but the following options worked reliably and were suitable for most of my use cases.

The timeline below highlights the key milestones of my self-taught beginnings and early developer path up to my diploma.
It not the whole history of my entire professional career.

• Age 14 First Touchpoint: Built initial HTML pages on a mobile phone, driven by a desire to learn beyond the standard IT and office curriculum at school.
• Age 15 Java & Databases: Learned Java and integrated MySQL databases, utilizing forums, technical blogs, and self-study resources.
• Age 16–19: Dual Path Start of a formal German apprenticeship as an electronics technician for energy and building systems.
• Age 16 Automation & Systems: Developed custom Java TeamSpeak bots. Engineered a dynamic banner system by hosting a web server that matched client request IPs with TeamSpeak active sessions to serve personalized real-time statistics. Deployed a Windows Server environment running XAMPP.
• Age 17 Linux & Infrastructure: Transitioned to Linux server environments. Created a Minecraft Spigot survival server with customized mechanics (custom recipes, specialized enchantments, and player utilities) for a community of up to 70 active users. Contributed non-profit code to the web and support infrastructure of startyourserver.com.
• Age 18–19 Web Controls: Designed and developed a PHP-based web administration interface to manage a remote Ubuntu host.
• Age 16–19: Dual Path Completed a formal German apprenticeship as an electronics technician for energy and building systems, which solidified my decision to pivot full-time into software engineering.
• Age 20: Software Engineer Began a formal German apprenticeship in Software Engineering at a hosting provider, graduating with an accelerated diploma. This environment provided deep, hands-on experience across software development, systems administration, DevOps, and hosting infrastructure.

The following selection highlights technologies and architectural patterns I worked with during and immediately following my software engineering diploma.
This list represents key technologies from some of my projects and is not a complete index of the tools, languages, or frameworks I used or I use today.

• Go (Golang): Developed internal tooling and management API services (including projects hosted here on GitHub).
• Node.js / Bun: Built enterprise API services. Migrated runtimes to Bun for performance optimization.
• PHP: Engineered custom frameworks from scratch—implementing dependency injection containerization, routing engines, and templating systems to master core MVC patterns.

• Angular (v16–v22): Developed enterprise-grade single-page applications (SPAs), including internal video platforms featuring advanced permission systems, dynamic dashboards, and resilient upload workflows.

• Kubernetes & Docker: Orchestrated highly available deployments utilizing automated load balancing, zero-downtime rolling updates, and automated Let's Encrypt SSL management.
• Terraform: Defined Infrastructure as Code (IaC) to provision and scale virtual machines on OpenStack for Kubernetes cluster nodes.
• GitLab CI/CD: Built automated documentation generators and CI pipelines.

• Resilient Video API: Developed an API service utilizing OpenStack Swift object storage and PostgreSQL. Implemented robust chunked/partial upload capabilities supporting pause, cancel, and resume operations.
• Real-time IoT Ingestion: Built an API service to ingest photovoltaic metrics and push real-time data to clients via WebSockets.

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- and opencode-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.

My read-only MCP server for fast, easy & securely AI context:
https://github.com/NobleMajo/explorer-mcp