So long as this is all true, then the code needs to be human readable, even if it's not human-written.

Maybe we'll get to the point that LLMS really are equivalent to compilers in terms of reliability -- but at that point, why would be have them write in Java or other human-readable languages? LLMs would _be_ a compiler at that point, with a natural-language UI, outputing some kind of machine code. Until then, we do need readable code.

My prompts end to be in the pattern of "I am looking to implement . . Review the code base to find similar examples of how this is currently done, and propose a plan for how to implement this."

These days I'm on Claude Code, and I do that first part in Plan mode, though even a few months ago on earlier, not-as-performant models and tools, I was still finding value with this approach. It's just getting better, as the company is investing in shared skills/tools/plugins/whatever the current terminology is that is specific to various use cases within the code base.

I haven't been writing so much code directly, but I do still very much feel that this is my code. My sessions are very interactive -- I ask the agent to explain decisions, question its plans, review the produced code and often revise it. I find it frees me up to spend more time thinking through and having higher level architecture applied instead of spending frustrating hours hunting down more basic "how does this work" information.

I think it might have been an article by Simon Willison that made the case for there being a way to use AI tooling to make you smarter, or to make you dumber. Point and shoot and blindly accept output makes you dumber -- it places more distance between you and your code base. Using AI tools to automate away a lot of the toil give you energy and time to dive deeper into your code base and develop a stronger mental model of how it works -- it makes you smarter. I keep in mind that at the end of the day, it's my name on the PR, regardless of how much Claude directly created or edited the files.

It’s always the people management stuff that’s the hard part, but AI isn’t going to solve that. I don’t know what my previous manager’s deal was, but AI wouldn’t fix it.

Comments URL: https://news.ycombinator.com/item?id=46810839

Points: 1

# Comments: 0

If what you are saying is that _maintenance_ is not the same as feature updates and changes, then I agree. If you are literally saying that you think software, once released, doesn't ever need any further changes for maintenance rather than feature reasons, I disagree.

For instance, you mention "security implications," but as a "might" not "will." I think this vastly underestimates security issues inherent in software. I'd go so far say that all software has two categories of security issues -- those that known today, and those that will be uncovered in the future.

Then there's the issue of the runtime environment changing. If it's web-based, changing browser capabilities, for instance. Or APIs it called changing or breaking. Etc.

Software may not be physical, but it's subject to entropy as much as roads, rails, and other good and infrastructure out in the non-digital world.

There are only two problems in computer science. We only have one joke, and it's not very funny.

The places people can find out about your product are controlled by a very small number of companies. And those companies not only own those spaces, they also own the means of advertising on those spaces. So if you have a product you want to advertise, you're not paying to distribute your message broadly to consumers, you're paying a toll to a gatekeeper that stands between you and your potential customers.

Comments URL: https://news.ycombinator.com/item?id=46522083

Points: 3

# Comments: 0

B&N, and Borders, are how I learned to code. Directionless after college, I thought, hey, why not learn how to make websites? And I'd spend a lot of time after work reading books at these stores (and yes, buying too).

At the second, it wasn't hostility but more indifference -- yes, in theory they'd like higher quality code, but none of the systems to make this possible were set up. My team was all brand new to the company, except for two folks who'd been at the company for several years but in a completely different domain , with a manger from yet another domain. The "relative beginner" aspect he calls out was in full effect.

"Eventually consistent," as I understand it, always implies a lag, whereas the way you're using it seems to imply that at some point there is no lag.

I'm not going to pretend to have a good definition of what "consciousness" is, but directionally, I think having goals -- no, that's too weak -- having _desires_, is an important part of it. And I'm not sure it's possible to have desires if one cannot die.

Something like an LLM can't actually die. Shut down all the machines its code runs on, then turn them back on, and it's in the same state it was before. So it's not the "hardware" that an LLM lives in. Is it the code itself? Copy it to another set of machines and it's the same program. Code + data? Maybe we run into storage issues, but in theory same thing -- transfer the code and date somemplace else and its the same program. You can't actually "kill" a computer program. So there's no inherent "mortality" to it that where any kinds of "desire" would emerge from.

I don't think the idea was that in the event of catastrophe, up to and including nuclear attack, the system would continue working normally, but that it would keep working. And the internet -- as a system -- certainly kept working during this AWS outage. In a degraded state, yes, but it was working, and recovered.

I'm more concerned with the way the early public internet promised a different kind of decentralization -- of economics, power, and ideas -- and how _that_ has become heavily centralized. In which case, AWS, and Amazon, indeed do make a good example. The internet, as a system, is certainly working today, but arguably in a degraded state.

- Channels I care about: ones where real work gets done every day, eg my team channels, other people I interact with frequently and directly.

- Temporarily important: short lived channels, or project channels that aren't as frequently actionable as the first category. Eg, I am struggling with some build issue so I join the public channel for the team that owns that process until I resolve my issue.

- Channels I need to follow: I don't really care too much about this, but partners or stakeholders are in them and sometimes say things I should know about or ping me or will add me if I leave, so I need to somewhat monitor it.

- Channels not really about me: Broad-based channels about company strategy, etc. In theory I guess they impact me since its about what the org, or my part of it, is up to, but tbh it doesn't actually impact me materially.

- Channels I may leave soon. Basically recycle bin, before I leave channel entirely.

> How do you tell someone that has had commit and admin access to critical infrastructure long after that need has expired that you need to revoke that access without upsetting them?

Start by letting go of the goal of not upsetting them. Make sure you do communicate clearly. Just say what you said a paragraph earlier: open source ecosystems, including ours, are increasingly suffering supply chain attacks. To guard against this, we need to tighten access that has traditionally been fairly loose. Starting , we're going to remove general access and ask that contributors sign before re-enabling access.

I mean, maybe that is what happened -- as the OP says, he wasn't part of the conversations so can't say. From the earlier public posts, it doesn't _sound_ like that's what happened. But I'd say as a general rule, it's important to communicate disruptive changes ahead of time to those affected and give a clear path to how they can mitigate the disruption.

Comments URL: https://news.ycombinator.com/item?id=45277983

Points: 1

# Comments: 0