| ▲ | OptionOfT 4 days ago |
| And the value of AI as pushed to us by these companies is in doing larger units of work. But... reviewing code is harder than writing code. Expressing how I want something to be done in natural language is incredibly hard. So over time I'm spending a lot of energy in those things, and only getting it 80% right. Not to mention I'm constantly in this highly suspicious mode, trying to pierce through the veil of my own prompt and the code generated, because it's the edge cases that make work hard. The end result is exhaustion. There is no recharge. Plans are front-loaded, and then you switch to auditing mode. Whereas with code you front-load a good amount of design, but you can make changes as you go, and since you know your own code the effort to make those are much lower. |
|
| ▲ | strogonoff 4 days ago | parent | next [-] |
| I somewhat dread code reviews. In order to properly evaluate the solution, you must first know what is the right solution to begin with. You must analyse the problem and arrive at it yourself. This is the brunt of the work, and yet you are not allowed the pleasant part of it: knowing that your work is shipped and feeling pride in it. Working with LLM-generated code is mostly the same. The more sophisticated the autocomplete, the more mental overhead spent on understanding its output. There is an advantage: you are spared having to argue with a possibly defensive peer about what you believe is best. There is also a disadvantage: you do not feel like you are helping someone grow, and instead you are an unpaid (you are not paid for that in particular) contributor to a product by Microsoft (or similar) intended generally in longer term to push you and/or your peers out of the job. Additionally, there is no single mind that you can build rapport with and learn to understand the approaches and vibes of after a while. |
|
| ▲ | nicce 4 days ago | parent | prev | next [-] |
| > Expressing how I want something to be done in natural language is incredibly hard Surprise, surprise… that is why programming languages were created. |
| |
| ▲ | dragonwriter 4 days ago | parent | next [-] | | Programming languages don’t solve that problem, since someone still has to explain what needs to be done in natural language unless the end customer is also the programmer. Programming languages were created because of the different problem of “its very hard to get computers to understand natural language even if you know how to express what you want in it”. | | |
| ▲ | derefr 4 days ago | parent | next [-] | | > someone still has to explain what needs to be done in natural language unless the end customer is also the programmer You're conflating requirement analysis with design. The customer only needs to describe the problem — a set of constraints on what comprises a valid solution. The software engineer is then free to design and develop a particular valid solution (and show it to the customer, which will result in more feedback, which will feed back into design, and so on.) Formalizing this split is the premise behind Domain Driven Design (DDD): you can sit with the customer and pin down a problem description (= set of design requirements) together with them, expressed in exactly the natural language the customer-as-problem-domain-expert uses, without any reference to any particular potential design's solution-space domain. You can then turn around and reuse that set of natural-language statements as the skeleton of a test suite, that "enforces" the customer's expectations upon any potential design you create. It's a lot like an artist sitting with a customer who's commissioning them, with the artist sketching something the customer is describing; and then the artist going away to actually illustrate/paint/craft/design/etc the thing, constrained by that sketch. | |
| ▲ | nicce 4 days ago | parent | prev | next [-] | | I don't see the difference? Natural language simply was lacking the level of precision. We see natural language words and symbols everywhere in programming languages. Natural language was fine-tuned with improved accuracy. And optimised to reduce the amount of needed words. The difference in the precision between natural languages and programming languages was simply just too big, so you needed "an interpreter" to translate the level of precision from customer to computer. | | |
| ▲ | dragonwriter 4 days ago | parent [-] | | Programming languages solve that machine code is hard for humans to work with for large problems and natural language (even when the meaning is perfectly clear) is very difficult (to the point of complete intractability with the level of knowledge and available hardware at the time programming languages were originally invented) to parse mechanically, a necessary first step in translation into machine code a computer could run. Any problem with the difficulty of clearly expressing things in natural language (a real thing for which there have long been solutions between humans that are different than programming languages) was a problem that was technically unreachable at the user->machine interface because of that more fundamental problem for most of the history of computing (its arguable that LLMs are at the level where now it is potentially an issue with computers, but it took decades of having programming languages to be able to get the technical capacity to even experience the problem, it is not the problem programming languages address.) |
| |
| ▲ | soraminazuki 4 days ago | parent | prev | next [-] | | I don't but that. In the same spirit, are you telling me that you solve math problems without using any mathematical notation because it doesn't offer any improvement over natural language? | | |
| ▲ | dragonwriter 3 days ago | parent | next [-] | | > In the same spirit, are you telling me that you solve math problems without using any mathematical notation because it doesn't offer any improvement over natural language? That’s not in the same spirit, and I didn’t say either that programming languages don’t solve any problem, or that there aren’t tools that do solve the problem it was suggested that programming language solve where it exists, which isn't (except maybe since the advent of LLMs) between human and computer. | |
| ▲ | pxc 4 days ago | parent | prev [-] | | I had a logic textbook in college where all the proofs were just prose with very little notation. It was okay. But it felt like it took a lot more effort to process than denser, more specialized notation! |
| |
| ▲ | SkyBelow 4 days ago | parent | prev [-] | | >Programming languages don’t solve that problem The idea is that a programmer will work with natural language dynamically to create enough of an understanding to create a formalized specification within the programming language (eh, we technically need to include the entire ecosystem needed to run the code, but rarely is that an issue). Often it won't be perfect, but then a demo can occur where natural language can then comment on what was missed, which can then better be captured in the formal language. This continues until we get close enough that further effort to refine isn't justified. This isn't the only reason programming languages were created, much as rarely anything has a single reason it was created. They were created as a way to get computers to do what we wanted without needing to modify the hardware, and then higher level languages were created so we can write more specification faster while losing a bit of the lowest level exactness. Also why we have many different programming languages, as they try to fit into different levels of trade off between the different reasons for a programming language to exist. Well, one of the reasons we have many different programming languages.... | | |
| ▲ | dragonwriter 3 days ago | parent [-] | | > The idea is that a programmer will work with natural language dynamically to create enough of an understanding to create a formalized specification within the programming language I don't disagree that that is some people’s idea of the idealized process (though there are others, too.) I disagree, though, that it is the purpose for which programming languages, as a category of tools, were invented. In fact, there were a whole bunch of tools for solving the problem of clarity of communicating expectations of sysstem behavior between humans in unconstrainted natural language invented, and that it was until fairly recently (well into the period of dominance of Agile, or at least “Agile”, methodss) the usual expectation in non-trivial programming projects that some combination of those would be used to solve that problem, and then the programmers, understanding the intent through those tools, would use programming languages to solve the problem that languages that are ideal for communicating between humans are not ideal for source languages for practical compilers or interpreters in computers. |
|
| |
| ▲ | bdangubic 4 days ago | parent | prev [-] | | COBOL would like a word :) |
|
|
| ▲ | palmotea 4 days ago | parent | prev | next [-] |
| That makes very clear these tools are not meant to serve you, you are meant to serve these tools. |
| |
|
| ▲ | rjh29 3 days ago | parent | prev | next [-] |
| Don't spend energy on clever prompting and reviewing. Spend your energy on knowing when to use the LLM at all. If you know what to write but it's tedious, LLMs are great, they'll just fill all that in for you. Anything more complex or open that needs checking could be quicker to just think through and write yourself. You can still use LLMs at the edges, e.g. what API methods should I use for this? |
| |
| ▲ | RealityVoid 3 days ago | parent [-] | | I like using LLM's for exploration of a new codebase, seeing what other options already exist for solving a solution I might not be aware of and planning a bit how to change stuff, since it sometimes sees thing I did not think of. Another thing it's good at is writing tests - a lot of times I won't bother, but with AI I can do it cheaply. And it's very good at keeping documentation and a codebase consistent, believe it or not. If I change a part that is mentioned somewhere else and it has it in the context window, it will update both parts, whereas I might omit it. |
|
|
| ▲ | falcor84 3 days ago | parent | prev [-] |
| > But... reviewing code is harder than writing code. For me it's very clearly the opposite. I wonder if it's a professional background, or personality or neurotype issue or something, but when I'm faced with a problem I often get somewhat paralyzed, spending a long time thinking about a good approach, but when I delegate to someone or ask an AI to tackle it, even if I get back something half-shitty, it removes my paralysis and then reviewing and improving what they did is significantly easier (or at least more motivating) for me than doing it from scratch. And even if they ended up giving me something that's entirely in the wrong direction, and I need to throw out all of it, I still usually feel that it removes that paralysis and gives me a better understanding of the problem space. I wonder if this difference between people accounts for a significant different between those who benefit from AI and those who don't. |
