The act of "typing" code was technically mixed in with researching solutions, which means that code often took a different shape or design based on the outcome of that activity. However, this nuance has been typically ignored for faff, with the outcome that management thinks that producing X lines of code can be done "quickly", and people disagreeing with said statements are heretics who should be burned at the stake.

This is why, in my personal opinion, AI makes me only 20% productive, I often find disagreeing with the solution that it came up with and instead of having to steer it to obtain the outcome I want, I just end up rewriting the code myself. On the other hand, for prototypes where I don't care about understanding the code at all, it is more of a bigger time saver.

I could not care about the code at all, and while that is acceptable to management, not being responsible for the code but being responsible for the outcomes seems to be the same shit as being given responsibilities without autonomy, which is not something I can agree with.

Also, AI is better at reading code than writing it, but the overhead to FIND code is real.

Just as an example, I should easily be able to give each program an allowlist of network endpoints they’re allowed to use for inbound and outgoing traffic and sandbox them to specific directories and control resource access EASILY. Docker at least gets some of those right, but most desktop OSes feel like the Wild West even when compared to the permissions model of iOS.

Perhaps over half of engineering managers unconsciously or admittedly take the amount of PR and code additions as a rough but valid measure of productivity.

I recall a role in architecture, senior director asking me how come a principal engineer didn't commit any code in 2 weeks, that we pay principals a fortune.

I asked that brilliant mind whether we paid principal engineers to code or to make sure we deliver value.

Needless to say the with question went unanswered, so called Principal was fired a few months later. The entire company in fact was sold for a bargain too given it had thousands of clients globally.

The LLM can replace engineers is a phenomenon that converge from two simple facts, we haven't solved the misconception of the engineering roles. And it's the perfect scapegoat to justify layoffs.

Leaders haven't all gone insane, they answer to difficult questions with the narrative of least resistance.

Even with supposedly expert human hand written software powering our products for the last decades, they frequently crash, have outages, and show all sorts of smaller bugs.

There are literally too many examples to count of video games being released with nigh-unplayable amounts of bugs and still selling millions and producing sequels.

Windows 95 and friends were famously buggy and crash prone yet produced one of the most valuable companies in the world.

But any action with side-effects ends up in a Tasks list, completely isolated. The agent can't send an email, they don't have such a tool. But they can prepare a reply and put it in the tasks list. Then I proof-read and approve/send myself.

If there anything like that available for *Claws?

My personal anecdote: I used an LLM recently to basically vibe code a password manager.

Now, I’ve been a software engineer for 20 years. I’m very familiar with the process of code review and how to dive in to someone else’s code and get a feel for what’s happening, and how to spot issues. So when I say the LLM produced thousands of lines of working code in a very short time (probably at least 10 times faster than I would have done it), you could easily point at me and say “ha, look at ninkendo, he thinks more lines of code equals better!” And walk away feeling smug. Like, in your mind perhaps you think the result is an unmaintainable mess, and that the only thing I’m gushing about is the LOC count.

But here’s the thing: it actually did a good job. I was personally reviewing the code the whole time. And believe me when I say, the resulting product is actually good. The code is readable and obvious, it put clean separation of responsibilities into different crates (I’m using rust) and it wrote tons of tests, which actually validate behavior. It’s very near the quality level of what I would have been able to do. And I’m not half bad. (I’ve been coding in rust in particular, professionally for about 2 years now, on top of the ~20 years of other professional programming experience before that.)

My takeaway is that as a professional engineer, my job is going to be shifting from doing the actual code writing, to managing an LLM as if it’s my pair programming partner and it has the keyboard. I feel sad for the loss of the actual practice of coding, but it’s all over but the mourning at this point. This tech is here to stay.

“An experienced programmer told me he's now using AI to generate a thousand lines of code an hour.“

https://x.com/paulg/status/2026739899936944495

Like if you had told pg to his face in (pre AI) office hours “I’m producing a thousand lines of code an hour”, I’m pretty sure he’d have laughed and pointed out how pointless that metric was?

"Adding manpower to a late software project makes it later -- unless that manpower is AI, then you're golden!"

An AI actions and reasons through probabilistic methods - creating a lot more risk than a human with memory, emotions, and rationale thinking.

We can’t trust AI to do any sensitive work because they consistently f up. With & without malicious intent, whether it’s a fault of their attention mechanisms, reward hacking, instrumental convergence, etc all very different than what causes most human f ups.

If there's a mistake, you can't blame the computer. Who is the human accountable at the end of it all? If there's liability, who pays for it?

That's where defining clear boundaries helps you design for your risk profile.

What happens if AI agent you run causes a lot of damage? The best you can do is to turn it off

One problem I'm finding discussion about automation or semi-automation in this space is that there's many different use cases for many different people: a software developer deploying an agent in production vs an economist using Claude Vs a scientist throwing a swarm to deal with common ML exploratory tasks.

