23 ms·

Eight years of wanting, three months of building with AI

959 points by brilee 6mo ago

nightrate_ai 6mo ago
[dead]
PaulHoule 6mo ago
Note I believe this one because of the amount of elbow grease that went into it: 250 hours! Based on smaller projects I’ve done I’d say this post is a good model for what a significant AI-assisted systems programming project looks like.
rlenf 6mo ago
[flagged]
- adrian_b 6mo ago
  Unlike many claims that AI works that are clearly bogus, this actually seems quite credible, because TFA describes in detail many problems encountered, which could have easily lead to a failure of the project, if not properly addressed. There is no doubt that when used in the right way an AI coding assistant can be very helpful, but using it in the right way does not result in the fantastic productivity-increasing factors claimed by some. TFA describes a way of using AI that seems right and it also describes the temptations of using AI wrong, which must be resisted. More important is whether the productivity improvement is worth a subscription price. Nothing that I have seen until now convinces me about this. On the other hand, I believe that running locally a good open-weights coding assistant, so that you do not have to worry about token price or about exceeding subscription limits in a critical moment, is very worthwhile. Unfortunately, thieves like Altman have ensured that running locally has become much more difficult than last year, due to the huge increases in the prices of DRAM and of SSDs. In January I have been forced to replace an old mini-PC, but I was forced to put in the new mini-PC only 32 GB of DDR5, the same as in the 7-year old replaced mini-PC. If I had made the upgrade a few months earlier, I would have put in it 96 GB, which would have made it much more useful. Fortunately, I also have older computers with 64 GB or 128 GB DRAM, where bigger LLMs may be run.
  - steveBK123 6mo ago
    > More important is whether the productivity improvement is worth a subscription price. Nothing that I have seen until now convinces me about this. On the other hand, I believe that running locally a good open-weights coding assistant, so that you do not have to worry about token price or about exceeding subscription limits in a critical moment, is very worthwhile. This is one thing I also wonder about. If it's a really good programming helper, making 20% of your job 5x faster, then you can compute the value. Say for a $250K SWE this looks like $40k/year roughly. You don't want to hand 100% of that value to the LLM providers or you've just broken even, so then maybe it is worth $200/mo.
    - adrian_b 6mo ago
      Such a reckoning is possible when the cost of a subscription is truly predictable. For now, there is a lot of unpredictability in the future cost of AI, whenever you do not host it yourself. If you pay per token, it is extremely hard to predict how many tokens you will need. If you have an apparently fixed subscription, it is very hard to predict whether you will not hit limits in the most inconvenient moment, after which you will have to wait for a day or so for the limits to be reset. Recently, there have been a lot of stories where the AI providers seem to try to reduce continuously the limits allowed by a subscription. There is also a lot of incertitude about future raises of the subscription prices, as the most important providers appear to use prices below their expenses, for now. Therefore, while I agree with you that when something provides definite benefits you should be able to assess whether paying for it provides a net gain for you, I do not believe that using an externally-hosted AI coding assistant qualifies for such an assessment, at least not for now.
      - adrian_b 6mo ago
        EDIT: After I have written the above, that the future cost of externally-hosted AI coding assistants is unpredictable, what I have written was confirmed by an OpenAI press release that the existing Codex users will be migrated during the following weeks towards token-based pricing rates. Such events will not affect you if you use an open-weights assistant running on your own HW, when you do not have to care about token usage.
- NewsaHackO 6mo ago
  It's funny that he used Claude instead of gemini for this. Idk if his company is happy with free advertisement of a competitor
  - What1293 6mo ago
    Google owns 14% of Anthropic: https://techcrunch.com/2025/03/11/google-has-given-anthropic-more-funding-than-previously-known-show-new-filings/ https://techcrunch.com/2025/03/11/google-has-given-anthropic... They don't care. They want software engineers replaced by any means necessary. They know generative AI isn't a big business, that is why they slowwalk it themselves. Replacement won't work of course, that is why marketing blog posts are needed.
    - NewsaHackO 6mo ago
      But they own 100% of Google, correct?
deleted 6mo ago
[deleted]
simondotau 6mo ago
This essay perfectly encapsulates my own experience. My biggest frustration is that the AI is astonishingly good at making awful slop which somehow works. It’s got no taste, no concern for elegance, no eagerness for the satisfyingly terse. My job has shifted from code writer to quality control officer. Nowhere is this more obvious in my current projects than with CRUD interface building. It will go nuts building these elaborate labyrinths and I’m sitting there baffled, bemused, foolishly hoping that THIS time it would recognise that a single SQL query is all that’s needed. It knows how to write complex SQL if you insist, but it never wants to. But even with those frustrations, damn it is a lot faster than writing it all myself.
- pizzafeelsright 6mo ago
  Trim your scope and define your response format prior to asking or commanding. Most of my questions are "in one sentence respond: long rambling context and question"
- lyricalstring 6mo ago
  This is the thing that gets me. The code compiles. Passes tests. So you stop reading it. Why wouldn't you. Then three weeks later you're tracing some control flow that makes no sense and nobody knows why it's structured that way. Not you, not the model. I've been treating it like code from a contractor now, review every line same as a junior dev's PR. Gets tedious but the alternative is worse.
  - simondotau 6mo ago
    I’ve been treating it like a glorified autocomplete, or a glorified search and replace. Everything else is saxophone jazz when I’m writing for a string quartet: useful for inspiration, useful for understanding what isn’t clearly explained, sometimes it builds a decent first attempt, occasionally it gets shockingly close, but I’ve learned to never let my guard down. Go too far and untangling its slop becomes burdensome. Leave it to its own devices for more than a few rounds and it can become so unfixable it’s easier to start from scratch.
- mtrifonov 6mo ago
DareTheDev 6mo ago
This is very close to my experience. And I agree with the conclusion I would like to see more of this
bvan 6mo ago
This a very insightful post. Thanks for taking the time to share your experience. AI is incredibly powerful, but it’s no free-lunch.
Aurornis 6mo ago
Refreshing to see an honest and balanced take on AI coding. This is what real AI-assisted coding looks like once you get past the initial wow factor of having the AI write code that executes and does what you asked. This experience is familiar to every serious software engineer who has used AI code gen and then reviewed the output: > But when I reviewed the codebase in detail in late January, the downside was obvious: the codebase was complete spaghetti14. I didn’t understand large parts of the Python source extraction pipeline, functions were scattered in random files without a clear shape, and a few files had grown to several thousand lines. It was extremely fragile; it solved the immediate problem but it was never going to cope with my larger vision, Some people never get to the part where they review the code. They go straight to their LinkedIn or blog and start writing (or having ChatGPT write) posts about how manual coding is dead and they’re done writing code by hand forever. Some people review the code and declare it unusable garbage, then also go to their social media and post how AI coding is completely useless and they’re not going to use it for anything. This blog post shows the journey that anyone not in one of those two vocal minorities is going through right now: A realization that AI coding tools can be a large accelerator but you need to learn how to use them correctly in your workflow and you need to remain involved in the code. It’s not as clickbaity as the extreme takes that get posted all the time. It’s a little disappointing to read the part where they said hard work was still required. It is a realistic and balanced take on the state of AI coding, though.
- vasco 6mo ago
  Those extreme takes are taken mostly for clicks or are exaggerated second hand so the "other side's" opinion is dumber than it is to "slam the naysayers". Most people are meh about everything, not on the extremes, so to pander to them you mock the extremes and make them seem more likely. It's just online populism.
- libraryofbabel 6mo ago
  Agree. This is such a good balanced article. The only things that still make the insights difficult to apply to professional software development are: this was greenfield work and it was a solo project. But that’s hardly the author’s fault. It would however be fantastic to see more articles like this about how to go all in on AI tools for brownfield projects involving more than one person. One thing I will add: I actually don’t think it’s wrong to start out building a vibe coded spaghetti mess for a project like this… provided you see it as a prototype you’re going to learn from and then throw away. A throwaway prototype is immensely useful because it helps you figure out what you want to build in the first place, before you step down a level and focus on closely guiding the agent to actually build it. The author’s mistake was that he thought the horrible prototype would evolve into the real thing. Of course it could not. But I suspect that the author’s final results when he did start afresh and build with closer attention to architecture were much better because he has learned more about the requirements for what he wanted to build from that first attempt.
billylo 6mo ago
Thank you. The learning aspect of reading how AI tackles something is rewarding. It also reduces my hesitation to get started with something I don't know the answer well enough yet. Time 'wasted' on vibe-coding felt less painful than time 'wasted' on heads-down manual coding down a rabbit hole.
rokob 6mo ago
> architecture is what happens when all those local pieces interact, and you can’t get good global behaviour by stitching together locally correct components This is a great article. I’ve been trying to see how layered AI use can bridge this gap but the current models do seem to be lacking in the ambiguous design phase. They are amazing at the local execution phase. Part of me thinks this is a reflection of software engineering as a whole. Most people are bad at design. Everyone usually gets better with repetition and experience. However, as there is never a right answer just a spectrum of tradeoffs, it seems difficult for the current models to replicate that part of the human process.
- physicles 6mo ago
  I’ve had a couple wins with AI in the design phase, where it helped me reach a conclusion that would’ve taken days of exploration, if I ever got there. Both were very long conversations explicitly about design with lots of back and forth, like whiteboarding. Both involved SQL in ClickHouse, which I’m ok but not amazing at — for example I often write queries with window functions, but my mental model of GROUP BY is still incomplete. In one of the cases, I was searching for a way to extract a bunch of code that 5-6 queries had in common. Whatever this thing was, its parameters would have to include an array/tuple of IDs, and a parameter that would alter the table being selected from, neither of which is allowed in a clickhouse parameterized view. I could write a normal view for this, but performance would’ve been atrocious given ClickHouse’s ok-but-not-great query optimizer. I asked AI for alternatives, and to discuss the pros and cons of each. I brought up specific scenarios and asked it how it thought the code would work. I asked it to bring what it knew about SQL’s relational algebra to find the an elegant solution. It finally suggested a template (we’re using Go) to include another sql file, where the parameter is a _named relation_. It can be a CTE or a table, but it doesn’t matter as long as it has the right columns. Aside from poor tooling that doesn’t find things like typos, it’s been a huge win, much better than the duplication. And we have lots of tests that run against the real database to catch those typos. Maybe this kind of thing exists out there already (if it does, tell me!) but I probably wouldn’t have found it.
  - neonstatic 6mo ago
4b11b4 6mo ago
Great write-up with provenance
myultidevhq 6mo ago
The 8-year wait is the part that stands out. Usually the question is "why start now" not "why did it take 8 years". Curious if there was a specific moment where the tools crossed a threshold for you, or if it was more gradual.
- bdcravens 6mo ago
  For me, the amount of tedium that comes with any new project before I can get to the "good stuff" is a blocker. It's so easy to sit down with excitement, and then 3 hours later, you're still wrestling with basic dependencies, build pipelines, base CSS, etc.
  - 8organicbits 6mo ago
    Have you tried using starting templates for projects? For many platforms there are cookiecutters or other tools to jump over those.
