У подкасті Confluent Developer інженер Confluent і відомий Java‑та open source‑розробник Гуннар Мерлінг розповів про Hardwood — новий Java‑рушій для читання й у перспективі запису файлів Apache Parquet. Проєкт цікавий не лише як технологія роботи з колонковим форматом, а й як експеримент: це перший для Мерлінга «AI‑first» софт, де штучний інтелект інтегрований у процес розробки з першого дня. Паралельно Hardwood демонструє нетиповий для Java підхід до роботи з S3 — без AWS SDK, на базі вбудованого HTTP‑клієнта — і готується до інтеграції з Apache Flink.
«Built with AI, not by AI»: як виглядає AI‑first розробка на практиці
Hardwood став для Мерлінга першим по‑справжньому «важким» проєктом, де AI не просто допоміжний інструмент, а ключовий елемент робочого процесу. Він прямо описує його як AI‑first: штучний інтелект залучений практично до всіх етапів написання коду.
За власною оцінкою розробника, близько 95% коду Hardwood створено за участі AI‑асистента. Це не означає, що модель самостійно генерує репозиторій у «чорному ящику». Мерлінг підкреслює принципову різницю між «побудовано з AI» і «побудовано AI»: кожен фрагмент коду, який потрапляє до проєкту, проходить людський перегляд і відбір.
Це важливий нюанс у дискусії про «агентну розробку» й автономних код‑агентів. У Hardwood AI виступає радше як надпотужний pair programmer, а не як незалежний автор. Мерлінг використовує моделі для генерації реалізацій, адаптації до специфікацій, перетворення API, але зберігає за собою роль остаточного редактора, який:
- перевіряє відповідність коду задуму й специфікації;
- контролює архітектурні рішення;
- слідкує за стилем, читабельністю та узгодженістю з рештою бази.
Такий підхід дозволяє поєднати швидкість, яку дає AI, із відповідальністю й контекстом, які поки що залишаються суто людською зоною.
Власні «скіли» для AI: як Hardwood формалізує стандарти в Claude.md
Щоб AI‑асистент не просто генерував «якийсь» код, а працював у руслі конкретних стандартів Hardwood, Мерлінг використовує конфігураційний файл Claude.md і власні «скіли» (custom skills).
Ідея проста: замість того, щоб щоразу пояснювати моделі, як саме тут прийнято писати код, оформлювати тести чи робити рев’ю, ці правила формалізуються один раз у конфігурації. Далі AI працює в заданих рамках.
У такій конфігурації можна зафіксувати:
- вимоги до стилю коду й форматування;
- конвенції щодо іменування класів, методів, пакетів;
- підхід до обробки помилок;
- структуру тестів і очікуваний рівень покриття;
- правила для коментарів, Javadoc, публічних API.
Фактично Claude.md перетворюється на «вбудований гайдлайн проєкту» для моделі. Це зменшує розрив між тим, як пише людина, і тим, що генерує AI, і робить результат більш передбачуваним. Для проєкту на кшталт Hardwood, де важливі й продуктивність, і акуратна робота з бінарними форматами, це критично: випадкові стилістичні чи архітектурні «зигзаги» від моделі могли б швидко перетворити кодову базу на хаос.
Такий підхід показує, як AI‑розробка поступово переходить від «одноразових підказок у IDE» до системного налаштування середовища, де модель є повноцінним учасником процесу з чітко визначеними правилами гри.
S3 без AWS SDK: чому Hardwood покладається на вбудований HTTP‑клієнт Java
Окрема лінія в дизайні Hardwood — робота з об’єктним сховищем, насамперед S3. Типовий Java‑проєкт, який читає Parquet із S3, майже автоматично тягне за собою AWS SDK. Це зручно, але дорого в сенсі залежностей: SDK приносить із собою значний обсяг додаткових бібліотек, які розростаються транзитивно.
Hardwood свідомо йде іншим шляхом. Для доступу до S3 він використовує вбудований HTTP‑клієнт, який з’явився в Java 11. Цей клієнт достатньо зрілий, підтримує HTTP/2, асинхронність і, що важливо для Parquet, дозволяє робити range‑запити — читати лише окремі ділянки файлу.
Для колонкового формату це ключова можливість. Parquet‑файли часто зберігаються в S3, і замість того, щоб завантажувати весь об’єкт, можна:
- прочитати службові структури й статистику;
- визначити, які блоки й сторінки потрібні для конкретного запиту;
- зробити кілька точкових HTTP range‑запитів до потрібних байтових діапазонів.
Це різко зменшує обсяг I/O і прискорює обробку, особливо на великих наборах даних. Вбудований HTTP‑клієнт Java повністю покриває цей сценарій, тож потреби в повноцінному AWS SDK саме для читання байтових діапазонів немає.
Такий вибір добре лягає в загальну філософію Hardwood: за замовчуванням — нуль залежностей, а все, що можна зробити силами стандартної бібліотеки, робиться саме так.
Власна реалізація підпису запитів AWS: коли «переписати» стає дешевше, ніж «підключити»
Є одна деталь, без якої прямий HTTP‑доступ до S3 не працює: підписування запитів. AWS використовує власний алгоритм підпису (наприклад, Signature Version 4), і клієнт має правильно сформувати заголовки, canonical request, string to sign і підпис на основі секретних ключів.
У звичайному сценарії це ще одна причина підключити AWS SDK: він «із коробки» вміє підписувати запити, і розробнику не потрібно занурюватися в деталі. Мерлінг визнає, що раніше навряд чи взявся б реалізовувати цей алгоритм самостійно: легко припуститися помилки, а специфікація досить прискіплива.
Однак у випадку Hardwood ситуація інша. Алгоритм підпису AWS добре задокументований, до нього існує офіційний тестовий набір. У поєднанні з сучасними LLM‑інструментами це змінює баланс «купити чи зробити»:
- модель може згенерувати початкову реалізацію за специфікацією;
- тестовий набір AWS дозволяє автоматично перевірити коректність;
- розробник залишається в ролі рецензента, який звіряє код зі спеком і тестами.
У результаті Hardwood реалізує підписування запитів самостійно, не покладаючись на AWS SDK. Це знову ж таки дозволяє уникнути великого дерева транзитивних залежностей, але без компромісів щодо коректності: поведінка перевіряється проти офіційного тест‑кіта.
Цей приклад добре ілюструє, як поява AI‑асистентів змінює межу того, що «має сенс» реалізовувати власними силами. Те, що раніше виглядало як надто ризикований або трудомісткий шматок низькорівневої роботи, тепер стає досяжним за прийнятний час — за умови, що людина зберігає контроль і валідує результат.
Де AI і «самопис» закінчуються: опційний модуль AWS auth та інші компроміси
Втім, навіть із AI‑асистентом Мерлінг не намагається переписати абсолютно все. У випадку автентифікації до AWS він проводить чітку межу.
Підпис запитів — це одна, відносно стабільна специфікація з чіткими тестами. А от способів автентифікації в AWS набагато більше: статичні ключі, IAM‑ролі, ролі, прив’язані до EC2‑інстансів, тимчасові токени, різні провайдери облікових даних. Цей простір відкритий, розвивається й може змінюватися з боку AWS у будь‑який момент.
Реалізовувати всю цю палітру механізмів із нуля в межах Hardwood означало б:
- постійно стежити за оновленнями AWS;
- підтримувати складну й чутливу до безпеки логіку;
- дублювати те, що вже надійно реалізовано в офіційних бібліотеках.
Тут Мерлінг робить інший вибір: для сценаріїв, де потрібна IAM‑автентифікація, Hardwood пропонує окремий опційний модуль AWS auth. Якщо застосунку потрібні такі можливості, він може підключити цей модуль і отримати інтеграцію з існуючою інфраструктурою AWS‑ідентичностей.
Ключовий момент у тому, що це саме опція, а не обов’язкова частина ядра. Базовий Hardwood залишається максимально «легким», а складніші сценарії автентифікації виносяться в додатковий шар, який підключається лише за потреби.
Такий підхід повторюється й в інших місцях. Наприклад, Parquet підтримує низку алгоритмів стиснення. Переписувати Gzip чи інші компресори з нуля немає сенсу, і Hardwood цього не робить. Натомість бібліотеки стиснення розглядаються як опційні залежності: якщо файли використовують певний формат стиснення, застосунок додає відповідну бібліотеку для декомпресії. Якщо ні — ці залежності просто не потрібні.
У підсумку формується чітка модель: ядро Hardwood за замовчуванням не має зовнішніх залежностей, а все додаткове — автентифікація, конкретні алгоритми стиснення — підключається модульно, лише коли це реально потрібно.
Майбутня інтеграція з Apache Flink: як Hardwood готується до екосистеми
Hardwood не задумувався як ізольована утиліта. У довгостроковій перспективі проєкт має стати частиною ширшої екосистеми обробки даних на Java, і одним із ключових напрямів тут є Apache Flink.
План Мерлінга — інтегрувати Hardwood із Flink, коли рушій буде стабільно підтримувати як читання, так і запис Parquet‑файлів. Для Flink, який широко використовується для потокової та батч‑аналітики, ефективний Parquet‑рушій із мінімальними залежностями може стати привабливою альтернативою існуючим рішенням.
Щоб така інтеграція була життєздатною, Hardwood має довести сумісність із «канонічною» реалізацією Parquet. Для цього використовуються два підходи.
По‑перше, проєкт перевіряє себе на тестових файлах Parquet, які публікуються в основному репозиторії Apache Parquet. Це дозволяє переконатися, що Hardwood коректно читає різні варіанти файлів, типи даних, схеми й особливі випадки, які вже враховані в офіційних тестах.
По‑друге, для запису Parquet Мерлінг планує порівнювати вихід Hardwood із результатами еталонної Java‑реалізації Parquet. Якщо обидва рушії генерують ідентичні або еквівалентні файли для тих самих вхідних даних і схем, це сильний аргумент на користь сумісності.
Такий підхід важливий не лише для Flink. Будь‑яка система, яка працює з Parquet‑файлами, очікує, що різні рушії зможуть читати й писати файли один одного без сюрпризів. Валідація проти upstream‑тестів і референсної реалізації — це спосіб формально підтвердити, що Hardwood не створює «свій» діалект формату.
І лише після того, як і читання, і запис будуть стабільними та сумісними, інтеграція з Flink має сенс як для розробника, так і для користувачів екосистеми.
AI як каталізатор «мінімалістичного» дизайну
Історія Hardwood показує, як два тренди — AI‑асистована розробка й прагнення до мінімальних залежностей — можуть підсилювати один одного.
З одного боку, відмова від великих SDK і «важких» бібліотек змушує команду брати на себе більше низькорівневої роботи: реалізовувати протоколи, підписування, обробку форматів. Раніше це часто виглядало як невиправданий ризик і витрата часу.
З іншого боку, сучасні LLM‑інструменти зменшують вартість такого «самопису». Вони допомагають швидко отримати робочу реалізацію за специфікацією, адаптувати її, покрити тестами. Людина залишається відповідальною за дизайн і перевірку, але не витрачає стільки часу на рутинну імплементацію.
У результаті стає можливим те, що Мерлінг описує як ментальну модель Hardwood: за замовчуванням — не брати залежностей, а потім свідомо й точково додавати їх там, де «переписати» справді було б нерозумно. AI у цій моделі не замінює розробника, але розширює діапазон завдань, які команда може реально взяти на себе, не перетворюючи проєкт на нескінченний марафон ручного кодування.
Hardwood, таким чином, стає не лише новим Parquet‑рушієм для Java, а й показовим кейсом того, як може виглядати AI‑first розробка інфраструктурного софту: з чіткою людською відповідальністю, формалізованими правилами для моделей, мінімалістичним дизайном і продуманою інтеграцією в екосистему.
Висновок
Hardwood поєднує одразу кілька важливих тенденцій у сучасній розробці: AI‑асистоване програмування, прагнення до контрольованих залежностей і фокус на сумісності з усталеними стандартами даних. Для Гуннара Мерлінга це перший по‑справжньому AI‑first проєкт, де близько 95% коду створено за участі моделей, але кожен рядок проходить людський рев’ю — «built with AI, not by AI».
Відмова від AWS SDK на користь вбудованого HTTP‑клієнта Java 11, власна реалізація підпису запитів на основі офіційної специфікації й тест‑кіта, опційний модуль AWS auth для IAM‑сценаріїв, модульний підхід до бібліотек стиснення — усе це елементи однієї стратегії: тримати ядро максимально легким і прозорим, додаючи складність лише там, де вона справді виправдана.
Попереду в Hardwood — стабілізація підтримки запису Parquet, подальша валідація проти референсної реалізації й інтеграція з Apache Flink. Але вже зараз проєкт демонструє, як AI може стати не заміною розробника, а інструментом, що дозволяє будувати складні інфраструктурні системи з меншими компромісами між контролем, безпекою та швидкістю розробки.
Джерело
Confluent Developer Podcast — Gunnar Morling Built a New Parquet Engine with AI | Ep. 31