Wie ich aus einer unfertigen Idee ein echtes KI-Produkt schuf

Ein halbes Jahr lag das Projekt in der Schublade – bis der GitHub Finish-Up-A-Thon-Challenge den entscheidenden Anstoß gab. Die Idee klang vielversprechend: ein KI-Assistent speziell für die Bauplanung, der Nutzern bei der Materialschätzung, Dokumentenanalyse und frühen Entscheidungsfindung helfen sollte. Doch aus dem Prototyp wurde nie ein fertiges Produkt. Bis heute.

Die ursprüngliche Vision von BuildGenAI war klar: Nicht noch ein generischer Chatbot, sondern ein Werkzeug, das Bauherren, Handwerker und Planer konkret unterstützt. Die Herausforderung lag nicht in der Technologie, sondern in der Umsetzung. Wie schafft man es, aus einer vagen Idee ein Produkt zu formen, das tatsächlich nützlich ist? Die Wiederbelebung des Projekts wurde zur Übung in Disziplin – und zeigte, warum „Fertigstellen“ oft schwerer ist als „Anfangen“.

Vom Prototypen zum nutzbaren Werkzeug

Die erste Version von BuildGenAI war ein klassischer Fall eines unvollendeten Experiments. Der Code lief, aber die Benutzerführung war holprig, die Ausgaben unstrukturiert und die Zielgruppe unklar. Der Prototyp fühlte sich an wie ein technisches Spielzeug – nicht wie ein Werkzeug, das jemand im echten Berufsalltag nutzen würde. Das Problem lag nicht in der KI selbst, sondern in der Frage: Wofür ist sie eigentlich da?

Die Überarbeitung begann mit einer einfachen, aber entscheidenden Frage: Welches konkrete Problem löst das Produkt für welche Nutzergruppe? Statt allgemeiner Bauchgefühls-Fragen sollte BuildGenAI nun gezielt Bauherren bei der frühen Planungsphase unterstützen. Die Nutzerführung wurde gestrafft, die Ausgabeformatierung vereinfacht und die Schnittstelle intuitiver gestaltet. Statt langer Textwüsten liefert die KI nun strukturierte Listen mit Materialbedarf, Kostenschätzungen und ersten Konformitätshinweisen – alles in einem Format, das sich direkt in Excel oder Planungssoftware übernehmen lässt.

Ein zentraler Schritt war die Definition klarer Use Cases:

• - Materialschätzung: Der Nutzer lädt einen Grundriss hoch, und die KI berechnet den ungefähren Bedarf an Ziegeln, Beton und anderen Baumaterialien.
• - Kostenübersicht: Basierend auf regionalen Preisen gibt das Tool eine grobe Kostenschätzung für das geplante Projekt aus.
• - Dokumentenanalyse: Baupläne oder Ausschreibungen werden auf Schlüsselbegriffe wie „Brandschutz“ oder „Statik“ durchsucht, um potenzielle Risiken früh zu erkennen.
• - Regelwerk-Hinweise: Die KI verweist auf relevante DIN-Normen oder lokale Bauvorschriften, die für das geplante Vorhaben gelten.

Diese Fokussierung machte den Unterschied: Statt einer unübersichtlichen Sammlung von KI-Funktionen entstand ein Werkzeug mit klarer Identität – ein Bau-KI-Assistent, der gezielt bei der frühen Planungsphase hilft.

Der Einfluss von GitHub Copilot auf die Entwicklung

Die Wiederbelebung von BuildGenAI wäre ohne moderne Entwicklungswerkzeuge wie GitHub Copilot deutlich aufwendiger gewesen. Der KI-gestützte Assistent half vor allem bei drei zentralen Aufgaben:

• Code-Vervollständigung: Wiederkehrende Boilerplate-Code-Teile – etwa für die Verarbeitung von PDF-Dokumenten oder die Formatierung von Bauplänen – wurden durch Copilot deutlich schneller implementiert. Das sparte Zeit und reduzierte Fehler.

• Dokumentation und Kommentare: Viele Funktionen mussten nachträglich dokumentiert werden. Copilot generierte nicht nur Code-Snippets, sondern auch passende Docstrings und README-Einträge, was die Wartbarkeit erhöhte.

• Fehlerbehebung: Bei der Integration externer APIs, etwa für die Materialpreisdatenbank, half Copilot, häufige Fehlerquellen wie falsche API-Endpunkte oder veraltete Bibliotheken früh zu erkennen.

