I've built a lot with LLM's, my experience sort of but not really tracks that. I've had to course correct a few bad abstractions but the larger the code base becomes the better it seems to be at reusing things. Maybe this is because of types, or spec-first development (with OpenAPI), or black box integration testing - but also maybe not. But generally I have to think about the abstractions and let the LLM fill in the details with rare exception.
I think the trick here is plural; I guarantee no single human knows all 1 million lines. Note this is different than knowing how to orient yourself in a million line codebase quickly.
The limit here I think the ancestor comments are getting at is cognitive load, which is real and measured. We only have so much memory to devote to a "stack" when executing, and it's usually quite constrained.
This is an interesting idea. I'm building https://tend2thrive.com - I could see an interesting collaboration here. Always looking for ways to re-engage your network without it feeling heavy.
Things like this have existed for awhile. The challenge is always rolling it out to peers. It's confusing to them, and kills their velocity. Just like functional programming paradigms themselves - objectively better, but also objectively more difficult to hire for.
Yeah, echoing the comments here. It's a good idea - kind of - but it is all about digging deeper when it is sus.
The tool assumes so much. That it is fine to kill a process itself versus just asking you to kill the process. That everyone MUST have passwords in their home directory. It's all meaningless without providing the thing it is running and so no activity is technically safe.
Why do people even get the agent to run the commands it asks to run? You can solve the entire threat vector by running it yourself and giving the agent the output. Claude practically only needs things like sed, awk, and grep. It's a pattern matcher. It's a waste of yours (and its) time to have it run your project.
yeah, I think there's the marketing and then there's the actual true utility. AI isn't a better computer program. It's not going to be able to do everything you want autonomously. But, it's pretty good at some stuff!
Fair. I have high hope for local inference, feel like right now it is simply cost prohibitive to get the hardware. It will be interesting to see what happens.
IMO It's a different and new model. We're engineers, and we're rich. It's not going to be good enough for us. But the much larger market by far is all the people who used to HAVE to work with engineers. They now have optionality; the pendulum is going to swing.
I'm curious - why for now? This stuff is practically commoditized. Trying to think of anything that ever successfully got back into proprietary land from there.
As an engineer, I want to believe this, but really - does it?
Most folks use frameworks because it's easier than learning how to build it all yourself - things are done for you instead. This niche is now getting eroded by AI and low-code substantially.
Couple that with my experience maintaining frontends that are far too complex for their use cases - e.g. do we really need SPA's, state sync, and reusable components for our admin tool that doesn't reuse components?
This leads me to think there's been bloat here for at least a decade. So, while vibe coding will also lead to bloat, it's easier to work with, and arguably higher value than paying for a specific framework.
It's a tragedy in life that things that are useful don't always get valued, instead being used as a stepping stone for progress, but I'm not sure that has a solution.
I've been exploring decentralized trust algorithms lately, and so reading this was nice. I've a similar intuition - for every advance in scraping detection, scrapers will learn too, and so it's an ongoing war of mutations, but no real victor.
The internet has seen success with social media content moderation and so it seems natural enough that an application could exist for web traffic itself. Hosts being able to "downvote" malicious traffic, and some sort of decay mechanism given IP's recycling. This exists in a basic sense with known TOR exit nodes and known AWS, GCP IP's, etc.
That said, we probably don't have the right building blocks yet, IP's are too ephemeral, yet anything more identity-bound is a little too authoritarian IMO. Further, querying something for every request is probably too heavy.
- Like you mentioned, it helps me learn more about a topic/explore it more deeply, I usually begin with an intuition and then explore outwards.
- Folks positively mention my articles - both current connections and new connections.
- They sometimes spark interesting discussion which helps refine my knowledge further.
> What kinds of posts actually worked (for learning, career, network, opportunities)?
- Hard to say, I don't have a high signal here. Usually just having some content for people to skim was enough, but folks would tend to mention nearly random articles depending on their interests.
> Any practical format that lowers the bar (length, cadence, themes)?
- I'm not a great blogger in that I have no established cadence. I didn't want pressure to deliver crap (biweekly), nor did I want necessarily to put posts on too high of a pedestal (monthly+).
> If you were starting today, what would you do differently?
- Highly recommend going with simple tech. A static site based on Markdown does wonders. Offload discussion threads to sites like HN or reddit - the comment section of your links.
Cooperatives do not get rid of the net negative cycle. Ultimately whatever the benevolent entity ends up being, it becomes a contest of who can bear to lose more money.
Cooperatives distribute the losses but it is still a money pit.
Good question, was on my mind too. The problem I could see is Walmart style - the predator will beat the prices of the non-predator down until the non-predator goes out of business, then raise their prices again.
They can do this because they are operating in other areas with predatory prices, giving them the ability to operate at a loss, and relying on the fact that at least some of those areas are not being challenged by non-predators.
Everybody seems to be playing the game right in this scenario. Interesting to try to come up with a good counter.
Builders once disrupted the tech world, but now they’re the gatekeepers. As their success made them risk-averse, they see any change as a threat.
Today, they’re bullies - ripe for disruption.
This is nothing new - we’ve watched this same story play out across many industries in our lifetime, as well as by empires rising and falling throughout our history.
These days, the empires may be smaller - e.g. products, teams, startups - but the pattern is still the same. If every move needs a meeting and every idea a committee, you’re not short on talent, you’re just tangled in control.
Here's three ways I've found to break out of this:
Cycle Leadership: To avoid entrenched thinking, cycle leadership between projects. This demonstrates both upward mobility as well as the idea that growth is continuous, and nobody is ever done.
Institutionalize Experimentation: Embrace the “how might we” mentality to continuously experiment and iterate. Form hypotheses and find the lowest cost way to validate them.
Subordinate to Metrics: Rather than following people, follow metrics - the measures that prove you’re moving in the right direction. This shifts teams from control towards collaboration, based on a set of values shared by both the market and the team.
As they say, in life the only constant is change. How is your organization tackling it? Are your teams builders, or bullies? I'd love to hear about your challenges and solutions.
I've built a lot with LLM's, my experience sort of but not really tracks that. I've had to course correct a few bad abstractions but the larger the code base becomes the better it seems to be at reusing things. Maybe this is because of types, or spec-first development (with OpenAPI), or black box integration testing - but also maybe not. But generally I have to think about the abstractions and let the LLM fill in the details with rare exception.