normalocity

Love the idea at the end of the article about trying to see if this style of prompt injection could be used to get the bots to submit better quality, and actually useful PRs.

If that could be done, open source maintainers might be able to effectively get free labor to continue to support open source while members of the community pay for the tokens to get that work done.

Would be interested to see if such an experiment could work. If so, it turns from being prompt injection to just being better instructions for contributors, human or AI.

The voice of reason who has seen some things.

Fair points. I guess I was asking if this is a new, or fundamentally different problem from pre-AI. I could be over-simplifying -- what do you think?

This makes me think of risk assessment in general. There's a tradeoff between risk and reward. More risk might mean more _potential_, but it's more potential for both benefit and ruin.

Do you think we'll figure out a good balance?

... software can, in a very real sense, become self-improving.

This is referring to the software the agent is working on, not the agent.

This creates a continuous feedback loop.

This is referring to the feedback loop of the agent effectively compressing learnings from a previous chat session into documentation it can use to more effectively bootstrap future sessions, or sub-agents. This isn't about altering the agent, but instead about creating a feedback loop between the agent and the software it's working on to improve the ability for the agent to take on the next task, or delegate a sub-task to a sub-agent.

"... the type of self-improvement we’re talking about is far more pragmatic and much less dangerous."

This is a statement about the agent playing a part in maintaining not just the code, but other artifacts around the code. Not about the agent self-improving, nor the agent altering itself.

... which I imagine would be important for a military control AI

I think this is a common, but incorrect assumption. What military commanders want (and what CEOs want, and what users want), is control and assistance. They don't want a system that can't be turned off if it means losing control.

It's a mistake to assume that people want an immortal force. I haven't met anyone who wants that (okay, that's decidedly anecdotal), and I haven't seen anyone online say, "We want an all-powerful, immortal system that we cannot control." Who are the people asking for this?

... it will do whatever it can to prevent it being turned off.

This statement pre-supposes that there's an existing sense of self-will or self-preservation in the systems. Beyond LLMs creating scary-looking text, I don't see evidence that current systems have any sense of will or a survival instinct.

Agree, this is the point the article makes. I don't think the article claims that it's the agent that is directly improved or altered, but that through the process of the agent self-maintaining its environment, then using that improvement to bootstrap its future self or sub-agents, that the agent _performance_ is holistically better.

... if the docs act like a summary of current state, you can just read it at the start and update it at the end of a session

Yeah, exactly. The documentation is effectively a compressed version of the code, saving agent context for a good cross-section of (a) the big picture, and (b) the details needed to implement a given change to the system.

Think we're all on the same page here, but maybe framing it differently.

Where is the claim, in the article itself, about improving the agent?

For sure this is a real example, but it's also largely a permissions issue where users are combining self-modifying capability with unlimited, effectively full admin access.

Outside of AI, the combination of "a given actor can make their own decisions, and they have unlimited permissions/access -- what could possibly go wrong?" very predictable bad things happen.

Whether the actor in this case is a bot of a human, the permissions are the problem, not the actor, IMO.

Interesting idea. While waiting for my verdict I was asked the same question (and provided the same answer) over and over. Was expecting a bunch of different questions, rather than the same questions, repeated.

it does seem very similar. the instantiation syntax and the way you handle things is very, very similar for sure.

huh, maybe. I didn't know about this or find it when I was looking around. thanks, I'll check this out.

Most of my code is in Ruby, but I've been watching languages like Go, Elixir, and ideas around the Actor model for years, trying to take the best ideas from these and applying them in my own system.

Inspired by all of these examples, but desiring a dead-simple solution for the Ruby applications I maintain - I created nobject.

It's not quite RPC. It's not quite the Actor model. It's not quite lightweight processes/channels. It's the ability to instantiate an object in one process but then push it to another process, yet be able to use that remote object like it's still local.

The example code in the repo's README will get you up-an-running in minutes.

Not sure why AI agents wouldn't also be connected to an ad platform eventually. Google does this currently.

While the author says that they are bypassing Google, that's not most people, and Google's results are front-loaded with AI answers, so Google results are already giving you specific answers, hallucinations and all. Not sure why average users would long-term switch to not-Google if Google can give them the amount of AI assistance that want or don't want.

What an incredibly pointless and long ad disguised as a blog post.

Many of the core challenges that are fundamentally about human factors and collaboration haven't changed, such as the conflict between business requirements, engineering approaches, and the desire for no-code solutions.

Ex.: People were writing about agile, no-code, and the challenges of reducing cost and complexity before we had the terminology for it and before a whole industry of consultants existed to explain it.

Application Development Without Programmers https://a.co/d/2kKeOTx

It depends on whether you want to play the game or break it. :D

Most people are taking this as a fun algorithmic exercise, assuming imperfect knowledge.

Tom's writeup inspired me to dig a little more. I unfortunately (for me) discovered a very simple way to solve the game on the first guess every time. My fault for reading the game's code, but I just can't look at the puzzle the same way anymore.

I liked the first half of the essay - some interesting nuggets of some possible ideas, particularly the point about schisms forming rather than continued collective action once a group becomes large enough.

The last half sounds a little bit too much like the bias towards markets and profit motives and whatnot without question and without critique. There are plenty of dysfunctional for-profit orgs that don't allocate resources well, in spite of overwhelming feedback, from the market and elsewhere. The majority of for-profit orgs also have a sales team that is out there pounding the pavement trying to drive sales: it's not all, "Build it and they will come."

I don't buy that a successful company needs to be a mission either. That's very common thinking in the startup world, but not even close to representative of the whole.

I do prefer PostgreSQL if I have a choice, but from the practicality standpoint that many people are hitting on, I'm okay with various design decisions (i.e. take a look at some of the flags for MySQL's `sql-mode` option over the years) being phased out via the normal (warn -> deprecate -> throw error -> remove) lifecycle that things like this often go through in software. Once a technology gets wide adoption, no matter how "flawed" or not earlier versions were, you start to prioritize stability and reliability over "correctness" at some point. This leads to the understandably practical approach to many bugs in many enterprise systems where the team supporting a tech stack learns to work around the rough edges, and might even depend on certain "weird" functionality because it's simply more practical in both the short and long term than not doing it.

