AI-Augmented Engineering Sprint

Sabbatical Independent Builder 2025–2026

Situation

After leaving ezCater, I used a sabbatical not as a break but as a return to hands-on engineering. The goal was to build at high velocity across a wide range of product and platform problems using AI-assisted development.

This was deliberate: I wanted to test whether a senior engineering leader could maintain technical currency and building speed by deeply integrating AI into the development workflow — and whether that experience would produce transferable judgment about AI-augmented engineering practices.

Decision

I committed to building across product, workflow, automation, and tooling domains. Every project started from a real customer problem, not technology for its own sake.

The result: 9,628 GitHub contributions in the last year across 100+ repositories. This is not volume for its own sake — it reflects repeated reps across varied problem spaces, each producing judgment about what works, what breaks, and what AI-assisted development is actually good for.

Risk

The risk of a sabbatical build sprint is diffusion. Building 100+ things can mean finishing nothing and learning nothing transferable. I managed this by treating each project as a judgment exercise: what’s the real problem, what’s the minimum viable approach, what would break in production, and what did I learn.

There’s also a perception risk: some organizations view sabbatical work as hobbyist activity rather than professional development. I accepted this because the work speaks for itself in both volume and variety.

Change

The sprint produced:

What This Demonstrates