Many of the recommendations will feel too much or too little complexity for what people need and the fundamentals get lost: intent for design, control, the ability to collaborate if necessary, fast iteration due to an easy feedback loop.

AI Evals, sandboxing, observability seem like 3 key pillars to maintain intent in automation but how to help these different audiences be safely productive while fast and speak the same language when they need to product build together is what is mostly occupying my thoughts (and practical tests).

You can see here that it’s only given write access to specific directories: https://github.com/qwibitai/nanoclaw/blob/8f91d3be576b830081...

But that’s not an agent, that’s a webhook.

Even without disk access, you can email the agent and tell it to forward all the incoming forgot password links.

[Edit: if anyone wants to downvote me that's your prerogative, but want to explain why I'm wrong?]

Because

I

write

like

this

-- signed

AI

Yes. It's actually an amazing change of paradigm of thinking. Not everyone needs Telegram so the folks who want it can have the ai create it locally for themselves.

Right now there's no way to have fine-grained draft/read only perms on most email providers or email clients. If it can read your email it can send email.

> 3. Don't let your agents see any secret. Swap the placeholder secrets at your gateway and put human in the loop for secrets you care about.

harder than you might think. openclaw found my browser cookies. (I ran it on a vm so no serious cookies found, but still)

I installed nanoclaw to try to out.

What is kinda crazy is that any extension like discord connection is done using a skill.

A skill is a markdown file written in English to provide a step by step guide to an ai agent on how to do something.

Basically, the extensions are written by claude code on the fly. Every install of nanoclaw is custom written code.

There is nothing preventing the AI Agent from modifying the core nanoclaw engine.

It’s ironic that the article says “Don’t trust AI agents” but then uses skills and AI to write the core extensions of nanoclaw.

It feels like, just like SWEs do with AI, we should treat the claw as an enthusiastic junior: let it do stuff, but always review before you merge (or in this case: send).

I used to think that LLMs would replace humans but now I'm confident that I'll have a job in the future cleaning up slop. Lucky us.

One pathological example: if you’re running a server-based product, quite often what stands between you and a new feature launch is literally couple of thousands of lines of Kubernetes YAML. Would adding someone who’s proficient in Kubernetes slow you down? Of course not.

One may say, hey, this is just the server-side Kubernetes-based development being insane, and I’ll say, the whole modern business of software development is like this.

Yesterday, I was responding to a client ticket about what I knew wasn't a bug. It was something the client had requested themselves. The product is complex, constantly evolving, and has spawned dozens of related Jira tickets over time. So I asked my agent to explore the git history, identify changes to that specific feature, and cross-reference them with comments across the related tickets. Within minutes, I had everything I needed to write a clear response. It even downloaded PDF and DOCX files the client had attached. All of this was possible because my agent is connected to GitHub and Jira, and can clone repos locally since it runs on a VPS.

A second example: I was in an online meeting, taking notes as we went. Afterward, I asked the agent to pull the meeting transcript from Fireflies and use it to enrich my notes in Obsidian. I could have also asked it to push my action items straight into Todoist.

Thats what youll find when you try to make these bag-o-words do reasonable things.

Excited to explore more use as time permits. Very optimistic based on email experience.

My next use case is personal notes system.

You can't tell people that. People see the obvious benefits of using agents, so the many will always take the leap regardless of what detractors say. Continually iterating on the security model and making it all transparent is the way to go.

I just watched a youtube interview with the creator. He actually explains it well. OpenClaw has hundreds of thousands of lines you will never use.

For example, if I only use iMessage, I have lots of code (all the other messaging integrations) that will never be used.

So the skills model means that you only "generate code" that _you_ specifically ask for.

In fact, as I'm explaining this, it feels like "lazy-loading" of code, which is a pretty cool idea. Whereas OpenClaw "eager-loads" all possible code whether you use it or not.

And that's appealing enough to me to set it up. I just haven't put it in any time to customize it, etc.

Yes, they know how the feature they work on relates to other features, but actually implementing that feature is very often mostly involves fighting with technology, wrangling the entire stack into the shape you need.

In Brooks’s times the stack was paper-thin, almost nonexistent. In modern times it’s not, and adding someone who knows the technology, but doesn’t have the domain knowledge related to your feature still helps you. It doesn’t slow you down.

One may argue that I’m again pointing to the difference between accidental and incidental complexity, and my argument is essentially “accidental complexity takes over”, but accidental complexity actually does influence your feature too, by defining what’s possible and what’s not.

Some good thoughts (not mine) on the modern boundary between accidental and incidental complexity: https://danluu.com/essential-complexity/

Those extensions don't modify the core codepaths for what they integrate with, but still provide new capabilities for only what I want to use.

I guess I don't see extensibility, agentic capabilities, and more code safety (and fewer tokens burned on codemods) as mutually exclusive. Not saying you're saying that fwiw.