When I was implementing my weather station system, I asked myself: what if I built it again but this time using AI?
The idea I had in mind was t...
For further actions, you may consider blocking this person and/or reporting abuse
second build always goes faster - you’ve already solved the domain problems once. the interesting comparison would be two teams starting cold, not one dev running two passes. AI gets credit for your own prior learning.
You're completely right. I mention in the article that the time comparison maybe is not as impressive as It seems due to the reason you are stating.
This a personal project I have mplemented in my free time, I don't have a team unless my son learns to program :-)
Solo project changes the calculus completely — no team history to control for. Future pair programmer incoming.
Really enjoyed the honesty in this comparison. The part that stood out to me was your point that AI looked much faster partly because the problem was already well understood, while the non-AI version included the real learning curve and refactoring cost. Also interesting that Sonar showed lower technical debt for the AI version but much higher cognitive complexity — that feels very true in practice. As an AI founder, I think this is the right framing: AI compresses iteration time, but it doesn’t remove the need for judgment.
That is the most important thing for me when developing with AI: how to avoid the loss of judgement that can be provoked by the business pressure for velocity.
Exactly — velocity pressure is its own form of technical debt for judgment. When you're building under time pressure, you stop asking "is this the right abstraction?" and start asking "does it work right now?"
I've noticed AI amplifies whatever decision-making mode you're already in. If you're in slow/deliberate mode, it helps you build more. If you're in fast/deadline mode, it helps you skip the uncomfortable questions faster.
The discipline of stopping to think — "why did the AI suggest this?" — is what separates good AI-assisted dev from accumulated invisible debt.
100% agree!
The meta-discipline of pausing to ask that question gets harder under pressure precisely when it matters most. One pattern Ive found useful: treat it like a code review rule -- never merge AI-generated code without being able to explain why it works, not just that it works. The explanation itself surfaces the judgment gaps. The projects where AI hurt the most were the ones where we shipped fast and never had that reckoning. The debt did not show up in the code -- it showed up in the teams mental model of the system.
As someone once said: "With great power comes great responsibility" 😉
The honest part of this writeup is the bit about running out of free Gemini and OpenRouter tokens. That is the experience nobody who writes the breathless AI productivity threads ever mentions. I tried the same comparison on a side project last month: same scope, two passes, one with Claude and one by hand. The AI pass got me to a runnable demo in about 40% of the time, but I spent the next two weekends fixing edge cases the model had silently papered over. By the end the total wall-clock was roughly identical. The thing I cannot evaluate honestly is which version I will be willing to maintain a year from now.
In my case I'm maintaining the handmade version because I know exactly the purpose of each line of code.
Thanks Andrii!
Maintaining the handmade version because you know every line is the strongest argument I have read for hand-rolled code in months. The cost is not the time you spend writing it it is the time you do not spend later trying to recover ownership of code an LLM wrote and you signed off on. The honest test is whether you would rewrite from scratch in a week if it disappeared. Hand-rolled almost always passes that test. AI-assisted almost never.
The maintenance cost of software is always higher than the cost of building it. We can still use AI for maintenance but at some point we will have to dirt our hands and solve an issue ourselves. The thing here is how to maintain certain level of ownership that enable us to solve it.
Is code review the only way to feel accountable of the solution? Should we delegate to AI only certain tasks, the easy and boring ones and do by ourselves the complex and critical ones? For me that is the key point, know when to use AI and when not.
Code review accountability works only if the reviewer actually rebuilds the mental model. Saw a team try 'AI does the boring 80%, humans review.' They became signoff machines in 3 weeks. The escape: rotate which 20% the human writes from scratch, weekly. Keeps the muscle warm. The split isn't 'easy vs complex' it's 'do you still know how the system works.'
Good point Andrii, know how the system works should be the goal. 100% agree!
Great breakdown of your experience! From the rewrite approach section I knew it was going to be fair and balanced.
Thanks for your kind comment. I'm glad you liked it! 😊
This is one of the most realistic comparisons of AI vs non-AI development I’ve read. The time-saving benefits of AI are impressive, but your experience clearly shows that speed doesn’t always mean better quality or easier debugging. I especially agree with the point that vague specifications can create more confusion with AI than with human developers. AI works best as a coding assistant, not a replacement for problem-solving and engineering judgment. The balance between human expertise and AI tools will probably define the future of software development.
Exactly, finding when to use AI and when not is key.
Regarding specifications, I remember myself, in the early 2000, reading hundreds of pages of software requirement specification documents. They aim to be accurate to let the developers translate them into code without problems. But the reality was that these documents always contains gaps and sometimes contradictory statements depending the page you were reading.
Thanks for your comment Jack!
The speed gap is real, but there's an interesting second-order effect nobody talks about: AI-generated code tends to converge on the same patterns because it's trained on the same corpus. Build 10 projects with AI assistance and you'll notice eerily similar architectures across all of them. The non-AI version is slower but more likely to produce novel solutions. For production code that needs to be maintained for years, that architectural diversity matters more than the initial velocity.
Exactly, this is another important concern, what can happen to innovation if we rely on AI to solve problems? Software development is a creative discipline as each context has its own solution, we can use patterns but each one has to be adapted to the context it is applied. AI, as any other tool, is not a silver bullet.
Your token limit struggles on Gemini/OpenRouter are relatable. Generic LLMs lack deep context for specialized tasks, hitting a wall beyond general knowledge.
This is crucial for our drug-interaction graph.
You're right, maybe I should use Claude or Codex, but OpenCode worked quite well.
I don't know how it is compared with others but, at least for learning and for what I needed in this personal project, it was ok for me.
Really appreciated how honest and balanced this was. A lot of AI discussions focus only on speed, but you highlighted something equally important, the mental overhead of trusting and maintaining generated code. The part about AI struggling with authentication flows and repeatedly missing the actual root cause felt very real.
Also loved your point that writing extremely precise specs can sometimes feel harder than just coding the thing yourself 😅 Great read.
Cognitive debt, frustration, accountability, ... these hidden costs that are hard to measure but you can see and feel, are the most concerning things when using AI from my point of view.
Thanks Anupam!
These side-by-side experiments are the most useful AI content right now, mostly because they expose the second-order effects nobody quantifies. The AI build often finishes first but accumulates implicit decisions the author can't reconstruct three weeks later, and that's the cost line that bites on the second iteration, not the first. The race-to-MVP comparison flatters AI, the maintenance-six-months-in comparison usually doesn't.
Technical and cognitive debt, reliability, accountability, ... downsides that most of the people that blindly follow AI don't want to take into account because... velocity!
Exactly. Velocity without architectural continuity eventually converts into operational drag. The tricky part is that the cost usually appears later: inconsistent patterns, decision drift, review fatigue, and systems that become harder to reason about over time. AI massively amplifies throughput, but it also amplifies divergence if constraints aren’t enforced somewhere in the workflow.
Exactly. Velocity without architectural continuity eventually converts into review bottlenecks, drift, and operational fragility.
A lot of the industry is still optimizing for generation throughput while underestimating the governance layer needed to sustain that throughput safely.
This is one of the more useful AI coding comparisons because it separates “time saved” from “confidence in the result.” The part about AI being great for bounded tasks but stressful for whole-project ownership feels very accurate. The hidden cost is not just code review, it is rebuilding enough understanding to trust what was generated.
Indeed! I'm more concerned about the hidden cost in form of stress or cognitive debt than the outcome of AI.
Thanks Leonard!
The complexity gap between AI-assisted and handwritten code hit close to home. I built my entire audio synthesis engine from scratch — Karplus-Strong guitar, physical rain models, convolution reverb — and the reason I didn't use AI to generate it is exactly what you described. When the code is doing something physically precise, like modelling string damping or wave periods from resting heart rate, you can't just eyeball the output and trust it sounds right. You have to understand every line. AI-generated synthesis code that's slightly wrong doesn't throw an error — it just sounds subtly off, and you'll never catch it if you don't own the logic.
Apart of understanding every line, handmade programming also provides another benefit, the domain knowledge you acquire while solving the problem. When we delegate the solution to the AI for the sake of velocity we are externalizing the domain knowledge.
That's the part that's hardest to quantify but easiest to feel when it's missing. Every time I had to fix why a rain model sounded wrong or why the string damping felt unnatural, I came out the other side actually understanding the physics — not just the code. That knowledge is now baked into how I think about the next feature. If AI had generated those solutions, I'd have working audio and zero intuition about why it works. And the moment something breaks in a subtle way, I'd be completely blind to where to even look.
Even with prompts like "write deletable code and dead simple to understand", it still produces complex code.
Humans still write better maintainable code in my opinion.
I guess unless we have to read the AI generated code it's fine.
Exactly! Because to apply correctly this prompt "write deletable code and dead simple to understand" is required understanding and judgement, something that only a real human can provide.
Thanks for your comment!
Your line on "AI amplifies whatever decision-making mode you're already in" lines up with what we see on the product side. We build AI-assisted tooling for audiobook creators — an auto-assign pass tags character voices and sound design across a chapter, and the writer edits from there. The pattern that keeps judgment in the loop without slowing the work is framing every AI output as a starting point that's editable in-place, rather than asking the user to spec everything precisely up front (which, as you note, is often harder than just doing the task). The hidden-debt risk you flag shows up even outside code — for us it's users accepting the auto-assign output uncritically because it looks competent, not because they've verified the character attribution matches what they wrote. The mitigation ends up being UI choices that make the human review feel like the work, not a checkpoint to skip.
Maybe the way to work with AI is, instead of writing a detailed spec, have a clear idea of what you want to do, prepare a plan and let it do the work (or some of it) step by step.
Thanks for your comment!
Really enjoyed the honest comparison. AI definitely helps speed things up, but your examples show why real dev experience still matters.
Thanks!
The point is: "AI is a good tool, an amazing one, but you still need to know how to write code."
Exactly, the judgement to evaluate the AI output arises from writing code! Thanks!