My 2025 GitHub contribution graph looks like it belongs to two different developers. The first half of the year is almost empty. The second half contains more than 4,000 commits.
I did not suddenly get more free time. I was still balancing a full-time job with side projects. What changed was the amount of friction between an idea and a verified change: I started using DeepSeek and other AI coding tools as part of my day-to-day Node.js workflow.
I want to be careful with the number because it is easy to tell the wrong story with it. Commit count is not a productivity metric. Four thousand commits do not mean four thousand meaningful improvements, and they say almost nothing about reliability, maintainability, or whether users benefited. What the graph does capture is a genuine change in behavior: I was opening projects more often, attempting smaller changes, testing ideas earlier, and shipping more consistently.
The interesting part was not that an AI could produce code. Code generation was only one piece. The bigger change was that many small forms of resistance—boilerplate, unfamiliar APIs, repetitive refactors, test setup, debugging hypotheses, documentation lookup, and “I should clean this up before I continue” work—became cheap enough that I stopped postponing them.
The bottleneck was activation energy, not ideas
Side projects rarely die because I run out of ideas. They die because the distance between an idea and the first useful feedback becomes too large. A feature may be conceptually simple while still requiring routing, validation, persistence, error handling, tests, deployment changes, and a dozen small decisions before I can see whether the idea is worth keeping.
Before I used AI coding tools seriously, I often treated that setup cost as a reason to postpone an experiment. If the first version looked like several evenings of routine work, the idea had to be unusually exciting to survive. Once I could offload parts of the mechanical work, I could reach a testable version while I still remembered why I cared about it.
This is the first change I would emphasize to anyone evaluating AI-assisted development: the largest gain is often not faster typing. It is a lower activation energy for small experiments. That changes which ideas get tested at all.
What changed in my Node.js workflow
I did not replace my development process with a chat window. I changed where I spent my attention. In Node.js projects, I started using DeepSeek as a second pair of hands for narrowly scoped work: drafting a first implementation, mapping unfamiliar code, proposing tests, explaining a stack trace, generating migration checklists, and turning a vague refactor into a sequence of smaller edits.
The most useful tasks were usually the ones with a clear local contract. If I could describe the inputs, expected outputs, constraints, and existing conventions, the model had a much better chance of producing something I could verify quickly. The less defined the task was, the more likely the answer was to look plausible while quietly choosing the wrong abstraction.
- Scaffolding: creating the boring first version of handlers, validation, scripts, or tests so I could focus on the decisions that actually mattered.
- Code reading: summarizing a module, tracing a request path, or identifying where a value was transformed before I started editing.
- Refactoring: splitting a large change into mechanical steps and checking that call sites, types, and error paths were updated consistently.
- Debugging: generating competing hypotheses from logs or stack traces instead of locking onto the first explanation that sounded right.
- Verification: proposing edge cases, failure cases, and regression tests after the implementation worked on the happy path.
- Operational work: reviewing configuration, release steps, scripts, and rollback assumptions with the same skepticism I would apply to application code.
My most reliable loop became deliberately boring: define the smallest useful change, give the model local context, ask for a plan if the edit crosses boundaries, apply a small patch, run the real checks, feed the exact failure back into the next iteration, and review the diff as if it came from a stranger.
That sounds slower than asking an AI to “implement everything,” but it saved time because it limited the blast radius of wrong assumptions. The cost of generating code is low. The cost of understanding a large incorrect change is not.
Where DeepSeek helped most—and where it did not
DeepSeek became useful to me because it was practical to use repeatedly for concrete programming tasks. I could ask for a first pass, reject part of it, provide the real error, narrow the task, and iterate without treating every prompt as a precious event.
I do not present that as a benchmark result. I did not run a controlled study against every competing model, and model quality changes too quickly for a personal preference to become a permanent ranking. The defensible claim is simply that DeepSeek fit my workflow well enough that I used AI assistance much more frequently, and that increased frequency changed how I approached side-project work.
It was strongest when the problem was concrete and the feedback was cheap: “here is the function, here are the tests, here is the failure.” It was weakest when the task depended on unstated product context, subtle architectural tradeoffs, or facts that were not present in the prompt. In those situations, fluent output could create more work by making a bad assumption look finished.
After enough repetitions, I started recognizing recurring failure modes: invented interfaces, local fixes that break a wider invariant, happy-path bias, unnecessary abstraction, silent behavior changes during refactors, and plausible configuration advice that is not valid for the actual runtime. The defense was not a magical prompt. It was a shorter verification loop.
AI changed the economics of experimentation
The biggest improvement was not “AI writes code, therefore development is automatic.” It was that many small pieces became cheap enough to attempt. A side-project feature that previously felt like too much setup could become something I could prototype while I still cared about the idea.
That distinction matters. AI reduced the cost of getting to a testable version. It did not make architecture, product judgment, deployment, or correctness disappear. A generated implementation can still be wrong; a successful build can still fail at runtime; a deployed prototype can still be a bad product.
For me, the practical benefit was momentum. Once I could see a system working, I was much more willing to keep refining it. More importantly, I could abandon weak ideas earlier because testing them was cheaper. Faster iteration is useful not only because good ideas ship sooner, but because bad ideas can die sooner.
The GitHub graph is visually persuasive, which is exactly why I do not want to overclaim from it. A workflow that encourages small, frequent commits can inflate the number without changing the amount of useful software produced. AI can also create rework: one generated patch, one correction, one cleanup, one regression fix. The graph records all four.
What a stronger benchmark would need
If I wanted to turn this experience into a reproducible benchmark, I would record exact model versions, fixed programming tasks, repository snapshots, prompts, raw outputs, elapsed time, accepted versus rejected patches, review time, test results, and the amount of rework required after each suggestion.
I would compare tasks by category. Boilerplate generation, debugging, refactoring, test design, code explanation, and architecture are different workloads. Compressing all of them into “which model codes best?” hides the information a developer actually needs.
I would also measure outcomes closer to the work I care about: time from idea to a verified first version, time spent reviewing generated changes, escaped defects, rollback frequency, rework, and how often an experiment produced information that changed a decision. Velocity is easy to see; quality requires instrumentation and patience.
As my use of AI increased, the boundary of what I wanted to keep under direct human control also became clearer. I am happy to delegate mechanical work. I do not want to delegate responsibility. Data models, irreversible migrations, security-sensitive behavior, public API semantics, destructive operations, and architectural changes that are expensive to undo still require an owner who understands the consequences.
What changed for me
2025 was the year I stopped treating every side project as a mountain of setup I had to climb manually. AI made the first working version cheap enough that I could reach the part where product decisions actually mattered more often.
That is the real reason the second half of my GitHub graph looks so different. Not because AI gave me more hours, and not because every generated line was good. It reduced friction: the delay between noticing a problem, attempting a change, and getting evidence about whether that change worked.
The lesson I am carrying forward is not “generate more code.” It is build shorter feedback loops. Use AI where it makes an experiment cheaper, keep diffs small, verify aggressively, and measure outcomes that matter more than activity.
If faster development produces faster learning, it is valuable. If it only produces more code, more commits, and more things to maintain, the graph may look impressive while the project quietly gets worse.