Eight years of wanting, three months of building with AI

Lalit Maganti · article · 2025-03-01 source ↗ Reader 🖥️

AI as Amplifier Code Quality Coding Agents Context Rot & Context Limits Mental Models & Understanding Software Design Fundamentals Taste & Judgment Vibe Coding

AI coding agents are a genuine force multiplier for implementation and last-mile polish, and can unlock projects that would otherwise die from the intersection of difficulty and tedium, but they are a dangerous substitute for design, architecture, and taste -- the developer must retain ownership of the soul of the software or risk building a codebase they cannot reason about.

practical · reflective essay / experience report — A practitioner's systematic post-mortem on building a real software project (syntaqlite, SQLite devtools) using AI coding agents over three months, structured as honest assessment rather than advocacy or dismissal.

Structure

Part	Role
Background and motivation (paragraphs 1-8)	Establishes the eight-year desire, the author's expertise (Perfetto/PerfettoSQL), and why the project was perpetually deferred.
What makes it hard and tedious (section 2)	Explains the technical difficulty -- SQLite has no formal grammar, no exposed parse tree, 400+ rules -- establishing that the project sits at the intersection of hard and tedious.
The vibe-coding month and pivot (paragraphs on January rewrite)	Narrates the failed first attempt at full delegation to AI, resulting in spaghetti code and a total rewrite.
AI is why this project exists (section 3)	Catalogues specific benefits: overcoming procrastination, obvious code generation, refactoring speed, research compression, domain bridging, last-mile features, UX headroom.
The toll AI took (slot-machine addiction, losing mental model, design procrastination, false test comfort)	Catalogues specific harms: addictive usage patterns, tiredness feedback loops, communication breakdowns, deferred design decisions, false confidence from generated tests.
The pattern of when AI helps vs hurts (expertise x verifiability matrix)	Synthesizes the experience into a two-axis framework: developer expertise and objective verifiability determine AI effectiveness.
Conclusion and call for honesty	Summarizes the eight-years-to-three-months arc and calls for more honest, detailed accounts from practitioners.

Key terms

vibe-coding Vibe Coding
Delegating nearly all design and implementation to AI while acting as a semi-technical manager, without maintaining deep ownership of the codebase.
obvious code Code Quality
Code where the specification can be fully expressed as 'write a function with this behaviour and parameters' -- implementation that has a locally checkable right answer.
taste Taste & Judgment
The human capacity to judge API design, architecture, and user experience -- qualities with no objectively checkable answer. Determines whether refactoring is merely rearranging or genuinely improving.
standard dialect Code Quality
The conventional, idiomatic way of writing code in a given language -- predictable, readable, unsurprising. AI defaults to this.
context pollution Context Rot & Context Limits
The problem that design decisions from one part of a codebase implicitly constrain other parts, and determining relevance requires exactly the institutional knowledge you are trying to externalize.
force multiplier AI as Amplifier
AI amplifies the developer's existing capability for implementation but does not substitute for missing capability in design or judgment.

Propositions

