randysalami

I worked on something for far too long and even submitted to YC but the ultimate idea ended up a way to coordinate human teams (both on-shore and off-shore), human-AI teams, and while I didn’t know if it could ever be possible, strictly AI teams. I built the whole thing by hand in 2023 but even then I didn’t see AI agents being able to be first class members of a team, only being guided by humans. Think I ought to dust that work off and get some more feedback from people. Also try cleaning it up with AI.

Do you think this chain will lead to AGI?

Maybe with their unlimited tokens, they can devise a testing strategy around an emulator that exercises all these cases.

I only skimmed but that’s a feature, no? Fixing a bug unprompted is a regression. Identifying the bug, codifying it in a test, is a win. Then analyzing the bug, determining if any users rely on the bug, and fixing it can be a separate change.

I think maybe a similar thing in Albania. Lots of people deep-down wanting to emulate the same power structures that oppress them. Cycles of abuse. The ones who don’t leave.

I’m sorry to say this is not dead internet.

Wonder if something similar will happen in Albania. See Edi Rama go.

Great advice! Thanks!

Turning buggy software A into buggy software B, with all bells and whistles (and bugs included). This is useful for doing large-scale restructuring of codebases. You can verify you aren’t adding (or removing) bugs.

The latter is something I’m dealing with and it’s given me some existential angst. An example is a company’s monolith with millions LoC and hacked together. With proper engineering strategies, it could be closer to 100k. Without proper AI tooling, my verdict was let it be. When you have so many developers, PMs, stakeholders who tie their value to the pile of slop and making “engineering” decisions with it, it becomes very unpopular to suggest any refactoring - especially when that refactoring relies on principles that require an understanding of software engineering.

An example: the UI applications suffer from massive amounts of repetitive code. People on hacker news will probably instantly jump to some kind of componentization strategy. More wise individuals probably understand you need to draw a winning strategy before that’s possible. Identify common workflows, from that, identify common components, figure out a parameterization and so on. The footguns are the slop having unintended consequences which fixing might actually cause production bugs by being “features”.

Hypothetical now: a current alternative solution which may exist is two simple detail views (of which there may be 30+ in the application) are 1000+ LoC template files, hand-coded, copy-paste, with all the errors you could imagine. You can get a lot of work from that so people are/could be content just fixing slop with slop and calling it engineering while piling on more features. Maybe it works but it doesn’t allow for much engineering room.

With AI tooling, popular support becomes less necessary - correctness matters more. Instead of galvanizing people to realize this is wrong (and it’s not just a want thing, with offshoring and the general difficulty of software engineering, many people don’t understand these concepts. They are great people but struggle understanding for loops intuitively; I don’t know what to say). Now I can provide my strategy to the tooling and do the decomposition and componentization myself. On top of this, my strategy can be more intelligent and robust because I’m not doing it by hand like concurrently using the API layer as a source of truth to give my agents more context on what the UI was trying to do. The code itself is confused so part of the work is learning the intent behind each module and also capturing bugs that are “features” to prevent regressions. Basically, a clean room rewrite (but we have access to the source code so I know that’s not the exact correct term).

The engineering moat is still there. If I say, “Claude make my UI codebase smaller” it will burn tokens and fail. One day it will succeed but right now it will fail. Likewise if I say “Claude suggest ways to make my codebase smaller”, it may suggest my strategy but it may not capture all the critical wrinkles. LLMs are not good at simplifying so to simplify (which is always a good goal in software engineering as long as the abstractions still hold), requires human strategies when complexity is high enough. Especially in my case where the behavior of the code is almost more emergent rather than engineered.

Then carrying on, hypothetically, I started to devise a system for not only rewriting the UI but the rest of the application (API and DB layer) as well as the corporate processes around the application. This may sound rude but these corporate processes can be disempowering and wasteful. The trick is inversion. First build a conceptual interface around the layer. The model will understand the purpose without understanding or rewriting the internals. This saves context and allows it to do more powerful reasoning by having perspective instead of being in a vacuum. Then when you have bandwidth, use that interface along with all the context you developed working on other modules, to take control. An example, you have a team which is responsible for building and deploying. To build and deploy, you may need to fill out forms, contact layers of people, all to achieve the end of goal of “building and deploying”. Through inversion, you communicate with an agent endpoint that handles communications to that team. Escalating, writing forms, and doing whatever is needed to get the code built and deployed. For all intents and purposes, you are now in control of that process. What used to be, for example, “I want my code built and deployed to QA” -> “message A” -> “message B” -> “write form A” -> “monitor for responses” -> “build triggered” can now be “I want my code built and deployed” -> “activate agent process” -> “build triggered”. This is an application of inversion in a nutshell. AI allows to apply engineering principles not only to our code but corporate processes where applicable.

So in this case, there could be 100+ individuals supporting this application and process. The one or two or three engineers that used to own the development process (more or less) were drowned out yet still responsible for the overall process and integrity of the software. It was an impossible task but now it seems more possible. The existential angst part comes from the all processes that were sprung up to support a reality where this all wasn’t possible.

Last, I definitely do not think the solution is one hundred engineers. If you know the show “Breaking Bad”, I actually find the reality of software engineering to be more like this now. The difference between 60, 90, 95, and even 98 percent purity is staggering. And the chemist who takes the input (money and tokens) and produces the highest quality output (codebase and processes), dominates. Just as in Breaking Bad when Walter White inherently has power, despite all other chemists and structures of authority, because his process had the highest purity output. It’s just business sense and adding more chemists does not increase purity. Output quantity is no longer gated by number of bodies so that argument goes out the window. Mentorship will be key (as in Breaking Bad) and large teams of all-high-quality producers should be put together into super high-thoroughput teams. But for regular operations, prioritize the highest quality output where the input is guided by the highest quality producer because adding more cooks will seriously degrade the output, at an exponential rate.

This article mainly argues around harnesses but a breakthrough for me was understanding why harnesses. Without a harness and only a raw LLM, exploring and modifying codebases is not feasible. It’s just text in, text out, and has no way of handling the context of the codebase (if large enough). Plug an LLM into a harness, and all of the sudden it has an exosuit that lets it funnel its thinking into discrete actions. It can now use strategies to manage that large context in pieces.

Normal person as in position in economic distribution, not normal as in not quirky or strange. Lots of quirky people all across the spectrum.

But to be clear, in my example products aren’t the only thing to which the economy doesn’t cater to normal people for (lower-middle class but increasingly middle and lower class). War, corruption, and genocide are all bad for the average person. Generally things that funnel money into hurting or enriching individuals. Both of these are inefficient and the inefficient use of resources, is hurtful to normal people. E.g. enriching an oligarch to build roads could be twice as much road if he takes a 50 percent cut. And the money sitting with him does harm, oppresses people. Food for thought.

You answered your own question in your very second sentence. “For a normal person”. The modern economy increasingly does not cater to the “normal person” and they prove this constantly. Granted “normal people” stopped existing a long time ago. You have poor people, soon to be poor people, and people who think they will soon be rich but will really soon be poor. Of course then you have the rest but they are not people.

I’d argue that a complex economy in a failing society is actually a sign of weakness. Lots of nobles and the likes wanting their cut of a pie that doesn’t really exist anymore. So all of that complexity is not really backed up by the reality and you just have a bubble. I can imagine all kinds of roles and professions that just exist to endow people. This also happens a lot in modern society.

I know this wasn’t actually your point but I just wanted to add.

I’m sure an EM can extrapolate the role of lead clerk at the grocery store. The EM probably goes to the grocery store and has interacted with the grocery store workers.