Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microsoft Amplifier

github.com

Post reply on HN
Print view View original

111–120 of 171 posts

Re: Microsoft Amplifier

#111

Post by Keyframe »

ramraj07 wrote: post #76
hansmayer wrote: post #64

Earlier quoted context omitted.

Nothing to do with ego, but you may want to check your own projections, you know how when you speak of the others, you mainly speak of yourself (Jung or Freud, not sure). No need to be bitter about not having the grind and focus to become an engineer yourself, it is after all much harder than say, earning an MBA and you should be OK with whatever you turned out to be. Not to mention that the tools themselves, were in…

For some reason youre assuming Im not an engineer which is funny and revealing. I am an engineer and my vibe coded prototype is now in production, one of the best applications of its type in the industry, and doing really well. So well, I have a pretty large team working on it now. This project was and still is 95% written by AI. No complaints, never going back. That's my experience. Clearly the eng community is spli…

trust me bro vibes

Re: Microsoft Amplifier

#112

Post by thethimble »

danmaz74 wrote: post #95
nightshift1 wrote: post #69

I think that letting an LLM run unsupervised on a task is a good way to waste time and tokens. You need to catch them before they stray too far off-path. I stopped using subagents in Claude because I wasn't able to see what they were doing and intervene. Indirectly asking an LLM to prompt another LLM to work on a long, multi-step task doesn't seem like a good idea to me. I think community efforts should go toward mak…

When the task is bigger than I trust the agent to work on it on its own, or for me to review the results, I ask it to create a plan with steps. Then create a md file for each step. I review the steps, and ask the agent to implement the first one. Review that one, fix it, then ask it to update the next steps, and then implement the next one. And so on, until finished.

Separately, you have to consider that "wasting tokens spinning" might be acceptable if you're able to run hundreds of thousands of these things in parallel. If even a small subset of them translate to value, then you're far net ahead vs with a strictly manual/human process.

Re: Microsoft Amplifier

#115

Post by thethimble »

stillsut wrote: post #110

I've actually written my own a homebrew framework like this which is a.) cli-coder agnostic and b.) leans heavily on git worktrees [0]. The secret weapon to this approach is asking for 2-4 solutions to your prompt running in parallel. This helps avoid the most time consuming aspect of ai-coding: reviewing a large commit, and ultimately finding the approach to the ai took is hopeless or requires major revision. By gen…

There is a related idea called "alloying" where the 2-4 candidate solutions are pursued in parallel with different models, yielding better results vs any single model. Very interesting ideas.

https://xbow.com/blog/alloy-agents

Re: Microsoft Amplifier

#116

Post by mark212 »

npalli wrote: post #18

Contributors claude Claude Interesting given Microsoft’s history with OpenAI

more than history -- early, massive investment in OpenAI by Microsoft and formerly their exclusive compute provider.

This stood out to me too, seems like a months-long project with heavy use of Claude

Re: Microsoft Amplifier

#117

Post by thethimble »

nine_k wrote: post #108
vincnetas wrote: post #97

Earlier quoted context omitted.

Claude Code will not ask for your approval before running potentially dangerous commands. and requires careful attention to security considerations and careful human supervision is a bit orthogonal no?

As a token of careful attention, run this in a clean VM, properly firewalled not to access the host, your internal network, GitHub or wherever your valuable code lives, and ideally anything but the relevant Anthropic and Microsoft API endpoints.

And even then if you give it Internet access you're at risk of code exfiltration attacks.

Re: Microsoft Amplifier

#118

Post by willahmad »

Project looks interesting, but no demos. As much I want to try it because of all cool concepts mentioned, but I am not sure I want to invest my time if I don't see any demos

Re: Microsoft Amplifier

#119

Post by typpilol »

furyofantares wrote: post #96
typpilol wrote: post #91

Earlier quoted context omitted.

I'd rather have in-depth commit messages then three word ones

When I blind-commit claude code commit messages they are sometimes totally wrong. Not even hallucinations necessarily - by the time I'm committing the context may be large and confusing, or some context lost. I'd rather have the three word message than detailed but wrong messages. I think I agree with you anyway on average. Most of the time a claude-authored commit message is better than a garbage message. But it's s…

You're not wrong.

I'd never encourage anyone to blind commit the messages But if they are correct they seem a lot more useful than 90% of commit messages.

I found the biggest mistakes that I've seen other people do are like - they move a file, and the commit message acts like it's a brand new feature they added because the llm doesn't put it together it's just a moved file

Re: Microsoft Amplifier

#120

Post by michaelbarton »

thethimble wrote: post #115
stillsut wrote: post #110

I've actually written my own a homebrew framework like this which is a.) cli-coder agnostic and b.) leans heavily on git worktrees [0]. The secret weapon to this approach is asking for 2-4 solutions to your prompt running in parallel. This helps avoid the most time consuming aspect of ai-coding: reviewing a large commit, and ultimately finding the approach to the ai took is hopeless or requires major revision. By gen…

There is a related idea called "alloying" where the 2-4 candidate solutions are pursued in parallel with different models , yielding better results vs any single model. Very interesting ideas. https://xbow.com/blog/alloy-agents

This reminds me of an an approach in mcmc where you run mutiple chains at different temperatures and then share the results between them (replica exchange MCMC sampling) the goal being not to get stuck in one “solution”
Post reply on HN