271–280 of 410 posts
Earlier quoted context omitted.
>I then iterate on that plan.md with the AI until it's what I want. Which tools/interface are you using for this? Opencode/claude code? Gas town?
I find that Antigravity is really good for this. You can comment on the plan documents in-line.
Earlier quoted context omitted.
> (2) there's nothing wrong with more people being able to create and share things There is very clearly many things wrong with this when the things being shown require very little skill or effort.
That is by no means all of these projects. I'm not interested in a circle-the-wagons crackdown because it won't work (see "it's foolish to fight the future" above), and because we should be welcoming and educating new users in how to contribute substantively to HN.
Is it really that difficult to identify bot accounts right now? Or people who create a HN account only to post their project?
That seems like low-hanging fruit that should be picked immediately.
The way I write code with AI is that I start with a project.md file, where I describe what I want done. I then ask it to make a plan.md file from that project.md to describe the changes it will make (or what it will create if Greenfield). I then iterate on that plan.md with the AI until it's what I want. I then ask it to make a detailed todo list from the plan.md and attach it to the end of plan.md. Once I'm fully sa…
People keep talking about how LLMs are like a compiler from human language to code. We commit source code instead of just compiled machine code, so why should this be any different? The "source code" is the prompts
The prompt isn't very useful. You'd see the exact same prompt on every ticket for me. Prompt 1: "Research domain, think deeply, and record a full analysis in /docs/TICKET-123-NOTES.md" Prompt 2: Based on our research, read TICKET-123 and began formulating solutions. Let's think this problem through and come up with multiple potential solutions. Document our solutions in TICKET-123-SOLUTIONS.md Prompt 3: Based on Solu…
> Prompt 2: Based on our research, read TICKET-123 and began formulating solutions. Let's think this problem through and come up with multiple potential solutions. Document our solutions in TICKET-123-SOLUTIONS.md
> Prompt 3: Based on Solution X, let's formulate a complete plan to implement. Break the work into medium sized tasks that a human could complete in 5-10 hours. Write our plan in TICKET-123-PLAN.md
Sounds to me that all these 10x - 100x "engineers" can be removed from the loop.
This feels woefully inadequate. It should be saving everything. Not just the prompts and replies, but also the tool calls and skill invocations. If that is too much, then why even save anything in the session? Right now this paradigm is so novel to us that we don’t know if what is being saved is useful in anyway or just hoarding garbage. There are some who (rightly IMO) just neatly squash their commits and destroy th…
Should my google search history be part of the commit? To that question my answer is no.
The way I write code with AI is that I start with a project.md file, where I describe what I want done. I then ask it to make a plan.md file from that project.md to describe the changes it will make (or what it will create if Greenfield). I then iterate on that plan.md with the AI until it's what I want. I then ask it to make a detailed todo list from the plan.md and attach it to the end of plan.md. Once I'm fully sa…
I do something similar, but across three doc types: design, plan, and debug Design works similar to your project.md file, but on a per feature request. I also explicitly ask it to outline open questions/unknowns. Once the design doc (i.e. design/[feature].md) has been sufficiently iterated on, we move to the plan doc(s). The plan docs are structured like `plan/[feature]/phase-N-[description].md` From here, the agent…
FWIW, what you describe maps well to Beads. Your directory structure becomes dependencies between issues, and/or parent/children issue relationship and/or labels ("epic", "feature", "bug", etc). Your markdown moves from files to issue entries hidden away in a JSONL file with local DB as cache.
Your current file-system "UI" vs Beads command line UI is obviously a big difference.
Beads provides a kind of conceptual bottleneck which I think helps when using with LLMs. Beads more self-documenting while a file-system can be "anything".
Earlier quoted context omitted.
The prompt isn't very useful. You'd see the exact same prompt on every ticket for me. Prompt 1: "Research domain, think deeply, and record a full analysis in /docs/TICKET-123-NOTES.md" Prompt 2: Based on our research, read TICKET-123 and began formulating solutions. Let's think this problem through and come up with multiple potential solutions. Document our solutions in TICKET-123-SOLUTIONS.md Prompt 3: Based on Solu…
> Prompt 1: "Research domain, think deeply, and record a full analysis in /docs/TICKET-123-NOTES.md" > Prompt 2: Based on our research, read TICKET-123 and began formulating solutions. Let's think this problem through and come up with multiple potential solutions. Document our solutions in TICKET-123-SOLUTIONS.md > Prompt 3: Based on Solution X, let's formulate a complete plan to implement. Break the work into medium…
However, what each domain will tell you (engineering included) is that AI doesn't understand the full context of what you're doing and the point of the business and where to spend effort and where to cut corners. There is definitely still room for competent engineers to iterate here on the solutioning and plans to refine the AI work into something more sturdy.
Although this is only in domains where code quality truly matters. A lot of consumer software without SLA's are just vibe coding full speed now. No code review, AI writing 100% of the code.