5 ms·

I am currently writing a lot of code that I am not reviewing anymore. These are all the things that make it work for me: - Work on small projects (< 500k lines

by xgb84j 7d ago

I am currently writing a lot of code that I am not reviewing anymore. These are all the things that make it work for me: - 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. I have never seen a customer or business person care about that. - Have clearly defined API boundaries. Examples: If the back end is solid you can just vibe code the first version of a front end according to some mockup. Define a data pipeline with steps and clear contracts of what data gets passed around and what each step does. If the LLM messes up one step, rip it out and rewrite it. - Have clearly set up workflows for tasks. Start with a "ask me everything" phase, then comes a plan phase, a review phase, an implementation phase, another review phase and then the integration phase. Multiple agents going over the same problem catch a surprising amount of dumb stuff that would otherwise slip through. - Set up excellent testing. Build your whole architecture around being easy to test. - Have skills for common problems. For one of my projects I had to set up a skill on how to query the ORM, because 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. I don't think this works for everybody and every project. If you have a culture that values code quality and readability, if you work on large existing projects, if you have to nail the architecture of some non-trivial piece of software etc. you are going to have a bad time. On the other hand you can probably build the MVP of your AI-supported CRUD app 10-20x faster. I think a lot of the discussions around development tools and techniques just stem from two facts: 1. Developers work on widely different projects with different management and constraints. 2. Tools, libraries, frameworks and code style have to match your mental model, otherwise you going to dislike them.

croon 7d ago
>> 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?
- deleted 7d ago
  [deleted]
- xgb84j 6d ago
  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.
re-thc 7d ago
> 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?
- juvvel 7d ago
  This is like the first rule of working with clients -- what the client says they want is often not what they truly want.
- xgb84j 6d ago
  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.
  - re-thc 6d ago
    > 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.
sillyfluke 7d ago
>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.
- xgb84j 6d ago
  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.
margolis20 7d ago
[flagged]
oliver236 6d ago
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
- xgb84j 6d ago
  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.)
  - oliver236 6d ago
    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.
suttontom 6d ago
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.

by xgb84j 7d ago

croon 7d ago

>> 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?

deleted 7d ago
[deleted]
xgb84j 6d ago
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.

re-thc 7d ago

> 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?

juvvel 7d ago
This is like the first rule of working with clients -- what the client says they want is often not what they truly want.
xgb84j 6d ago
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.
- re-thc 6d ago
  > 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.

sillyfluke 7d ago

>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.

xgb84j 6d ago
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.

margolis20 7d ago

[flagged]

oliver236 6d ago

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

xgb84j 6d ago
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.)
- oliver236 6d ago
  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.

suttontom 6d ago

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.