jrvarela56

Pay someone else to develop. Usually someone shows up because people need to make a living.

Sandboxing is a solved problem, there are dozens of providers of firecracker instances to run your agent in.

The problem to be solved is how do you define task-specific least privilege versions of your coding agent.

“Teaching and engineer to understand the minutia of fund accounting well enough to build software for these firms is tough.”

Sounds like you need a senior familiar with finance/accounting and a family to feed. Email me!

how do you measure if google’s engineering org is more productive than meta’s? What about comparing 2 startups/small teams?

I think the discussion about methods (coding agents included) depends on answering those questions. Seems pointless to claim these agents [dont] make you more productive.

Although, at a first glance, the productivity increase does seem like nothing I’ve seen before. Even more than the transition of making webapps in plain js -> jquery -> frameworks or going from something like Flask to using Rails.

Problem is this is not evidence based. I just feel prototyping has speed up 100x. So the number of iterations/attempts has gone up. Transforming specs into a test suite takes a fraction of the time. Dunno, feels weird not to be able to be overall more productive (do more with less time) if you have these new tools.

A key term is ‘single player value’. One type of user needs to get benefits out of this marketplace as a tool so that you can use that engagement to solve the chicken and egg problem.

Not sure if you mean 1) sub-agent definitions (similar to skills in Claude Code) or 2) CLI scripts that use other coding agents (eg claude calling gemini via cli).

For (1) I'm trying to come up with a simple enough definition that can be 'llm compiled' into each format. Permissions format requires something like this two and putting these together some more debugging.

(2) the only one I've played with is `claude -p` and it seems to work for fairly complex stuff, but I run it with `--dangerously-skip-permissions`

I implemented a client for each so that the session history is easy to extract regarding the agent (somewhat related to progress of goal).

Context: AGENTS.md is standard across all; and subdirectories have their AGENTS.md so in a way this is a tree of instructions. Skills are also standard so it's a bunch of indexable .md files that all agents can use.

I'm leaning in this direction. Recently slopforked pi to python and created a version that's basically a loop, an LLM call to openrouter and a hook system using pluggy. I have been able to one-shot pretty much any feature a coding agent has. Still toy project but this thread seems to be leading me towards mantaining my own harness. I have a feeling it will be just documenting features in other systems and maintaining evals/tests.

The past month made me realize I needed to make my codebase usable by other agents. I was mainly using Claude Code. I audited the codebase and identified the points where I was coupling to it and made a refactor so that I can use either codex, gemini or claude.

Here are a few changes:

1. AGENTS.md by default across the codebase, a script makes sure CLAUDE.md symlink present wherever there's an AGENTS.md file

2. Skills are now in a 'neutral' dir and per agent scripts make sure they are linked wherever the coding agent needs them to be (eg .claude/skills)

3. Hooks are now file listeners or git hooks, this one is trickier as some of these hooks are compensating/catering to the agent's capabilities

4. Subagents and commands also have their neutral folders and scripts to transform and linters to check they work

5. `agent` now randomly selects claude|codex|gemini instead of typing `claude` to start a coding session

I guess in general auditing where the codebase is coupled and keeping it neutral makes it easier to stop depending solely on specific providers. Makes me realize they don't really have a moat, all this took less than an hour probably.

I guess then if you did not receive instruction from the Buddha himself you cannot call yourself a true buddhist.

It’s a feature not a bug!

Would be awesome to see something like this for agents/harnesses

Agree, i was going the vaultwarden route and figured this pattern seems better: https://fly.io/blog/tokenized-tokens/

Secrets are encrypted and the proxy decrypts on the fly if destination is whitelisted for that token.

the LLM can use types just like the human

The problem we have as software engineers (from an entrepreneur's pov) is that we mostly struggle with stuff that's removed from the client's problem.

I mean it in terms of owning the solution to a problem, being accountable/responsible for something working e2e not just the software or even the product - the service/experience of the customer that makes them want to give you money. Once you put on another hat - guess what - you'd probably be the star of some operations team or a great supervisor of some department. You would automate everything around you to a point others think you're the most capable person they've ever seen in that role.

I’ve been a year deep into my first job out of tech. There is a never ending slew of problems where being able to code, specially now with AI, means you have wizard-like powers to help your coworkers.

My codebase is full of one-offs that slowly but surely converge towards cohesive/well-defined/reusable capabilities based on ‘real’ needs.

I’m now starting to pitch consulting to a niche to see what sticks. If the dynamic from the office holds (as I help them, capabilities compound) then I’ll eventually find something to call ‘a product’.

Just wrapped up my own module for this. Remixed my worktree workflow with a lima wrapper. I wanted to go head first to giving Claude Code full autonomy but realized capability and prevention need to go hand in hand

Next step for me is creating a secrets proxy like credit card numbers are tokenized to remove risk of exfiltrating credentials.

Edit: It’s nice that Deno Sandbox already does this. Will check it out.

If they believe it would get them AGI they would risk it.

I agree with you in spirit but this harms the potential for these new products to emerge. You’re saying you don’t want them to be able to accrue a data moat. It sounds good for user privacy and optionality later on but it makes it harder for these services to get started as they dont see that model as possible.

If every other PC is more expensive, they will just increase prices.

I have a directory called workspace where there’s a projects directory and the main area is for messing around. Just setup workspace once as a project.

Spot on, this is a solid abstraction to build upon. I always felt MCP was a misstep in comparison to OpenAI’s focus on OpenAPI specs. HATEOAS is the principle that has become more useful as agents drive applications.

The AI of chemical engineering/material science?

I think it’s a mix of social media and risk aversion, this article touches on the broader discussion as it impacts many kinds of design

https://www.alexmurrell.co.uk/articles/the-age-of-average

I agree with you in spirit, but that’s not an answer you can apply when there’s someone else’s money at stake.

My take on “Hard on purpose” is that it’s plausible deniability. It’s not for showing off, it’s to make the situation polite in a way that you can’t rationally attribute malice.

Ive used CrewAI to compose agents, it’s easy to mix and match and it does seem to change context based on roles https://docs.crewai.com/en/guides/agents/crafting-effective-...

Why does Mr Beast dig wells in Africa?

This seems misguided. The human submitter is accountable for the code submitted. Doesn’t matter if the AI built it, a contractor in another timezone, or ten thousand monkeys typing away.

Github provides a profile but it’s not meant to make this kind of assessment. Basically a trust badge/metrics of some sort you could check before engaging with someone’s PR.

I don't think this is a fair comparison. It's easier to move and retrain nowadays; there's also more kinds of jobs. These things will probably become even easier with more automation.