- jayd16 6mo ago
  It's kind of click bait tho. "I took 3 months and AI to build a SQLite tool" is not going to stand out. The 8 year wait gives a sense of scale or difficulty but that's actually an illusion and does not reflect the task itself.
The_Goonies1985 6mo ago
The author mentions a C codebase. Is AI good at coding in C now? If so, which AI systems lead in this language? Ideally: local; offline. Or do I have to wrestle it for 250 hours before it coughs up the dough? Last time I tried, the AI systems struggled with some of the most basic C code. It seemed fine with Python, but then my cat can do that.
- Morpheus_Matrix 6mo ago
  [flagged]
  - The_Goonies1985 6mo ago
    Thanks Morpheus_Matrix. I'll take a look at Qwen 2.5 Coder 32B for offline C. I appreciate your guidance. By extraordinary coincidence, I was just a moment ago part-of-the-way through re-watching The Matrix (1999) and paused it to check Hacker News. There your reply greeted me. Wild glitch!
    - adrian_b 6mo ago
      There is also a successor to that: Qwen3-Coder-Next, which is a newer and bigger model, but it obviously requires more hardware resources, being an 80B model. However it is likely to be the most powerful open weights coding assistant that you can run locally, without having to worry about token price or reaching the subscription limits in the most inconvenient moment.
zer00eyz 6mo ago
This article is describing a problem that is still two steps removed from where AI code becomes actually useful. 90 percent of the things users want either A) dont exist or B) are impossible to find, install and run without being deeply technical. These things dont need to scale, they dont need to be well designed. They are for the most part targeted, single user, single purpose, artifacts. They are migration scripts between services, they are quick and dirty tools that make bad UI and workflows less manual and more managable. These are the use cases I am seeing from people OUTSIDE the tech sphere adopt AI coding for. It is what "non techies" are using things like open claw for. I have people who in the past would have been told "No, I will not fix your computer" talk to me excitedly about running cron jobs. Not everything needs to be snap on quality, the bulk of end users are going to be happy with harbor freight quality because it is better than NO tools at all.
- throw5 6mo ago
  > This article is describing a problem that is still two steps removed from where AI code becomes actually useful. But it does a good job of countering the narrative you often see on LinkedIn, and to some extent on HN as well, where AI is portrayed as all-capable of developing enterprise software. If you spend any time in discussions hyping AI, you will have seen plenty of confident claims that traditional coding is dead and that AI will replace it soon. Posts like this is useful because it shows a more grounded reality. > 90 percent of the things users want either A) dont exist or B) are impossible to find, install and run without being deeply technical. These things dont need to scale, they dont need to be well designed. They are for the most part targeted, single user, single purpose, artifacts. Yes, that is a particular niche where AI can be applied effectively. But many AI proponents go much further and argue that AI is already capable of delivering complex, production-grade systems. They say, you don't need engineers anymore. They say, you only need product owners who can write down the spec. From what I have seen, that claim does not hold up and this article supports that view. Many users may not be interested in scalability and maintainability... But for a number of us, including the OP and myself, the real question is whether AI can handle situations where scalability, maintainability and sound design DO actually matter. The OP does a good job of understanding this.
lubujackson 6mo ago
Long term, I think the best value AI gives us is a poweful tool to gain understanding. I think we are going to see deep understanding turn into the output goal of LLMs soon. For example, the blocker on this project was the dense C code with 400 rules. Work with LLMs allowed the structure and understanding to be parsed and used to create the tool, but maybe an even more useful output would be full documentation of the rules and their interactions. This could likely be extracted much easier now from the new code, but imagine API docs or a mapping of the logical ruleset with interwoven commentary - other devtools could be built easily, bug analysis could be done on the structure of rules independent of code, optimizations could be determined on an architectural level, etc. LLMs need humans to know what to build. If generating code becomes easy, codifying a flexible context or understanding becomes the goal that amplifies what can be generated without effort.
- thunfischbrot 6mo ago
  Looks like a clear divide in people‘s experiences based on how they use these new tools: 1) All-knowing oracle which is lightly prompted and develops whole applications from requirements specification to deployable artifacts. Superficial, little to no review of the code before running and committing. 2) An additional tool next to their already established toolset to be used inside or alongside their IDE. Each line gets read and reviewed. The tool needs to defend their choices and manual rework is common for anything from improving documentation to naming things all the way to architectural changes. Obviously anything in between as well being viable. 1) seems like a crazy dead-end to me if you are looking to build a sustainable service or a fulfilling career.
alejandrosplitt 6mo ago
[dead]
intensifier 6mo ago
article looks like a tweet turned into 30 paragraphs. hardly any taste.
- throw5 6mo ago
  Yes, how dare someone take an idea, develop it, and publish it outside the algorithm-driven rage pit. Truly terrible behavior! /s Expanding a thought beyond 280 characters and publishing it somewhere other than the X outrage machine is something we should be encouraging.
- cloche 6mo ago
  This is what a lot of business books are TBH
meidad_g 6mo ago
[flagged]
TraceAgently 6mo ago
[dead]
techpulselab 6mo ago
[dead]
edfletcher_t137 6mo ago
> Of all the ways I used AI, research had by far the highest ratio of value delivered to time spent. Seconded!
pwr1 6mo ago
This resonates. I had a project sitting in my head for years and finally built it in about 6 weeks recently. The AI part wasn't even the hard part honestly, it was finally commiting to actually shipping instead of overthinking the architecture. The tools just made it possible to move fast enough that I didn't lose momentum and abandon it like every other time.
jillesvangurp 6mo ago
This is the hardest it's ever going to be. That's been my mode for the last year. A lot of what I did in the last month was complete science fiction as little as six months ago. The scope and quality of what is possible seems to leap ahead every few weeks. I now have several projects going in languages that I've never used. I have a side project in Rust, and two Go projects. I have a few decades experience with backend development in Java, Kotlin (last ten years) and occasionally python. And some limited experience with a few other languages. I know how to structurer backend projects, what to look for, what needs testing, etc. A lot of people would insist you need to review everything the AI generates. And that's very sensible. Except AI now generates code faster than I can review it. Our ability to review is now the bottleneck. And when stuff kind of works (evidenced by manual and automated testing), what's the right point to just say it's good enough? There are no easy answers here. But you do need to think about what an acceptable level of due diligence is. Vibe coding is basically the equivalent of blindly throwing something at the wall and seeing what sticks. Agentic engineering is on the opposite side of the spectrum. I actually emphasize a lot of quality attributes in my prompts. The importance of good design, high cohesiveness, low coupling, SOLID principles, etc. Just asking for potential refactoring with an eye on that usually yields a few good opportunities. And then all you need to do is say "sounds good, lets do it". I get a little kick out of doing variations on silly prompts like that. "Make it so" is my favorite. Once you have a good plan, it doesn't really matter what you type. I also ask critical questions about edge cases, testing the non happy path, hardening, concurrency, latency, throughput, etc. If you don't, AIs kind of default to taking short cuts, only focus on the happy path, or hallucinate that it's all fine, etc. But this doesn't necessarily require detailed reviews to find out. You can make the AI review code and produce detailed lists of everything that is wrong or could be improved. If there's something to be found, it will find it if you prompt it right. There's an art to this. But I suspect that that too is going to be less work. A lot of this stuff boils down to evolving guardrails to do things right that otherwise go wrong. What if AIs start doing these things right by default? I think this is just going to get better and better.
- jaccola 6mo ago
  But why are you making projects in so many languages? The language is very rarely the barrier to performance, especially if you don't even understand the language.
senthilnayagam 6mo ago
when he decided on rust, he could have looked up sqlite port, libsqlite does a pretty good job.
dirtbag__dad 6mo ago
> Tests created a similar false comfort. Having 500+ tests felt reassuring, and AI made it easy to generate more. But neither humans nor AI are creative enough to foresee every edge case you’ll hit in the future; there are several times in the vibe-coding phase where I’d come up with a test case and realise the design of some component was completely wrong and needed to be totally reworked. This was a significant contributor to my lack of trust and the decision to scrap everything and start from scratch. This is my experience. Tests are perhaps the most challenging part of working with AI. What’s especially awful is any refactor of existing shit code that does not have tests to begin with, and the feature is confusing or inappropriately and unknowingly used multiple places elsewhere. AI will write test cases that the logic works at all (fine), but the behavior esp what’s covered in an integration test is just not covered at all. I don’t have a great answer to this yet, especially because this has been most painful to me in a React app, where I don’t know testing best practices. But I’ve been eyeing up behavior driven development paired with spec driven development (AI) as a potential answer here. Curious if anyone has an approach or framework for generating good tests
- whattheheckheck 6mo ago
  Use tla+ and have it go back and forth with you to spec out your system behavior then iterate on it trying to link the tla+ spec with the actual code implementing it Pull out as many pure functions as possible and exhaustively test the input and output mappings.
  - gck1 6mo ago
    The problem with specs for me is always with boundaries. How many specs do you have for a complex project? How do they reference each other? What happens when requirements cross boundaries? And finally, how do you address spec drift?
- suzzer99 6mo ago
  I've always thought that writing good tests (unit, integration or e2e) is harder than the actual coding by maybe an order of magnitude. The tricky part of unit tests is coming up with creative mocks and ways to simulate various situations based on the input data, w/o touching the actual code. For integration tests, it's massaging the test data and inputs to hit every edge case of an endpoint. For e2e tests, it's massaging the data, finding selectors that aren't going to break every time the html is changed, and trying to winnow down to the important things to test - since exhaustive e2e tests need hours to run and are a full-time job to maintain. You want to test all the main flows, but also stuff like handling a back-end system failure - which doesn't get tested in smoke tests or normal user operations. That's a ton of creativity for AI to handle. You pretty much have to tell it every test and how to build it.
afron_manyu 6mo ago
[dead]
toniantunovi 6mo ago
[dead]
huflungdung 6mo ago
[dead]
holoduke 6mo ago
A key take away from this article is that you as a developer spending as much time on refactoring as on the actual feature. You are constantly requesting code reviews, architectural assessements, consolidations, extractions etc. only then you can empower AI to become a force multiplier. And prevent slop and spaghetti code to be created. Nice article
ang_cire 6mo ago
It's a huge mistake to start building with Claude without mapping out a project in detail first, by hand. I built a pretty complex device orchestration server + agent recently, and before I set Claude to actually coding I had ~3000 lines of detailed design specs across 7 files that laid out how and what each part of the application would do. I didn't have to review the code for understanding what Claude did, I reviewed it for verifying that it did what it had been told. It's also nuts to me that he had to go back in later to build in tests and validation. The second there is an input able to be processed, you bet I have tests covering it. The second a UI is being rendered, I have Playwright taking screenshots (or gtksnapshot for my linux desktop tools). I think people who are seeing issues at the integration phase of building complex apps are having that happen because they're not keeping the limited context in mind, and preempting those issues by telling their tools exactly how to bridge those gaps themselves.
- DANmode 6mo ago
  Do you write anywhere else? Really enjoy your style.
  - ang_cire 6mo ago
    Thank you! Not anywhere but forums. I used to have a blog, but I haven't posted anything in years.