None of the above means that I don't see MySQL as flawed in some ways. I'm in a group of developers that I suspect make up a sizable portion of the MySQL community who didn't choose MySQL, but must support it, if for no other reason than because we see ourselves as professionals, and that's what professional do: make the employer's application work reliably.

For applications that have already survived past the point of finding product/market fit, a wholesale conversion of DBMS is rarely worth it, and conversions of this type are costly/risky even if it is worth it. I do understand many of the benefits (real and theoretical) of PostgreSQL, and if I'm around at the moment when a project's DBMS is being selected I'm going to recommend _not_ MySQL, but at some level I'm also paid to make the application that my employer is running on top of their DBMS work reliably ... and the fact is even among people who get PostgreSQL - who prefer it, would choose it if they could - many of us are also pragmatic enough not to pull the rug out from under a running application for "reasons".

It can function like this, yes. There's a flag for the `sql_mode` that enables/disables this functionality, and I believe zero dates are disallowed by default in MySQL 8.0+ IIRC.

The main points made by the article are not unique to any particular job or industry. The method, if one is to get more freedom of choice in work, is to get yourself onto important projects that contribute to the bottom line.

For a broader view, years ago I read the book, "Power: Why Some People Have It—and Others Don't" by Jeffery Pfeffer, and it was an excellent object lesson in understanding how and why companies work the way they work, how decisions are made, and why you can do the same job in different organizations and yet have a totally different experience one organization to the next.

The ship has long since sailed on this point, powered on or not.

There's research that's talked about in the book, "Data and Goliath" that explains how the behavior of people specifically trying to avoid being tracked is sufficiently different from most other people that, even if you turn off your phone (sometimes ESPECIALLY if you turn off your phone) that act can be a behavioral marker used to correlate your activities with other people who do similarly, and your location can be largely deduced by process of elimination anyway.

It's a fascinating read.

I bought a movie on Amazon Prime just yesterday for $14 and it didn't make me as happy as this comment section.

Preach!

I haven't been this entertained for the mere price of $12 in a very long time. I think it's worth the price of admission even if I never even try to upload an image.

I see humor in the entire project, and am okay with this. Given Stavros' clear intent to be funny and make it abundantly clear what _isn't_ being promised, it's pretty great.

I mean c'mon - have a little fun.

At any rate it's classic absurdist marketing, and I approve.

Besides, I don't read the TOS of most other services. Why would I start now?

I got so much joy out of the FAQ I nearly paid just as a thank you for putting a smile on my face.

This seems like a great way to get fools to trade something valuable (the electricity they pay for to run arbitrary computation) for something worthless (a new crypto currency).

If you think of electricity as fuel for computers, similar to fuel for a semi, then this scheme seems analogous to an attempt to get truck drivers to drive your stuff to it's destination at their upfront cost in exchange for an IOU that has no backing.

