Yapay zeka ile veri analizi yapmak: Excel’den dashboard’a

Yapay zeka ile veri analizi yapmak için verini bir kodlama ajanına göstermen ve ondan analiz kodunu yazmasını istemen yeterli: ajan Excel, CSV ya da SQL verini pandas ile okur, temizler, özetler ve Streamlit ile birkaç saatte etkileşimli bir dashboard’a çevirir. Ürünün parçası olacak bir pano gerekiyorsa aynı işi Next.js ve bir grafik kütüphanesiyle yaparsın. Asıl dikkat edilecek nokta kod değil, rakamların doğruluğu ve verinin gizliliği.

Bu yazıda bir satış Excel’inden paylaşılabilir bir panoya kadar adım adım gidiyorum: araçlar, ilk prompt, veritabanına salt okunur bağlanmak, yapay zekanın hesaplarını doğrulamak ve yayına almak.

Ne yapacağız?

Hedef, elle her hafta güncellediğin bir Excel raporunu kendini güncelleyen bir panoya çevirmek. Tipik bir satış panosunda şunlar olur: dönem toplamı, geçen döneme göre değişim, aylık ciro grafiği, en çok satan ürünler, bölge ya da kanal kırılımı ve tarih filtresi.

Bunu vibe coding yaklaşımıyla yapacağız: kodu ajan yazar, sen ne görmek istediğini anlatır ve sonucu kontrol edersin. Veri analizinde bu yaklaşımın tek bir şartı var: çıkan rakamı sorgulayabilecek kadar verini tanıman.

Hangi yolu seçmeli: Streamlit mi, Next.js mi?

Hızlı yol: Python, pandas ve Streamlit. Tek bir Python dosyası çalışan bir web arayüzüne dönüşür. Filtre, tablo, grafik ve metrik kartları birkaç satırdır. Kendin, yöneticin ya da küçük bir ekip için iç pano gerekiyorsa en kısa yol bu. pandas Excel, CSV ve SQL’i aynı rahatlıkla okur.

Ürün yolu: Next.js ve bir grafik kütüphanesi. Pano müşterilerine sunulacaksa, kullanıcı girişi, kullanıcı başına veri yetkisi ve markana uygun tasarım gerekiyorsa React tabanlı bir uygulama daha doğru. Recharts, Chart.js ya da ECharts gibi kütüphaneler yaygın seçimler. Veri sunucu tarafında, bir API rotasında sorgulanır; tarayıcıya yalnızca gerekli özet gider.

Emin değilsen Streamlit ile başla. Hangi grafiklerin gerçekten kullanıldığını gördükten sonra ürüne taşımak çok daha kolay.

Adım 1: Kurulum

Bir terminal kodlama ajanı (Claude Code, Codex, Gemini CLI, Cursor’un CLI’ı gibi) ve Python yeterli:

mkdir satis-panosu && cd satis-panosu
git init
python3 -m venv .venv
source .venv/bin/activate          # Windows: .venv\Scripts\activate
pip install pandas openpyxl streamlit plotly
mkdir data && cp ~/Downloads/satislar_2026.xlsx data/
echo "data/" >> .gitignore
echo ".env" >> .gitignore

data/ klasörünü baştan git dışında tutuyorum; müşteri verisi depoya girmemeli.

Adım 2: Önce veriyi tanıt

En sık yapılan hata, ajana doğrudan “bana dashboard yap” demek. Önce verinin ne olduğunu anlamasını iste. Bu ilk tur hiçbir şey çizmez, yalnızca rapor verir:

data/satislar_2026.xlsx dosyasını pandas ile oku ve bana bir veri raporu çıkar:
- Sayfa adları, her sayfadaki satır ve sütun sayısı
- Her sütunun tipi, boş değer oranı ve 5 örnek değer
- Tarih ve para sütunlarının biçimi (Türkçe ondalık virgül var mı?)
- Tekrarlanan satırlar ve olası anahtar sütunlar (sipariş no gibi)
- Gözüne çarpan tutarsızlıklar
Hiçbir dosyayı değiştirme, grafik çizme. Raporu analiz/veri_raporu.md olarak yaz.