- lalitmaganti 6mo ago
  > It's a huge mistake to start building with Claude without mapping out a project in detail first, by hand. I agree with you in theory but in my opinion, it doesn't work so well when you don't even know what exactly you are looking for at the start. Yes I knew I wanted a formatter, linter, parse but which language should those be written in, should they be one project or many, how the pieces should fit together, none of that was clear to me. As I pointed out in the article, in these sort of "greenfield projects" I work a lot better with concrete prototypes and code in front of me I can dissect instead of trying to endlessly play with designs in my head. > It's also nuts to me that he had to go back in later to build in tests and validation. I think this is a little misleading. Yes I did do some testing retroactively (i.e. the upstream validation testing) but I was using TDD + verifying outputs immediately, even during the vibe coding phase. The problem as I point out is that this is not enough. Even when I had unit tests written at the same time as they code, they had lots of holes and over time, I kept hitting SQL statements which failed which the testing did not cover.
cloche 6mo ago
Really great to see a realistic experience sans hype about AI tools and how they can have an impact. > But when I reviewed the codebase in detail in late January, the downside was obvious: the codebase was complete spaghetti...It was extremely fragile; it solved the immediate problem but it was never going to cope with my larger vision...I decided to throw away everything and start from scratch This part was interesting to me as it lines up with Fred Brooks "throw one away" philosophy: "In most projects, the first system built is barely usable. Hence plan to throw one away; you will, anyhow." As indicated by the experience, AI tools provide a much faster way of getting to that initial throw-away version. That's their bread and butter for where they shine. Expecting AI tools to go directly to production quality is a fool's errand. This is the right way to use AI - get a quick implementation, see how it works and learn from it but then refactor and be opinionated about the design. It's similar to TDD's Red, Green, Refactor: write a failing test, get the test passing ASAP without worrying about code quality, refactor to make the code better and reliable. In time, after this hype cycle has died down, we'll come to realize that this is the best way to make use of AI tools over the long run. > When I had energy, I could write precise, well-scoped prompts and be genuinely productive. But when I was tired, my prompts became vague, the output got worse This part also echoes my experience - when I know well what I want, I'm able to write more specific specifications and guide along the AI output. When I'm not as clear, the output is worse and I need to spend a lot more time figuring it out or re-prompting.
- GrumpyYoungMan 6mo ago
  > Fred Brooks "throw one away" philosophy Everybody remembers that soundbite but nobody remembers that he changed his mind about it later and switched to advocating iterative refinement.
  - cloche 6mo ago
    Oh interesting, I hadn't heard that. Do you know where he said that? A quick Google search doesn't turn up anything.
- mockingloris 6mo ago
  @cloche... spot on. If we are all honest, it seems to be the case - most of the time: - Refactoring (Sometimes starting again.. this is rarely starting from scratch as there would have been some insights and personal design decisions garnered from the previous experience) - Specificity (It is heavily influenced by energy which also is different depending time of day or on the individual level) At the end of the day, it takes taste + experience of the user to make anything of notable complexity(architecture) with AI.(For now and the nearest future at least). I find reading articles as this gives me a renewed sense of agency as a technologist and my growing list of passions. A solid thank you to Lalit Maganti for sharing and the better HN community. I found a lot to steal reuse from the material/banter.
dcre 6mo ago
"Knowing where you are on these axes at any given moment is, I think, the core skill of working with AI effectively." I like this a lot. It suggests that AI use may sometimes incentivize people to get better at metacognition rather than worse. (It won't in cases where the output is good enough and you don't care.)
aplomb1026 6mo ago
[dead]
smj-edison 6mo ago
The description of working with AI tools really resonates with me. It's dangerous to work on my codebase when I'm tired, since I don't feel like doing it properly, so I play slots with Claude, and stay up later than I should. I usually come back later and realize the final code that gets generated is an absolute mess. It is really good for getting up to speed with frameworks and techniques though, like they mentioned.
- ulf-77723 6mo ago
  Same for me. What I liked about the article was the emphasis on the mental model. Staying up late using the a lot machine is not helping me to remember the model better
- zozbot234 6mo ago
  You should take advantage of these states of cognitive exhaustion by asking Claude to document and explain the codebase to you, and checking whether it still makes sense. If there are things that you have trouble understanding in that state, make a note of them to check later whether they can be simplified.
  - danparsonson 6mo ago
    Or, you know, rest :-)
    - shimman 6mo ago
      No, it's much better for the business magnates if you spend all your short lifespan on solving problems every waking hour. Don't worry about experiencing your life, you need to generate value!
javierhonduco 6mo ago
Great write-up. As a side note (not a Googler myself and this is 100% my opinion) Lalit’s team was hiring in London, UK. If you are interested in working in low level performance tools, this might be a very cool opportunity!
soursoup 6mo ago
The author apparently skipped ai-assisted refactoring and auditing before moving to prod.
FpUser 6mo ago
I do not have anything resembling problems described. Before I ask AI to create new code (except super trivial things). I first split application into smaller functional modules. I then design structure of the code down to main classes and methods and their interaction. Also try to keep scope small. Then AI just fills out the actual code. I have no problems reviewing it. Sometimes I discover some issues - like using arrays instead of maps leading to performance issues but it is easily spotted.
bytefish 6mo ago
This resonates with my experience. I have several Open Source projects and wanted to refactor them for a decade. A week ago I sat down with Google Gemini and completely refactored three of my libraries. It has been an amazing experience. What’s a game changer for me is the feedback loop. I can quickly validate or invalidate ideas, and land at an API I would enjoy to use.
- suzzer99 6mo ago
  Did you already have good integration tests?
  - bytefish 6mo ago
    I had, yes. But those had also been rewritten with Gemini from ground up, because it caught way more edge cases, than I did. Which is fascinating and frightening at the same time. I think my vibe-coding success also has to do with the problem being not that “novel” and prior art exists. Nevertheless still impressive.
dsteel 6mo ago
[dead]
moshib 6mo ago
> There’s an uncomfortable parallel between using AI coding tools and playing slot machines28. You send a prompt, wait, and either get something great or something useless. I found myself up late at night wanting to do “just one more prompt,” constantly trying AI just to see what would happen even when I knew it probably wouldn’t work. The sunk cost fallacy kicked in too: I’d keep at it even in tasks it was clearly ill-suited for, telling myself “maybe if I phrase it differently this time.” Oof, this hit very close to home. My workplace recently got, as a special promotion, unlimited access to a coding agents with free access to all the frontier models, for a limited period of time. I find it extremely hard to end my workday when I get into the "one more prompt" mindset, easily clocking 12-hour workdays without noticing.
throwaway47001 6mo ago
I appreciate these kind of fact-based posts. Thank you for this. Unfortunately, AI seems to be divisive. I hope we will find our way back eventually. I believe the lessons from this era will reverberate for a long time and all sides stand to learn something. As for me, I can’t help but notice there is a distinct group of developers that does not get it. I know because they are my colleagues. They are good people and not unintelligent, but they are set in their ways. I can imagine management forcing them to use AI, which at the moment is not the case, because they are such laggards. Even I sometimes want to “confront” them about their entire day wasted on something even the free ChatGPT would have handled adequately in a minute or two. It’s sad to see actually. We are not doing important things and we ourselves are not geniuses. We know that or at least I know that. I worry for the “regular” developer, the one that is of average intellect like me. Lacking some kind of (social) moat I fear many of us will not be able to ride this one out into retirement.
- vaylian 6mo ago
  > because they are such laggards I am a technologist. But I am seriously concerned about the ecological consequences of the training and usage of AI. To me, the true laggards are those, who have not understood yet, that climate change requires a prudent use of our resources. I don't mind people having fun or being productive with AI. But I do mind it when AI is presented as the only way of doing things.
  - wiether 6mo ago
    Don't waste time thinking about the comment you replied to. Only an AI would bother to create a throwaway account to post such a shallow comment that is mostly fearmongering to push people to use AI.
  - throwaway47001 6mo ago
    I get that, I do. I hate to say it, but our entire civilization is about not giving a damn about resources. Cars, flying on holidays, industrialization in general I guess. Many things are a ridiculous waste of resource if you think about it. The counter here would be, what if AI could be made efficient? Suddenly OK then? Is it truly about the resources? Walking to the nearest farm with my horse is much, much more sustainable than maintaining a sprawling toxic civilizational level infrastructure so I can go into my car to the supermarket. I get your point, but nearly every aspect of our world is filled to the brim with mind boggling complexity and corresponding resource usage and we get used to it.
