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

Points: 151

# Comments: 56

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

Points: 3

# Comments: 0

[0]https://bookshop.org/p/books/the-barbarous-years-the-peoplin...

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

Points: 2

# Comments: 0

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

Points: 2

# Comments: 0

Isn't this kind of true, though? Housing construction, for instance, isn't bottlenecked by the technical difficulties of building, but by political and regulatory hurdles. Or look at large, capital-intensive projects such as the always-proposed, never built new Hudson river train tubes. Actually building these will take billions of dollars and many years, but even they would be long built by now were it not for their constantly being blocked by political jockeying.

Building stuff _does_ often involve difficult technical challenges, but I still think that as a general aphorism the observation that this isn't the _hardest_ part holds true.

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