zingar

Experience doesn’t leave me with any confidence that the long term memory will be useful for long. Our agentic code bases are a few months old, wait a few years for those comments to get out of date and then see how much it helps.

Actually good naming does plenty to explain the why. And because it’s part of the code it might actually be updated when it stops being true.

I wrote this an hour ago and it seems that Claude might not understand it as frustration:

> change the code!!!! The previous comment was NOT ABOUT THE DESCRIPTION!!!!!!! Add to the {implementation}!!!!! This IS controlled BY CODE. *YOU* _MUST_ CHANGE THE CODE!!!!!!!!!!!

That definition moves the goalposts almost by definition, people only stopped thinking that chess demonstrated intelligence when computers started doing it.

Something something powers go to definition… is this an implementation of an LSP server? Or a subset of what’s needed to implement LSP? A formerly proprietary alternative to LSP?

Love the concept that I can glean from the opening paragraph. Very interested. Not going to upgrade to a Medium premium plan to read it.

Unfortunately using Medium seems to be a choice to compete with every other Medium article that month for the limited number of free articles that can be read without paywall.

Misleading title, the article has zero content on outages. This is purely positive content about what they are doing with AI-powered bug detection.

What is the appeal of swift for this project? Is it just what you know?

Would you mind elaborating on the superiority you perceive?

One of the possible outcomes of this journey is that “LLMs can never do X”. Another is that X is easier than we thought.

Turning a hard problem into a series of problems we know how to solve is a huge part of problem solving and absolutely does result in novel research findings all the time.

Standard problem*5 + standard solutions + standard techniques for decomposing hard problems = new hard problem solved

There is so much left in the world that hasn’t had anyone apply this approach purely because no research programme has decides that it’s worth their attention.

If you want to shift the bar for “original” beyond problems that can be abstracted into other problems then you’re expecting AI to do more than human researchers do.

No that’s not it. Opencode is a pure terminal app, your interaction is by typing prompts and slash commands. You can also script prompts to it.

There are probably IDE plugins that feed prompts or context in based on your interaction with the editor.

My question was based on seeing courts springing up all over London recently.

Can anyone explain to me why this sport is so popular that it’s taking over prime locations in expensive cities?

Geez there should be a big warning on the tin about this. They’re so neatly integrated with copilot that I assumed (and told others) that they had all the privacy guarantees of copilot :(

This is exactly me considering what I might have leaked to god knows who via grok. I was hyped by opencode but now I’m thinking of alternatives. A huge red flag… at best irresponsible?

You can access anthropic models with subscription pricing via a copilot license.

Aren’t those in-editor tools? Opencode is a CLI

Anecdotal pros and one annoyance:

- GH copilot API is a first class citizen with access to multiple providers’ models at a very good price with a pro plan - no terminal flicker - it seems really good with subagents - I can’t see any terminal history inside my emacs vterm :(

Maybe. It might also have nothing to do with ill-conceived attempts at evaluation. I sometimes suggest teams work in steps that small (usually because they don't have the experience to handle something bigger) and it has nothing to do with evaluating the team. It has everything to do with them learning to move precisely and avoid mistakes.

I have so many thoughts:

Depending on the reality, either that company doesn't understand agile very well, or you didn't understand the importance of the small steps.

A plan is not made agile by being split into many small sequential steps; what would make this agile is learning from each step and being prepared to scrap steps 2-8 if step 1 turns out to be enough. Usually this attitude results in splits that make more sense and do add user value.

OTOH I've seen many experienced folks get tripped up because it's easy to get consumed and not evaluate work vs the customer value when you're in the middle of a big task.

For example on an internationalisation project a dev thought: "Every translation key is handled the same way in Rails, let me just do them all at once"; spent weeks with the appearance of no progress because they were working through many cases often slightly more complicated than imagined. They said out loud ~ "I'm not working just for the sake of a task board, the work needs to be done, let's be better than box ticking, it's all one logically consistent piece of work".

I had to interrupt to point out that most of the pages were either about to be deleted or were only needed later. Meanwhile we had tons of work that needed this person's attention on things that were of immediate importance.

It's also important to work in a way that a high number of PRs is not a penalty. It's a smell if we're motivated to reduce the number of PRs because shipping PRs feels difficult.

Great point! We’ve been shifting quality left in human teams for decades now, and there’s still territory there that few (no?) teams have explored. AI is probably where that unexplored terrain becomes worthwhile to explore.

This is a profound point but is review really the problem or is it the handoff that crosses boundaries (me to others, our team to other team, our org to outside our org)?

Interesting point about not moving out of the medium. I don’t think this is terribly important but you could say that the airplane completely moves from the medium of wheels on the ground into the less dense medium of air.

Ha ha, we were taught to keep our optimist bathtubs halfway out of the water when sailing downwind back then. I mostly joke but no one called that flying :).

It’s possible to manage the quarterly expectations by saying “we can improve metric X by 10% in a quarter”. It’s often possible to find an improvement that you’re very confident of making very quickly. Depending on how backwards the company is you may need to hide the fact that the 10% improvement required a one line change after a month of experimentation, or they’ll fight you on the experimentation time and expect that one line to take 5 minutes, after which you should write lots more code that adds no value.

Agile isn’t a good match for a business that can only think in terms of effort and not learning+value. That doesn’t make agile the problem.

Comparing the same work done between agile and waterfall I can accept your experience of what sounds like an org with unusually effective long term planning.

However the value of agile is in the learning you do along the way that helps you see that the value is only in 10% of the work. So you’re not comparing 100% across two methodologies, you’re comparing 100% effort vs 10% effort (or maybe 20% because nobody is perfect).

Most of the time when I see unhappiness at the agile result it’s because the assessment is done on how well the plan was delivered, as opposed to how much value was created.

Reviews are vital for 80% of the programmers I work with but I happily trust the other 20% to manage risk, know when merging is safe without review, and know how to identify and fix problems quickly. With or without pairing. The flip side is that if the programmer and the reviewer are both in the 80% then the review doesn’t decrease the risk (it may even increase it).

I love me some hulls out of the water but I have a quibble with the term “flying” when there’s still something in the water and taking everything out of the water is dangerous, even of it is only a tiny fraction of the boat… have hydrofoils always been spoken of as flying or is that more recent hype?

Prescient!