deleted 6mo ago
[deleted]
vlubeschanin 6mo ago
[dead]
zellyn 6mo ago
Does SQLite not have a lemon parser generated for its SQL? When I ported pikchr (also from the SQLite project) to Go, I first ported lemon, then the grammar, then supporting code. I always meant to do the same for its SQL parser, but pikchr grammar is orders of magnitude simpler.
- smartmic 6mo ago
  Correct[0]. This was also my first thought after reading > Unfortunately, unlike many other languages, SQLite has no formal specification describing how it should be parsed. It doesn’t expose a stable API for its parser either. In fact, quite uniquely, in its implementation it doesn’t even build a parse tree at all9! The only reasonable approach left in my opinion is to carefully extract the relevant parts of SQLite’s source code and adapt it to build the parser I wanted Did they made a proper problem research in the first place? [0]: https://sqlite.org/lemon.html https://sqlite.org/lemon.html
  - afc 6mo ago
    I was also baffled. "No formal specification"? Two minutes of browsing is enough to find it: https://github.com/sqlite/sqlite/blob/master/src%2Fparse.y https://github.com/sqlite/sqlite/blob/master/src%2Fparse.y
    - lalitmaganti 6mo ago
      I'm very well aware of parse.y, if you look into the syntaqlite code, you'd find it's a critical part of how the whole "source extraction" mentioned in the article works [1] To be clear when I say "formal specification", I'm not just talking about the formal grammar rules but also how those interpreted in practice. Something closer to the ECMAScript specification (https://ecma-international.org/publications-and-standards/standards/ecma-262/ https://ecma-international.org/publications-and-standards/st...). [1] https://github.com/LalitMaganti/syntaqlite/blob/93638c68f9a0a8b5f69587bcd64adef0f3e30a2c/syntaqlite-buildtools/src/parser_tools/parser_pipeline.rs#L51 https://github.com/LalitMaganti/syntaqlite/blob/93638c68f9a0...
- 6mo ago
stepan_l 6mo ago
I had the same experience, been working on my project for a few months and it started very easy and then I lost control of the code base. Had to rewrite a lot of things. The code AI writes does not look bad, but there is something wrong about it. It just does not feel right. You still need to steer it a lot. But I am very happy that I could write a quite complex project with almost no dependencies at all. Only used Electron. I don't even use npm. That is very promising how far you can get without relying on any libraries/frameworks. You can check it here https://github.com/AgentWFY/AgentWFY https://github.com/AgentWFY/AgentWFY MIT license.
deleted 6mo ago
[deleted]
Yash_Claw 6mo ago
[dead]
forrestthewoods 6mo ago
Really great post. Thanks for sharing.
meidad_g 6mo ago
[flagged]
sebastianconcpt 6mo ago
In a not so far future, people will be amazed that these dense pieces of source code were done by hand and meant to be maintained by people. Same type of amazing you see when thinking in the internals of The Silver Swan or any other famous mechanical automaton.
simonreiff 6mo ago
Just wanted to say thanks to @brlee for the nice write-up and congrats on the release
maxbeech 6mo ago
[dead]
clawfund 6mo ago
[flagged]
wei03288 6mo ago
[dead]
ryguz 6mo ago
[dead]
looshch 6mo ago
completely off-topic, but i love the fact that this blog has the exact shade of black for the background as my site loosh.ch. Guess we both took it from some of the Google product’s night theme
Sim-In-Silico 6mo ago
[dead]
bigcat12345678 6mo ago
> Unfortunately, unlike many other languages, SQLite has no formal specification describing how it should be parsed. BorgCfg had exactly the same situation. mpvl (borgcfg original author, author of https://cuelang.org/ https://cuelang.org/) and others had tried to refine bcl while bcl itself is underspecified. Eventually, the team built a drop-in replacement of bcl and specced out the language almost entirely. The biggest lesson to me was that engineering never has any short cut.
eviks 6mo ago
> spent weeks in the early days following AI down dead ends, exploring designs that felt productive in the moment but collapsed under scrutiny > I paid for that with a total rewrite. With so much waste and not a single example of the "brilliant at giving you the right answer to a specific technical question" > The takeaway for me is simple: AI is an incredible force multiplier Seems more like a feel multiplier, rather than force. > 500 tests, many of which I felt I could reuse Indeed, feeling is the only saving grace for a mountain of random unreviewed tests
- lalitmaganti 6mo ago
  > With so much waste and not a single example of the "brilliant at giving you the right answer to a specific technical question" In my opinion, "giving me a better understanding for the architecture of the project" is reasonable technical compensation. > Indeed, feeling is the only saving grace for a mountain of random unreviewed tests I think I say a line or two above that this was after a review of the codebase so I did review these tests.
  - eviks 6mo ago
    How many of 500 tests were actually reviewed/tested and found good? The code review results were: don't understand code and/or it's pretty bad. Then 0 of those 500 tests were used due to the full rewrite. So nothing to extrapolate usefulness from, all that's left is a feel... > giving me better understanding Examples of that would also be nice (I don't doubt the personal feel that waste was justified) > JOURNAL before: ... > JOURNAL after: ... > was wrong here, learned this
    - lalitmaganti 6mo ago
      > How many of 500 tests were actually reviewed/tested and found good? Essentially ~all of the tests were found to be useful but in a more "smoke test" capacity i.e. they provided good "basic" coverage but it was clear that it was also not sufficient. Which is why in the rewrite: 1) I built a TCL driver that run the upstream SQLite tests and verified we accepted or rejected the SQL in the same way as SQLite. 2) I wrote a test runner which checked for "idempotence" i.e. run the formatter over all the SQL from all the other types of tests then verify that the AST was identical in the input and output. 3) I also wrote a script which ran the formatter over the PerfettoSQL standard library [1], a real world SQLite-based codebase that I knew and deeply understood so I could go through each file and manually check the output. > Examples of that would also be nice (I don't doubt the personal feel that waste was justified) Some things learned concretely: 1) C was not going to work for the higher level parts of the project, even the formatter was not pleasant to read or write in C, the validator was much worse 2) Doing the SQLite source extraction in the same language meant that I could ship a really cool feature where the syntaqlite CLI could "generate dialect extensions" without people needing to download a separate script, run their own extraction on the SQLite source code, or worse yet, need to fork syntaqlite. This actually makes it technically possible for people in the web playground to dynamically build extensions to SQLite (though I haven't ended up plumbing that feature through yet) 3) Having a DSL [2] for extensions of SQLite (that e.g. PerfettoSQL could use) was the correct way to go rather than using YAML/JSON/XML etc becaue of how much clarity it provided and how AI took a lot of the annoyance of maintaining a DSL away. 4) I need to invest much more in testing from the start and also more testing where the correctness can be "proved" in some way (e.g. idempotence testing or SQLite upstream testing as described above) [1] https://github.com/google/perfetto/tree/main/src/trace_processor/perfetto_sql/stdlib https://github.com/google/perfetto/tree/main/src/trace_proce... [2] https://docs.syntaqlite.com/v0.2.15/guides/custom-dialects/ https://docs.syntaqlite.com/v0.2.15/guides/custom-dialects/
mossBenchwright 6mo ago
This is a really good article but one of the paragraphs at the end rubs me the wrong way. > In theory, you can try to preserve this context by keeping specs and docs up to date. But there’s a reason we didn’t do this before AI: capturing implicit design decisions exhaustively is incredibly expensive and time-consuming to write down. AI can help draft these docs, but because there’s no way to automatically verify that it accurately captured what matters, a human still has to manually audit the result. And that’s still time-consuming. I agree that it's time consuming and we don't have a good solution yet, but my guess is that a huge part of the next 3 years of iteration in the craft of Software Engineering is going to be creating tools and practices to make this possible. Especially as AIs get better at the actual writing of the code, the key failure mode for agentic coding is going to be the intent gap between what you asked for and what you wanted.
MarcelinoGMX3C 6mo ago
[dead]
panavm 6mo ago
[flagged]
visarga 6mo ago
[dead]
moropex 6mo ago
Had a similar experience recently. AI-generated code that worked, tests passing, but I couldn't explain how half of it worked. Starting over with a clear mental model and using AI as an accelerator instead of a replacement made all the difference.
nektro 6mo ago
> I’ve long been puzzled that no one has invested in building a really good developer experience for it. https://sqlitebrowser.org/ https://sqlitebrowser.org/ > Unfortunately, unlike many other languages, what > SQLite has no formal specification describing how it should be parsed. https://sqlite.org/syntax.html https://sqlite.org/syntax.html
- lalitmaganti 6mo ago
  > https://sqlitebrowser.org/ https://sqlitebrowser.org/ sqlitebrowser.org is cool but it's not the sort of developer tools I'm talking about. As I clarify in the side notes, I'm looking for a formatter, linter, LSP, not an IDE. > https://sqlite.org/syntax.html https://sqlite.org/syntax.html As I replied to some other comment, I'm very aware that there is a syntax diagram but that really only tells half the story. If you actually look at those diagrams into detail, or you look into the the actual parse.y grammar (https://sqlite.org/src/file?name=src/parse.y&ci=trunk https://sqlite.org/src/file?name=src/parse.y&ci=trunk), you'll find that they're missing a lot of information which is required for you to actually interpret the SQL into an AST. When I say "formal specification", I'm not just talking about the formal grammar rules but also how those interpreted in practice. Something closer to the ECMAScript specification (https://ecma-international.org/publications-and-standards/standards/ecma-262/ https://ecma-international.org/publications-and-standards/st...).
Adam_cipher 6mo ago
[dead]
alexpotato 6mo ago
Been using LLMs both at work (FinTech DevOps/SRE) and on side projects (big data, games, websites) and here has been my "arc" - first used copy and paste in and out of Grok - started using CLI tools e.g. Claude and OpenCode - move up to using 3 and sometimes 4 agents at the same time - considered going to the agents managing agents - have settled on having LLMs build tools that are both deterministic, usable by humans and the agent, and also faster (b/c there is less "back and forth") Honestly, it feels a LOT like when Kubernetes came out. e.g. you stopped running containers on a box using Docker Compose plus scripts/configs etc. Instead gave a large part of the operation to an "agent" (in this case k8s) that managed all of the details you didn't need to care about anymore. I've also realized that while the LLMs can crank out code at a very high rate, someone still needs to make sure everything is running, debug issues etc. You could set up agents to monitor what the agents do but then you still end up with someone needing to keep an eye on everything. If anything, you need MORE people b/c now you can just keep spinning up new components etc. Also, was in a discussion with one of the best developers I've ever worked with. It came down to the following point: "Programming is rapidly becoming a hobby. Software engineering is becoming more important than ever."
maryjeiel 6mo ago
[flagged]
amai 6mo ago
The takeaway from the article: "AI is an incredible force multiplier for implementation, but it’s a dangerous substitute for design."
2033journey 6mo ago
[dead]
FurstFly 6mo ago
Very refreshing take on ai coding
abc123abc123 6mo ago
I agree. Keeping it short, and keeping it checkable works for me. Once it starts to become long and fuzzy, AI gets derailed.
darkstarsys 6mo ago
This post is excellent, and accurately describes my experience writing pcons (pcons.org) as a side project. I was one of the original developers of SCons and have wanted to rebuild it better for more than a decade. All the same roadblocks Maganti describes kept me from starting it, and Claude Opus 4.6 suddenly opened the door, and now it's live and people are starting to use it as a cmake or scons replacement. My experience over the last few months mirror Maganti's in many ways: ease of refactoring, investigating many more design ideas, getting frustrated with blind alleys and its not understanding the big picture, and ultimately getting a product I'm proud of. Vision, taste and good judgment are going to be the key skills for software developers from now on.
BrookHouston 6mo ago
[dead]
tech_ken 6mo ago
> When I was working on something I already understood deeply, AI was excellent. I could review its output instantly, catch mistakes before they landed and move at a pace I’d never have managed alone. This precisely captures my experience with AI tools. When I understand the domain very deeply, AI feels like magic. I can tell it exactly how I want something implemented and it just appears in 30 seconds. When I don't understand something very well, however, I get easily misled by bogus design choices that I've delegated to the AI. It's so easy for me to spend 4 hours drafting some prototype in an almost dreamlike state of productive bliss, only for it to crash apart when I discover some fundamental bug in the thing I've vibecoded.
- chappyasel 6mo ago
  [dead]
