hellerKopf

Genau hier sehe ich auch die Herausforderung. Die hitzige Diskussion, ob KI .... ersetzen kann, vernachlässigt vollkommen den 'Maßstab' nach dem man dies beurteilen kann. Der Junior könnte mir auch alle 20 Punkte zu RAII (nur als Beispiel) aufzählen. Aber auch beim Senior bin ich nicht sicher, ob er alle Punkte berücksichtigt. Und ob KI/LLM alle seine Punkte auch berücksichtigt, muss ich aufwendig nachprüfen.

Das ist ein Punkt, wo ich gerne tiefer gehen will. Verglichen werden kann: Ich fordere die Regeln von einem frisch Ausgebildeten, einem Junior (2 Jahre BE) und einem Senior. Ich nenne die Anforderung genauso in den Anweisungen an die KI. Das Ergebnis sollte sein zu erkennen, auf welchem Level beginnt die KI besser zu sein, als der humane Mitarbeiter. Dann erfolgt das Tuning. Wie muss ich die Anforderung formulieren, damit KI den Junior ersetzt und ab wann ist die KI dem Senior gleich. Ich habe das für zwei Systeme gemacht, die sich untereinander schon geringfügig unterscheiden. Was mir die drei Arten von Mitarbeiter geantwortet hätten und welche Memory-Leak-Rate diese verursachen, versuche ich gerade vor Ort zu ermitteln. Die LLM haben auf "Nutze RAII" wie folgt reagiert: LLM1 LLM2 Übereinstimmung/Ergänzung 1. Ressourcen an Objektlebensdauer binden Ressourcen werden im Konstruktor erworben und im Destruktor freigegeben. ✅ Übereinstimmung 2. Kein manuelles new/delete im Anwendungscode Vermeide new/delete; nutze Smart Pointer oder Container. ✅ Übereinstimmung 3. Kein manuelles malloc/free in modernem C++ Kein manuelles Speichermanagement; nutze Standardbibliothek. ✅ Übereinstimmung 4. Destruktor gibt die Ressource zuverlässig frei Destruktor gibt Ressourcen frei, auch bei Ausnahmen. ✅ Übereinstimmung 5. Destruktoren dürfen keine Exceptions werfen Nicht explizit erwähnt, aber implizit durch Ausnahmesicherheit abgedeckt. ⚠️ Ergänzung: 6. Ressourcenbesitz eindeutig modellieren Konsistente Ownership-Semantik (z. B. unique_ptr, shared_ptr). ✅ Übereinstimmung 7. Rule of Zero bevorzugen Nutzung von Standardtypen, die Ressourcen selbst verwalten. ✅ Übereinstimmung 8. Falls eigene Ressourcenklasse nötig: Rule of Five beachten Eigenen RAII-Wrapper erstellen, inkl. Move-Semantik. ✅ Übereinstimmung (implizit durch Move-Semantik) 9. Kopierbarkeit bewusst entscheiden Move-Semantik für Ownership-Übertragung; Kopieren oft gelöscht. ✅ Übereinstimmung 10. Locks per RAII verwalten Nutzung von std::lock_guard, std::scoped_lock. ✅ Übereinstimmung 11. Dateien per RAII verwalten Nutzung von std::fstream oder eigenen Wrappern. ✅ Übereinstimmung 12. Transaktionen und Rollbacks absichern Nicht explizit erwähnt. ❌ Fehlend 13. Frühe Returns müssen sicher sein RAII stellt sicher, dass Ressourcen auch bei return/throw freigegeben werden. ✅ Übereinstimmung (implizit) 14. Keine „Cleanup“-Blöcke am Funktionsende Aufräumlogik gehört in Destruktoren. ✅ Übereinstimmung 15. Rohpointer nur als beobachtende Pointer verwenden Rohe Zeiger nur für Nicht-Ownership; Ownership durch RAII-Typen. ✅ Übereinstimmung 16. Scope bewusst klein halten Nicht explizit erwähnt. ⚠️ Ergänzung: Wichtiger Punkt, 17. Initialisierung vollständig und gültig machen Konstruktoren sollten Objekte in gültigen Zustand versetzen. ✅ Übereinstimmung (implizit) 18. Keine halbgültigen Objekte bevorzugen Keine init()-Methoden; Objekte sollten nach Konstruktion gültig sein. ✅ Übereinstimmung (implizit) 19. Qt-spezifisch: Ownership beachten Qt’s Eltern-Kind-Mechanismus und QScopedPointer/QSharedPointer. ✅ Übereinstimmung 20. Qt-spezifisch: Smart Pointer passend wählen Nutzung von std::unique_ptr, QSharedPointer etc. ✅ Übereinstimmung