explicitAI coding agents are the reason syntaqlite exists; without them, the project would have remained indefinitely deferred.conf: high
explicitdevelopedAI changed what the project was, not just how fast it was built -- it enabled a level of completeness (editor extensions, docs site, WASM playground, packaging) that would have been cut without AI.conf: high
extends ←Running Python code in a sandbox with MicroPython and WASM · p5 — Willison generalizes the observation that AI changed what a solo project could be: coding agents make it economical for one developer to build infrastructure that previously required a team.
explicitAI is better than the author at writing obvious, well-scoped code but is somewhere between unhelpful and harmful for architecture and design.conf: high
explicitcorroboratedThe effectiveness of AI is determined by two axes: the developer's existing expertise in the domain and whether the task has an objectively checkable answer.conf: high
supports ←LLMs Reward Expertise · p1 — Both claims name domain expertise as the (or a) primary determinant of how much value a person gets from an LLM; this doc isolates and elaborates the expertise axis with a detailed mechanism (register-matching, correction, self-generated direction) that the other extract states more tersely.
extends ←LLMs Reward Expertise · p7 — Extends the two-axis (expertise + verifiability) framing into a forward-looking structural claim: as models improve, the expertise axis becomes relatively more binding because the information gap closes while the communication/elicitation gap does not.
explicitcontestedVibe-coding (full delegation to AI) produces functional but unmaintainable systems; the developer must take ownership of all design decisions and review every change.conf: high
contradicts ←Podcast: The AI Joy Gap: Why Some Developers Thrive While Others Struggle · p9 — Parker predicts the industry will eventually stop reviewing code entirely, incompatible with the claim that owning and reviewing every AI change is what keeps systems maintainable.
contradicts ←Vibe coding and agentic engineering are getting closer than I'd like · p1 — Willison reports abandoning line-by-line review of agent code in his own practice, against the review-every-change ownership rule.
explicitAI's lack of temporal understanding -- its inability to feel how code evolved over time -- is a fundamental limitation analogous to losing a senior engineer's institutional knowledge.conf: high
explicitUsing AI coding tools has addictive properties similar to slot machines, with sunk cost fallacy and tiredness feedback loops degrading output quality.conf: high
explicitThe normal rules of software engineering (clear architecture, well-defined boundaries, thoughtful design) still apply in the AI age and cannot be bypassed by generating more code or more tests.conf: high
explicitAI research assistance has the highest ratio of value delivered to time spent of all AI use cases.conf: high
implicitDevelopers who lose their mental model of an AI-generated codebase become the kind of disconnected manager that engineers have always complained about.conf: high
implicitcorroboratedThe ability to refactor cheaply with AI only has value if the developer has taste; without taste, cheap refactoring just rearranges confusion.conf: medium
supports ←You can't unit test for taste · p11 — The other doc: cheap AI work only has value if the developer has taste, else it 'rearranges confusion.' Here, without the human's taste the correct-by-the-numbers pipeline degrades into a population map.

Arguments

AI is an incredible force multiplier for implementation but a dangerous substitute for design. strength: high

Explicit premises:

AI is better than the author at writing obvious, well-scoped code.
AI struggles with tasks that have no objectively checkable answer.
The vibe-coding month produced functional but unmaintainable code that had to be discarded.
AI has no sense of history, taste, or how a human will feel using an API.

Implicit premises:

Software quality depends on both correct implementation and good design.
Design quality cannot be verified by automated tests or compilation.
The ratio of design-dependent to implementation-dependent work increases as a project matures.

Inferences:

Developers should use AI heavily for implementation while retaining full ownership of design.
The developer's role shifts from writing code to making design decisions, reviewing output, and maintaining taste.

AI effectiveness varies predictably along two axes: developer expertise and task verifiability. strength: high

Explicit premises:

When the author understood a domain deeply, AI output could be reviewed and iterated on quickly.
When the author could describe but didn't yet know a domain, AI was useful but required more care.
When the author didn't know what he wanted, AI led him down dead ends.
Even with deep expertise, AI struggled on tasks with no objectively checkable answer (e.g., API design).

Implicit premises:

The ability to evaluate AI output is a prerequisite for productive use.
Evaluation requires either domain knowledge or an objective correctness criterion (ideally both).

Inferences:

Knowing where you are on these axes at any moment is the core skill of working with AI effectively.

Continuous refactoring is essential when using AI to generate code at scale. strength: high

Explicit premises:

AI generates code at industrial scale.
The vibe-coding month showed that without refactoring, the codebase becomes impossible to reason about.
AI itself is good at executing refactoring when given direction.

Implicit premises:

Code entropy increases faster when generation speed exceeds comprehension speed.
Refactoring requires a human to identify the right abstractions.

Inferences:

The developer's workflow should alternate between generation and refactoring.
Taste determines whether refactoring is productive or merely cosmetic.

Narratives

