2025: The year in review
From startup death to methodology shift - and whether the productivity gains are real
2025 started with a startup death and ended with more code than I've written in any previous year. The question isn't whether that's impressive - it's whether the methodology that produced it is real, repeatable, and actually valuable.
The numbers: 156K lines of code, 322K lines of documentation, 702 commits across 4 substantial builds plus prototypes and research. Q4 alone delivered 52% of the year's output.
I don't know yet if this is a genuine productivity shift or an artifact of how I measured it. What follows is my attempt to examine both possibilities.
What Actually Happened
The arc matters more than any single quarter
Q1 - Startup Ending
Jan-MarWorking on nxi, the now-dead startup. High output, wrong direction. Traditional development with AI autocomplete.
Q2 - The Low Point
Apr-Jun~50 commits only. After a startup death, you need space to figure out what actually matters. So I've spent time exploring, reflecting and making small experiments.
Q3 - Learning
Jul-SepStarted heavy AI methodology work, embracing the fall into the rabbit hole. Learned MCP, context engineering, agentic coding flows. The commits stayed low (~50) but something was shifting in how I approached problems.
Q4 - Everything Clicked
Oct-Dec366 commits - more than Q1-Q3 combined. Projects ranging from early research to production alpha. The methodology that I'd been developing in Q3 became operational.
The Productivity Question
The math suggests 15-31x improvement. That's either real or a measurement problem.
The Claim
Industry baseline is 10-50 lines of code per day when you include planning, testing, debugging, refactoring.
I produced 156K lines in roughly 200 active days - approximately 780 LOC/day.
The ratio is 15-31x depending on which baseline you use.
The Caveats
- Lines of code is a terrible metric. It measures typing, not value.
- Solo developer output. No coordination overhead, no handoffs, complete context.
- Output is functional prototypes and MVPs, not production-hardened systems.
- 25 years of experience guides AI effectively. Less context = different results.
What I Actually Believe
The multiplier is real but overstated. The genuine gain comes from eliminating waste rather than speeding up execution. Research-before-build kills bad ideas early. Scope compression reduces iteration cycles. AI handles boilerplate so I can focus on decisions that matter.
The productivity isn't "I code faster." It's "I spend less time on things that don't matter."
The 2:1 Documentation Ratio
322K lines of documentation for 156K lines of code. This ratio is the artifact of a compression process.
156K Lines of Code
Real programming languages only - no data files, no config, no library code
322K Lines of Documentation
- Competitive analyses (30+ tools for LogMark alone)
- Requirements and scope documents
- Architecture decisions and trade-off analysis
- Kill-decision documentation for abandoned approaches
- Strategic frameworks and evaluation protocols
Most of it is exploration that gets compressed away
The Compression Pipeline
Market Research (broad, exploratory) - Vision (filtering what matters) - Scope (focused problem definition) - Instructions (precise, actionable context)
At each stage, information amount is reduced, signal gets extracted, clarity gets sharpened. Only the most important findings flow forward. By the time I code, I'm working with distilled information, ai agent receives dense context and can focus on what's important.
The 2:1 ratio shows the cost of figuring out what actually matters before writing code. This is divide-and-conquer on the problem space itself.
What I Built
By maturity stage
Opensourced
OneNoteXML
GitHubPython library for parsing OneNote XML exports. Part of personal knowledge system migration.
haic-lab
GitHubHuman-AI Collaboration knowledge base. Frameworks and methodology documentation.
Alpha - In Daily Use
LogMark
C# developer knowledge capture tool with notation-based routing. Obsidian-native, MCP-compatible. Used daily.
ShotQueue
Genre-agnostic photography automation platform. Python-based with AI-powered analysis. Heavy research-before-build.
Shipped - Under NDA
LytenUp Prototype
TypeScript/React application for domain founder. 3-day sprint. Delivered, awaiting founder's go-to-market.
Sustained Development
Quantitative Trading Platform
Trading infrastructure with backtesting, data acquisition, simulation. 170-day sustained focus.
Validated - Answered "No"
MotorCanvas
AI-assisted virtual car dealership showroom. Built to answer "will this approach work?" Answer: no. Stopped before wasting more time.
White-Box vs Black-Box AI Collaboration
The difference between "vibe coding" and methodology
Black-Box Approach
Throw problem at AI, hope for the best
- Unclear what AI is actually doing
- When it breaks, no idea where it failed
- Debugging is trial-and-error guesswork
- Process isn't repeatable or teachable
White-Box Approach
Explicit stages where AI amplifies each step of your process
- Understand what AI does at each stage
- Know exactly where failures occur
- Can verify and guide AI output
- Process is documented and repeatable
When you vibe code - you treat AI as a black box, every mistake is a mystery. When you use white-box methodology, you know which stage failed - was it bad research? Unclear scope? Wrong architecture? Poor implementation?
Q3 was learning to think in white-box terms. Q4's output happened because the methodology matured - I stopped "vibe coding" and started systematically integrating AI at each stage of an explicit, documented process.
What I Actually Learned
Not Building Is Often The Right Call
I killed or shelved more ideas in 2025 than I shipped. China sourcing platform with a friend? 15 minutes of research revealed Alibaba's Aidge AI (500K users, free) already solved it. Saved 300+ hours.
The B2B Pain Point Evaluation Protocol emerged from these failures - a 6-gate, 35-minute framework that kills bad ideas before they become bad code. Time NOT spent matters as much as time spent.
Research Isn't Overhead, It's Compression
Every Q4 sprint was preceded by deep research: LogMark (30+ tool competitive analysis), ShotQueue (photography publishing landscape), Visual Mastery (computational aesthetics research).
The upstream thinking didn't slow me down - it compressed development time by eliminating dead ends. You code faster when you know exactly what you're building and why.
Frameworks Compound
Developed many strategic frameworks in 2025: Human AI Collaboration Protocols, Conviction-Based Opportunity Evaluation, thinking primitives transferable across domains. The reasoning-tools knowledge base captures 500+ mental models across 32 domains.
Each new opportunity evaluates faster than the last. Reusable thinking infrastructure.
AI Collaboration Is A Skill, Not A Tool
Q1 (traditional coding): 139 commits. Q4 (AI-augmented): 366 commits - 52% of the year. This wasn't about simply adopting an ai-coding agent of choice, but more about learning to think in human-AI partnership.
The skill is knowing when and how to use AI at each stage of your process. The velocity spike came from methodology shift instead of longer hours.
Building in Public After 25 Years of NDAs
Why I started open-sourcing work - and what I'm hoping to get out of it
The Debt
I've used open source software for 25 years. Built careers on top of it. Linux, Python, .NET (now open), React, countless libraries and tools. In all that time, I contributed exactly two small fixes. Two.
Some people volunteer at shelters or mentor students. My view: contributing to open source is also volunteering. It's giving time and skill to make tools better for everyone. I'd been taking for decades without giving back. That bothered me, so now I'm acting.
The Other Motivations
I'm being honest about mixed motivations. Giving back is real, but it's not the only thing:
- 1.Credibility signal. 25 years of corporate and NDA-protected work means a CV full of claims with no public evidence. Public code is verifiable - you can see how I think, how I structure problems, whether my standards match my claims.
- 2.Finding like-minded people. The specific things I build filter for the specific people I want to work with. OneNoteXML attracts knowledge management nerds. haic-lab attracts people thinking seriously about AI collaboration methodology.
- 3.Filling gaps that should be filled. OneNoteXML exists because Microsoft's export format is undocumented and painful. No one had built a proper parser. Now someone has.
The motivations aren't separable. Building useful things, making them public, giving back, and benefiting from the visibility are all part of the same act.
What's Public Now
The Discomfort
Building in public after decades of private work is genuinely uncomfortable. There's exposure in showing unfinished thinking, imperfect code, projects that might not go anywhere. The instinct to polish before publishing is strong.
But polish delays feedback. And the people I want to connect with - other builders who think seriously about methodology and craft - can see through polish anyway. They're more interested in how you think than how you present.
What's Still Uncertain
I don't know if my newly founded methodology scales beyond solo work. Team dynamics, coordination overhead, context transfer - these are different problems that the methodology hasn't been tested against.
I don't know if Q4 was an outlier. Maybe I had particularly good project selection. Maybe the flow state and new tooling created unusual momentum. One quarter isn't proof of repeatability.
I don't know if lines of code is even the right thing to measure. What I actually care about is whether the things I built matter - whether they solve real problems for real people. That's a different metric, and 2026 will reveal more about it than 2025 did.
What's Next
2025 was about building execution capacity. 2026 is about deploying that capacity toward outcomes that matter.
The methodology seems real. The compression process produces consistent results. The white-box AI collaboration is repeatable and documentable. The framework development compounds over time.
What remains: choosing the right opportunities and executing with conviction. Building the right things and fast.
The real measure of 2026 won't be lines of code. It'll be whether the things I built actually matter.