Live data from Hacker News

How I program with agents

crawshaw.io

191–200 of 308 posts

Re: How I program with agents

#191
post #129

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.

I have been coding 10+ years, surely it is fine for me to vibecode then?

Re: How I program with agents

#192
post #155

Earlier 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.

I am going to put it out here: Docker and other modern infra is easier to understand than CSS (at least pre flex).

Re: How I program with agents

#193

Earlier 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?

Only if you don’t mind what comes out :)

Re: How I program with agents

#195

Maybe 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 use it almost like an RSI mitigation device, for tasks I can do (and do well) but don't want to do anymore. I don't want to write another little 20-line script to format some data, so I'll have the machine do it for me.

I'll also use it to create basic DAOs from schemas, things like that.

Re: How I program with agents

#196
post #168

Earlier 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 :)

>you’re assembling prefab plywood homes while they’re building marble mansions

Which one are there more of nowadays, hm?

Re: How I program with agents

#197
post #186
post #109

Earlier 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.

The comment that started this whole thread off mentioned LLMs oneshot-ing parsers. I didn't think an LLM could one shot a parser and I am interested in parsers which is why I asked about more info.

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

#198
post #109

Earlier 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.

Can you give more info?

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

#199
post #53

Earlier 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.

If you have some idea of what future changes may be seen, it is fine to design for that. However, it is impossible to design a codebase to handle any change. Realistically, just doing the absolute bare minimum is probably the best defence in that situation.

Re: How I program with agents

#200

Earlier 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.

That you don't know when it will make a mistake and that it is getting harder to find them are not exactly encouraging signs to me.
Post reply on HN