This explains why they are trying to cut all the third party software out of the subscriptions.

Interesting!

I still wouldn't give to any claw access to my mail accounts, but it is a step in the good direction.

I love how NanoClaw is aggregating the effort of making personal assistants more secure.

Good job!

I don't get the idea of giving a claw access to your own mail account, but am now playing with the idea of it having its own email account that I selectively forward to - that offers almost the full benefit, with significantly less risk.

yeah, that's the approach I've taken. I quite liked the idea of giving it full delegated perms on my email account and calendar (eg, dig out that email and reply back to them for me) but the risk profile is just too high, and forwarding emails where needed mostly works.

Same here. Coupled with configuring the agent's email account at the provider to only be able to send and receive to my email address.

One part that makes me wary of these tools is security.

If I use a remote MCP or CLI that relies on network calls, and I give it in the hands of my coding assistant, wouldn't be too easy to inject prompts and exfiltrate data from my machine?

At least MCP don't have direct access to my machine, but CLIs do.

We've been working on a warrant model that ensures task-scoped authorization: constrain your agents to specific tools and specific arguments, cryptographically enforced at the MCP tool boundary. Even a fully compromised agent can't reach outside its warrant. Open source. github.com/tenuo-ai/tenuo

There is another differentiator between CLIs and MCP.

The CLI are executed by the coding assistants in the project directory, which means that they can get implicit information from there (e.g. git branch and commit)

With an MCP you would need a prepare step to gather that, making things slower.

I wonder if flood and drain would work with orchids.

I do that manually with my plants twice a week, they have flowers almost all year, but it's a chore to bring them out, flood them, make them drain and bring them back home.

Also my wife always yells at me because I always wet the floor in the process.

There's a couple of YouTube channels (mainly from India) that claim great success with orchids and safron though I'm skeptical of the claims.

Really depends on the draining proprieties of your soil,

and how “flood” your flood is,

right?

It really depends on what kind and of job you do.

If it's not something very common LLMs could end up generating random code.

Also if you work on something performance critical, you can get inspiration from LLMs, but they often don't write fast code.

not my experience, they write fast code, and if you ask them to optimize, can pull all kinds of tricks out of the bag. Even with some of the niche stuff I work on, they seem really good.

Without telling us what kind of code you are talking about it is hard to compare. I would say that is true for CRUD web code because there is so much out there that the LLMs can reference.

I work on all sorts as we have an IoT product offering.... embedded bare metal systems, web, backend IoT servers, Gateways, APIs, Import/Export Systems, Integrations with Manufacturing systems, accounting systems, Automatic Test Equipment. I've been coding for nearly 50 years now, so pretty experienced. What peoples comments seem to imply to me is that they haven't really gone full agentic coding, where you hone your context, your tools, and how you iterate and test with an AI agent. Where any mistakes an AI makes you make sure it can't do it again, you have it setup so your AI code reviews are honed to focus on the things you care about etc.

Software development is a quite vast discipline.

In my experience performance of LLMs can be surprisingly good on things that are not mainstream, like database engineering, and surprisingly bad at mainstream categories approached in an unconventional way.

That said, I'm amazed that you have 50 years of experience and still able to have the mental flexibility to adapt to new development paradigms.

As you imply, this stuff isn't simple to pick up, and is completely different on how we have done our job without AI.

> I'm amazed that you have 50 years of experience and still able to have the mental flexibility to adapt to new development paradigms.

This is the root of age discrimination in technology fields.

Sorry, I now realize that it could be read like this.

Just to clarify, I meant to share admiration toward a fellow engineer.

I do not think that age implies any hard assumption, usually brings cultural diversity which is good.

gdorsi , it's not that hard to swap really, because the goal, designing systems, just got easier. I feel AI lets you be a system engineer way better as you can quickly iterate. I have the same kinds of goals in mind, just can do it a heck of a lot quicker.

hubertdinsk, can't reply directly... but yes lots of niche things, especially in the embedded side, automatic test side. We have a lot of hardware, we control a lot of things, sense a lot of things. There's nothing inherently complicated about it such that AI can't code, in fact you feed AI technical data sheets its insanely useful when writing code against that hardware. It's going to pick up on all the weird nuances. It's great for protocols, especially proprietary ones. Anything with spec sheets are good.

there's no magic anywhere. At the end of the day the result is 0 and 1 onto memory.

The approach to get there is the differentiate factor. If you are to tell a probabilistic tool to be 99.9999999% correct it would just be silly.

so not niche at all. You described a bit of everything.

Niche is more like "ISO26262 compliant, response time under 50ms, measured with a oscilloscope with at least 40MHz bandwidth, failure rate less than 10^-7, proven with maths and soak tests". It gets more niche the closer you get to hardware.

Next word prediction will get you laughed out of the room.

> Fine-grained permissions and policies. Not just what tools an agent can access, but what it can do with them. Read email but not send. Access one repo but not another. Spend up to a threshold but no more.

If nailed this is going to be interesting.

All the other solutions I've been sumbling around are either very hard to customize or too limited.

Docker sandboxing is kinda nice, but not enough to trust an LLM even with my messaging accounts.

Sweet, great job Vite team!

I wonder how much of the Rollup bundling magic has been ported to Rolldown.

One thing that always made this kind of switch to Rust has always been that Rollup has become so sophisticated that's hard to replace with something new.

I see this post as something motivational around public writing or public speaking.

It's true that the more you are afraid of expressing yourself, the worse your "performance" is going to be.

On general work level it's different.

There the trust needs to be balanced.

People should feel free to express themselves, but also that they need to meet some certain standards of quality at work.

Otherwise we may tend to relax too much and become sloppy in certain areas.

This comes as reminder that software engineering is way more than generating code.

We build systems that can fail in unpredictable ways, and without knowing the system we built deeply is hard to understand what's going on.