Bu raporu oku. “Tutar sütununda 37 satır metin olarak gelmiş” ya da “aynı sipariş no iki kez geçiyor” gibi bulgular, sonraki tüm rakamları etkiler. Hangisinin hata, hangisinin gerçek (iade, bölünmüş sipariş) olduğuna sen karar verirsin; ajan veriyi tahminle düzeltmesin.

Adım 3: Dashboard prompt’u

Veri temizse panoyu iste. Hangi soruları cevaplaması gerektiğini yaz; grafik türlerini ajan önerebilir:

Streamlit ile app.py yaz. Veri: data/satislar_2026.xlsx, "Satislar" sayfası.

Temizlik ayrı bir fonksiyonda (load_data) olsun ve st.cache_data ile önbelleklensin.
İadeler (Tutar < 0) ciroya dahil, ayrıca ayrı bir metrik olarak gösterilsin.

Pano şunları cevaplasın:
1. Seçilen tarih aralığında toplam ciro, sipariş sayısı, ortalama sepet
   (her biri geçen yılın aynı dönemine göre değişimiyle)
2. Aylık ciro trendi (çizgi grafik)
3. En çok ciro yapan 10 ürün (yatay çubuk)
4. Bölgeye göre ciro (çubuk) ve bölge filtresi

Kurallar:
- Tüm hesaplar ayrı bir metrics.py içinde, saf fonksiyonlar olarak.
- metrics.py için pytest testleri yaz; testler küçük, elle hesaplanmış bir örnek veri kullansın.
- Para birimini ₺ ve Türkçe biçimle göster.
Bitince testleri çalıştır ve streamlit run app.py komutunu söyle.

Hesapları ayrı bir dosyaya ve test edilebilir fonksiyonlara koydurmak bu prompt’un en önemli kısmı. Arayüzü değiştirmek kolaydır; yanlış bir toplam fonksiyonu ise her grafiği bozar.

pytest -q
streamlit run app.py

Tarayıcıda açılan panoya bak, sonra küçük adımlarla iste: “Ürün grafiğinde etiketler kesiliyor, yatay yap.” “Tarih filtresinin varsayılanı bu ay olsun.” Her değişiklikten sonra git commit at ki bir adım geri dönebilesin.

Adım 4: Veritabanına salt okunur bağlan

Veri Excel’de değil de uygulamanın veritabanındaysa en önemli kural: panonun kullanıcısı yalnızca okuyabilsin. PostgreSQL için ayrı bir kullanıcı:

CREATE ROLE pano_okuyucu LOGIN PASSWORD 'buraya-guclu-bir-parola';
GRANT CONNECT ON DATABASE uygulama TO pano_okuyucu;
GRANT USAGE ON SCHEMA public TO pano_okuyucu;
GRANT SELECT ON orders, order_items, products TO pano_okuyucu;

Bağlantı adresini .env içine koy (DATABASE_URL=...) ve ajana yalnızca değişkenin adını söyle. Birkaç pratik not daha:

• Yetkiyi yalnızca gereken tablolara ver. Kullanıcı tablosunda e-posta ve telefon varsa panonun ona ihtiyacı yoksa erişimi de olmasın.
• Mümkünse bir okuma replikası ya da gece alınan bir kopya kullan. Ajanın yazdığı ağır bir sorgu canlı sistemi yavaşlatabilir.
• Sorgulara zaman aşımı koy (PostgreSQL’de statement_timeout) ve sonuç setini sınırla.
• Ajandan SQL’i ayrı .sql dosyalarında tutmasını iste; sorguyu okumak ve elle çalıştırmak kolaylaşır.

Adım 5: Rakamları doğrula

Burası yazının en önemli bölümü. Bir dashboard’un en tehlikeli hatası çökmesi değil, yanlış bir rakamı ikna edici bir grafikle göstermesidir.

Ana toplamları elle karşılaştır