Was erwartest du genau zu erfahren? Die Grenzen hängen davon ab, wo du die Grenzen ziehst. Ein aussagekräftiger Vergleich zwischen KI-generierter und menschlicher Softwareentwicklung erfordert: Quantitative Metriken (z. B. Entwicklungszeit, Fehlerrate, Testabdeckung) für objektive Daten. Qualitative Metriken (z. B. Code-Design, Entwicklerzufriedenheit) für subjektive Bewertungen. Langfristige Studien zur Bewertung von Wartbarkeit und Skalierbarkeit und kontextspezifische Analysen (z. B. Projektgröße, Teamdynamik, Domänenkomplexität). Mir scheinen bestimmte Beobachtungen sehr nützlich zu sein, um zu einer Bewertung zu kommen. Die Qualität der KI-Ausgabe hängt stark von den Prompt-Guardrails ab. Testet du, welche Formulierungen mehr oder weniger gut arbeiten? Wenn sowas wie Best-Practice-to-generate herauskommt, würde ich das unterstützen.

Da findet man was bei einigen IHK, z.B.: https://www.ihk.de/berlin/ausbildung/infos-fuer-ausbildungsbetriebe/der-betriebliche-ausbildungsplan-5724006

Hattest du einen Kurs zur Erlangung des AEVO Scheins? In den Schulungsunterlagen dazu ist der Prozess der Umsetzung ganz gut beschrieben

Aus den bisherigen Beiträgen erkenne ich : "Datev macht krank!"

Am Anfang war der Dark Mode. 14 Zoll - Amber auf Schwarz.

Wahrscheinlich E6 (ca. 3.600–3.800 € brutto) und Aufstieg in E7 nach 2–3 Jahren mit erweiterter Verantwortung Details auf chemie-tarif.de

Das kann keine rechtsverbindliche Entscheidung sein. Was ist genau der Verweigerungsgrund? Ich habe schon ältere Teilnehmer gesehen, allerdings oft über die Rentenversicherung.

Das ist auch richtig, weil man so den Stil und die Formulierungen kennenlernt. Aber wer sagt: "Es kommen nur Fragen, die schon mal da waren?" Auch die sind nützlich, um Schwerpunkte zu erkennen. Was aber drankommen kann, ist alles aus dem Prüfungskatalog. Es ist so. Wie im folgenden Beispiel: Gelehrt wird, dass in einer Trommel 49 Kugeln sind und bei jeder Prüfung werden 6 ausgewählt. Schau dir alte Sendungen mit Lottozahlenziehungen an. Du lernst, wie eine Ziehung abläuft. Es gibt auch Listen, welche Zahlen, wie oft in der Vergangenheit gezogen wurden. Da gibt es also Favoriten, die sich durchsetzen können. Wer würde denn jetzt verlangen, dass nur Zahlen aus der Vergangenheit in der nächsten Runde einen Gewinn bringen? Die Gleichsetzung von Abschlussprüfung und Zufallszahlen ist Absicht! Ich sehe den Unterschied nur darin, dass bei der Erstellung der Fragen der Faktor eine zufällige Gruppe von Menschen ist und kein elastischer Stoß.

Auch gut, solange es in einem Lernfeld gemacht wird, dass alle Umschüler hören.

Das ist ein derartiger Verstoß gegen die Ausbildungsordnung und den Rahmenplan, dass eine Beschwerde beim Bildungs- und Kostenträger geben muss. Wenn nicht darauf geachtet wird, dass die vertraglichen Zusagen eingehalten werden, kann man dafür nicht die Abschlussprüfung verantwortlich machen.

Ich nehme mal den so oft jetzt beklagten Round Robin. Irgendwann in Einführung Programmieren, kommt man zu den Rechenarten und den dazugehörigen Operatoren. Klar, alle kennen + - * /. Und dann ist da noch % ( modulo ) was macht denn for( i= 0; i < 100; i++) { Robin = i % 5; } und Robin wird dann nacheinander 0, 1, 2, 3, 4 und wieder 0, 1, 2, 3, 4 usw bis i = 100 Und Robin kann an vielen Stellen sinnvoll verwendet werden. Oft als Index. Das ist Inhalt seit 1970 er. Wenn sowas nicht vermittelt wird, dann würde ich Geld zurückverlangen!!!

Was würde es denn bringen, wenn hier nur die aktuellen Prüflinge sich gegenseitig etwas vorjammern? Die Erfahrenen bringen zumeist die Verwunderung zum Ausdruck, dass anscheinend die Messlatte in der Ausbildung immer mehr nach unten verschoben wird. Ich sage ja nicht, Dinge wären easy, weil wir sie nach 30 Jahren kennen. Ich sage, das hätte man wissen sollen, weil ich es schon in meiner Ausbildung so gelernt habe oder ich es selber heute vermittle.

wie in RAID ? oder etwa wirklich array[]?