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

Points: 4

# Comments: 0

Would it be possible to ditch Twilio and build it as a peer-to-peer system though? Or does that always require a coordination server?

So to the OP's example "optimise a bike wheel", technically an AI should be able to understand whether a proposed wheel is good or not, in a similar way to a human.

If anything, AI could help by "understanding" the real objective, so we don't have to code these simplified goals that ML models end up gaming no?

I might start reading the actual submissions more often instead of just the comments

I'm thinking a system that figures out how to talk to devices using a mixture of hardcoded knowledge about APIs and mainstream devices, and LLMs figuring APIs out.

Something where natural language can be used to create complex automations: i.e. "when the washing machine plugged into the smart plug called Washer ends, say through the Alexas 'Washing is done'", "whenever possible, turn on the lights softly whenever they are off and someone walks into a room, then dim to off shortly after the room is empty".

LLMs can solve most of this with today's capabilities and good prompting, and I haven't done the math but with a subscription model I imagine it should be possible to cover API costs, possibly with a fair use cap.

Whenever I think about this I conclude that the limiting factor would be that you'd need hardware, but something like a raspberry pi is <100$/unit and would "just" need to be put in a nice wrapper with a speaker and a microphone (although I'm sure this is harder than I can envision), so all in all it seems doable?

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

Points: 1

# Comments: 0

I envision it being able to fully replace a junior engineer, and in some use-cases senior engineers as well.

In the case of junior engineers: the AI should have access to an internal knowledge base (i.e. Confluence) and the task/ticketing system (Jira), and ideally the internal chat (Slack). I would assign tickets to it, and I'd expect the AI to reply with comments asking for clarification when there is something unclear, or proposing an implementation before starting if it's not a very simple task (this could even be defined in the task, using story points for instance.

Once cleared, the AI submits a PR linked to the task - so far just like any engineer in the team would. The PR gets reviewed as usual, with suggestions/requests for changes made by the (human) team, which then get addressed by the AI. With the big difference that all this process may happen in less than 1h from ticket creation to PR review.

I wouldn't expect it to be able to implement complex features, onboard new libraries, or rearchitect the system in major ways to accommodate future features - just like I wouldn't expect that from junior team members.

It would obviously be amazing if it could incorporate previous PR comments into it's "context" for future work, so it could learn and improve.

Separately I mentioned it could also do part of the job of senior team members - in the form of PR reviews. If it has access to every previous PR review and learns from them it might be able to give insightful suggestions, and for very large codebases it could have an advantage over humans as it could find patterns or existing code that may be overlooked (i.e. "It looks like this util function you added is the same as this one that was already there", or "This code looks different to similar areas, but follows a different pattern, you might want to rewrite it this way //..."

Is GPT-4 there? Definitely not, perhaps an LLM is not even the way to achieve this, but I absolutely see this becoming an incredible asset to a tech team.

If at any point anyone goes like "oh it doesn't seem to support this, we'll have to write some wrappers/custom stuff", take a step back and read the docs again or ask around - the library in general takes care of everything it should and gets out of the way really well otherwise.

Happy to help with this.

You could rotate encryption keys whenever you want for new external id calculation, so that older external ids won't change (as they are external, they need to stay immutable).

You can even have dependency groups, to separate main/dev dependencies for instance. It also brings env management, and plays very nicely with Docker if you use containers.

[1] https://python-poetry.org

A dream of mine would be to setup a hostel of sorts, with an area for camping, a cafe, maybe food trucks in the summer?, surf/climbing options nearby and perhaps a partnership with schools/guides.

And the main thing: a big hangar to work on campervan conversions, with a ton of tools available and some staff supervision. The idea being that you bring your van, pay some sort of membership/one-time fee and work on it, with our help.

Perhaps do some in-house conversions for clients, but that would be just a side business to help keep things going.

I'm sure there are very complex valuable pieces of code within the maps codebase (or any other), but it would be a fairly massive task finding those pieces, extracting them, and getting them to work properly in a different codebase...

Thanks

[Client]->[Cloudfront]->[Load balancer]->[ECS service in a VPC]->[RDS/other internal systems]

* Replace the above with any other cloud provider, or just commercial/open source tools that do the same job running in a VPS or whatever *

I can't see how any of this could be claimed to be protected by an NDA or similar, as this is just a highly standard architecture.

If you work on a proprietary system that has a specific architecture just don't mention that of course. I think the above allows us to discuss things pretty well, talk about introducing caching, why each layer is there, TLS termination, authentication/authorization concerns and implementation, secrets management...

If we're going to blindly do something because "it's the exact rule written here" then we might as well replace all decision makers with an AI that never interprets anything.

Their teacher was wrong for not interpreting the rules correctly - everyone's aware of that. On top of that the people writing those rules were wrong as well for either assuming that teachers would interpret them correctly, or not being more explicit when writing them.

It's a competition that includes writing code as a team: one of the main things you'd want them to do is to use git and thus a website like Github.

Several websites and years later I had a pretty good understanding of backend/frontend concerns, web security, SQL and databases... although I didn't really bother setting up a local environment so I just tested new stuff "in prod" by dropping the new files directly via FPT!

After University I then started working as a software developer doing full stack work (mostly Java & Python backends) and Angular, then React for frontend.

In many ways I prefer TypeScript + React in the frontend with a Java/Nodejs + TS GraphQl backend, but I remember the speed with which you could get a website up and running, self contained, with no CI/build/deploy issues and it was the best thing ever to learn really

I'm almost curious to see what it'd be like to build a website super professionally now with PHP, but I'm pretty sure it'd feel very similar to typed python or Java