Ein konkretes Beispiel: Die ursprüngliche Version von BuildGenAI nutzte eine selbstgebaute PDF-Parser-Funktion, die oft abstürzte. Copilot schlug eine Alternative vor, die auf der Bibliothek pdfminer.six basierte – stabiler, besser dokumentiert und einfacher zu warten. Die Zeitersparnis lag bei geschätzten 30 bis 40 Stunden.

Trotz der Vorteile blieb der Entwickler kritisch: Copilot ist ein Werkzeug, kein Zauberstab. Entscheidend war, die generierten Vorschläge zu verstehen, zu testen und an die eigenen Anforderungen anzupassen. Die KI half beim Schreiben, nicht beim Denken.

Die größten Herausforderungen beim Fertigstellen

Ein Projekt „fertigzustellen“ klingt einfach – doch in der Praxis geht es oft um schmerzhafte Entscheidungen. Drei zentrale Hürden prägten die Wiederbelebung von BuildGenAI:

1. Die Illusion der Vollständigkeit

Viele Entwickler neigen dazu, ein Projekt als „fertig“ zu betrachten, sobald der Hauptcode läuft. Doch ein wirklich nutzbares Produkt braucht mehr: eine klare Benutzerführung, verständliche Ausgaben und eine kohärente Story. So musste etwa die Ausgabe der KI-Ergebnisse komplett überarbeitet werden. Statt langer Fließtexte liefert BuildGenAI nun strukturierte JSON-Daten, die sich leicht in andere Tools importieren lassen:

{
  "materials": [
    {"name": "Ziegel", "quantity": 1200, "unit": "Stück", "estimated_price": 480},
    {"name": "Beton", "quantity": 5, "unit": "m³", "estimated_price": 850}
  ],
  "compliance_notes": ["DIN 4102 Brandschutz beachten", "Statik prüfen lassen"]
}

Diese Änderung machte den Unterschied zwischen einem Prototypen und einem tatsächlichen Werkzeug aus.

2. Die Balance zwischen Feature-Reichtum und Benutzerfreundlichkeit

Jeder Entwickler kennt das: Man will „noch schnell“ eine neue Funktion einbauen. Doch beim Fertigstellen geht es genau darum, nicht alles zu tun. Statt dutzender halbfertiger Features konzentrierte sich der Autor auf die Kernfunktionen, die für die Zielgruppe wirklich relevant sind. Alles andere wurde gestrichen oder verschoben.

3. Die psychologische Hürde

Ein unvollendetes Projekt wirkt oft wie ein Berg an Arbeit – besonders, wenn man zurückblickt und sieht, wie viel noch fehlt. Der GitHub Finish-Up-A-Thon-Challenge gab dem Entwickler den entscheidenden Motivationsschub. Plötzlich ging es nicht mehr um Perfektion, sondern um Fortschritt: Was kann ich in den nächsten zwei Wochen tatsächlich abschließen? Die Antwort lag nicht im Hinzufügen, sondern im Kürzen.

Fazit: Warum „Fertigstellen“ wichtiger ist als „Anfangen“

BuildGenAI ist heute ein anderes Projekt als vor sechs Monaten. Es ist kein Proof-of-Concept mehr, sondern ein Werkzeug mit klarer Zielgruppe und definierten Use Cases. Die größten Lektionen aus der Wiederbelebung waren:

• - Fokus schlägt Features: Lieber weniger Funktionen, die wirklich funktionieren, als dutzende halbfertige Ideen.
• - Benutzerführung ist Code: Ein gutes Produkt entsteht nicht nur im Backend, sondern in der Art, wie Nutzer mit ihm interagieren.
• - Fertigstellen ist eine Entscheidung: Es geht nicht darum, alles perfekt zu machen, sondern darum, zu entscheiden, was wirklich zählt.

Die Erfahrung zeigt: Die meisten Ideen scheitern nicht am fehlenden Know-how, sondern am fehlenden Willen, sie tatsächlich abzuschließen. Der GitHub Finish-Up-A-Thon-Challenge war dafür der perfekte Anstoß – und BuildGenAI ist nur der Anfang. Der nächste Schritt? Die Integration von Echtzeit-Baupreisdaten und die Zusammenarbeit mit lokalen Handwerkern, um die Schätzungen noch präziser zu machen.