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.

While I do find the new iOS a little more awkward to use than the previous version I haven't given up hope on the concept yet. It's a big change and I can see v2 making some big improvements. Whether it'll be worth it in the long run I'm not sure but I can't be too upset about them trying something new.

The vscode integration does feel far tighter now. The one killer feature that Cursor has over it is the ability to track changes across multiple edits. With Claude you have to either accept or reject the changes after every prompt. With Cursor you can accumulate changes until you're ready to accept. You can use git of course but it isn't anywhere near as ergonomic.

I found the instructions pretty confusing because you're not actually moving anything. You're combining the first selected row/column with the second selected row/column and replacing the second with the result of the combination.

When they transitioned to the app router it was like they'd given some bootcamp graduates a crack at "improving" on the express apis - which are mature and roughly align with the composable russion doll approach taken in servlets, rack, plug and any other server interface I've ever seen.

Aside from the abysmal middleware api you also have the dubious decision to replace having a request parameter with global functions like cookies() and headers().

Perhaps there is some underlying design constraint that I'm missing where all of these decisions make sense but it really does look like they threw out every hard fought lesson and decided to make every mistake again.

I've seem some game of thrones clips recently in youtube shorts which looked like they'd been generated by ai. I couldn't understand why anyone would have done that to the original good looking material. The only thing I could think was that it was some kind of copyright evasion.

You can be an architect without reading the code. My process involves building a detailed plan before starting, at which point I ask lots of questions about architecture. After implementation I have a custom agent for reviewing the architecture and I usually ask a few questions at this point as well.

This is a prompting issue. You're still responsible for constraining the behaviour of the system. For the validation example asking for tests that show validation passing and failing would have surfaced the issue.

The Spring framework was released in 2003 when Java was at v1.4. From memory it wasn't the first DI framework either.

You're right, it's the use of the Context that allows for the injection of the effects. It's also all handled at runtime which does unfortunately mean that the contexts supplying the effects can't be required at compile time.

As I understand it this was the inspiration for React's hooks model. The compiler won't give you the same assurances but in practice hooks do at least allow to inject effects into components.

It is incredibly slow though. I have a project with 40k lines of code which takes a minute to generate on an m1. It's a far cry from incremental compilation. It's enough that I generally avoid adding anything new that would require generation.

Once you can load up a full codebase into an LLM I'm hoping the cost to update client code is significantly reduced. Then you could focus on evolving the design without all the grunt work.

I'm using Toujeo which I believe is more consistent over 24 hours but I'm going to try your suggestion and see how it goes.

This sounds interesting, which basal insulin do you use?