Hacker News Reader

Comment by credit_guy | Hacker News Reader

I spent Friday and today using Copilot on a project and I (or it) wrote about 13k LOC: about 5k LOC of python code, 6k LOC jupyter notebooks and 2k LOC markdown files with agent orchestration. My time was spent waiting for Copilot to do the coding, then running tests and making sure they pass and they are meaningful, and then debugging. The debugging is a very interesting experience. You devise various tests to tease out what's going wrong and narrow down to a very small context so the issue becomes apparent to both you and the LLM. I didn't actually write a single line of python code myself. But a junior developer would have gotten stuck at the first problem that required debugging. These two days felt a lot like hard work. The only difference is that I have much more to show for after 2 days of work than I used to have in the past.

View on HN

5k in python is tremendous since the lack of {()} will make reading a long function quite the journey, this is of course my naive assumption that some of the functions are very long, in theory you could just put 1000 functions each of which 5 lines but i doubt that's the case in practice, the LLMs tend to give long and detailed statements from time to time.

The 5k lines of code are spread over 44 files. Most of this code is testing code. Just about 2k LOC are functional code. The functions are generally small. Only 5 functions have more than 100 LOC, and all have less than 200 LOC. All the functions have generous docstrings. I set up a system with a manager agent that would create action plans and executor agents that would execute, and then the manager had to review and accept the execution, and if not (it did happen once), the executor had to resume the execution until the manager confirmed the task was done. I stumbled upon this workflow by myself, and so far it looks like it works.

Most of my Python functions are less than 10 lines long and many are two or three lines long. At 10 I am already questioning if I should refactor it and at 20 my internal voice is screaming about it.

This does not change as the project gets larger.

LLMs don't write like this without very specific instructions, and it might be difficult even then. After all, most programmers don't write like that.

But I think they should, and I'm absolutely prepared to defend that.

Losing brackets doesn't make the code harder to read. After all, Python code must be properly indented for correctness. It does mean that you can't use the % key in vim to find the end of a block easily. But Python-specific editors can easily identify the end of a block and provide a "fold" feature if you like using those. I just prefer not to write code that would benefit from that.

Reply on news.ycombinator.com