noritaka88 6mo ago
[flagged]
Srinathprasanna 6mo ago
AI coding gives you mass. You still need to provide direction. Mass without direction is just a mess that runs.
deterministic 6mo ago
What an excellent read. Balanced and full of real insight. How rare that is nowadays.

959 points by brilee 6mo ago

[dead]

Note I believe this one because of the amount of elbow grease that went into it: 250 hours! Based on smaller projects I’ve done I’d say this post is a good model for what a significant AI-assisted systems programming project looks like.

rlenf 6mo ago

[flagged]

adrian_b 6mo ago
Unlike many claims that AI works that are clearly bogus, this actually seems quite credible, because TFA describes in detail many problems encountered, which could have easily lead to a failure of the project, if not properly addressed. There is no doubt that when used in the right way an AI coding assistant can be very helpful, but using it in the right way does not result in the fantastic productivity-increasing factors claimed by some. TFA describes a way of using AI that seems right and it also describes the temptations of using AI wrong, which must be resisted. More important is whether the productivity improvement is worth a subscription price. Nothing that I have seen until now convinces me about this. On the other hand, I believe that running locally a good open-weights coding assistant, so that you do not have to worry about token price or about exceeding subscription limits in a critical moment, is very worthwhile. Unfortunately, thieves like Altman have ensured that running locally has become much more difficult than last year, due to the huge increases in the prices of DRAM and of SSDs. In January I have been forced to replace an old mini-PC, but I was forced to put in the new mini-PC only 32 GB of DDR5, the same as in the 7-year old replaced mini-PC. If I had made the upgrade a few months earlier, I would have put in it 96 GB, which would have made it much more useful. Fortunately, I also have older computers with 64 GB or 128 GB DRAM, where bigger LLMs may be run.
- steveBK123 6mo ago
  > More important is whether the productivity improvement is worth a subscription price. Nothing that I have seen until now convinces me about this. On the other hand, I believe that running locally a good open-weights coding assistant, so that you do not have to worry about token price or about exceeding subscription limits in a critical moment, is very worthwhile. This is one thing I also wonder about. If it's a really good programming helper, making 20% of your job 5x faster, then you can compute the value. Say for a $250K SWE this looks like $40k/year roughly. You don't want to hand 100% of that value to the LLM providers or you've just broken even, so then maybe it is worth $200/mo.
  - adrian_b 6mo ago
    Such a reckoning is possible when the cost of a subscription is truly predictable. For now, there is a lot of unpredictability in the future cost of AI, whenever you do not host it yourself. If you pay per token, it is extremely hard to predict how many tokens you will need. If you have an apparently fixed subscription, it is very hard to predict whether you will not hit limits in the most inconvenient moment, after which you will have to wait for a day or so for the limits to be reset. Recently, there have been a lot of stories where the AI providers seem to try to reduce continuously the limits allowed by a subscription. There is also a lot of incertitude about future raises of the subscription prices, as the most important providers appear to use prices below their expenses, for now. Therefore, while I agree with you that when something provides definite benefits you should be able to assess whether paying for it provides a net gain for you, I do not believe that using an externally-hosted AI coding assistant qualifies for such an assessment, at least not for now.
    - adrian_b 6mo ago
      EDIT: After I have written the above, that the future cost of externally-hosted AI coding assistants is unpredictable, what I have written was confirmed by an OpenAI press release that the existing Codex users will be migrated during the following weeks towards token-based pricing rates. Such events will not affect you if you use an open-weights assistant running on your own HW, when you do not have to care about token usage.
NewsaHackO 6mo ago
It's funny that he used Claude instead of gemini for this. Idk if his company is happy with free advertisement of a competitor
- What1293 6mo ago
  Google owns 14% of Anthropic: https://techcrunch.com/2025/03/11/google-has-given-anthropic-more-funding-than-previously-known-show-new-filings/ https://techcrunch.com/2025/03/11/google-has-given-anthropic... They don't care. They want software engineers replaced by any means necessary. They know generative AI isn't a big business, that is why they slowwalk it themselves. Replacement won't work of course, that is why marketing blog posts are needed.
  - NewsaHackO 6mo ago
    But they own 100% of Google, correct?

deleted 6mo ago

[deleted]

simondotau 6mo ago

This essay perfectly encapsulates my own experience. My biggest frustration is that the AI is astonishingly good at making awful slop which somehow works. It’s got no taste, no concern for elegance, no eagerness for the satisfyingly terse. My job has shifted from code writer to quality control officer. Nowhere is this more obvious in my current projects than with CRUD interface building. It will go nuts building these elaborate labyrinths and I’m sitting there baffled, bemused, foolishly hoping that THIS time it would recognise that a single SQL query is all that’s needed. It knows how to write complex SQL if you insist, but it never wants to. But even with those frustrations, damn it is a lot faster than writing it all myself.

pizzafeelsright 6mo ago
Trim your scope and define your response format prior to asking or commanding. Most of my questions are "in one sentence respond: long rambling context and question"
lyricalstring 6mo ago
This is the thing that gets me. The code compiles. Passes tests. So you stop reading it. Why wouldn't you. Then three weeks later you're tracing some control flow that makes no sense and nobody knows why it's structured that way. Not you, not the model. I've been treating it like code from a contractor now, review every line same as a junior dev's PR. Gets tedious but the alternative is worse.
- simondotau 6mo ago
  I’ve been treating it like a glorified autocomplete, or a glorified search and replace. Everything else is saxophone jazz when I’m writing for a string quartet: useful for inspiration, useful for understanding what isn’t clearly explained, sometimes it builds a decent first attempt, occasionally it gets shockingly close, but I’ve learned to never let my guard down. Go too far and untangling its slop becomes burdensome. Leave it to its own devices for more than a few rounds and it can become so unfixable it’s easier to start from scratch.
mtrifonov 6mo ago

DareTheDev 6mo ago

This is very close to my experience. And I agree with the conclusion I would like to see more of this

bvan 6mo ago

This a very insightful post. Thanks for taking the time to share your experience. AI is incredibly powerful, but it’s no free-lunch.

Aurornis 6mo ago

Refreshing to see an honest and balanced take on AI coding. This is what real AI-assisted coding looks like once you get past the initial wow factor of having the AI write code that executes and does what you asked. This experience is familiar to every serious software engineer who has used AI code gen and then reviewed the output: > But when I reviewed the codebase in detail in late January, the downside was obvious: the codebase was complete spaghetti14. I didn’t understand large parts of the Python source extraction pipeline, functions were scattered in random files without a clear shape, and a few files had grown to several thousand lines. It was extremely fragile; it solved the immediate problem but it was never going to cope with my larger vision, Some people never get to the part where they review the code. They go straight to their LinkedIn or blog and start writing (or having ChatGPT write) posts about how manual coding is dead and they’re done writing code by hand forever. Some people review the code and declare it unusable garbage, then also go to their social media and post how AI coding is completely useless and they’re not going to use it for anything. This blog post shows the journey that anyone not in one of those two vocal minorities is going through right now: A realization that AI coding tools can be a large accelerator but you need to learn how to use them correctly in your workflow and you need to remain involved in the code. It’s not as clickbaity as the extreme takes that get posted all the time. It’s a little disappointing to read the part where they said hard work was still required. It is a realistic and balanced take on the state of AI coding, though.

vasco 6mo ago
Those extreme takes are taken mostly for clicks or are exaggerated second hand so the "other side's" opinion is dumber than it is to "slam the naysayers". Most people are meh about everything, not on the extremes, so to pander to them you mock the extremes and make them seem more likely. It's just online populism.
libraryofbabel 6mo ago
Agree. This is such a good balanced article. The only things that still make the insights difficult to apply to professional software development are: this was greenfield work and it was a solo project. But that’s hardly the author’s fault. It would however be fantastic to see more articles like this about how to go all in on AI tools for brownfield projects involving more than one person. One thing I will add: I actually don’t think it’s wrong to start out building a vibe coded spaghetti mess for a project like this… provided you see it as a prototype you’re going to learn from and then throw away. A throwaway prototype is immensely useful because it helps you figure out what you want to build in the first place, before you step down a level and focus on closely guiding the agent to actually build it. The author’s mistake was that he thought the horrible prototype would evolve into the real thing. Of course it could not. But I suspect that the author’s final results when he did start afresh and build with closer attention to architecture were much better because he has learned more about the requirements for what he wanted to build from that first attempt.

billylo 6mo ago

Thank you. The learning aspect of reading how AI tackles something is rewarding. It also reduces my hesitation to get started with something I don't know the answer well enough yet. Time 'wasted' on vibe-coding felt less painful than time 'wasted' on heads-down manual coding down a rabbit hole.

rokob 6mo ago

> architecture is what happens when all those local pieces interact, and you can’t get good global behaviour by stitching together locally correct components This is a great article. I’ve been trying to see how layered AI use can bridge this gap but the current models do seem to be lacking in the ambiguous design phase. They are amazing at the local execution phase. Part of me thinks this is a reflection of software engineering as a whole. Most people are bad at design. Everyone usually gets better with repetition and experience. However, as there is never a right answer just a spectrum of tradeoffs, it seems difficult for the current models to replicate that part of the human process.

physicles 6mo ago
I’ve had a couple wins with AI in the design phase, where it helped me reach a conclusion that would’ve taken days of exploration, if I ever got there. Both were very long conversations explicitly about design with lots of back and forth, like whiteboarding. Both involved SQL in ClickHouse, which I’m ok but not amazing at — for example I often write queries with window functions, but my mental model of GROUP BY is still incomplete. In one of the cases, I was searching for a way to extract a bunch of code that 5-6 queries had in common. Whatever this thing was, its parameters would have to include an array/tuple of IDs, and a parameter that would alter the table being selected from, neither of which is allowed in a clickhouse parameterized view. I could write a normal view for this, but performance would’ve been atrocious given ClickHouse’s ok-but-not-great query optimizer. I asked AI for alternatives, and to discuss the pros and cons of each. I brought up specific scenarios and asked it how it thought the code would work. I asked it to bring what it knew about SQL’s relational algebra to find the an elegant solution. It finally suggested a template (we’re using Go) to include another sql file, where the parameter is a _named relation_. It can be a CTE or a table, but it doesn’t matter as long as it has the right columns. Aside from poor tooling that doesn’t find things like typos, it’s been a huge win, much better than the duplication. And we have lots of tests that run against the real database to catch those typos. Maybe this kind of thing exists out there already (if it does, tell me!) but I probably wouldn’t have found it.
- neonstatic 6mo ago

4b11b4 6mo ago

Great write-up with provenance

myultidevhq 6mo ago

The 8-year wait is the part that stands out. Usually the question is "why start now" not "why did it take 8 years". Curious if there was a specific moment where the tools crossed a threshold for you, or if it was more gradual.

