Код с ИИ стал «дешевле», а вот архитектура дороже.
Генеративный ИИ позволяет быстрее проверять идеи и проводить эксперименты, но без умения задавать правильные вопросы и опыта в выстраивании SDLC, это всего лишь позволит вам генерировать больше кода низкого качества.
Вот например пришла идея посчитать косты и спрогнозировать расходы на K8s в облаке и on-prem. Конечно есть много (в основном платных) проектов типа Kubecost, но они не достаточно гибкие для решения такого рода задач.
Если об этом попросить ИИ то он поможет сгенерировать почти работающий скрипт, который нужно будет поправить. Но выберет самое наивное решение, забрать метрики через metrics API:
# Fetch pod metrics for a specific namespace
def get_pod_metrics(namespace):
try:
result = subprocess.run(
["kubectl", "get", "--raw", f"/apis/metrics.k8s.io/v1beta1/namespaces/{namespace}/pods"],
capture_output=True,
text=True,
check=True
)
return json.loads(result.stdout)
except subprocess.CalledProcessError as e:
print(f"Error fetching pod metrics for namespace {namespace}: {e}")
return {}
В данном случае мы используем гипотетический AWS.
python3 kost.py --plot
Namespace Costs:
Namespace: default
Hourly Cost: $0.04
Daily Cost: $1.00
Monthly Cost: $30.00
6-Month Cost: $180.01
Namespace: kube-system
Hourly Cost: $0.07
Daily Cost: $1.77
Monthly Cost: $53.17
6-Month Cost: $319.04
И получаем график с прогнозом расходов:
Но это слишком простое решение, для реальной инфры, нужна будет мультитенантность и гарантии доставки. Если ИИ попросить очень настойчего, то он может быть расскажет вам, что нужно забрать метрики из Prometheus, но он никогда не предложит использовать kubernetes API для передачи событий в NATS. Как показано в этом примере.
Такое, я вам скажу, под силу лишь человеку.
