I think, more generally, "push effects to the edges" which includes validation effects like reporting errors or crashing the program. If you, hypothetically, kept all of your runtime data in a big blob, but validated its structure right when you created it, then you could pass around that blob as an opaque representation. You could then later deserialize that blob and use it and everything would still be fine -- you'd just be carrying around the validation as a precondition rather than explicitly creating another representation for it. You could even use phantom types to carry around some of the semantics of your preconditions.
Point being: I think the rule is slightly more general, although this explanation is probably more intuitive.
Systems tend to change over time (and distributed nodes of a system don’t cut over all at once). So what was valid when you serialized it may not be valid when you deserialize it later.
This issue exists with the parsed case, too. If you're using a database to store data, then the lifecycle of that data is in question as soon as it's used outside of a transaction.
We know that external systems provide certain guarantees, and we rely on them and reason about them, but we unfortunately cannot shove all of our reasoning into the type system.
Indeed, under the hood, everything _is_ just a big blob that gets passed around and referenced, and the compiler is also just a system that enforces preconditions about that data.
> As I understood it the trick was effectively to dump the full public API documentation of one of those services into their agent harness and have it build an imitation of that API, as a self-contained Go binary. They could then have it build a simplified UI over the top to help complete the simulation.
This is still the same problem -- just pushed back a layer. Since the generated API is wrong, the QA outcomes will be wrong, too. Also, QAing things is an effective way to ensure that they work _after_ they've been reviewed by an engineer. A QA tester is not going to test for a vulnerability like a SQL injection unless they're guided by engineering judgement which comes from an understanding of the properties of the code under test.
The output is also essentially the definition of a derivative work, so it's probably not legally defensible (not that that's ever been a concern with LLMs).
No. The fact that you built something yourself doesn't make it free to produce.
More over, you __won't__. You simply cannot build all of the things that you could buy at scale. What if you had to write all of your own video games? Or operating systems?
I assumed that they meant "cost of production", since that's what you give to keep your money, so that includes 0->1. But if what they meant is what you said then I'd say that the cost of 0->1 is not somehow less important. Software does make 1->100 much more accessible though, so, in that way, you have an opportunity to help out very small businesses in a way that you can't in other industries, which is even more of a reason to buy code from your peers, IMO.
On the one hand, I agree and wish more people would pay for useful code. Hell, I wish I would be more willing to pay for useful code. It's irrational how unwilling many people, including myself, are to pay for things like that.
I think the comparison to other industries is that while they pay for tools, it's not the inventor of the hammer that gets paid, but the producer of the unit, which in software is ~0. I'm not arguing against paying/donating to FOSS, but I do support the discrete distinction to physical tools.
If the tool is saving you a large chunk of time, then why does it matter what's happening in another industry? We seem to be losing a really simple thread here: Pay for things because they present more value to you than you're giving away in payment.
Y'all seem to have some notion of what constitutes "fair" payment that you're so attached to that you're willing to shoot yourselves in the foot.
Definition one on Merriam Webster is, "To make into a product suitable for use." This is what I thought you meant, because cost of production is what it costs to forego buying something. IMO, that's the cost you really want to consider.
How do you know that it's actually faster than if you'd just written it yourself? I think the review and iteration part _is_ the work, and the fact that you started from something generated by an LLM doesn't actually speed things up. The research that I've seen also generally backs this idea up -- LLMs _feel_ very fast because code is being generated quickly, but they haven't actually done any of the work.
Because I’ve been a software engineer for over 20 years. If I look at a feature and feel like it will take me a day and an LLM churns it out in a hour including the iterating, I’m confident that using the LLM was meaningfully faster. Especially since engineers (including me) are notoriously bad at accurate estimation and things usually take at least twice as long as they estimate.
I have tested throwing several features at an LLM lately and I have no doubt that I’m significantly faster when using an LLM. My experience matches what Antirez describes. This doesn’t make me 10x faster, mostly because so much of my job is not coding. But in term of raw coding, I can believe it’s close to 10x.
> I know exactly what the result should be, the LLM is just typing it for me.
This is the mental model people should be working with. The LLM is there to tighten the loop from thought to code. You doing need to test it like an engineer. You just need to use it to make you more efficient.
It so happens that you *can^ give an LLM half-baked thoughts and it will sometimes still do a good job because the right thing is so straightforward. But in general the more vague and unclear your own thoughts, the lower quality the results, necessitating more iterations to refine.
Yes, but then the study result should be, "AI correctly identifies 100% of breast cancers in study"
If we're saying there was a discrepancy and we're saying that all of the patients had cancer, then it would seem that there must have been some that were identified as not having cancer by AI.
Hey, this looks cool. Out of curiosity, how did you create your initial listing of jobs? Did you scrape job data from elsewhere, or maybe you looked at other listings and built yours up by hand?
While it can be nice to throw something out there and play with it, I think a lot of the anxiety that causes people to feel that they _need_ to do that comes from the idea that "thinking isn't working." As an alternative, try validating early stages of thought work as being "real work" that's usually far more valuable than what follows.
Whiteboarding or taking notes can be a good proxy for thought work in early stages. Iow, those are good ways to "get something imperfect out" early because they are at a high enough level that they don't kill much time. However, hacking code out before it's been thought through tends to be a massive time suck.
I definitely agree that there's a shitton of value in hitting things regularly though (usually daily).
Point being: I think the rule is slightly more general, although this explanation is probably more intuitive.
reply