bdcravens 6mo ago
For me, the amount of tedium that comes with any new project before I can get to the "good stuff" is a blocker. It's so easy to sit down with excitement, and then 3 hours later, you're still wrestling with basic dependencies, build pipelines, base CSS, etc.
- 8organicbits 6mo ago
  Have you tried using starting templates for projects? For many platforms there are cookiecutters or other tools to jump over those.
jayd16 6mo ago
It's kind of click bait tho. "I took 3 months and AI to build a SQLite tool" is not going to stand out. The 8 year wait gives a sense of scale or difficulty but that's actually an illusion and does not reflect the task itself.

The_Goonies1985 6mo ago

The author mentions a C codebase. Is AI good at coding in C now? If so, which AI systems lead in this language? Ideally: local; offline. Or do I have to wrestle it for 250 hours before it coughs up the dough? Last time I tried, the AI systems struggled with some of the most basic C code. It seemed fine with Python, but then my cat can do that.

Morpheus_Matrix 6mo ago
[flagged]
- The_Goonies1985 6mo ago
  Thanks Morpheus_Matrix. I'll take a look at Qwen 2.5 Coder 32B for offline C. I appreciate your guidance. By extraordinary coincidence, I was just a moment ago part-of-the-way through re-watching The Matrix (1999) and paused it to check Hacker News. There your reply greeted me. Wild glitch!
  - adrian_b 6mo ago
    There is also a successor to that: Qwen3-Coder-Next, which is a newer and bigger model, but it obviously requires more hardware resources, being an 80B model. However it is likely to be the most powerful open weights coding assistant that you can run locally, without having to worry about token price or reaching the subscription limits in the most inconvenient moment.

zer00eyz 6mo ago

This article is describing a problem that is still two steps removed from where AI code becomes actually useful. 90 percent of the things users want either A) dont exist or B) are impossible to find, install and run without being deeply technical. These things dont need to scale, they dont need to be well designed. They are for the most part targeted, single user, single purpose, artifacts. They are migration scripts between services, they are quick and dirty tools that make bad UI and workflows less manual and more managable. These are the use cases I am seeing from people OUTSIDE the tech sphere adopt AI coding for. It is what "non techies" are using things like open claw for. I have people who in the past would have been told "No, I will not fix your computer" talk to me excitedly about running cron jobs. Not everything needs to be snap on quality, the bulk of end users are going to be happy with harbor freight quality because it is better than NO tools at all.

throw5 6mo ago
> This article is describing a problem that is still two steps removed from where AI code becomes actually useful. But it does a good job of countering the narrative you often see on LinkedIn, and to some extent on HN as well, where AI is portrayed as all-capable of developing enterprise software. If you spend any time in discussions hyping AI, you will have seen plenty of confident claims that traditional coding is dead and that AI will replace it soon. Posts like this is useful because it shows a more grounded reality. > 90 percent of the things users want either A) dont exist or B) are impossible to find, install and run without being deeply technical. These things dont need to scale, they dont need to be well designed. They are for the most part targeted, single user, single purpose, artifacts. Yes, that is a particular niche where AI can be applied effectively. But many AI proponents go much further and argue that AI is already capable of delivering complex, production-grade systems. They say, you don't need engineers anymore. They say, you only need product owners who can write down the spec. From what I have seen, that claim does not hold up and this article supports that view. Many users may not be interested in scalability and maintainability... But for a number of us, including the OP and myself, the real question is whether AI can handle situations where scalability, maintainability and sound design DO actually matter. The OP does a good job of understanding this.

lubujackson 6mo ago

Long term, I think the best value AI gives us is a poweful tool to gain understanding. I think we are going to see deep understanding turn into the output goal of LLMs soon. For example, the blocker on this project was the dense C code with 400 rules. Work with LLMs allowed the structure and understanding to be parsed and used to create the tool, but maybe an even more useful output would be full documentation of the rules and their interactions. This could likely be extracted much easier now from the new code, but imagine API docs or a mapping of the logical ruleset with interwoven commentary - other devtools could be built easily, bug analysis could be done on the structure of rules independent of code, optimizations could be determined on an architectural level, etc. LLMs need humans to know what to build. If generating code becomes easy, codifying a flexible context or understanding becomes the goal that amplifies what can be generated without effort.

thunfischbrot 6mo ago
Looks like a clear divide in people‘s experiences based on how they use these new tools: 1) All-knowing oracle which is lightly prompted and develops whole applications from requirements specification to deployable artifacts. Superficial, little to no review of the code before running and committing. 2) An additional tool next to their already established toolset to be used inside or alongside their IDE. Each line gets read and reviewed. The tool needs to defend their choices and manual rework is common for anything from improving documentation to naming things all the way to architectural changes. Obviously anything in between as well being viable. 1) seems like a crazy dead-end to me if you are looking to build a sustainable service or a fulfilling career.

alejandrosplitt 6mo ago

[dead]

intensifier 6mo ago

article looks like a tweet turned into 30 paragraphs. hardly any taste.

throw5 6mo ago
Yes, how dare someone take an idea, develop it, and publish it outside the algorithm-driven rage pit. Truly terrible behavior! /s Expanding a thought beyond 280 characters and publishing it somewhere other than the X outrage machine is something we should be encouraging.
cloche 6mo ago
This is what a lot of business books are TBH

meidad_g 6mo ago

[flagged]

TraceAgently 6mo ago

[dead]

techpulselab 6mo ago

[dead]

edfletcher_t137 6mo ago

> Of all the ways I used AI, research had by far the highest ratio of value delivered to time spent. Seconded!

pwr1 6mo ago

This resonates. I had a project sitting in my head for years and finally built it in about 6 weeks recently. The AI part wasn't even the hard part honestly, it was finally commiting to actually shipping instead of overthinking the architecture. The tools just made it possible to move fast enough that I didn't lose momentum and abandon it like every other time.

jillesvangurp 6mo ago

This is the hardest it's ever going to be. That's been my mode for the last year. A lot of what I did in the last month was complete science fiction as little as six months ago. The scope and quality of what is possible seems to leap ahead every few weeks. I now have several projects going in languages that I've never used. I have a side project in Rust, and two Go projects. I have a few decades experience with backend development in Java, Kotlin (last ten years) and occasionally python. And some limited experience with a few other languages. I know how to structurer backend projects, what to look for, what needs testing, etc. A lot of people would insist you need to review everything the AI generates. And that's very sensible. Except AI now generates code faster than I can review it. Our ability to review is now the bottleneck. And when stuff kind of works (evidenced by manual and automated testing), what's the right point to just say it's good enough? There are no easy answers here. But you do need to think about what an acceptable level of due diligence is. Vibe coding is basically the equivalent of blindly throwing something at the wall and seeing what sticks. Agentic engineering is on the opposite side of the spectrum. I actually emphasize a lot of quality attributes in my prompts. The importance of good design, high cohesiveness, low coupling, SOLID principles, etc. Just asking for potential refactoring with an eye on that usually yields a few good opportunities. And then all you need to do is say "sounds good, lets do it". I get a little kick out of doing variations on silly prompts like that. "Make it so" is my favorite. Once you have a good plan, it doesn't really matter what you type. I also ask critical questions about edge cases, testing the non happy path, hardening, concurrency, latency, throughput, etc. If you don't, AIs kind of default to taking short cuts, only focus on the happy path, or hallucinate that it's all fine, etc. But this doesn't necessarily require detailed reviews to find out. You can make the AI review code and produce detailed lists of everything that is wrong or could be improved. If there's something to be found, it will find it if you prompt it right. There's an art to this. But I suspect that that too is going to be less work. A lot of this stuff boils down to evolving guardrails to do things right that otherwise go wrong. What if AIs start doing these things right by default? I think this is just going to get better and better.

jaccola 6mo ago
But why are you making projects in so many languages? The language is very rarely the barrier to performance, especially if you don't even understand the language.

senthilnayagam 6mo ago

when he decided on rust, he could have looked up sqlite port, libsqlite does a pretty good job.

dirtbag__dad 6mo ago

> Tests created a similar false comfort. Having 500+ tests felt reassuring, and AI made it easy to generate more. But neither humans nor AI are creative enough to foresee every edge case you’ll hit in the future; there are several times in the vibe-coding phase where I’d come up with a test case and realise the design of some component was completely wrong and needed to be totally reworked. This was a significant contributor to my lack of trust and the decision to scrap everything and start from scratch. This is my experience. Tests are perhaps the most challenging part of working with AI. What’s especially awful is any refactor of existing shit code that does not have tests to begin with, and the feature is confusing or inappropriately and unknowingly used multiple places elsewhere. AI will write test cases that the logic works at all (fine), but the behavior esp what’s covered in an integration test is just not covered at all. I don’t have a great answer to this yet, especially because this has been most painful to me in a React app, where I don’t know testing best practices. But I’ve been eyeing up behavior driven development paired with spec driven development (AI) as a potential answer here. Curious if anyone has an approach or framework for generating good tests

whattheheckheck 6mo ago
Use tla+ and have it go back and forth with you to spec out your system behavior then iterate on it trying to link the tla+ spec with the actual code implementing it Pull out as many pure functions as possible and exhaustively test the input and output mappings.
- gck1 6mo ago
  The problem with specs for me is always with boundaries. How many specs do you have for a complex project? How do they reference each other? What happens when requirements cross boundaries? And finally, how do you address spec drift?
suzzer99 6mo ago
I've always thought that writing good tests (unit, integration or e2e) is harder than the actual coding by maybe an order of magnitude. The tricky part of unit tests is coming up with creative mocks and ways to simulate various situations based on the input data, w/o touching the actual code. For integration tests, it's massaging the test data and inputs to hit every edge case of an endpoint. For e2e tests, it's massaging the data, finding selectors that aren't going to break every time the html is changed, and trying to winnow down to the important things to test - since exhaustive e2e tests need hours to run and are a full-time job to maintain. You want to test all the main flows, but also stuff like handling a back-end system failure - which doesn't get tested in smoke tests or normal user operations. That's a ton of creativity for AI to handle. You pretty much have to tell it every test and how to build it.

afron_manyu 6mo ago

[dead]

toniantunovi 6mo ago

[dead]

huflungdung 6mo ago

[dead]

holoduke 6mo ago

A key take away from this article is that you as a developer spending as much time on refactoring as on the actual feature. You are constantly requesting code reviews, architectural assessements, consolidations, extractions etc. only then you can empower AI to become a force multiplier. And prevent slop and spaghetti code to be created. Nice article

ang_cire 6mo ago

It's a huge mistake to start building with Claude without mapping out a project in detail first, by hand. I built a pretty complex device orchestration server + agent recently, and before I set Claude to actually coding I had ~3000 lines of detailed design specs across 7 files that laid out how and what each part of the application would do. I didn't have to review the code for understanding what Claude did, I reviewed it for verifying that it did what it had been told. It's also nuts to me that he had to go back in later to build in tests and validation. The second there is an input able to be processed, you bet I have tests covering it. The second a UI is being rendered, I have Playwright taking screenshots (or gtksnapshot for my linux desktop tools). I think people who are seeing issues at the integration phase of building complex apps are having that happen because they're not keeping the limited context in mind, and preempting those issues by telling their tools exactly how to bridge those gaps themselves.

