kvisner

I agree, I think the era of trying to adapt your work, business, or life to work the way a project manager or app designer thinks is best for you needs to come to an end. Our tools should adapt to meet our needs, we should not need to adapt to fit our tools.

I would be very careful about basing your career decsions based on this trend. The data center build out will always be very boom and bust, which would really suck to work in. One year you would be making 300k working on dataceters and the next you would make 30k because thousands of electricians are now competing to build a few single family homes.

Considering it was made legal at the federal level, that is where the reforms will need to be. Also, having individual states try to regulate and online marketplace would be hell. You would always just be a VPN away from accessing it anyway.

How does it handle chron jobs or waking from a messaging app?

I'm curious how this will play out. So far having agents in a group chats with multiple people is hard. Either the agent creates a different "thread" internally for each user and everyone has a 1 on 1 convo with the agent in the same group chat, or it's just chaos.

Doing my part!

Yea, but those aren't subscriptions with fixed costs. I'm wary of running my dev flow against a pay-per-token endpoint, since costs can easily explode doing that.

A note on your website, when I hit the EN button in the top right, it presents a pop-up in German, which I can't read, so I can't change it to be in English.

Very cool, but if I'm prompting / looping an AI agent as my main development process, what is the use case here? I feel the biggest help would be to make Reviewing PRs from the terminal easier, I care less about commit logs and status.

I wish they had some kind of US hosted option, NDR policy, or something like that. I love the price and power, but I have concerns around data sovereignty and leaking IP to an overseas company.

I have been so ahead of the curve on this, I'm going to live forever!

I agree, but that formal language doesn't need to be executable code.

I see what Martin is saying here, but you could make that argument for moving up the abstraction layers at any point. Assembly to Python creates a lot of Intent & Cognitive debt by his definition, because you didn't think through how to manipulate the bits on the hardware, you just allowed the interpereter to do it.

My counter is that technical intent, in the way he is describing it, only exists because we needed to translate human intent into machine language. You can still think deeply about problems without needed to formulate them as domain driven abstractions in code. You could mind map it, or journal about it, or put post-it notes all over the wall. Creating object oriented abstractions isn't magic.

I've tried a bunch of these "memory" systems and they aren't there yet.

There is, currently, a tension between memory, and context pressure on the coding agent. There have been multiple studies now that tools like codex and claude code get worst at coding as their context window fills up.

As you start adding skills, memory systems, plugins and then a large code base on top of it, I've personally seen the agent start to flounder pretty quickly.

We need a way for agents to pull adhoc memory as they are going along, in the same way we do, rather than trying to front load all the context they might need.

I find a lot of these IDEs are simply not as useful as a CLI. When I'm running a full agentic workflow, I don't really need to see the contents of the files at all time, I'd actually say I often don't need to at all, because I can't really understand 10k lines of code per hour.

So most messaging apps rely on a phone number or centralized server to provide a means of making atleast the initial connection. In a purely P2P messaging system, how do I, as a user, find the other person I might want to talk to?

I can't say I needed yet another reason to hate the current state of LinkedIn, but I am not surprised in the slightest.

Two quick questions/thoughts:

1) Reading the changes, as a human, is not easy, having a document with a bunch editing marks in it, especially at the rate AI can make edits to things, would be very hard to keep track of, atleast that's how I feel.

2) Since you are tracking the context change forever, as a project developed over time, wouldn't the size of the context grow over time, with no upper bound. Would this cause memory pressure issues once we are talking about a huge codebase and a huge Changedown context?

This looks pretty cool, would love to try it.

One thing I'm trying to understand from the docs. I have 100s of playwright based BDD tests in my projects, especially the ones that are purely AI written. How does this interface with my existing tests? Does it scan the repo or is it meant to have it's own stand alone folder?

You could certainly build that today, mario tennis had ai controlled virtual tennis players 20+ years ago. You would simply need to put two of them opposite each other and you could create this. It's just not very compelling to watch two video game npcs do things.

Depends on how hard the question is.

Simple functions in small code bases, will probably work.

Once you get large code bases and more complex work, you'd have issues with the small LLM having the context it needs to actually solve the issue.

That doesn't seem terribly surprising, a human can quickly look through a grid of shirts to find one they like. ChatGPT would be guessing what they might want and the human would probably get a bad experience there with some regularity.

Maybe this is going over my head, but how do you reduce something like a computer vision system for a ROS2 robot down to a mathmatical proof?