這是一個非常有意思的問題，作為一名從業多年的程式設計師，我來回答一下這個問題。

首先，介面是程式設計過程中最為常見的元素，不論是研發級程式設計師還是應用級程式設計師，在日常的程式設計過程中都是離不開介面的。介面可以看成是程式設計過程中連線各種資源的方式，在按角色開發的時代，程式設計師不可能一個人完成所有從硬體到軟體的開發過程，所以如果沒有介面的幫助，整個軟體開發將無法實現規模化發展。

在雲計算技術逐漸普及的當下，介面對於程式設計的意義得到了進一步的體現，現在的介面也進入到了“微介面”時代，以適應大資料時代對於程式設計的要求。所謂的“微介面”是對應於“微服務”的概念，使得程式的呼叫更輕，也更容易實現模組化封裝。當然，微介面的程式設計對於雲計算平臺提出了更高的要求，尤其是對於PaaS的要求。

如果當前的程式設計師無法透過介面來完成資源的整合，那麼程式設計體系將出現巨大的變化，從目前的技術體系結構來看，完全脫離介面進行程式設計是不現實的。也許在未來的人工智慧時代，程式設計師可以只關心業務邏輯，而無需關心各種資源的整合，那個時候也許介面將會以另一種形式來呈現。

程式設計師如果脫離介面進行程式設計將面臨三大障礙，其一是如何完成硬體資源的管理；其二是如何完成各種開發資源的呼叫；其三是如何完成功能的擴充套件。當然，如果沒有介面的支援，這些工作都需要程式設計師從頭開始做，那麼在當前的技術體系結構下，這種開發方式是不可想象的，也並不是“996”能夠解決的問題。

那就只能用匯編從操作暫存器開始一點一點的碼，先碼一個作業系統，再在作業系統上碼應用軟體。不對，彙編也是要呼叫BIOS API的，先得碼一個BIOS。。。

不知道你說的API，是程式語言以為的才算，還是程式語言，如C語言的printf這個標準函式都算。

如果程式語言的標準庫不算的話，那問題可能會更簡單些，只需要閱讀一下各種應用層的協議，行業協議，使用標準庫的函式封裝便是了

如果連標準庫都不算，那隻能從機器程式碼，彙編程式碼作起了，但無可否認，總有大牛會覺得使用機器程式碼編寫麻煩，會整理出彙編的經驗封裝，彙編太苦澀，也會另外更簡單的去封裝和編譯，諸如此類，人類終究是一代疊一代，以儘量簡單的方式做產品，希望我這個回答，你能滿意！