anyonecancode

Right? The person who you impersonated would then be marked as having voted twice, which would pretty quickly get noticed and investigated. So somehow you'd have to get away with that, plus do this at scale so as to actually influence the outcome. Doesn't make sense.

> While I certainly don't work at Cisco, I've come to the conclusion that I need to re-examine my priors when it comes to code rewrites and general maintainability.

One of the reasons to avoid rewriting has long been that the time spent rewriting code that works is time not spent writing code to meet new business needs. In other words, it's usually a huge opportunity cost, rarely balanced out by sufficient gains to be net positive.

I do think AI does challenge this prior, as the time needed to do a rewrite shrinks dramatically. It's not zero, of course, but it now becomes worth asking if it's worth doing, rather than defaulting to avoiding rewrites in nearly all cases.

Guest link: https://www.nytimes.com/2026/10/25/world/africa/tristan-da-c...

Doesn't arbitration avoid setting binding precedent? So even if the consumer wins a case, it's still overall better for the company.

It sounds similar to the more thoughtful critiques of AI in programming. Treating AI as a lines of code (LOC) generator, where actual human beings end up not engaging with the domain the software is working in, and there is then little to no understanding or care to understand the resulting code, we call "slop." The term slop is definitely pejorative, but since most software is commercial, it ends up raising questions as to how much quality and domain knowledge matter if the goal is primarily marketplace success. Then we get those thorny questions of what is software for, anyway -- do we really accept the premise that "marketplace success" is the best, and perhaps only relevant, criteria?

The declaration here, as I understand it, is taking the premise that the point of mathematics _is_ the domain knowledge, and that using "solves math problems" as a benchmark is exactly the kind of shallow, domain-eroding approach to AI that in software we label "slop."

Not just the largest city, but also the city where much of our national media is based or has a very large presence. It's so bizarre when I visit friends and family in other parts of the country and they know more about my local news stories than their own cities.

Grocery stores aren't evenly distributed throughout the city, though, and there are neighborhoods were either there is no store at all nearby, or the store that exists has poor quality and high prices. In those locations, the dynamic of a city-owned store undercutting a "normal" store isn't really going to apply since there isn't really a "normal" store in the area.

So much, of course, depends on the execution -- a crappy city store won't be a help to anyone -- but the concept isn't inherently bad on its face.

It runs into the Mississippi river, which runs into the sea.

Given that each planet seems to have one species, except that humans live everywhere, I always kind of assumed that the Galactic Empire was one with humans at the core.

I first learned about New Sweden several years ago from reading The Barbarous Years[0]. Now I always think about it whenever I drive south toward Maryland and DC when I cross the Delaware and see signs for towns like Swedesboro (NJ) and various Cristiana/Christiana place names in DE.

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

A graffito, or a pack of graffiti ;-)

In the US, much of the woods are owned by corporations too. Those that aren't are, in theory, owned by the public, but the oligarchs work hard to hollow that out so that practically public lands are owned by them too.

> Imagine telling workers at a construction company that the hard problem was never building stuff but figuring out what needs to be built.

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.

That may be the future, but we're not there yet. If you're having the LLM write to a high level language, eg java, javascript, python, etc, at some point there will be a bug or other incident that requires a human to read the code to fix it or make a change. Sure, that human will probably use an LLM as part of that, but they'll still need be able to tell what the code is doing, and LLMs simply are not reliable enough yet that you just blindly have them read the code, change it, and trust them that it's correct, secure, and performant. Sure, you can focus on writing tests and specs to verify, but you're going to spend a lot more time going in agentic loops trying to figure out why things aren't quite right vs a human actually being able to understand the code and give the LLM clear direction.

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.

Somewhat against the common sentiment, I find it's very helpful on a large legacy project. At work, our main product is a very old, very large code base. This means it's difficult to build up a good understanding of it -- documentation is often out of date, or makes assumptions about prior knowledge. Tracking down the team or teams that can help requires being very skilled at navigating a large corporate hierarchy. But at the end of the day, the answers for how the code works is mostly in the code itself, and this is where AI assistance has really been shining for me. It can explore the code base and find and explain patterns and available methods far faster than I can.

My prompts end to be in the pattern of "I am looking to implement <X>. <Detailed description of what I expect X to do.>. 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.

What the teacher did.

If the goal is to reduce the need for SWE, you don’t need AI for that. I suspect I’m not alone in observing how companies are often very inefficient, so that devs end up spending a lot of time on projects of questionable value—something that seems to happen more often the larger the organization. I recall at one job my manager insisted I delegate building a react app for an internal tool to a team of contractors rather than letting me focus for two weeks and knock it out myself.

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.

These posts are in a thread about someone pumping out a large amount of software in a short amount of time using AI. I'm guessing that you and I would agree that programs flung out of an AI shotgun are highly unlikely to be the kind of software that will work well and satisfy users with no changes over 10 years.

> There's this notion of software maintenance - that software which serves a purpose must be perennially updated and changed - which is a huge, rancid fallacy. If the software tool performs the task it's designed to perform, and the user gets utility out of it, it doesn't matter if the software is a decade old and hasn't been updated.

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.

Well, there's the variation I heard recently:

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

> In order to sell anything, people need to know about it. Google and Meta provide a way to make this possible. If they didn't exist, you wouldn't somehow have a more affordable way to get people to know about your product. However frustrating the current situation is, it is still more accessible than needing access to the airwaves or print media to try to sell anything new.

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.

Who are these mythical people who can pay $500/month to park below 60th street but will be bankrupted by the congestion toll?