Panodaki 3–4 ana rakamı başka bir yoldan hesapla: Excel’de pivot tablo, ya da kendi yazdığın basit bir SQL. Örneğin mart ayı cirosu:

SELECT SUM(total) FROM orders
WHERE created_at >= '2026-03-01' AND created_at < '2026-04-01'
  AND status <> 'cancelled';

Panodaki rakam bununla aynı değilse farkı açıklayana kadar devam etme. Fark çoğu zaman şu sorulardan birinin cevabındadır: iptaller dahil mi, iadeler nerede, KDV dahil mi, saat dilimi hangisi?

Sessiz yanlış JOIN

Yapay zekanın SQL’de en sık yaptığı ve en zor fark edilen hata bu:

-- YANLIŞ: her sipariş, kalem sayısı kadar tekrarlanır
SELECT SUM(o.total)
FROM orders o
JOIN order_items i ON i.order_id = o.id;

Üç kalemli bir sipariş üç satıra dönüşür ve o.total üç kez toplanır. Sorgu hata vermez, sonuç makul görünür, ama ciro şişmiştir. Çözüm, toplamı doğru seviyede almak: ya yalnızca orders üzerinden topla, ya da kalemleri önce sipariş başına özetleyip sonra birleştir. Kontrol için ajana şunu sor:

Bu sorgudaki her JOIN için: birleşme sonrası satır sayısı, birleşme öncesi ana
tablonun satır sayısıyla aynı mı? COUNT(*) ve COUNT(DISTINCT o.id) ile göster.

İki sayı farklıysa bir yerde satırlar çoğalıyor demektir.

Diğer tuzaklar

• Tarih sınırları: BETWEEN '2026-03-01' AND '2026-03-31' zaman damgalı sütunda 31 Mart’ın gün içini kaçırır. Yarı açık aralık kullan.
• Saat dilimi: Veritabanı UTC tutuyorsa gece yarısına yakın siparişler yanlış güne düşer.
• Ortalama hatası: Bölgelerin ortalama sepetlerinin ortalaması, genel ortalama sepet değildir.
• Boş değerler: pandas’ta NaN içeren satırlar bazı işlemlerde sessizce düşer.

Adım 6: Paylaş ve yayına al

• Streamlit: Ekip içi kullanım için bir sunucuda ya da Docker konteynerinde çalıştırıp şirket ağına veya bir giriş katmanının arkasına koyabilirsin. Streamlit’in kendi barındırma hizmeti de var, ama müşteri verisi içeren bir panoyu herkese açık bir adrese koyma; erişimin kimde olduğunu bilmelisin.
• Next.js: Vercel gibi bir platforma ya da kendi sunucuna dağıtılır. Kimlik doğrulamayı ve her kullanıcının yalnızca kendi verisini gördüğünü sunucu tarafında kontrol et; filtreyi yalnızca arayüzde yapmak güvenlik değildir.
• Veriyi tazelemek: Excel tabanlı panolarda dosyayı paylaşılan bir klasörden okumak ya da gece çalışan küçük bir script ile veritabanına aktarmak elle güncellemeyi bitirir.

Yapay zekanın sık yaptığı hatalar

• Veriyi tahminle “düzeltmek”: Boş değerleri sıfırla doldurmak, ayrıştırılamayan tarihleri silmek. Her temizlik kuralını açıkça yazdır ve onayla.
• Var olmayan sütun adları: Şemayı görmeden customer_name gibi bir sütun uydurur. Ona gerçek şemayı ver.
• Türkçe sayı biçimi: 1.234,56 değerini 1,234 olarak okumak. Ham değer ile okunan değeri yan yana göstermesini iste.
• Her şeyi grafiğe dökmek: 15 grafiklik bir pano kimsenin bakmadığı bir panodur. Cevaplanacak soruyu sınırla.
• “Doğruladım” demek: Ajanın kendi yazdığı kodu kendi yazdığı testle doğrulaması, aynı yanlış varsayımı iki kez yapması olabilir. Bir rakamı sen kontrol et.

Güvenlik ve gizlilik