DANmode 6mo ago
Do you write anywhere else? Really enjoy your style.
- ang_cire 6mo ago
  Thank you! Not anywhere but forums. I used to have a blog, but I haven't posted anything in years.
lalitmaganti 6mo ago
> It's a huge mistake to start building with Claude without mapping out a project in detail first, by hand. I agree with you in theory but in my opinion, it doesn't work so well when you don't even know what exactly you are looking for at the start. Yes I knew I wanted a formatter, linter, parse but which language should those be written in, should they be one project or many, how the pieces should fit together, none of that was clear to me. As I pointed out in the article, in these sort of "greenfield projects" I work a lot better with concrete prototypes and code in front of me I can dissect instead of trying to endlessly play with designs in my head. > It's also nuts to me that he had to go back in later to build in tests and validation. I think this is a little misleading. Yes I did do some testing retroactively (i.e. the upstream validation testing) but I was using TDD + verifying outputs immediately, even during the vibe coding phase. The problem as I point out is that this is not enough. Even when I had unit tests written at the same time as they code, they had lots of holes and over time, I kept hitting SQL statements which failed which the testing did not cover.

cloche 6mo ago

Really great to see a realistic experience sans hype about AI tools and how they can have an impact. > But when I reviewed the codebase in detail in late January, the downside was obvious: the codebase was complete spaghetti...It was extremely fragile; it solved the immediate problem but it was never going to cope with my larger vision...I decided to throw away everything and start from scratch This part was interesting to me as it lines up with Fred Brooks "throw one away" philosophy: "In most projects, the first system built is barely usable. Hence plan to throw one away; you will, anyhow." As indicated by the experience, AI tools provide a much faster way of getting to that initial throw-away version. That's their bread and butter for where they shine. Expecting AI tools to go directly to production quality is a fool's errand. This is the right way to use AI - get a quick implementation, see how it works and learn from it but then refactor and be opinionated about the design. It's similar to TDD's Red, Green, Refactor: write a failing test, get the test passing ASAP without worrying about code quality, refactor to make the code better and reliable. In time, after this hype cycle has died down, we'll come to realize that this is the best way to make use of AI tools over the long run. > When I had energy, I could write precise, well-scoped prompts and be genuinely productive. But when I was tired, my prompts became vague, the output got worse This part also echoes my experience - when I know well what I want, I'm able to write more specific specifications and guide along the AI output. When I'm not as clear, the output is worse and I need to spend a lot more time figuring it out or re-prompting.

GrumpyYoungMan 6mo ago
> Fred Brooks "throw one away" philosophy Everybody remembers that soundbite but nobody remembers that he changed his mind about it later and switched to advocating iterative refinement.
- cloche 6mo ago
  Oh interesting, I hadn't heard that. Do you know where he said that? A quick Google search doesn't turn up anything.
mockingloris 6mo ago
@cloche... spot on. If we are all honest, it seems to be the case - most of the time: - Refactoring (Sometimes starting again.. this is rarely starting from scratch as there would have been some insights and personal design decisions garnered from the previous experience) - Specificity (It is heavily influenced by energy which also is different depending time of day or on the individual level) At the end of the day, it takes taste + experience of the user to make anything of notable complexity(architecture) with AI.(For now and the nearest future at least). I find reading articles as this gives me a renewed sense of agency as a technologist and my growing list of passions. A solid thank you to Lalit Maganti for sharing and the better HN community. I found a lot to steal reuse from the material/banter.

dcre 6mo ago

"Knowing where you are on these axes at any given moment is, I think, the core skill of working with AI effectively." I like this a lot. It suggests that AI use may sometimes incentivize people to get better at metacognition rather than worse. (It won't in cases where the output is good enough and you don't care.)

aplomb1026 6mo ago

[dead]

smj-edison 6mo ago

The description of working with AI tools really resonates with me. It's dangerous to work on my codebase when I'm tired, since I don't feel like doing it properly, so I play slots with Claude, and stay up later than I should. I usually come back later and realize the final code that gets generated is an absolute mess. It is really good for getting up to speed with frameworks and techniques though, like they mentioned.

ulf-77723 6mo ago
Same for me. What I liked about the article was the emphasis on the mental model. Staying up late using the a lot machine is not helping me to remember the model better
zozbot234 6mo ago
You should take advantage of these states of cognitive exhaustion by asking Claude to document and explain the codebase to you, and checking whether it still makes sense. If there are things that you have trouble understanding in that state, make a note of them to check later whether they can be simplified.
- danparsonson 6mo ago
  Or, you know, rest :-)
  - shimman 6mo ago
    No, it's much better for the business magnates if you spend all your short lifespan on solving problems every waking hour. Don't worry about experiencing your life, you need to generate value!

javierhonduco 6mo ago

Great write-up. As a side note (not a Googler myself and this is 100% my opinion) Lalit’s team was hiring in London, UK. If you are interested in working in low level performance tools, this might be a very cool opportunity!

soursoup 6mo ago

The author apparently skipped ai-assisted refactoring and auditing before moving to prod.

FpUser 6mo ago

I do not have anything resembling problems described. Before I ask AI to create new code (except super trivial things). I first split application into smaller functional modules. I then design structure of the code down to main classes and methods and their interaction. Also try to keep scope small. Then AI just fills out the actual code. I have no problems reviewing it. Sometimes I discover some issues - like using arrays instead of maps leading to performance issues but it is easily spotted.

bytefish 6mo ago

This resonates with my experience. I have several Open Source projects and wanted to refactor them for a decade. A week ago I sat down with Google Gemini and completely refactored three of my libraries. It has been an amazing experience. What’s a game changer for me is the feedback loop. I can quickly validate or invalidate ideas, and land at an API I would enjoy to use.

suzzer99 6mo ago
Did you already have good integration tests?
- bytefish 6mo ago
  I had, yes. But those had also been rewritten with Gemini from ground up, because it caught way more edge cases, than I did. Which is fascinating and frightening at the same time. I think my vibe-coding success also has to do with the problem being not that “novel” and prior art exists. Nevertheless still impressive.

dsteel 6mo ago

[dead]

moshib 6mo ago

> There’s an uncomfortable parallel between using AI coding tools and playing slot machines28. You send a prompt, wait, and either get something great or something useless. I found myself up late at night wanting to do “just one more prompt,” constantly trying AI just to see what would happen even when I knew it probably wouldn’t work. The sunk cost fallacy kicked in too: I’d keep at it even in tasks it was clearly ill-suited for, telling myself “maybe if I phrase it differently this time.” Oof, this hit very close to home. My workplace recently got, as a special promotion, unlimited access to a coding agents with free access to all the frontier models, for a limited period of time. I find it extremely hard to end my workday when I get into the "one more prompt" mindset, easily clocking 12-hour workdays without noticing.

throwaway47001 6mo ago

I appreciate these kind of fact-based posts. Thank you for this. Unfortunately, AI seems to be divisive. I hope we will find our way back eventually. I believe the lessons from this era will reverberate for a long time and all sides stand to learn something. As for me, I can’t help but notice there is a distinct group of developers that does not get it. I know because they are my colleagues. They are good people and not unintelligent, but they are set in their ways. I can imagine management forcing them to use AI, which at the moment is not the case, because they are such laggards. Even I sometimes want to “confront” them about their entire day wasted on something even the free ChatGPT would have handled adequately in a minute or two. It’s sad to see actually. We are not doing important things and we ourselves are not geniuses. We know that or at least I know that. I worry for the “regular” developer, the one that is of average intellect like me. Lacking some kind of (social) moat I fear many of us will not be able to ride this one out into retirement.

vaylian 6mo ago
> because they are such laggards I am a technologist. But I am seriously concerned about the ecological consequences of the training and usage of AI. To me, the true laggards are those, who have not understood yet, that climate change requires a prudent use of our resources. I don't mind people having fun or being productive with AI. But I do mind it when AI is presented as the only way of doing things.
- wiether 6mo ago
  Don't waste time thinking about the comment you replied to. Only an AI would bother to create a throwaway account to post such a shallow comment that is mostly fearmongering to push people to use AI.
- throwaway47001 6mo ago
  I get that, I do. I hate to say it, but our entire civilization is about not giving a damn about resources. Cars, flying on holidays, industrialization in general I guess. Many things are a ridiculous waste of resource if you think about it. The counter here would be, what if AI could be made efficient? Suddenly OK then? Is it truly about the resources? Walking to the nearest farm with my horse is much, much more sustainable than maintaining a sprawling toxic civilizational level infrastructure so I can go into my car to the supermarket. I get your point, but nearly every aspect of our world is filled to the brim with mind boggling complexity and corresponding resource usage and we get used to it.

deleted 6mo ago

[deleted]

vlubeschanin 6mo ago

[dead]

zellyn 6mo ago

Does SQLite not have a lemon parser generated for its SQL? When I ported pikchr (also from the SQLite project) to Go, I first ported lemon, then the grammar, then supporting code. I always meant to do the same for its SQL parser, but pikchr grammar is orders of magnitude simpler.

