ollysb

How could you enforce this?

What you're describing sounds like code hygiene and refactoring not features.

This is my confusion, we already have commits to bundle changes, why not simply allow commits to be reviewed independently within a pr?

Creating derivative products you charge for surely can't be considered fair use?

Different tools for different cases. Debuggers are great for a snapshot in time but print statements are better for seeing the execution flow.

If shows the direction your fingers would point on the guitar neck but it's not like there's much confusion around this point.

Each genre has a fairly tight envelope within which to operate. Regardless 90% of tracks never make it to the finish line because hobbyists haven't learnt them well enough to groove them out. If with a little help these tracks were all finished then bedroom producers will over time learn what works and be able to explore more.

While I can get behind the sentiment I hope bad writing doesn't become the standard for anti AI. A simple grammar check would have greatly improved this post.

If it was fast I'd ask questions more than read the code in detail. This isn't viable for that approach yet though.

Good code has always been written with a reader in mind. The compiler understanding it was assumed. The real audience was other engineers. We optimized for readability because it made change easier and delivered business value faster.

That audience is changing. Increasingly, the primary reader is an agent, not a human. Good code now means code that lets agents make changes quickly and safely to create value.

Humans and agents have very different constraints. Humans have limited working memory and rely on abstraction to compress complexity. Agents are comfortable with hundreds of thousands of tokens and can brute-force pattern recognition and generation where humans cannot.

We are still at the start of this shift. Our languages and tools were designed for humans. The next phase is optimizing them for agents, and it likely will not be humans doing that optimization. LLMs themselves will design tools, representations, and workflows that suit agent cognition rather than human intuition.

Just as high-level languages bent machine code toward human needs, LLMs let us specify intent at a much higher level. From there, agents can shape the underlying systems to better serve their own strengths.

For now, engineers are still needed to provide rigor and clearly specify intent. As feedback loops shorten, we will see more imperfect systems refined through use rather than upfront design. The iteration looks less like careful planning and more like saying “I expected you to do ABC, not XYZ,” then correcting from there.

Given how precious the main context is would it not make sense to have the skill index and skill runner occur in a subagent? e.g. "run this query against the dev db" the skills index subagent finds the db skill, runs the query then returns the result to the main context.

I used Charles for many years but proxyman's performance is a real step up.

The big limitation is that you have to approve/disapprove at every step. With Cursor you can iterate on changes and it updates the diffs until you approve the whole batch.

It's fine to have dependencies, the point is two services that need to be deployed at the same time are not independent microservices.

Free at the point of use is how it's usually expressed.