Comments URL: https://news.ycombinator.com/item?id=49117602

Points: 17

# Comments: 4

Amazing job!

Same discussion 3 years ago

The user needs to do 3 things for this to be actually be phished:

1. Receive money from somebody they don’t known with a weird description 2. Proactively ask the agent for such transaction 3. Click the link the agent provide

While this of course can happen on scale, doesn’t seems so critical in practice

Of course innovation in shoes will have a bigger marginal impact (because physics).

The invented “people start with a k8s cluster for 5 users” doesn’t really exist. This is just a story repeated ad nauseam to fit a narrative that help them justify their choices. This position is just as dogmatic, if not more, than the alleged dogma it attempts to disrupt.

Smart technical leaders knows that technical decisions only matter in context never in absolutes. The right answer is always “it depends”.

I can agree that there is a tendency to prematurely optimize infra, as a direct consequence of lack of measuring especially in young busy startups. One could argue that premature optimization might be the smart choice when you don’t have enough data, as in the best case scenario (your startup do well) you’ve saved some time, worst case scenario you’ve lost some money that depending on the situation might be less valuable than time spent in maintaining, and later refactoring, infra.

The sentence reads: “Distribution of satellite cable television decryption devices”

As I will need to fully handover the task and let the agent(s) essentially one-shot the implementation I need to be way for specific and clear in giving it context and goals, otherwise I’m afraid it will start build code purely by accumulation creating a pile of unmanageable garbage.

Also changes which requires new UI components tend to require more manual adjustments and detailed testing on the UX and general level of polishing of the experience our users expect at this stage.

I’m starting to develop a feeling of tasks that can be done this way and I think those more or less represent 20 to 30% of the tasks in a normal sprint. The other 70% will have diminishing returns if not actually a negative return as I will need to familiarise with the code before being able to instruct AI to improve/fix it.

From your experience building this, what’s your take on:

1. How do your product helps in reducing the project management/requirements gathering for each individual tasks to be completed with a sufficient level of accuracy?

2. Your strong point seems to be in parallelisation, but considering my previous analysis I don’t see how this is a real pain for a small teams. Is this intended to be more of a tool for scale up with a stable product mostly in maintenance/enhancement mode?

3. Are you imagining a way for this tool to implement some kind of automated way of actually e2e test the code of each task?

What do you think about this project? Has something like this being tried before?

Comments URL: https://news.ycombinator.com/item?id=47110386

Points: 1

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=46020096

Points: 141

# Comments: 97

Comments URL: https://news.ycombinator.com/item?id=45552160

Points: 2

# Comments: 1