Anthropic announced a new feature yesterday: ‘Skills’, a new method to add ‘abilities’ to their models. I think it’s a step toward something more reasonable than the Model Context Protocol. MCP can easily dump tens of thousands of tokens into your context—GitHub’s official MCP is famous for doing so. Combine that with the Lost in the Middle problem, and it’s easy to see why many have struggled to effectively integrate MCPs into their workflows. ...
One of the most immediately-beneficial principles of writing SOLID code is the Single Responsibility Principle. The official definition is “Any ’entity’ (i.e. a class, method, function, arguably module, etc.) should have only one reason to change.” One interpretation of this is that any ’entity’ should ‘depend’ on just one layer. If you’re writing logic in a PHP framework like Laravel, your controller should “officially” only interact with the HTTP layer: the request and its data. ...
Trying to debug a request being sent by Laravel’s Http facade? Check this out: the PendingRequest class has two methods you probably haven’t noticed before: dd() and dump() . These are incredibly useful when you’re quickly trying to debug a request issue—specifically, being able to avoid sending extraneous requests to 3rd-parties while you’re debugging: Http::baseUrl('https://service.com/api')->dd()->get('/profile'); The dd() method will dump the request without sending it. The dump() method will dump the request without stopping execution. This is especially useful when paired with something like Telescope, where you can see your dumps styled nicely in a separate tab.
Legacy codebases usually have one of two problems (usually both): they’re larger than they need to be, or they’re over-engineered. Features were built to meet requirements, but never actually used in production, an eager engineer created a ‘system’ of classes and services for a feature that’s used by a small percentage of users, a list of providers that had to be supported was actually much shorter than initially thought… you’ve heard this story before. These situations are unavoidable; they are inherent in the nature of software development. ...
I recently published a piece in Cognition on handling large, legacy projects—specifically updating them in a sane manner without a the often-desired (by engineers) “throw-it-out-and-start-over” approach. I wrote this while updating a large scale Laravel project that served ~250 organizations across the US. When I was handed the project as Technical Lead, it was running Laravel 4, and had been built/maintained by multiple teams over the previous 7 years. It also had essentially no test coverage for the critical business logic. ...