Think about adding up some numbers in a tabular structure. That's straightforward with most programming languages. But what if that same table is in a web page, or a mobile app, or a PDF? It's right there on the screen, it's probably encoded as a table in the markup. So the data is there. And yet, we can't query it.

I mean, it sounds like you're describing command line tools that fetch the data you want, wherever it might exist (in a table, in an image, on the web, across a network link, whatever) and pipes the data you're interested in on the command line so you can use a whole ecosystem of filtering/transforming/combining/querying whatever — even your own code.

Currently, "doing programming" is a segregated activity from mainstream computing - separate software, command lines, specialist knowledge, clunky text-driven interfaces.

What's clunky about a text-based interface like a command line, or code written to process simple data in text form or in files or in a database? It seems like you have a /integration/ and /ingestion/ problem, not a programming or app design problem. The issue is that, wherever the data lives, you simply need to get it out and transformed into a format that makes it easy to process it with the amazing and existing tools that have existed for decades.

The reason that apps, websites, etc. exist are either because those interfaces aren't built for programmers to consume (i.e. it's for non-technical users, or business people, or some other purpose), or out of ignorance of the power of the command line, or because of personal preferences of the person who designed it.

How do you build ubiquitous programmability into interfaces without adding clutter or reducing usability?

You don't. You build integrations and ingestion pipelines to move data from wherever it may currently live into a place that is easy for your system to process.

The reason you can't get ubiquitous programmability is because different users/consumers need different things from interfaces, and that's just a simple fact of life. The closest (and one of the most powerful) thing we have that's pretty close to ubiquitous across so many different types of users are spreadsheets. But these come with tradeoffs as well — first of all if you just need the information and don't want all the surrounding capability then a spreadsheet is overkill. If you need rigid validation, and hugely powerful query capabilities then it needs to be in a database.

The realization that the software experience is still built on artifacts of computing from the 80s like text-based command lines is a lot less surprising considered within the context of this ongoing decline.

Software is built on these text-based command lines because they work. They're not clunky once you get to learn them — they're pretty much the best thing anyone's ever done. They're still around because no one has improved on them to a degree so significant as to replace them.

It sounds like this article is proposing a new way to do things, will which just end up being yet another walled garden. It's absolutely preposterous to think you're going to reinvent 60+ years of advancements in computing when the things that have been working, evolving, and still constantly improving for at least the last 20 years of those 60 years work incredibly well already.

Climate change has shown us that mere awareness of the situation we are in isn't enough. Actual liberation from disaster requires a bold change of direction and a acknowledgement of shared, public goals beyond the financial.

Climate change taught us this? Wow. Learn your history. There's /always/ a mix of short-term and long-term research going on, there always will be, and while the mix might change a bit no one part of it has even been completely dried up. Some people and organizations have short-term goals. Some have long-term goals, and lots of orgs fall somewhere in between. Innovation only looks like a really inefficient search and cobbled-together mess when looking at it in hind sight, where you can look backwards and see, "If only the people 20 years ago would have done X, Y, and Z and not wasted time on A, B, and C we would have been in the present 20 years earlier" —- but the major problem with this kind of thinking is that this is only obvious in hind sight, and nobody has the benefit of predicting the future from the present. Is there waste? Sure. But the idea that old stuff is clunky, or terrible, or poorly designed just because you're judging it from modern standards and a place where you have access to more information than people in the past is just silly. You're just going to wind up creating yet another attempt at "solving" computing once and for all. This kind of silver-bullet thinking is naive at best. No one has invented a silver bullet because there either isn't one, or so much collectively learning needs to happen /before/ it can be found that we just need to keep doing the sometimes boring work of trying things and seeing what works. It doesn't feel glorious in the present, but that's what it takes.

The problem with judging the past is that there's always waste, you never know which part is the waste and which part is going to lead you to a good solution. The searching (researching) is what gets you there, and it's hard work.

Rare-but-notable efforts like Xerox PARC suffered similar fates, able to fend off the bean-counters for a while but not indefinitely.

This is romanticism, and "good old days" kind of thinking. The past is worse in almost every single way, and to put Xerox PARC up so as to imply that modern research orgs aren't probably better in almost every way is a bit foolish. Is modern research flawed? Sure, but so it was in the past as well.

Pay-as-you-go compute pricing means this is $$$, which I'm guessing is the tradeoff. But hey, classic time/money tradeoff for some level of automated (non-customized) performance -- should be good for a bunch of common use cases that would otherwise require hiring a human, like many generic technologies.