Hacker News Reader

>> but I look at those same people’s code and it’s horrific, and then I find they haven’t made it far past a proof of concept phase.

> Work on small projects (< 500k lines of code).

> Work for business people who want fast results. Agentic coding gets you to something presentable much faster at the cost of code quality.

You then expand on methods and processes that work for you, but I think the crucial question that you do not answer is: How long lived are any of these codebases?

All the projects I work on have an explorative character. It's very difficult to design a product, build it and sell it. You need actual customer feedback. LLM code gives you a much faster feedback loop.

If you have a clearly defined problem with customers lined up, you should absolutely use a different approach. In the startup world you often don't and you already know that you will throw away or rework 90% of the code before the first line is even written. The best thing to do then is to have clear boundaries and good tests, which allow ripping out parts of the codebase and reworking them.

> Work for business people who want fast results. Agentic coding gets you to something presentable much faster at the cost of code quality. I have never seen a customer or business person care about that.

That's always false. It's like people want their meals delivered fast. They say they don't care about taste or how it is done. Watch when they get sick or don't like it and the drama that happens.

People don't care until they do. They don't know what to care (in this case code quality) or say that because you're not explaining it. People also "gamble" and you take the blame. Long term impacts? Nah doesn't matter. Weeks later and things break -- what did you do?

This is like the first rule of working with clients -- what the client says they want is often not what they truly want.

In my country we have very protective labor laws, but what you describe is one of the few reasons that allow for instant termination: You refuse a direct order. If your boss says that he does not care about long term consequences and he want things done a certain way, you do it that way. Everything else is unprofessional. Your opinion on what you think he wants is legally irrelevant.

> You refuse a direct order.

I never said. It's not about outright refuse. It's how to deliver better outcomes. It's not a win or lose situation. Don't treat it like that.

> If your boss says that he does not care about long term consequences and he want things done a certain way

As suggested in my previous comment it could be you didn't explain it well. If you say code quality they might not care. Say it will crash randomly and can't fix it then they might. There's some art to it.

> Your opinion on what you think he wants is legally irrelevant.

No it's not. So you're saying if you got told to do something illegal you'd also do it anyway? I doubt it. You need to at least cover your back and document it as such. I'd say termination is better than jail.

>Claude was consistently doing database operations in a for loop, where it could use batch operations.

>The code in the end is better than a lot of the code I've seen humans write.

It's a little amusing to see those two sentences written back to back with no hint of irony to be frank.

By the way, why didn't the "Multiple agents going over the same problem catch a surprising amount of dumb stuff that would otherwise slip through" catch it?

Who knows how many skills you would have to have added if you actually reviewed the 400k codebase...But don't worry that's not what I am advocating. I myself would also latch onto any excuse that allows me to avoid the realization that I have to review 400k (or half that) lines of code, primary one being that I will always have a desperate paying customer that will always be grateful for anything I give them.

Which comes to your most valid advice which has nothing to do with AI (now that many devs have access to it):

> Work for business people who want fast results

This is what well oiled outsourve shops used to do and I must say it is no easy feat to be able to line up a constant stream of desperate businness people out of thin air, especially for your regular "I just want to code" engineer.

My guess is you're in the honeymoon phase with most of these people. The outsource shops that survived would fire the client that became more demanding and less grateful and move onto more freshly desperate client pastures. It is true that sales, self-promotion, and marketing are more important than ever now...

>Set up excellent testing.

Is this the part that you hand code or constantly review yourself? I guess not, since you would have explicitly mentioned something that important. I would caution you not to be surprised when no one believes you have excellent testing when you've unleashed multiple LLMs on it and are not reviewing code anymore.

I do not believe you read my comment in good conscience.

>>Claude was consistently doing database operations in a for loop, where it could use batch operations.

>>The code in the end is better than a lot of the code I've seen humans write.

>It's a little amusing to see those two sentences written back to back with no hint of irony to be frank.

There is no irony because I have seen humans do the same thing. The difference is that the human was paid 50x more.

I do not understand your arguments around outsource shops. I get clients. They want something. I deliver. There is not a lot of complexity to this. I am not a world start programmer that has 50 clients to choose from.

>>Set up excellent testing.

>Is this the part that you hand code or constantly review yourself? I guess not, since you would have explicitly mentioned something that important. I would caution you not to be surprised when no one believes you have excellent testing when you've unleashed multiple LLMs on it and are not reviewing code anymore.

I set up excellent testing the same way a CTO would set up excellent testing: I give clear guidelines on the architecture I want to see on the project. I then review key parts and samples of it and give feedback. When it looks good I mark it as done and move on. Any bugs or defects always result in additional test coverage.

I'm happy to have a constructive discussion about this, but I do not appreciate your sarcastic, tongue-in-cheek, condescending tone. It makes people not wanting to communicate with you.

> There is no irony because I have seen humans do the same thing.

Your original comment started with the sentence:

> I am currently writing a lot of code that I am not reviewing anymore.

Then you give an example of catching a bad pattern the LLMs used when you actually reviewed the code, after you mentioned you had multiple agents set up to catch each others mistakes. That is the irony. You're mentioning that LLMs engage in basic bad coding patterns that are not caught by multiple agents, hence underlining the importance of human review.

> There is no irony because I have seen humans do the same thing.

Yes, but you were reviewing the humans. You're not reviewing the LLMs.

> I set up excellent testing the same way a CTO would set up excellent testing.

Knowing LLMs can make basic coding pattern mistakes (as you mention) but still unleashing them on your tests without routine human review that makes sure that test suites have not been negatively affected after each iteration seems like the polar opposite of consistantly maintaining excellent testing throughout the software development process.

So, only use it for small codebases, don't use it if you value code quality or readability, and it's really good at building a CRUD app demo? I'm shocked. This is all completely new information.

how are you setting up excellent testing? using AI agents? hand writing tests? I hate talking to AI, I wish I could just write the test and the AI agent implement the fix

I am hand-holding the AI on the e2e setup. It mostly consists of Playwright + Cucumber + a test API to set up more complex scenarios. I also have unit tests for logic that lends itself to that. I also use mocked LLM responses for LLM projects.

If you enjoy writing tests, AI is really good at finding appropriate fixes for bugs that are easily reproducable. Just make sure to always have another AI review the fix. Otherwise you get a lot very, very dirty quickfixes. (At least in my experience.)

Thanks for the reply! So you would say that you have personally reviewed all the tests?

I’ve been thinking about how tests comunícate product function much more clearly and durably than prose, and that it maybe possible to create some sort of portable testing SDK that connects to the codebase and allows the dev to talk to the AI by just carefully writing tests, posting them to a backlog for the AI to pick up and edit the codebase until green.