His Blindsight is one of my all time favorite novels (sequel is good to). His short story Malak - about a military drone given a prototype ethical program - is so good.
Another suggestion for optimizing local inference - the Hermes team talks a lot on X about how much better results are when you use custom parsers tuned to the nuances of each model. Some models might like to use a trailing `,` in JSON output, some don't - so if your parser can handle the quirks of the specific model, then you get higher-performing functionality.
> Treat code design and architecture as the thing that lets your slop canons (90% of engineers even pre-ai) move fast without breaking things
I'm currently of the opinion that humans should be laser focused on the data model. If you've got the right data model, the code is simpler. If you've got the relevant logical objects and events in the database with the right expressivity, you have a lot of optionality for pivoting as the architecture evolves.
It's about that solid foundation - and of course lots of tests on the other side.
"Show me your code and conceal your data structures, and I shall continue to be mystified. Show me your data structures, and I won't usually need your code; it'll be obvious."
Lots of people try to make their code better by revising their procedures and don't even think about changing their data model, and generally fail. You might not be able to change your data model without changing your code, but they're different activities.
No, that part is just smart. Databases have terrible support for nontrivial datastructures, doing everything at the app level is the only reasonable response.
It's called "systems analysis". Programmers are generally pretty terrible at it because it requires holistic, big-picture thinking. But it used to take up the bulk of the design activity for a new enterprise system.
And the result was usually a complex system that no one needed and could maintain. Successful refinement is needed when you try to accomplish something from the ground up, refining it as you're adding features. Not locking yourself in the ivory tower drawing UML diagrams and drafting requirements. Doing and thinking go in pair, not separately.
Research conducted by M. Bryce and Associates suggested that use of a structured systems analysis phase before programming began resulted in time and cost savings vs. just "hacking it together" like programmers want to do. Locking yourself in the ivory tower is an unfair way to characterize systems analysis. Systems analysts talk to people in the business to understand what the business requirements actually are, and then design an information system (NOTE: not a computer system or software system; if it cannot in principle be run on pen and paper it is not an information system) that meets those needs. Programmers only come in when the automatable parts of the system need to be implemented, and work from a detailed and precise spec.
> Programmers only come in when the automatable parts of the system need to be implemented, and work from a detailed and precise spec.
A lot of systems are complex enough that you can’t get to that stage (and if you think you do, think again). Mostly because of communication issues and time concerns. Which is where the agile manifesto comes in and recommends the talk-do-show in short cycle. It needs not to be hacked together and the showing helps with communication, the talking guides the doing, and the doing is what pays for everything.
Yeah, the field of software engineering has come a long way since then. But just because previous implementations of the analysis phase were flawed doesn't mean that the phase itself was flawed.
A few years ago I read a claim that the word 'happy' is relatively young - ~500 years old - and that translations of others words into 'happy' are somewhat approximate.
My takeaway is that (presuming the argument is correct) that much of human striving is probably better described with specific words (as you suggested - joy, accomplishment, fulfillment, excitement, etc). For most of human history, most people probably didn't think "I want to be happy" but "I want to have a good partner", "I want a big family", "I want my crop to grow so I don't die."
I wonder how much unhappiness is caused by seeking a poorly-defined ideal of happiness.
The book was called "Power, Pleasure, and Profit: Insatiable Appetites from Machiavelli to Madison".
> My takeaway is that (presuming the argument is correct) that much of human striving is probably better described with specific words (as you suggested - joy, accomplishment, fulfillment, excitement, etc).
All those four words combined is something like the concept of eudaimonia that Aristotle describes in his Nicomachean Ethics:
I've not read Aristotle directly but translating eudaimonia was an example in the book that I mentioned. The argument was that eudaimonia is often translated as happiness but that doesn't make sense in contexts where we talk about a soldier dying experiencing eudaimonia (suggesting a loose translation).
No. It's certainly not a goal. And even if it can somehow happen, soneone could be resigned or drugged, it's different from something like "happy to die".
This question itself seems to be a perfect example of the point that the word is worse than meaningless. Worse because people use it like it has a useful meaning.
One can die in a state that has a lot of the qualities or features that overlap with other states that people call happy, but that doesn't make them equal or equivalent.
What emotion must people be feeling when they die then?
> the word is worse than meaningless
It seems as though you are redefining it to be meaningless, then projecting that onto everyone else. Is it not curious to you that everyone else takes no issue with its usage?
Dunno. Traveling to less developed places parents still want the kids to be happy for a start. It's surprising in places without roads, internet, phones etc. how normal everything is.
The word שמחה and conjugations appear in the Bible about 200 times, so we have a good idea of what it means in context. It means exactly what I perceive the noun Happiness and the adjective Happy to mean in English.
The German word for happy "glücklich" derives from the German word for luck "Glück". Could also be the other way round, idk.
Instead of saying "being lucky" we therefore say "having luck" instead. However, "glücklich" is commonly used in both contexts: "I bin glücklich" (I am happy) is very common as well as "Ein glücklicher Zufall" (A lucky coincidence). It's kind of implied by the language that a lucky coincidence makes you happy.
Makes sense to me that this might even be the origin of the term and the underlying emotion it described. Even hundreds of thousands years ago, people have been lucky from time to time which triggered an emotion: Happiness.
On a related note, this type of reasoning is what made me flip my opinion on microservices. I've generally been skeptical of a many-microservice architecture for the last decade but LLMs change that - a small microservice is more likely to fit in a context window.
I think this gestures at a more general point - we're still focusing on how to integrate LLMs into existing dev tooling paradigms. We squeeze LLMs into IDEs for human dev ergonomics but we should start thinking about LLM dev ergonomics - what idioms and design patterns make software development easiest for AIs?
Microservices are about deployment, less about code structure. You can have the same code modularization like microservices provide within a monolith instead, for example in the form of libraries. Conversely, you can in principle build several distinct microservices out of the same shared codebase.
They don't need to be services. You can - and many projects do - structure your code as a set of loosely coupled modules. Each module has a responsibility or set of responsibilities. They communicate with each other via well defined interfaces. For exposing code like this to an LLM, you would have them make a change to one or sometimes two modules, with access to the interface docs of all the other modules. The disadvantage of this compared to microservices is that if a module crashes it will take the entire process down with it, you can't move a module onto a different machine or create multiple instances of it as easily, etc. The advantage is that communication is done via function calls, which are simpler and more efficient than rpc.
> I think this gestures at a more general point - we're still focusing on how to integrate LLMs into existing dev tooling paradigms.
This is what we should be doing. This for a couple reasons. For one thing, humans don't have an entire codebase "in context" at a time. We should be recognizing that the limitations of an AI mirror the limitations of a person, and hence can have similar solutions. For another, the limitations of today's LLMs will not be the limitations of tomorrow's LLMs. Redesigning our code to suit today's limitations will only cause us trouble down the road.
Adding to your comment, I've found that frequent squashing of commits on the feature branch makes rebasing considerably easier - you only have to deal with conflicts on one commit.
And of course, making it easier to rebase makes it more likely I will do it frequently.
reply