LIPAS is Finland's national database of sports and recreational facilities, maintained by the University of Jyvaskyla. The web application is open-source, built in Clojure/ClojureScript, and has been developed primarily by one developer since 2018. From 2018--2019 it was a full-time project. Since ~2019 it has been a side responsibility -- evenings and weekends alongside a day job. In mid-2025, AI coding tools (Claude Desktop, then Claude Code) were adopted.
The central question: can AI-assisted part-time development match or exceed full-time output? This analysis uses git history to find out.
All statistics derived from git log --no-merges on the LIPAS repository
(first commit: 2018-04-18). Metrics used:
- Commits:
git shortlog -sne --no-merges, filtered by--authorand date ranges - Lines added/deleted: parsed from
git log --shortstatoutput per commit - Active days: unique dates (YYYY-MM-DD) with at least one commit
- Average commit size: total insertions and deletions divided by commit count
- Weekend/weekday split: extracted from
git log --format="%aD"(day-of-week field) - Working hours: extracted from author timestamp (
%ai) hour component
Lines-of-code metrics are inherently noisy (reformatting, generated files, dependency locks), but trends over multi-year periods are meaningful. Commit counts are more stable but say nothing about scope. The combination of both, plus active days and files-per-commit, gives a reasonably honest picture.
All data was collected on 2026-02-21 at commit 71931892.
| Span | April 2018 -- February 2026 (~8 years) |
| Total commits | 2,715 (non-merge) |
| Primary author | Valtteri Harmainen (86% of all commits) |
| Other contributors | Juho Teperi (276), Tuomas-Matti Soikkeli (67), Dependabot (26) |
| Stack | Clojure/ClojureScript, PostgreSQL, Elasticsearch |
| Year | Commits | Active Days | Lines Added | Lines Deleted | Avg +/- per commit | Files/commit |
|---|---|---|---|---|---|---|
| 2018 | 623 | 135 | 66,488 | 31,629 | 107+ / 51- | 3.3 |
| 2019 | 545 | 123 | 82,288 | 31,469 | 151+ / 58- | 3.2 |
| 2020 | 63 | 40 | 3,920 | 2,566 | 62+ / 41- | 2.6 |
| 2021 | 69 | 39 | 16,619 | 5,200 | 241+ / 75- | 3.1 |
| 2022 | 99 | 48 | 31,984 | 51,558 | 323+ / 521- | 3.0 |
| 2023 | 226 | 93 | 21,414 | 15,387 | 95+ / 68- | 3.2 |
| 2024 | 232 | 95 | 37,481 | 20,636 | 162+ / 89- | 2.4 |
| 2025 | 411 | 112 | 167,521 | 53,426 | 408+ / 130- | 4.6 |
| 2026* | 78 | 23 | 13,557 | 20,245 | 174+ / 260- | 4.4 |
*2026 covers Jan 1 -- Feb 17 only (7 weeks). Avg +/- per commit is noisy:
2022's high average is 5 infrastructure commits (build system migration,
package-lock.json churn, vendored JS removal) that account for 86% of the
year's line changes; excluding them, the remaining 92 commits average 128
lines. Similarly, 2025's average is inflated by mechanical migration diffs
(spec-to-Malli, UIX-to-Reagent).
xychart-beta
title "Commits per Year (Valtteri)"
x-axis [2018, 2019, 2020, 2021, 2022, 2023, 2024, 2025]
y-axis "Commits" 0 --> 700
bar [623, 545, 63, 69, 99, 226, 232, 411]
xychart-beta
title "Lines Added per Year (Valtteri, thousands)"
x-axis [2018, 2019, 2020, 2021, 2022, 2023, 2024, 2025]
y-axis "Lines (k)" 0 --> 180
bar [66, 82, 4, 17, 32, 21, 37, 168]
The numbers above tell a clear story when you know the context behind them.
LIPAS was Valtteri's primary project. 623 commits in 2018, 545 in 2019 -- 3--5 commits per working day sustained over two years. Work was almost entirely on weekdays (< 5% weekends), consistent with full-time focused development.
Peak month: March 2019, 50,385 lines changed.
Baseline: ~584 commits/year, ~74k lines added/year, ~129 active days/year.
Around 2019, LIPAS became a side responsibility. Contributions moved to evenings and weekends -- the shift is visible in weekend commit share jumping from ~5% to ~50-60%.
The drop was immediate and sustained: 63--99 commits/year in 2020--2022, with 40--48 active days. The project was alive but not the primary focus.
2022 had a notable cleanup: average commits deleted more lines (521-) than they added (323+), especially a December purge removing 27k lines of dead code.
In 2023--2024, two contributors joined:
- Tuomas-Matti Soikkeli (Siili consulting, 67 commits total): legacy API, reverse geocoding, floorball features, test infrastructure.
- Juho Teperi (276 commits, mostly 2024): API v2 with reitit/OpenAPI, PTV integration, Reagent 2.0 upgrade, organisation functionality. His Oct--Dec 2024 sprint alone was 224 commits.
Even with team support, Valtteri's personal output plateaued at ~230 commits/year and ~30k lines/year -- roughly a quarter of his full-time pace. This is what evenings and weekends buy you.
Side-job baseline (Valtteri only, 2020--2024 avg): ~137 commits/year, ~22k lines added/year, ~53 active days/year.
Git history places the adoption of AI tools around late May 2025. The evidence:
- May 29: 13 commits in one day including "Add PROJECT_SUMMARY.md", "Improve CLAUDE.md", "More streamlined bootstrapping for robots", and "chore: complete Leiningen to deps.edn migration cleanup" -- LLM context files and conventional-commit prefixes that never appeared before.
- May 31: "Pull MCP out of the project" (clojure-mcp had been embedded
in the repo), "Improve robot experience",
feat(ptv/audit):prefix. - June 1: "Add babashka expert LLM instructions" -- an LLM system prompt committed as a doc file.
- June 8: First burst of the word "comprehensive" in commit messages, a signature of AI-generated text.
The initial tool was Claude Desktop with clojure-mcp (an MCP server for nREPL interaction). Claude Code was adopted later, with CLAUDE.md first committed in a WIP commit on August 31, 2025.
The nature of work changed. H2 2025 saw several major architectural projects completed in rapid succession:
- Complete UIX to Reagent 2.0 migration (systematic, tiered across 5+ PRs)
- Full clojure.spec to Malli migration (schema replacement across entire codebase)
- Docker infrastructure and health check overhaul
- CRS coordinate transform performance optimization
- Removal of dead code and unused dependencies
These are cross-cutting refactors that would typically be deferred indefinitely in a side-job context because the effort-to-risk ratio is too high for limited evening sessions. AI tools changed that calculation.
December 2025 stands out: 84,902 lines added across 77 commits -- the single most productive month in the repository's history by a factor of 1.7x. This coincided with 1.5 weeks of holiday from the day job, providing a few full working days with AI assistance. The spike illustrates what happens when AI tools meet available time.
Early 2026 continues with a cleanup-heavy profile (more deletions than additions), indicating confident refactoring.
The question is whether AI tools bridge the gap between part-time and full-time output. Three eras, same developer, same codebase:
| Metric | Full-time (2018--19) | Side-job pre-AI (2020--24) | Side-job + AI (2025) |
|---|---|---|---|
| Commits/year | 584 | 137 | 411 |
| Lines added/year | 74,388 | 22,417 | 167,521 |
| Active days/year | 129 | 53 | 112 |
| Avg lines per commit | 129+ | 167+ | 408+ |
| Files per commit | 3.3 | 2.9 | 4.6 |
xychart-beta
title "Three-Era Comparison: Commits per Year"
x-axis ["Full-time (2018-19)", "Side-job pre-AI (2020-24)", "Side-job + AI (2025)"]
y-axis "Commits" 0 --> 650
bar [584, 137, 411]
xychart-beta
title "Three-Era Comparison: Active Days per Year"
x-axis ["Full-time (2018-19)", "Side-job pre-AI (2020-24)", "Side-job + AI (2025)"]
y-axis "Days" 0 --> 150
bar [129, 53, 112]
The AI-assisted side-job output exceeds full-time output by lines (2.3x) and approaches it by commits (70%) and active days (87%). Compared to the pre-AI side-job baseline, everything roughly tripled.
But there's a confound. Active days doubled from the side-job baseline (53 to 112). This means the increase isn't purely "same hours, more output" -- there's also "more sessions." Two explanations, likely both true:
- Each session is more productive. AI tools amplify output per hour, especially for systematic multi-file changes.
- AI lowers the activation energy. When you know an AI agent can handle the tedious parts, it's easier to open the laptop for an evening session you might otherwise skip. The tool makes it worth starting.
The data cannot separate these effects. If it's mostly (1), the productivity multiplier per hour is very high. If (2) is significant, part of the output increase comes from spending more total time on LIPAS -- not because you have to, but because AI made it rewarding enough to do. That's still a real productivity story, just a different one than "same effort, 3x output." The reality is likely somewhere in between: more efficient per hour and more hours invested because the friction dropped.
| Period | Weekend % of commits | Peak hours | Character |
|---|---|---|---|
| 2018--19 | ~5% | 12:00--19:00 | Full-time weekday work |
| 2020--22 | ~50%+ | Evenings/weekends | Side-job maintenance |
| 2023--24 | ~60% | Mixed | Side-job + team contributors |
| 2025--26 | ~45% | Mixed | AI-augmented side-job |
Most productive hour across all years: 17:00 (234 commits).
The weekend share actually decreased slightly in the AI era (45% vs 60%), possibly because AI makes short weekday evening sessions viable -- you can accomplish something meaningful in an hour, so weeknight sessions happen more often.
| Contributor | Total Commits | Period | Focus |
|---|---|---|---|
| Valtteri Harmainen | 2,346 | 2018--present | Creator, architect, sole constant |
| Juho Teperi | 276 | 2024--2025 | API v2, Reagent upgrade, PTV |
| Tuomas-Matti Soikkeli | 67 | 2023--2025 | Legacy API, tests, features |
| Dependabot | 26 | 2020--2025 | Automated dependency bumps |
A note on 2024 vs 2025: Juho contributed 268 commits in 2024 but only ~28 in 2025. The total repository output was 535 commits in 2024 vs 434 in 2025. Some of the increase in Valtteri's 2025 output may reflect absorbing work that Juho would have done. However, Valtteri's output in 2025 (411 commits) exceeds his output in any year since 2019, including 2024 when Juho was handling a large share of the work. The AI effect is not just a team-size artifact.
Higher output is only meaningful if quality holds. Four signals from the git history: test coverage, reverts, fix rates, and code churn.
The project had minimal test coverage for most of its history. Measured at year end:
| Year | Test files | deftest forms |
(is ...) assertions |
Test lines | Source lines | Test/src ratio |
|---|---|---|---|---|---|---|
| 2018 | 2 | 25 | 52 | 393 | 22,453 | 1.8% |
| 2019 | 2 | 35 | 69 | 531 | 36,313 | 1.5% |
| 2020 | 2 | 37 | 72 | 554 | 37,505 | 1.5% |
| 2021 | 2 | 37 | 72 | 554 | 40,909 | 1.4% |
| 2022 | 2 | 37 | 72 | 554 | 44,245 | 1.3% |
| 2023 | 4 | 41 | 85 | 677 | 49,773 | 1.4% |
| 2024 | 8 | 62 | 160 | 1,118 | 72,271 | 1.5% |
| 2025 | 41 | 421 | 2,244 | 12,693 | 91,106 | 13.9% |
| 2026* | 41 | 428 | 2,268 | 12,485 | 85,798 | 14.6% |
*2026 = Feb 17. Source lines decreased due to dead code removal.
xychart-beta
title "Test Assertions Over Time"
x-axis [2018, 2019, 2020, 2021, 2022, 2023, 2024, 2025]
y-axis "Assertions" 0 --> 2400
bar [52, 69, 72, 72, 72, 85, 160, 2244]
From 2018 to 2024 -- six years -- the project went from 2 test files to 8, and from 52 assertions to 160. The test/source ratio hovered around 1.3--1.5%.
In 2025, after AI adoption: 41 test files, 2,244 assertions, 12,693 lines of test code. The test/source ratio jumped from 1.5% to 13.9% -- roughly a 10x increase in a single year.
The new tests are concentrated in:
- Jobs system (8 test files: core, dispatcher, handler, resilience, deduplication, etc.)
- Legacy API v1 (6 test files: handler, integration, transform, golden files)
- Schema validation (3 test files)
- Analysis features (3 test files: diversity, heatmap)
- Backend core (handler, org, PTV, search mapping, business logic)
87 of the 101 test-touching commits in 2025 were by Valtteri (the rest by Tuomas-Matti). Writing tests was historically deferred -- AI tools made the cost of writing them low enough to actually do it. This is perhaps the clearest example of AI changing the effort-to-value calculation: tests were always known to be worthwhile, but never worth the limited evening hours. When AI handles the mechanical work of writing test scaffolding, the decision flips.
| Period | Commits | Reverts |
|---|---|---|
| 2018 | 623 | 5 |
| 2019 | 545 | 4 |
| 2020--22 | 229 | 2 |
| 2023 | 230 | 4 |
| 2024 | 237 | 0 |
| 2025 (AI) | 311 | 0 |
| 2026 (AI) | 76 | 0 |
15 reverts in the pre-AI history, zero since 2024. Despite 3x more output in the AI era, nothing catastrophic has gotten through.
Commits with "fix" (case-insensitive) in the subject, as a percentage of total.
| Period | Total commits | Fix commits | Fix % |
|---|---|---|---|
| 2018 | 623 | 97 | 15.6% |
| 2019 | 545 | 152 | 27.9% |
| 2020--22 | 229 | 36 | 15.7% |
| 2023 | 230 | 43 | 18.7% |
| 2024 (pre-AI) | 237 | 43 | 18.1% |
| 2025 Jan--Apr (pre-AI) | 95 | 12 | 12.6% |
| 2025 May--Dec (AI) | 311 | 55 | 17.7% |
| 2026 (7 weeks, AI) | 76 | 19 | 25.0% |
Fix rates have fluctuated between 13% and 28% across all eras. The full-time peak was 27.9% (2019). The AI era's 17.7% sits in the lower half of the historical range. Even 2026's elevated 25.0% -- during heavy refactoring where breakage-then-fix cycles are expected -- remains below the 2019 full-time peak.
There is no signal that AI tools increased the defect rate.
Does AI-generated code get thrown away faster? Two measures from git blame
and file edit history suggest not.
Line survival rate. Using git blame on HEAD to check how many lines
written in each period still exist. Older code naturally has lower survival
(more time to be replaced), so the key comparison is periods at similar age.
Caveat: git blame tracks textual authorship, not logical authorship.
A formatting change, reindentation, or mechanical migration (e.g. renaming
s/def to m/schema) resets the blame timestamp even if the logic is
unchanged. The 2025 migrations (spec-to-Malli, UIX-to-Reagent) systematically
touched many lines this way, which inflates "lines added" for 2025 and deflates
"surviving lines" for earlier periods. The relative comparison between 2025
pre-AI and 2025 AI is less affected since both are subject to the same bias,
but the absolute survival percentages should be read as approximate.
| Period | Lines added | Surviving at HEAD | Survival % | Code age |
|---|---|---|---|---|
| 2018 | 66,488 | 4,136 | 6.2% | ~8 years |
| 2019 | 82,288 | 7,019 | 8.5% | ~7 years |
| 2023 | 21,414 | 6,643 | 31.0% | ~3 years |
| 2024 | 37,481 | 22,924 | 61.2% | ~1--2 years |
| 2025 pre-AI | 12,681 | 2,417 | 19.1% | ~10 months |
| 2025 AI | 154,814 | 28,407 | 18.3% | ~3--9 months |
| 2026 AI | 13,557 | 9,926 | 73.2% | ~1--7 weeks |
The fair comparison is 2025 pre-AI vs 2025 AI at similar age: 19.1% vs 18.3% -- virtually identical. AI-written code is not being replaced any faster than hand-written code from the same period. The high 2024 survival (61.2%) reflects Juho's stable infrastructure work (API v2, reitit routes) that hasn't needed changes since.
File-level churn. For files created in each year, how many follow-up edits happened within 30 days of creation?
| Year | New files created | Avg edits within 30 days |
|---|---|---|
| 2018 | 201 | 2.4 |
| 2019 | 79 | 1.9 |
| 2023 | 32 | 1.3 |
| 2024 | 32 | 1.7 |
| 2025 | 132 | 1.7 |
| 2026 | 18 | 0.8 |
AI-era file churn (1.7 edits within 30 days) is identical to 2024 and lower than 2018. Files aren't being created and immediately rewritten.
The numbers paint a consistent picture across multiple metrics:
AI-assisted side-job output matches or exceeds full-time output. By commits (70% of full-time pace), active days (87%), and lines added (2.3x), the 2025 side-job numbers are in the same range as the 2018--2019 full-time era -- despite LIPAS competing with a day job for time and energy.
The multiplier vs the pre-AI side-job is ~3x. Commits tripled (137 to 411), lines added grew 7x (though inflated by migrations), and active days doubled (53 to 112). This is the comparison that controls for life circumstances.
Quality did not degrade. Fix rates (17.7%) sit in the lower half of the historical range (13--28%), zero reverts since 2024 despite 3x more output, and code churn is identical to hand-written code. Test coverage grew 10x, suggesting AI actually improved quality by making previously-deferred testing economically viable.
Work that wouldn't have happened, happened. The two major migrations (UIX to Reagent 2.0, clojure.spec to Malli) and the 10x test coverage growth are the strongest evidence. These aren't line-count inflation -- they're substantive architectural improvements that were deferred for years because the effort didn't fit into evening sessions. AI changed the calculus.
This analysis is based entirely on git log data. Key things it cannot measure:
- Actual hours worked. An "active day" could be 30 minutes or 14 hours. The doubling of active days (53 to 112) means part of the output increase comes from more sessions, not just more productive sessions. The data cannot separate these effects.
- Quality beyond fix rate. User-facing bug reports, performance regressions, and security issues are not visible in commit messages.
- Lines != value. A 500-line schema migration and a 500-line new feature are very different. The AI era skews toward large mechanical refactors that produce many lines but aren't proportionally more valuable than careful 20-line bug fixes.
- Motivation vs tooling. New tools are exciting. Some of the output surge may reflect renewed enthusiasm rather than pure tool leverage. AI tools may also lower activation energy -- making it easier to start a session -- which conflates "more productive" with "more willing to work."
- Team composition changed. Juho contributed 268 commits in 2024 but ~28 in 2025. Some of Valtteri's 2025 increase may reflect absorbing Juho's scope. However, Valtteri's 2025 output exceeds his output in every year including those when Juho was active, so team size alone doesn't explain the jump.
- December 2025 is an outlier. 84,902 of 167,521 lines added (51%) came from one month that coincided with holiday time from the day job. Without December, 2025 had ~83k lines added -- still the second-highest year ever, and 3.7x the pre-AI side-job average, but not the dramatic 2.3x-over-full-time headline.
The most defensible summary: a developer working on a side project in limited hours, with AI assistance, produced output comparable to when the same project was his full-time job. The per-hour efficiency gain is likely substantial but not precisely measurable from git data alone.
LIPAS offers an unusually clean natural experiment. One developer, one codebase, eight years, three distinct working conditions. The developer didn't change. The codebase didn't change. The technology stack didn't change. What changed was time allocation (full-time to side-job) and then tooling (AI adoption). Git history records the consequences.
When LIPAS moved from full-time to side-job, output fell to a quarter of its previous level and stayed there for five years. That gap is what motivated the question this analysis set out to answer: can AI tools close it?
The data says largely yes. In the first eight months of AI-assisted development, a side-job developer produced 70% of his full-time commit volume, worked 87% as many active days, and completed architectural refactors that had been deferred for years. Test coverage -- the metric least susceptible to line-count inflation -- grew 10x. Fix rates stayed within their historical range. No reverts. Code churn identical to hand-written code from the same period.
The productivity gain is not purely "same hours, more output per hour." Active days doubled, meaning AI also changed how often the developer chose to work on the project. Whether this reflects lower friction, renewed motivation, or both, the end result is the same: more useful work shipped. The effect is real regardless of which mechanism dominates.
What stands out most is not the volume increase but the change in what gets done. Before AI, limited evening hours went to features and urgent fixes -- the work with immediate visible payoff. Technical debt accumulated. With AI handling the mechanical parts of cross-cutting refactors, the effort-to-value calculation shifted. Codebase-wide migrations, systematic test coverage, and dependency cleanup became viable in hour-long sessions. The project is in better structural shape than at any point in its history.
This is a single case study, not a controlled experiment. The confounds are real and acknowledged. But the consistency across metrics -- commits, lines, active days, test coverage, code survival, file churn -- all pointing in the same direction makes the signal hard to dismiss. For a solo developer maintaining a production system in limited hours, AI coding tools are not incremental. They are a step change.
Analysis performed 2026-02-21 using git log data from the LIPAS repository.