Comment by hombre_fatal
4 days ago
I like writing code, and it definitely isn't satisfying when an LLM can one-shot a parser that I would have had fun building for hours.
But at the same time, building a parser for hours is also a distraction from my higher level ambitions with the project, and I get to focus on those.
I still get to stub out the types and function signatures I want, but the LLM can fill them in and I move on. More likely I'll even have my go at the implementation but then tag in the LLM when it's not fun anymore.
On the other hand, LLMs have helped me focus on the fun of polishing something. Making sweeping changes are no longer in the realm of "it'd be nice but I can't be bothered". Generating a bunch of tests from examples isn't grueling anymore. Syncing code to the readme isn't annoying anymore. Coming up with refactoring/improvement ideas is easy; just ask and tell it to make the case for you. It has let me be far more ambitious or take a weekend project to a whole new level, and that's fun.
It's actually a software-loving builder's paradise if you can tweak your mindset. You can polish more code, release more projects, tackle more nerdsnipes, and aim much higher. But it took me a while to get over what turned out to be some sort of resentment.
I agree, agents have really made programming fun for me again (and I say this as someone who has been coding for more two decades - I'm not a script kiddy using them to make up for lack of skill).
Configuring tools, mindless refactors, boilerplate, basic unit/property testing, all that routine stuff is a thing of the past for me now. It used to be a serious blocker for me with my personal projects! Getting bored before I got anywhere interesting. Much of the time I can stick to writing the fun/critical code now and glue everything else together with LLMs, which is awesome.
Some people obviously like the fiddly stuff though, and more power to them, it's just not for me.
Parsing is an area that I'm interested in. Can you talk more about your experience getting LLMs to one-shot parsers?
From scratch LLMs seem to be completely lost writing parsers. The bleeding edge appears to be able to maybe parse xml, but gives up on programming languages with even the most minimal complexity (an example being C where Gemini refused to even try with macros and then when told to parse C without macros gave an answer with several stubs where I was supposed to fill in the details).
With parsing libraries they seem better, but ultimately that reduces to transform this bnf. Which if I had to I could do deterministically without an LLM.
Also, my best 'successes' have been along the lines of 'parse in this well defined language that just happens to have dozens if not hundreds of verbatim examples on github'. Anytime I try to give examples of a hypothetical language then they return a bunch of regex that would not work in general.
A few weeks ago I gave an LLM (Gemini 2.5 something in Cursor) a bunch of examples of a new language, and asked it to write a recursive descent parser in Ruby. The language was nothing crazy, intentionally reminiscent of C/JS style, but certainly the exact definition was new. I didn’t want to use a parser generator because (a) I’d have to learn a new one for Ruby, and (b) I’ve always found it easier to generate useful error messages with a handwritten recursive descent parser.
IIRC, it went like this: I had it first write out the BNF based on the examples, and tweaked that a bit to match my intention. Then I had it write the lexer, and a bunch of tests for the lexer. I had it rewrite the lexer to use one big regex with named captures per token. Then I told it to write the parser. I told it to try again using a consistent style in the parser functions (when to do lookahead and how to do backtracking) and it rewrote it. I told it to write a bunch of parser tests, which I tweaked and refactored for readability (with LLM doing the grunt work). During this process it fixed most of its own bugs based on looking at failed tests.
Throughout this process I had to monitor every step and fix the occasional stupidity and wrong turn, but it felt like using a power tool, you just have to keep it aimed the right way so it does what you want.
The end result worked just fine, the code is quite readable and maintainable, and I’ve continued with that codebase since. That was a day of work that would have taken me more like a week without the LLM. And there is no parser generator I’m aware of that starts with examples rather than a grammar.
Thanks for giving details about your workflow. At least for me it helps a lot in these sorts of discussions.
Although, it is interesting to me that the original posting mentioned LLMs "one-shot"ing parsers and this description sounds like a much more in depth process.
"And there is no parser generator [...] that starts with examples [...]"
People. People can generate parsers by starting with examples. Which, again, is more in line with the original "one-shot parsers" comment.
If people are finding LLMs useful as part of a process for parser generation then I'm glad. (And I mean testing parsers is pretty painful to me so I'm interested in the test case generation). However I'm much more interested in the existence or non-existent of one-shot parser generation.
7 replies →
> I still get to stub out the types and function signatures I want, but the LLM can fill them in and I move on. More likely I'll even have my go at the implementation but then tag in the LLM when it's not fun anymore.
This is the best part for me. I can design my program the way I want. Then hack at the implementation, get it close, and then say okay finish it up (fix the current compiler errors, write and run some unit tests etc).
Then when it's time to write some boiler plate / do some boiler plate refactoring it's extract function xxx into a trait. Write a struct that does xxx and implements that trait.
I'm not over the resentment entirely, and if someone were to push me to join a team that coded by creating github issues, and reviewing the PRs I would probably hate that job, I certainly do when I try to do that in my free time.
In wood working you can use hand tools or power tools. I use hand tools when I want to use them either for a particular effect, or just the joy of using them, and I don't resent having to use a circular saw, or orbital sander when that's the tool I want to use, or the job calls for it. To stretch the analogy developing with plain text prompts and reviewing PRs feels more like assembling Ikea furniture. Frustrating and dull. A machine did most of the work cutting out the parts, and now I need to figure out what they want me to do with them.
This is exactly my take as well!
I do really like programming qua programming, and I relate to a lot of the lamentation I see from people in these threads at the devaluation of this skill.
But there are lots of other things that I also enjoy doing, and these tools are opening up so many opportunities now. I have had tons of ideas for things I want to learn how to do or that I want to build that I have abandoned because I concluded they would require too much time. Not all, but many, of those things are now way easier to do. Tons of things are now under the activation energy to make them worthwhile, which were previously well beyond it.
Just as a very narrow example, I've been taking on a lot more large scale refactorings to make little improvements that I've always wanted to make, but which have not previously been worth the effort, but now are.