Earlier quoted context omitted.
Senior engineers delegate to junior engineers, which have all the same downsides you described, all the time. This pattern seems to work fine for virtually every software company in existence.
> Another way to look at this is you’re outsourcing your understanding to something that ultimately doesn’t think. You read this quote wrong. Senior devs outsource _work_ to junior engineers, not _understanding_. The way they became senior in the first place is by not outsourcing work so they could develop their understanding.
How I program with agents
191–200 of 308 posts
Re: How I program with agents
#192Earlier quoted context omitted.
I read the quote just fine. I don't understand 100% of what my junior engineers do. I understand a good chunk, like 90-95% of it, but am I really going to spend 30 minutes trying to understand why that particular CSS hack only works with `rem` and not `px`? Of course not - if I did that for every line of code, I'd never get anything done.
You are moving goalposts significantly here -- a small CSS hack is a far cry from your docker infrastructure.
Re: How I program with agents
#193Earlier quoted context omitted.
> Another way to look at this is you’re outsourcing your understanding to something that ultimately doesn’t think. You read this quote wrong. Senior devs outsource _work_ to junior engineers, not _understanding_. The way they became senior in the first place is by not outsourcing work so they could develop their understanding.
I have been coding 10+ years, surely it is fine for me to vibecode then?
Re: How I program with agents
#194Re: How I program with agents
#195Maybe it's because I only code for my own tools, but I still don't understand the benefit of relying on someone/something else to write your code and then reading it, understand it, fixing it, etc. Although asking an LLM to extract and find the thing I'm looking for in an API Doc is super useful and time saving. To me, it's not even about how good these LLMs get in the future. I just don't like reading other people's…
I'll also use it to create basic DAOs from schemas, things like that.
Re: How I program with agents
#196Earlier quoted context omitted.
You’re clinging to an old model of work. Today an LLM converted my docker compose infrastructure to Kubernetes, using operators and helm charts as needed. It did in 10 minutes what would take me several days to learn and cobble together a bad solution. I review every small update and correct it when needed. It is so much more productive. I’m driving a tractor while you are pulling an ox cart.
> I’m driving a tractor while you are pulling an ox cart. Or you’re assembling prefab plywood homes while they’re building marble mansions. It’s easy to pick metaphors that fit your preferred narrative :)
Which one are there more of nowadays, hm?
Re: How I program with agents
#197Earlier quoted context omitted.
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, i…
I guess I don't really understand the goal of "one-shot" parser generation, since I can't even do that as a human using a parser generator! There's always an iterative process, as I find out how the language I wanted isn't quite the language I defined. Having somebody or something else write tests actually helps with that problem, as it'll exercise grammar cases outside my mental happy path.
It's not a goal of mine but because of interests in parsing I wanted to know if this was something that was happening or if it was hyperbole.
Re: How I program with agents
#198Earlier quoted context omitted.
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, i…
I recently did something similar, but different: gave Claude some code examples of a Rust-like language, it wrote a recursive descent parser for me. That was a one-shot, though it's a very simple language. After more features were added, I decided I wanted BNF for it, so it went and wrote it all out correctly, after the fact, from the parser implementation.
How big of a number is "some"?
Also what kind of prompts were you feeding it? Did you describe it as Rust like? Anything else you feel is relevant.
[Is there a GitHub link? I'm more than happy to do the detective work.]
Re: How I program with agents
#199Earlier quoted context omitted.
I mean given that you've had this problem repeatedly, I'd call it "past-proofing", but I suppose you know your codebase better than I do.
There’s always a balance to be struck when avoiding premature consolidation of repeated code. We all face the same issue as osigurdson at some point and the productive responses fall in a range.
Re: How I program with agents
#200Earlier quoted context omitted.
The difference is that humans learn. I got bit by this behavior of CombinedOutput once ten years ago, and no longer make this mistake.
This applies to AI, too, albeit in different ways: 1. You can iteratively improve the rules and prompts you give to the AI when coding. I do this a lot. My process is constantly improving, and the AI makes fewer mistakes as a result. 2. AI models get smarter. Just in the past few months, the LLMs I use to code are making significantly fewer mistakes than they were.