This is a submission for the GitHub Finish-Up-A-Thon Challenge
This is a submission for the GitHub Finish-Up-A-Thon Challenge
⭐ GitHub Repository
👉 github.com/sulthonzh/logchef-zig — Star it if you find it useful!
What I Built
logchef — a 592KB binary that parses, filters, and pretty-prints log files in JSON, logfmt, or plain text. Think jq meets tail meets grep, purpose-built for logs.
I'm a TypeScript/Node.js developer. I'd never written a line of Zig before this project. I built the entire thing using GitHub Copilot.
Demo
# Filter errors from any log format
logchef app.log -l error
# Search + follow in real-time
logchef app.log -c "timeout" -F
# Field filtering
logchef app.log -f status=500
# JSON output for piping
logchef app.log -l error -o json | jq '.message'
# Pipe from kubectl
kubectl logs my-pod | logchef -c panic
🔗 GitHub: github.com/sulthonzh/logchef-zig
⭐ Give it a star! It helps other developers discover the project.
The Comeback Story
BEFORE (May 6, 2026)
I started logchef during a weekend sprint. I had an idea: replace bloated Node.js log viewers with a tiny Zig binary. I didn't know Zig, so I opened VS Code, enabled Copilot, and started learning.
The first version was rough:
- 1,218 lines of code
- Basic JSON parsing and level filtering worked
- Text search worked
- Color output worked
- 21 tests passing
But the README listed features that didn't exist:
- ❌ Follow mode (tail -f)
- ❌ Logfmt format support
- ❌ No benchmarks
- ❌ No cross-platform builds
- ❌ No release automation
Life happened. The project sat for 2 weeks.
AFTER (May 25, 2026)
I picked it back up for the GitHub Finish-Up-A-Thon. Using GitHub Copilot CLI (copilot -p), I created 6 issues and implemented them one by one:
- ✅ Follow mode — polls file every 500ms, handles rotation
- ✅ Logfmt support — auto-detects and parses key=value pairs
- ✅ JSON output — NDJSON format for pipeline integration
- ✅ Benchmarks — compared vs jq, grep, awk
- ✅ Cross-platform CI — Linux + macOS, x86 + ARM
- ✅ Polished README — badges, comparison table, benchmarks
Final stats:
- 1,991 lines of Zig code (+64%)
- 23 tests
- 592KB binary
- 4-platform CI
- Zero dependencies
My Experience with GitHub Copilot
Learning Zig Through Copilot
Zig has concepts I'd never seen in TypeScript:
- Explicit allocators — every allocation needs an allocator passed in
-
Error unions —
!Typesyntax for functions that can fail - Comptime — code that runs at compile time
- No hidden control flow — no exceptions, no hidden allocations
I didn't learn these from docs. I learned them by writing prompts like:
copilot -p "How do I read a file line by line in Zig? Show me with explicit allocators."
And Copilot would generate code that taught me the pattern:
var gpa = std.heap.GeneralPurposeAllocator(.{}){};
const allocator = gpa.allocator();
const file = try std.fs.cwd().openFile(path, .{});
const content = try file.readToEndAlloc(allocator, max_size);
defer allocator.free(content);
Copilot CLI as My Zig Tutor
The most valuable tool was copilot -p — non-interactive mode that reads your codebase and generates matching code:
# Implement follow mode
copilot -p "Add follow mode that polls a file for new lines every 500ms" \
--allow-all -C . -s
# Add logfmt parsing
copilot -p "Add logfmt key=value parsing to the existing parser" \
--allow-all -C . -s
# Fix build errors
copilot -p "The build fails with: [error]. Fix it." \
--allow-all -C . -s
Every prompt taught me something new about Zig. By the end, I understood allocators, error handling, and even cross-compilation — all through Copilot-guided implementation.
What Copilot Got Right
- Pattern matching — it read my existing code and matched the style perfectly
-
Zig idioms — it knew to use
deferfor cleanup,tryfor error propagation - Test writing — it generated tests that followed my existing test patterns
- Cross-platform — it knew the right Zig target triples for all 4 platforms
What I Still Needed to Do
- Architecture decisions — Copilot writes code, but I decided what to build
- Code review — I read every line before committing
- Integration — I connected the pieces Copilot built
- Problem framing — the quality of Copilot's output depends on how you describe the problem
Results
| Metric | Before | After |
|---|---|---|
| Lines of code | 1,218 | 1,991 |
| Tests | 21 | 23 |
| Binary size | 592KB | 592KB (unchanged!) |
| Formats supported | JSON, plain text | JSON, logfmt, plain text |
| Follow mode | ❌ | ✅ |
| JSON output | ❌ | ✅ |
| Cross-platform CI | ❌ | ✅ (4 platforms) |
| Benchmarks | ❌ | ✅ |
Key Takeaway
You don't need to know a language to build something useful in it. GitHub Copilot won't replace understanding — but it dramatically lowers the barrier to entry. I went from "what is Zig?" to "I shipped a cross-platform CLI tool in Zig" in 3 weeks, part-time.
The trick isn't blindly accepting Copilot's output. It's:
- Having a clear idea of what you want to build
- Reading and understanding every line Copilot generates
- Using Copilot to learn, not just to code
Thanks to GitHub and DEV for the challenge! 🙏
Built with GitHub Copilot (free tier). No paid subscriptions used.
Top comments (0)