Live data from Hacker News

Test-driven development with an LLM for fun and profit

blog.yfzhou.fyi

61–70 of 91 posts

Re: Test-driven development with an LLM for fun and profit

#61
post #58
post #13

Earlier quoted context omitted.

> On a similar note, has anyone found themselves absolutely not trusting non-code LLM output? I'm working on a LLM chat app that is built around mistrust. The basic idea is that it is unlikely a supermajority of quality LLMs can get it wrong. This isn't foolproof though, but it does provide some level of confidence in the answer. Here is a quick example in which I analyze results from multiple LLMs that answered, "Wh…

It's the backwards reasoning that really frustrates me when using LLMs. You ask a question, it says sure do these things, they don't work out and you ask the LLM why not, and it replies yes that thing I told you to do wouldn't work because of these clear reasons. It would be nice to start at the end of that chain of reasoning instead of the other side. Another regular example is when it "invents" functions or classes…

> I am finding LLMs far more useful for soft skill topics than engineering type work, simply because of how often it leads me down a path that is eventually a dead end, because of some small detail that was wrong at the very beginning.

Yeah I felt the same way in the beginning which is why I ended up writing my own chat app. What I've found while developing my spelling and grammar checker is that it is very unlikely for multiple LLMs to mess up at the same time. I know they will mess up, but I'm also pretty sure they won't at the same time.

So far, I've been able to successfully create working features that actually saved me time by pitting LLMs against their own responses and others. My process right now is, I'll ask 6+ models to implement something and then I will ask models to evaluate everyone's responses. More often than not, a model will find fault or make a suggestion that can be used to improve the prompt or code. And depending on my confidence level, I might repeat this a couple of times.

The issue right now is tracking this "chain of questioning" which is why I am writing my own chat app. I need an easy way to backtrack and fork from different points in the "chain of questioning". I think once we get a better understanding of what LLMs can and can't do as a group, we should be able to produce working solutions easier.

Re: Test-driven development with an LLM for fun and profit

#62
post #4

One trend I've noticed, framed as a logical deduction: 1. Coding assistants based on o1 and Sonnet are pretty great at coding with 2. Coding agents do massively better when they have a test-driven reward signal. 3. If a problem can be framed in a way that a coding agent can solve, that speeds up development at least 10x from the base case of human + assistant. 4. From (1)-(3), if you can get all the necessary context…

You don't need microservices for that, just factor your code into libraries that can fit into the context window. Also write functions that have clear inputs and outputs and don't need to know the full state of the software.

This has always been good practice anyway.

Re: Test-driven development with an LLM for fun and profit

#63
post #37

Earlier quoted context omitted.

What does team size have to do with this? Small teams can (and should) absolutely build modularized software ... You simply cannot build a [working/maintainable] large piece of software if everything is connected to everything and any one change may cause issues in conceptually unrelated pieces of code. As soon as your codebase is bigger than what you can fully memorize, you need modules, separation of concerns, etc.

Sure I agree with that, but microservices are just one of many ways to modularize software/achieve separation of concerns. I assumed you were talking about team size specifically because that is the thing that a microservice architecture uniquely enables in my experience.

I think you might be missing that Swizec edited the quote, crossing out microservices and correcting it to modular systems. It seems to me you're both in violent agreement.

Re: Test-driven development with an LLM for fun and profit

#64

Earlier quoted context omitted.

Sure I agree with that, but microservices are just one of many ways to modularize software/achieve separation of concerns. I assumed you were talking about team size specifically because that is the thing that a microservice architecture uniquely enables in my experience.

I think you might be missing that Swizec edited the quote, crossing out microservices and correcting it to modular systems. It seems to me you're both in violent agreement.

Ahh, the strike through doesn't render on mobile. Yes, I think we are just agreeing with each other.

Re: Test-driven development with an LLM for fun and profit

#65

Earlier quoted context omitted.

So having clear requirements, a focused purpose for software, and a clear boundary of software responsibility makes for a software development task that can be accomplished? If only people had figured out at some point that the same thing applies when communicating to human software engineers.

If human software engineers refused to work unless those conditions were met, what a wonderful world it would be.

They do implicitly: you can only be accidentally productive without those preconditions.

Re: Test-driven development with an LLM for fun and profit

#66
post #4

One trend I've noticed, framed as a logical deduction: 1. Coding assistants based on o1 and Sonnet are pretty great at coding with 2. Coding agents do massively better when they have a test-driven reward signal. 3. If a problem can be framed in a way that a coding agent can solve, that speeds up development at least 10x from the base case of human + assistant. 4. From (1)-(3), if you can get all the necessary context…

It doesn't have to be microservices. You can use modular architecture. You can use polylith. You can have boundaries in your code and mock around them.

Re: Test-driven development with an LLM for fun and profit

#67
post #31

Earlier quoted context omitted.

Can you extend that - what was the domain, how did you start? I would like to give this a try but am not quite sure I get it?

Backend coding for web services. In the past I would hand write 8 or 9 unit tests. Now I write the first one or two and then brain dump anything else into the LLM prompt. It then outputs mine plus 6 or more. I delete any that seem low value or ridiculous or have a follow up prompt to ask for refinements. Then just copy/pasta back into the codebase out of the chat.

Can confirm this approach works well for us too.

Re: Test-driven development with an LLM for fun and profit

#68
post #7

In Rust, there's a controversial practice around putting unit tests in the same file as the actual code. I was put off by it at first, but I'm finding LLM autocomplete is able to be much more effective just being able to see the tests. No clunky loop needed. It's gotten me back into TDD.

I've sometimes done the same in python. I do quite like the ergonomics.

Re: Test-driven development with an LLM for fun and profit

#69

This is not a good idea. If you want better tests with more cases exercising your code: write property based tests. Tests form an executable, informal specification of what your software is supposed to do. It should absolutely be written by hand, by a human, for other humans to use and understand. Natural language is not precise enough for even informal specifications of software modules, let alone software systems.…

The confusion in this article about what TDD is demonstrates how far everything has drifted. It's interesting in terms of what it achieves, but I don't think it's useful as a comment on TDD (or, for that matter, testing).

Re: Test-driven development with an LLM for fun and profit

#70

Hey, yeah, this is a fun idea. I built a little toy llm-tdd loop as a Saturday morning side project a little while back: https://github.com/zephraph/llm-tdd . This doesn't actually work out that well in practice though because the implementations the llm tended to generate were highly specific to pass the tests. There were several times it would cheat and just return hard coded strings that matched the expects of the…

> just return hard coded strings that matched the expects of the tests

I have done literally this in test ping-pong. It's fine. It just means it's on the other half of the loop to make the tests more in-depth.

Post reply on HN