Zu empfehlen ist ein Versionsverwaltungssystem wie Subversion oder Git.
Ansonsten sollte der Code sehr sauber sein, damit er von anderen später gut gelesen werden kann. Einheitliche Codeformatierung; Methoden/Funktionsnamen, die erkennen lassen was die Methode/Funktion tut; Vareablennamen, bei denen man sofort ihre Bedeutung erkennt; Bei komplexeren Vorgängen sollte man dokumentieren.

Wenn du von einem PHP-Skript redest, könntest du voraussetzen, dass mit einem bestimmten Framework programmiert wird - in der Regel gibt es in den Frameworks für das durchführen bestimmter Aktivitäten gewisse Standards. Entsprechend sollte sich der Kollege dann auch dann die Code Guidelines des entsprechenden Frameworks halten. Zur Überprüfung kann man wohl (bin nicht mehr allzu fit in PHP) wahrscheinlich sowas hier nutzen: pear.php.net/package/PHP_CodeSniffer/

Naja, du versuchst dich sehr abstrakt auszudrücken, was auch nur zu sehr allgemeinen oder spekulativen Antworten führt. Beschreibe doch mal konkret was du vor hast.

Wie muss ein Script vom Anfang an programmiert werden, ohne dass jeder Programmierer den ganzen Script zu sehen bekommt?

Naja, man kann mit Closed-Source Bibliotheken arbeiten.
Man programmiert eine Bibliothek (Libraries), deren Quellcode nicht offen ist, sondern nur das compilierte Ergebnis. Die muss man natürlich dokumentieren, so daß jeder die Bibliothek verwenden kann.
Wie so etwas genau aussieht hängt stark von der Programmiersprache ab.

Wie muss ein Script vom Anfang an programmiert werden, ohne dass jeder Programmierer den ganzen Script zu sehen bekommt?

Man kann auch gegen Interface programmieren. Also in einem Interface definierst du quasi die Methoden. Die kannst du dann einem Entwickler zur Verfügung stellen. Zum Testen der Applikation müsstest du ein Implementierung dieses Interface zur Verfügung stellen. Halt nicht mit den konkreten Methoden, sondern mit Dummys, die einfach einen denkbaren Wert zurückgeben.

OK, ich versuche mal zusammen zu tragen was ich bisher verstanden habe.

- Ein AdServer soll programmiert werden.
- Du selbst bist kein Programmierer sondern wirst maximal die Rolle desjenigen übernehmen, der am Programmierten ein paar Einstellungen vornimmt.
- Dir stehen keine vertraunsenswürdigen Programmierer zur verfügung bzw. maximal dem ersten möchtest du veretrauen, dieser wird dir aber nicht auf Dauer zur verfügung stehen.

Sei dir zunächst bewußt, dass Software Pflege braucht. Manchmal ändern sich Anforderungen in Nachhinnein oder es treten ganz einfach Fehler auf. Wenn der ursprüngliche Programmierer weg ist und du den Quelltext keinen anderen Programmierer zeigen willst, dann werden sich diese Probleme nicht lösen.
OK, sagen wir du hast einen Kernmodul der Software (oder des Scripts wie du zu sagen pflegst), auf die nur ausgewählte Programmierer Zugriff haben (aber es wird immer einen geben dem du vertrauen musst, wenn du nicht selbst programmierst). Zusätzlich gibt es noch ein oder mehrere andere Module der Software, für die anderen Programmierer. In diesem Fall muss eine Liste erstellt werden welche Anforderungen zu welchen Breich der Software gehören. Wenn das passiert ist, müssen zwischen diesen Modulen Interfaces deffiniert werden, damit die Module miteinander inteagieren können (wie schon BennyBunny sagte).
Das ist aber ganz schön Overhead und erfordert viel Kommunikation zwischen den Programmierern der einzelnen Module.
Sei dir zudem bewußt, dass du am Anfang des Projektes niemals alle Anforderungen kennst (zumindest laut meiner Erfahrung). Viele "Ach so... daran hab ich ja garnicht gedacht"-Situationen werden eintreten. Deswegen werden an allen Modulen potenziel Veränderungen auftreten.

Die Frage ist auch: Müssen den Teile des Quelltextes vor anderen Programmierern verborgen sein? Wenn es um Sicherheit geht, dann kann ich nur sagen, dass Passwörter und ähnliches sowieso niemals im Sourcecode stehen sollten sondern verschlüsselt in einer Datenbank. Maximal das illegale wiederverwenden des Codes in Konkurenzprojekten kann damit erschwert werden.

Sei dir auch bewußt, dass ein neuer Mitarbeiter immer eine Einarbeitungszeit braucht. Bei komplexer Software dauert das natürlich auch länger. Damit ist das natürlich erheblich ineffizienter.

Das ist ja nichts anderes, als das die Module, von denen ich vorher sprach, die Größe von Klassen haben.

Ich stelle mir das eher schwierig vor.
Programmierer sollten auch die Möglichkeit haben ihren Quellcode zu testen. Dafür brauchen sie letztendlich auch die anderen Klassen. Diese musst du also mindestens als closed-Source zur Verfügung stellen.
Technisch stelle ich mir das zwar theorethisch machbar aber äußerst knifflig vor.
Die Aufgaben berühren in der Regel auch mehre Klassen. Die Programmierer könnten also nur stumpf eine Methode implementiern ohne ihre Verwendung zu überblicken (Muss sie mit null-Werten umgehen können? Wann muss ich Exceptions werfen? etc.). Klar kann man das mit Unit-Tests alles absichern, aber dann kann man die Methode auch oft gleich selbst schreiben (was schneller geht).
Und wie ich schon oben sagte, auch das Design wird sich nachträglich noch häufig ändern müssen. Man kann initial ein UML-Diargramm zeichnen und daraus (noch unimplementierte) Klassen generieren, doch man wird auch diese Klassen und das UML im Nachhinnein noch anpassen müssen.
All das kostet unmengen an Zeit und Zeit ist Geld wie wir alle wissen.

Ach ja, nach meiner Einschätzung bist du mit festeingestellten Programmierern, dennen du vertrauen kannst, deutlich besser bedient, da du dir den Overhead, die ganze Verwaltung, die Einarbeitungszeiten etc. spaarst und viel flexiebler bist. Sie sind auch ansprechbar wenn es Probleme gibt und können dann sogar brauchbare Antworten geben. Sie arbeiten auch schneller und haben bei ihrer Programmierung das ganze System im Hinterkopf (können also mitdenken) was Fehler reduziert. Es bringt mehr Qualität, braucht weniger Zeit und kostet letztendlich auch weniger.

Mit anderen Worten: Ich würde Geld darauf wetten, dass du mit der Horde von Freelancern am Ende nur Ärger hast.