evolve-maz

Python makes it very easy to do these experiments without changing cpython itself. For example, a lot of the cases for the "not set" Sentinel can be handled by making it MyClass | None. Treat None as "not set". If you need a "no-op" then you can give MyClass a field or something which implies it does nothing. And then override the bool dunder method to make it return false if the no op field is set to true. If you really want, you can have a classmethod which returns a "no op" instance of MyClass so people can easily call your func with MyClass.no_operation() when you want no op, and null when its not actually set.

Sentinels just help you wrap that up nicely and for more general use cases, but theres value in stepping back and thinking about where the unset vs no op case matters.

I agree with the article, but I'd also ask people to extend this thinking past just software they build.

If you're putting anything out there for consumption (software, articles, presentations, documentation) ensure your own voice is the dominant one in the output.

I look at it as a giant experiment. Any research tends to be very investment heavy, and people are given a lot more leeway to try things which are wildly unprofitable.

I'm glad they're doing this, because it lets me see an extreme of LLM development.

If anthropic is making as many PRs as stated in articles, then rolling back is unlikely an option. More likely it'd be a new commit to fix it, and with a feature flag to preserve the "wrong" behavior (even if wrong, since people will probably depend on that function since its original behaviour).

Those sorts of changes are really rough to manage. Maybe still manageable by LLMs but we'll find out.

I've always worried about the level of "IP laundering" which is done by LLMs.

While that's not technically the case here (given Mononoke's license) it is still quite negative in my view. We will have fewer people wanting to share ideas openly since LLMs are so good at not only finding them, but also not attributing them. This also leads to a loss in diverse collaboration, which is probably one of the biggest drivers for good software.

Right now there's probably a lot of these "novel" ideas floating around which models can present as their own, but that's raiding our coffers with no inbound future stream.

I agree architecture is important. But I think the best way to design a good architecture is to have a high level plan, and then feel it out by coding parts of it (usually near component edges / interfaces) in the actual domain with real use cases.

That exploration helped me see whether general "best practices" are applicable in this frame, and let me justify if not.

That was also prevailing opinion pre LLM:

> Only the hands on engineers can shape it since the design evolves in step with writing the code.

So I'm curious to know where people changed their minds.

It's interesting to see how over the span of just a few years a lot of people went from:

> Architecture astronauts are out of touch and shouldn't give any advice because they haven't written code in ages. Only the hands on engineers can shape it since the design evolves in step with writing the code.

To

> I focus on the architecture patterns and high level goals and let the LLM take care of the rest.

Similar commentary was shared about anyone not writing the code daily, not just the architects.

No gotchas, I just think it's something which calls for introspection.

Only in the last few years did I start using SQL properly. Before that my pipelines would live in python. Now I offload as much to the db as possible, and keep my python simple glue. I'm very happy with this compared to other methods in pandas or polars.

If I still need to do db-like things in python I think duckdb is better.

I've spent many years doing work in compliance for airlines. Hundreds of pages of documentation to describe the different rules and regulations which must be followed in specific scenarios. We'd convert those documents into a programmatic definition (rule engine) to alert when rules are at risk of not being followed.

This work was fraught with bugs, a large portion of which came down to disagreement of what was coded v/s what was written. Even if you had airlines sign off sentence by sentence exactly what you wrote down in English, that's too open to interpretation.

People don't appreciate how the same sentence can be read five different ways by different people (or the same person on different days). We had to structure our documents to be closer to pseudo-code than to English to get any meaningful consensus on the definition.

I use this pattern for my makefiles. First item is for "help", and it dynamically scrapes all the other commands (assuming format <command>: ## <description>). So if I do 'make help' it'll list all the commands in the makefile without much extra work from me.

.PHONY: help

help: ## Show this help message

@grep -E '^[a-zA-Z_-]+:.?## .$$' $(MAKEFILE_LIST) | awk 'BEGIN {FS = ":.*?## "}; {printf "\033[36m%-20s\033[0m %s\n", $$1, $$2}' @echo "" @echo "Examples:" @echo " make deploy" @echo " make deploy-branch BRANCH=feature-x" @echo " make deploy AUTO_START=true"

.PHONY: deploy

deploy: ## Deploy from current branch (default main) (use AUTO_START=true to restart service after)

@$(MAKE) _deploy BRANCH=$(git branch --show-current)

Yep, the poke pattern is additionally nice because it means my state reconciliation function is the same when running on cron interval vs event driven.

On the flip side, it helps to have endpoints which have a query param linking to some sort of resource update time stamp. That way you can query to only get those items changed since last poll.

Anthropic releasing things like Cowork explains why they wouldn't want you to host the model and retain your data.

They need that data so they can push into wider job automation, displacing the SaaS companies who used Anthropic in the first place.

Here's a common workflow:

- Ask cursor to summarize your existing repo to write you a nice readme

- Cursor opens repo

- Cursor looks at current code

- Because it's going above and beyond, it also wants to give you some metadata about the code (other branches for things in development, maybe previous tags as milestones, etc)

- To do that, it runs some git commands

Now the malicious behavior. I ask Cursor to evaluate some remote repo. It clones it down and then runs the git command from the working directory. However, if you just call "git ..." from the command line there is ambiguity about that. What if there's already a git file in the directory which windows thinks you want to execute?

This could happen with an untrusted repo. Or could happen from you switching branches to a compromised branch (which you wouldn't expect to immediately run some code).

Normal way to handle this is using fully qualified path names for things. E.g. instead of git ... you give the full path to system installed git. Annoying for humans to type but trivial for Cursor.

I've been a manager for some years. Without sounding too up myself, what made me good at management was the fact that I knew how to do the things I asked people to do. It allowed me to critically evaluate the work, set realistic timelines, and champion the contributions up the chain. I also maintained the ability to perform this work (by design and happenstance sometimes, since we could be understaffed due to sickness etc).

The good managers I saw also had this ability. The managers I didn't enjoy working with / saw struggle were ones who either never had that ability, or had lost it a long time ago.

Note I'm speaking about line management. There's a world of difference between managing a dozen or so individual contributors vs managing senior managers / directors. However, managing LLMs is analogous to line management.