In a single evening, a strategic conversation identified over €30,000 in revenue that wasn't being properly tracked, and produced a full technical specification for a project management system. Then autonomous AI agents built, tested, and hardened the entire system - over 800 tests, around 7,000 lines of code, no human code written.
A freelance developer might have quoted me 3-4 weeks to build this, or I could have gone down a rabbit hole for several weeks doing it myself. But the honest answer is I never would have built it at all.
01The problem that wasn't the problem
I've been running my consultancy for 19 years. When I shifted focus to AI in early 2024, the business didn't get simpler - it accumulated more layers on top of the previous ones. Legacy clients, AI training, speaking, implementation projects, a SaaS product, and several books. There's a lot of context-switching, and each type of work needs a different kind of attention, on a different timescale.
ADHD is a genuine asset in a lot of my work - the ability to lock in on a problem for hours is how a build like this happens in a single evening. But the flip side is that quiet, ongoing work disappears from my radar completely. Invoices don't get sent, pipeline contacts go cold, and admin that nobody's chasing simply stops existing in my mind until something breaks.
That's why Spark exists - a personal AI assistant that manages my tasks, deadlines, and calendar through a chat interface. To decide whether to build project-management features into it, I needed to understand my own business better first. So I fed an AI advisory council - a structured prompt that synthesises several expert perspectives - my email and invoice history from the past six weeks. It found over €30,000 in revenue that wasn't being properly tracked. The point wasn't the number; it was that I couldn't tell which was which.
"You don't have a revenue problem. You have a collections problem and an admin problem. The money isn't flowing in because invoices aren't being sent or chased."
- one of the AI advisors
That tension - build the system versus do the work the system would remind you to do - ran through the entire project.
02The taxonomy conversation
If Spark is going to manage projects intelligently, how should it categorise different types of work? A consulting business doesn't have one kind of project. The council debated for over an hour: simplicity (three categories) versus accuracy (five that map to how the business actually works). Five survived - each with its own way of failing.
Five categories, five failure modes
A flat task list can't tell "your revenue work is stalling" from "your book isn't progressing." These five can.
03The specification
I didn't write the spec myself. I continued the conversation with the council, and over about two hours we produced three documents - then handed them to the machine.
7-field data model, client slug registry, 20+ validation scenarios, a modular collector architecture.
21 phases across 4 parallel tracks, each with dependencies, files touched, tests, and acceptance criteria.
A structured prompt for Claude Code: per-phase sub-agents, scoped briefs, a checkpoint system to resume after interruptions.
Three documents, one evening of conversation, and zero code written by a human. The design conversation was the hard part - judgment calls an AI can't make alone, but can implement cleanly once they're made and documented.
04The build
I handed over the three documents and said: "Begin autonomous build." Claude Code read the spec, read the existing codebase, and started building. Two things happened that I didn't expect.
It noticed Phase 5 only depended on Phase 2, not 3 or 4 - so it built it early to unlock more downstream phases. Reasoning about the dependency graph, not following the list.
Edge-case tests revealed three issues. It diagnosed each, implemented fixes, wrote regression tests, and re-ran the full suite - no human intervention.
With all 21 phases complete, I gave it a comprehensive QA plan and let it stress-test its own work - malformed data, ambiguous commands, full-day and full-week simulations. QA added close to 180 tests, bringing the total past 800. A separate architectural review caught three more blind spots:
- The "fat finger": manual slug edits creating orphaned tasks - solved with orphan detection in the morning briefing.
- Silent API failures: partial invoice data overwriting the cache - solved with a payload-size comparison before overwrite.
- No undo button: a wrongly deleted project - solved with daily rolling backups, 7-day retention.
One evening, end to end
From "should I even build this?" to a system sending Monday-morning briefings.
05What this actually means
The design conversation was as valuable - possibly more valuable - than the code. Even if I'd hired someone, I'd have spent weeks explaining the business logic. But the real answer is simpler: I never would have built it. The barrier just dropped low enough that a single evening of focused conversation could produce it.
AI built the software, but the human still had to decide what to build, and why.
"Production-ready" here means: it works, the tests pass, it's running - but it still needs the real-world testing you only get from daily use. I can do that because I can read the code and fix what breaks. This isn't something I'd build for a client and hand over - it's a system I can maintain because I understand what's underneath it.
06The numbers
| Design conversation | ~3 hours |
| Specification documents | 3 |
| Build phases | 21 |
| Build tracks (parallel) | 4 |
| QA phases | 7 |
| Hardening fixes | 3 |
| Tests at start to finish | ~400 to 800+ |
| Test execution time | under 2 seconds |
| Lines of code added (prod + test) | ~7,000 |
| Human code written | 0 |
| First conversation to production | ~12 hours |
| Estimated freelance equivalent | 3-4 weeks |
07For the practitioner
The barrier to building dropped low enough that one evening was enough.
HumanSpark Labs Report · February 2026 · "Fewer late nights, not fewer humans."
Book a Focus Call