5 ms·
> The important part seems to be knowing what to ask, what to check, and what you are actually trying to build. 1. Understanding user requirements/pain points
by Oras 25d ago
> The important part seems to be knowing what to ask, what to check, and what you are actually trying to build.
1. Understanding user requirements/pain points is very important and many get it wrong.
2. Doing the architecture of the system within the org env/cloud/infra is often wrong by LLMs (for now).
3. Debugging when things go wrong. What to log, how to log it, and how to ensure not logging much or logging sensitive data.
4. Guide junior engineers, so they are not just accepting what LLMs are spiting.
- gokuljs 25d agoOn point 1, it depends, and I think it is a UX issue. There might be a little bit of friction in nailing things down, but the coding part is 100% solved. On point 2, yes, again, there is a bit of friction. I would divide this into two cases based on what I have seen. Let’s say you don’t know coding and you are building a product for a decent number of users. Most people who don’t know coding get things wrong. I have seen that. But I have also observed that if they had asked better questions, much better questions, they would have gotten most things right. The other case is when you are dealing with a large enterprise. That is a different game altogether, but not everyone faces that kind of problem. Point 3 is completely solved. Most companies have integrated agents into the development cycle itself. If something goes wrong, you review it and merge it. The only bottleneck is when it is connected to external factors. Point 4: an environment with proper `SKILLS.md` and `AGENTS.md` files writes better code than most senior engineers . Trust me, I am not even lying here.
- Oras 25d agoSkills and agents md files have better guidance than most senior engineers? Oh well, good for you then, especially with the “trust me” phrase
- gokuljs 25d agoProve me wrong. I’d be happy if you do. The only engineers I’ve seen who are extremely good tend to have 15 to 20 years of experience. The difference they bring is not really in the code. It’s in how aggressively they cut unnecessary complexity and how much more effective they are at system design.
- bridgejump 25d ago30 days ago you say you have 4.5 yoe Comment activity and contents, you are clearly unemployed troll I hate people like you so much We need a war to clear the underbrush desperately I curse you
- gokuljs 25d agoWho are you calling troll here?. Tell me where I am wrong if you can't answer that, keep quiet
- deleted 25d ago[deleted]
- deleted 25d ago[deleted]
- Oashe02 25d agoi used to get to much problem in 3 debugging and logging for unknown errors in blindsight. but after using Trace browser ide , other than engineering thinking mostly things are getting automated.
- gokuljs 25d agoI can see infra teams directly integrating agents into DevOps now. If something goes down, by the time the team looks at it, the PR with the fix can already be ready. That whole loop is getting automated too.