←back to thread

214 points Brajeshwar | 2 comments | | HN request time: 0s | source
Show context
marcyb5st ◴[] No.45087065[source]
In terms of LOCs maybe, in terms of importance I think is much less. At least that's how I use LLMs.

While I understand that <Enter model here> might produce the meaty bits as well, I believe that having a truck factor of basically 0 (since no-one REALLY understands the code) is a recipe for a disaster and I dare say long term maintainability of a code base.

I feel that you need to have someone in any team that needs to have that level of understanding to fix non trivial issues.

However, by all means, I use the LLM to create all the scaffolding, test fixtures, ... because that is mental energy that I can use elsewhere.

replies(2): >>45087181 #>>45090543 #
epicureanideal ◴[] No.45087181[source]
Agreed. If I use an LLM to generate fairly exhaustive unit tests of a trivial function just because I can, that doesn’t mean those lines are as useful as core complex business logic that it would almost certainly make subtle mistakes in.
replies(1): >>45087230 #
andsoitis ◴[] No.45087230[source]
> If I … generate fairly exhaustive unit tests of a trivial function

… then you are not a senior software engineer

replies(1): >>45087252 #
triyambakam ◴[] No.45087252[source]
Neither are you if that's your understanding of a senior engineer
replies(2): >>45087398 #>>45087504 #
mgh95 ◴[] No.45087398[source]
I think the parent commentors point was that it is nearly trivial to generate variations on unit tests in most (if not all) unit test frameworks. For example:

Java: https://docs.parasoft.com/display/JTEST20232/Creating+a+Para...

C# (nunit, but xunit has this too): https://docs.nunit.org/articles/nunit/technical-notes/usage/...

Python: https://docs.pytest.org/en/stable/example/parametrize.html

cpp: https://google.github.io/googletest/advanced.html

A belief that the ability of LLMs to generate parameterizations is intrinsically helpful to a degree which cannot be trivially achieved in most mainstream programming languages/test frameworks may be an indicator that an individual has not achieved a substantial depth of experience.

replies(3): >>45087613 #>>45087958 #>>45091265 #
com2kid ◴[] No.45087613[source]
The useful part is generating the mocks. The various auto mocking frameworks are so hit or miss I end up having to manually make mocks which is time consuming and boring. LLMs help out dramatically and save literally hours of boring error prone work.
replies(1): >>45088016 #
mgh95 ◴[] No.45088016{3}[source]
Why mock at all? Spend the time making integration tests fast. There is little reason a database, queue, etc. can't be set up in a per-test group basis and be made fast. Reliable software is built upon (mostly) reliable foundations.
replies(3): >>45088108 #>>45088169 #>>45090246 #
com2kid ◴[] No.45090246{4}[source]
Because if part of my tests involve calling an OpenAI endpoint, I don't want to pay .01 cent every time I run my tests.

Because my tests shouldn't fail when a 3rd party dependency is down.

Because I want to be able to fake failure conditions from my dependencies.

Because unit tests have value and mocks make unit tests fast and useful.

Even my integration tests have some mocks in them, especially for any services that have usage based pricing.

But in general I'm going to mock out things that I want to simulate failure states for, and since I'm paranoid, I generally want to simulate failure states for everything.

End to End tests are where everything is real.

replies(1): >>45090315 #
1. mgh95 ◴[] No.45090315{5}[source]
> Because if part of my tests involve calling an OpenAI endpoint, I don't want to pay .01 cent every time I run my tests.

This is a good time to think to yourself: do I need these dependencies? Can I replace them with something that doesn't expose vendor risk?

These are very real questions that large enterprises grapple with. In general (but not always), orgs that view technology as the product (or product under test) will view the costs of either testing or inhousing technology as acceptable, and cost centers will not.

> But in general I'm going to mock out things that I want to simulate failure states for, and since I'm paranoid, I generally want to simulate failure states for everything.

This can be achieved with an instrumented version of the service itself.

replies(1): >>45093967 #
2. com2kid ◴[] No.45093967[source]
> This is a good time to think to yourself: do I need these dependencies? Can I replace them with something that doesn't expose vendor risk?

Given that my current projects all revolve solely around using LLMs to do things, yes I need them.

The entire purpose of the code is to call into LLMs and do something useful with the output. That said I need to gracefully handle failures, handle OpenAI giving me back trash results (forgetting fields even though they are marked required in the schema, etc), or just the occasional service outage.

Also integration tests only make sense once I have an entire system to integrate. Unit tests let me know that the file I just wrote works.