• Bağlantı bilgileri .env’de, .env ve data/ git dışında.
• Parolayı ya da bağlantı adresini sohbete yapıştırma. Ajana değişken adını söyle.
• Ham müşteri verisini modele gönderme. Ajanın kod yazmak için şemaya ve birkaç örnek satıra ihtiyacı var; örnekleri anonimleştir ya da sahte veri üret. Kod veriyi senin makinende işler, model işlemez. Kişisel verilerde KVKK ve GDPR yükümlülüklerin değişmez.
• Ajanın çalıştırdığı komutları ve SQL’i oku. DELETE, UPDATE, DROP içeren bir şeyi panoya bağlı bir kullanıcıyla çalıştırmak zaten imkânsız olmalı; salt okunur kullanıcı bunun için.
• Panonun adresini kimin gördüğünü bil. Paylaşılan bir link, verinin kendisini paylaşmaktır.

AgentVera ile nasıl yapılır?

Yukarıdakilerin hiçbiri belirli bir araç gerektirmiyor. Ben bu tür işleri AgentVera içinde yapıyorum, çünkü veritabanı tarafında birkaç adımı kısaltıyor:

• Veritabanı yöneticisi. Veritabanı yöneticisi PostgreSQL, MySQL/MariaDB ve SQLite’a bağlanır. “Salt okunur” işaretlediğin bağlantı sunucu tarafında da salt okunur açılır. Ajanın yazdığı SQL’i SQL editöründe kendin çalıştırıp toplamları karşılaştırabilir, EXPLAIN ile ağır sorguları görebilirsin.
• Ajanlara kontrollü erişim. Bir bağlantı için ajan erişimini açarsan, MCP destekleyen ajanlar sorguları agentvera-db aracıyla çalıştırır; parolayı görmezler, mod varsayılan olarak salt okunurdur ve her sorgu kaydedilir. “Yapay zekâ” düğmesi isteğini SQL’e çevirirken tablo ve sütun adlarını gönderir, tablo satırlarını göndermez.
• DB Guard. Pano için ajan bir index ya da view migration’ı yazarsa, DB Guard tur sonunda dosyayı tarar ve kilitleyen index, veri kaybı gibi riskleri gösterir.
• Paralel ajanlar ve önizleme. Bir panelde Claude Code SQL ve metrikleri yazarken diğerinde Codex arayüzü düzenleyebilir; her biri ayrı bir git worktree içinde. Önizleme ortamları her worktree’nin sunucusunu ayrı bir portta açar.
• Diff incelemesi. Kod incelemesi metrik fonksiyonlarındaki değişiklikleri birleştirmeden önce bir kez daha gözden geçirmeni sağlar.

Veritabanı yöneticisi ve ajan erişimi Pro ve Team planlarında. Ajanın yazdığı kodu incelemeye dair daha fazlası için yapay zeka kod incelemesi, paralel çalışmak için git worktree ile paralel geliştirme yazılarına bakabilirsin.

Kısa kontrol listesi

• Ajan önce veri raporu çıkardı, temizlik kurallarını sen onayladın
• Hesaplar ayrı, test edilmiş fonksiyonlarda
• En az 3 ana rakam başka bir yoldan elle doğrulandı
• Her JOIN için satır sayısı kontrol edildi
• Veritabanına yalnızca SELECT yetkili bir kullanıcıyla bağlanılıyor
• .env ve data/ git dışında, müşteri verisi modele gönderilmedi
• Pano erişimi bilinen kişilerle sınırlı

Sonuç

Yapay zeka ile veri analizi yapmak, kod yazmayı hızlandırır ama düşünmeyi devretmez. Ajan pandas, SQL ve Streamlit kodunu dakikalar içinde yazar; hangi rakamın doğru olduğuna, hangi verinin paylaşılabileceğine yine sen karar verirsin. Bu hafta elle güncellediğin bir Excel raporunu seç, ajandan önce veri raporunu iste, sonra Streamlit ile ilk panoyu kur ve üç rakamı elle doğrula.