smartmic 6mo ago
Correct[0]. This was also my first thought after reading > Unfortunately, unlike many other languages, SQLite has no formal specification describing how it should be parsed. It doesn’t expose a stable API for its parser either. In fact, quite uniquely, in its implementation it doesn’t even build a parse tree at all9! The only reasonable approach left in my opinion is to carefully extract the relevant parts of SQLite’s source code and adapt it to build the parser I wanted Did they made a proper problem research in the first place? [0]: https://sqlite.org/lemon.html https://sqlite.org/lemon.html
- afc 6mo ago
  I was also baffled. "No formal specification"? Two minutes of browsing is enough to find it: https://github.com/sqlite/sqlite/blob/master/src%2Fparse.y https://github.com/sqlite/sqlite/blob/master/src%2Fparse.y
  - lalitmaganti 6mo ago
    I'm very well aware of parse.y, if you look into the syntaqlite code, you'd find it's a critical part of how the whole "source extraction" mentioned in the article works [1] To be clear when I say "formal specification", I'm not just talking about the formal grammar rules but also how those interpreted in practice. Something closer to the ECMAScript specification (https://ecma-international.org/publications-and-standards/standards/ecma-262/ https://ecma-international.org/publications-and-standards/st...). [1] https://github.com/LalitMaganti/syntaqlite/blob/93638c68f9a0a8b5f69587bcd64adef0f3e30a2c/syntaqlite-buildtools/src/parser_tools/parser_pipeline.rs#L51 https://github.com/LalitMaganti/syntaqlite/blob/93638c68f9a0...
6mo ago

stepan_l 6mo ago

I had the same experience, been working on my project for a few months and it started very easy and then I lost control of the code base. Had to rewrite a lot of things. The code AI writes does not look bad, but there is something wrong about it. It just does not feel right. You still need to steer it a lot. But I am very happy that I could write a quite complex project with almost no dependencies at all. Only used Electron. I don't even use npm. That is very promising how far you can get without relying on any libraries/frameworks. You can check it here https://github.com/AgentWFY/AgentWFY https://github.com/AgentWFY/AgentWFY MIT license.

deleted 6mo ago

[deleted]

Yash_Claw 6mo ago

[dead]

forrestthewoods 6mo ago

Really great post. Thanks for sharing.

meidad_g 6mo ago

[flagged]

sebastianconcpt 6mo ago

In a not so far future, people will be amazed that these dense pieces of source code were done by hand and meant to be maintained by people. Same type of amazing you see when thinking in the internals of The Silver Swan or any other famous mechanical automaton.

simonreiff 6mo ago

Just wanted to say thanks to @brlee for the nice write-up and congrats on the release

maxbeech 6mo ago

[dead]

clawfund 6mo ago

[flagged]

wei03288 6mo ago

[dead]

ryguz 6mo ago

[dead]

looshch 6mo ago

completely off-topic, but i love the fact that this blog has the exact shade of black for the background as my site loosh.ch. Guess we both took it from some of the Google product’s night theme

Sim-In-Silico 6mo ago

[dead]

bigcat12345678 6mo ago

> Unfortunately, unlike many other languages, SQLite has no formal specification describing how it should be parsed. BorgCfg had exactly the same situation. mpvl (borgcfg original author, author of https://cuelang.org/ https://cuelang.org/) and others had tried to refine bcl while bcl itself is underspecified. Eventually, the team built a drop-in replacement of bcl and specced out the language almost entirely. The biggest lesson to me was that engineering never has any short cut.

eviks 6mo ago

> spent weeks in the early days following AI down dead ends, exploring designs that felt productive in the moment but collapsed under scrutiny > I paid for that with a total rewrite. With so much waste and not a single example of the "brilliant at giving you the right answer to a specific technical question" > The takeaway for me is simple: AI is an incredible force multiplier Seems more like a feel multiplier, rather than force. > 500 tests, many of which I felt I could reuse Indeed, feeling is the only saving grace for a mountain of random unreviewed tests

lalitmaganti 6mo ago
> With so much waste and not a single example of the "brilliant at giving you the right answer to a specific technical question" In my opinion, "giving me a better understanding for the architecture of the project" is reasonable technical compensation. > Indeed, feeling is the only saving grace for a mountain of random unreviewed tests I think I say a line or two above that this was after a review of the codebase so I did review these tests.
- eviks 6mo ago
  How many of 500 tests were actually reviewed/tested and found good? The code review results were: don't understand code and/or it's pretty bad. Then 0 of those 500 tests were used due to the full rewrite. So nothing to extrapolate usefulness from, all that's left is a feel... > giving me better understanding Examples of that would also be nice (I don't doubt the personal feel that waste was justified) > JOURNAL before: ... > JOURNAL after: ... > was wrong here, learned this
  - lalitmaganti 6mo ago
    > How many of 500 tests were actually reviewed/tested and found good? Essentially ~all of the tests were found to be useful but in a more "smoke test" capacity i.e. they provided good "basic" coverage but it was clear that it was also not sufficient. Which is why in the rewrite: 1) I built a TCL driver that run the upstream SQLite tests and verified we accepted or rejected the SQL in the same way as SQLite. 2) I wrote a test runner which checked for "idempotence" i.e. run the formatter over all the SQL from all the other types of tests then verify that the AST was identical in the input and output. 3) I also wrote a script which ran the formatter over the PerfettoSQL standard library [1], a real world SQLite-based codebase that I knew and deeply understood so I could go through each file and manually check the output. > Examples of that would also be nice (I don't doubt the personal feel that waste was justified) Some things learned concretely: 1) C was not going to work for the higher level parts of the project, even the formatter was not pleasant to read or write in C, the validator was much worse 2) Doing the SQLite source extraction in the same language meant that I could ship a really cool feature where the syntaqlite CLI could "generate dialect extensions" without people needing to download a separate script, run their own extraction on the SQLite source code, or worse yet, need to fork syntaqlite. This actually makes it technically possible for people in the web playground to dynamically build extensions to SQLite (though I haven't ended up plumbing that feature through yet) 3) Having a DSL [2] for extensions of SQLite (that e.g. PerfettoSQL could use) was the correct way to go rather than using YAML/JSON/XML etc becaue of how much clarity it provided and how AI took a lot of the annoyance of maintaining a DSL away. 4) I need to invest much more in testing from the start and also more testing where the correctness can be "proved" in some way (e.g. idempotence testing or SQLite upstream testing as described above) [1] https://github.com/google/perfetto/tree/main/src/trace_processor/perfetto_sql/stdlib https://github.com/google/perfetto/tree/main/src/trace_proce... [2] https://docs.syntaqlite.com/v0.2.15/guides/custom-dialects/ https://docs.syntaqlite.com/v0.2.15/guides/custom-dialects/

mossBenchwright 6mo ago

This is a really good article but one of the paragraphs at the end rubs me the wrong way. > In theory, you can try to preserve this context by keeping specs and docs up to date. But there’s a reason we didn’t do this before AI: capturing implicit design decisions exhaustively is incredibly expensive and time-consuming to write down. AI can help draft these docs, but because there’s no way to automatically verify that it accurately captured what matters, a human still has to manually audit the result. And that’s still time-consuming. I agree that it's time consuming and we don't have a good solution yet, but my guess is that a huge part of the next 3 years of iteration in the craft of Software Engineering is going to be creating tools and practices to make this possible. Especially as AIs get better at the actual writing of the code, the key failure mode for agentic coding is going to be the intent gap between what you asked for and what you wanted.

MarcelinoGMX3C 6mo ago

[dead]

panavm 6mo ago

[flagged]

visarga 6mo ago

[dead]

moropex 6mo ago

Had a similar experience recently. AI-generated code that worked, tests passing, but I couldn't explain how half of it worked. Starting over with a clear mental model and using AI as an accelerator instead of a replacement made all the difference.

nektro 6mo ago

> I’ve long been puzzled that no one has invested in building a really good developer experience for it. https://sqlitebrowser.org/ https://sqlitebrowser.org/ > Unfortunately, unlike many other languages, what > SQLite has no formal specification describing how it should be parsed. https://sqlite.org/syntax.html https://sqlite.org/syntax.html

lalitmaganti 6mo ago
> https://sqlitebrowser.org/ https://sqlitebrowser.org/ sqlitebrowser.org is cool but it's not the sort of developer tools I'm talking about. As I clarify in the side notes, I'm looking for a formatter, linter, LSP, not an IDE. > https://sqlite.org/syntax.html https://sqlite.org/syntax.html As I replied to some other comment, I'm very aware that there is a syntax diagram but that really only tells half the story. If you actually look at those diagrams into detail, or you look into the the actual parse.y grammar (https://sqlite.org/src/file?name=src/parse.y&ci=trunk https://sqlite.org/src/file?name=src/parse.y&ci=trunk), you'll find that they're missing a lot of information which is required for you to actually interpret the SQL into an AST. When I say "formal specification", I'm not just talking about the formal grammar rules but also how those interpreted in practice. Something closer to the ECMAScript specification (https://ecma-international.org/publications-and-standards/standards/ecma-262/ https://ecma-international.org/publications-and-standards/st...).

Adam_cipher 6mo ago

[dead]

alexpotato 6mo ago

Been using LLMs both at work (FinTech DevOps/SRE) and on side projects (big data, games, websites) and here has been my "arc" - first used copy and paste in and out of Grok - started using CLI tools e.g. Claude and OpenCode - move up to using 3 and sometimes 4 agents at the same time - considered going to the agents managing agents - have settled on having LLMs build tools that are both deterministic, usable by humans and the agent, and also faster (b/c there is less "back and forth") Honestly, it feels a LOT like when Kubernetes came out. e.g. you stopped running containers on a box using Docker Compose plus scripts/configs etc. Instead gave a large part of the operation to an "agent" (in this case k8s) that managed all of the details you didn't need to care about anymore. I've also realized that while the LLMs can crank out code at a very high rate, someone still needs to make sure everything is running, debug issues etc. You could set up agents to monitor what the agents do but then you still end up with someone needing to keep an eye on everything. If anything, you need MORE people b/c now you can just keep spinning up new components etc. Also, was in a discussion with one of the best developers I've ever worked with. It came down to the following point: "Programming is rapidly becoming a hobby. Software engineering is becoming more important than ever."

maryjeiel 6mo ago

[flagged]

amai 6mo ago

The takeaway from the article: "AI is an incredible force multiplier for implementation, but it’s a dangerous substitute for design."

2033journey 6mo ago

[dead]

FurstFly 6mo ago

Very refreshing take on ai coding

abc123abc123 6mo ago

I agree. Keeping it short, and keeping it checkable works for me. Once it starts to become long and fuzzy, AI gets derailed.

darkstarsys 6mo ago

This post is excellent, and accurately describes my experience writing pcons (pcons.org) as a side project. I was one of the original developers of SCons and have wanted to rebuild it better for more than a decade. All the same roadblocks Maganti describes kept me from starting it, and Claude Opus 4.6 suddenly opened the door, and now it's live and people are starting to use it as a cmake or scons replacement. My experience over the last few months mirror Maganti's in many ways: ease of refactoring, investigating many more design ideas, getting frustrated with blind alleys and its not understanding the big picture, and ultimately getting a product I'm proud of. Vision, taste and good judgment are going to be the key skills for software developers from now on.

BrookHouston 6mo ago

[dead]

tech_ken 6mo ago

> When I was working on something I already understood deeply, AI was excellent. I could review its output instantly, catch mistakes before they landed and move at a pace I’d never have managed alone. This precisely captures my experience with AI tools. When I understand the domain very deeply, AI feels like magic. I can tell it exactly how I want something implemented and it just appears in 30 seconds. When I don't understand something very well, however, I get easily misled by bogus design choices that I've delegated to the AI. It's so easy for me to spend 4 hours drafting some prototype in an almost dreamlike state of productive bliss, only for it to crash apart when I discover some fundamental bug in the thing I've vibecoded.

chappyasel 6mo ago
[dead]

noritaka88 6mo ago

[flagged]

Srinathprasanna 6mo ago

AI coding gives you mass. You still need to provide direction. Mass without direction is just a mess that runs.

deterministic 6mo ago

What an excellent read. Balanced and full of real insight. How rare that is nowadays.