The eight-year itch: carrying the SQLite devtools idea from teens-era open source enthusiasm through professional maturity, deferred by the intersection of difficulty and tedium, until AI made it viable.
→ Establishes emotional stakes and credibility; demonstrates that AI didn't just accelerate work but unlocked a psychologically blocked project.
The vibe-coding month and the rewrite: January spent delegating to Claude producing spaghetti code, followed by the decision to throw everything away, switch to Rust, and take ownership.
→ Central cautionary tale; the pivot point where the author learns the lesson that AI without design ownership produces waste.
The slot-machine loop: late-night prompting, sunk cost fallacy, tiredness degrading prompt quality, resulting in slower progress than manual coding.
→ Humanizes the account and warns about psychological hazards; positions AI tool use as requiring self-discipline.
Becoming the disconnected manager: losing the mental model of the codebase and finding himself unable to communicate effectively with the agent, mirroring the classic engineer-vs-manager dysfunction.
→ Reframes a familiar workplace dynamic as a personal risk of AI-assisted development; warns that the developer-AI relationship degrades when the developer stops reading the code.

Questions addressed

✅ Can AI coding agents enable projects that would otherwise never be built?
Yes -- syntaqlite is direct evidence. The project was deferred for eight years and completed in three months with AI.
✅ What is the right way to use AI for a serious software project?
Retain ownership of design; use AI as 'autocomplete on steroids' within a tight process of opinionated design, thorough review, eager refactoring, and automated scaffolding to check AI output.
✅ What are the psychological costs of using AI coding tools?
Addictive slot-machine dynamics, tiredness feedback loops, loss of mental model, deferred design decisions, false confidence from generated tests.
✅ When does AI help vs hurt in software development?
Two-axis framework: AI helps most when the developer has high expertise and the task has objectively checkable answers; it hurts most when expertise is low and answers are subjective.
⭕ Will AI fundamentally change the role of the software developer?
Partially addressed -- the author implies the role shifts toward design, review, and taste, but does not explore long-term implications.

Gaps

unstated assumptionThe author assumes that the inability to externalize institutional knowledge and design context is a fundamental limitation of AI, not merely a tooling limitation. This conflates current AI capabilities with inherent constraints. Future models with persistent memory, codebase-scale context, and temporal reasoning could potentially bridge this gap.
Read next: Read work on long-context models, AI memory architectures, and research on whether design taste can be formalized or learned (e.g., Christopher Alexander's pattern language as a possible bridge).
selection biasThe author is an exceptionally skilled systems programmer (C++, Android performance, SQLite internals). His experience with AI may not generalize to developers with less expertise, where the expertise-x-verifiability framework would place nearly all work in the low-expertise quadrant. The article does not address how junior developers should calibrate their AI use.
Read next: Look for studies on AI-assisted development among developers of varying skill levels; compare with Maganti's framework.
closed by13) Tobias K. Torrissen om kodekvalitet, konferanser og AI — Torrissen answers how juniors should calibrate AI use: learn IT architecture and core principles (TDD, design heuristics) before relying on language models — drive the Toyota Corolla before the Formula 1 car.
omissionThe article does not discuss the economics of AI-assisted development beyond the $200/month Claude Max subscription. The 250 hours of personal time invested is mentioned but not analyzed in terms of opportunity cost or compared to hiring/contracting alternatives.
Read next: Compare with analyses of AI coding tool ROI; consider the total cost including cognitive overhead and the discarded vibe-coding month.
unexamined tensionThe author claims 'AI didn't just make the same project faster -- it changed what the project was' (adding editor extensions, docs, WASM playground). But he also claims the core value comes from the parser architecture, which AI was harmful for. This raises the question: did AI expand the project's scope in the right direction, or did the cheap last-mile features dilute focus on the hard core?
Read next: Consider the 80/20 principle in open source: does breadth of features or depth of core reliability drive adoption?
implicit premiseThe expertise-x-verifiability framework assumes that 'taste' and design judgment are inherently human and non-formalizable. This is stated as obvious but is actually a deep philosophical claim about the nature of aesthetic and design knowledge. If taste could be partially formalized (as design systems and API design guidelines attempt), the framework's boundaries would shift.
Read next: Joshua Bloch's 'How to Design a Good API and Why It Matters'; API design guideline literature; whether LLMs can learn design heuristics from large corpora of well-designed APIs.

Eight years of wanting, three months of building with AI

Structure

Key terms

Propositions

Arguments

Narratives

Questions addressed

Gaps

Related documents