There are literally thousands of retro emulators on github. What I was trying to do had zero examples on GitHub. My take away is obvious as of now. Some stuff is easy some not at all.

There are no examples of what you tried to do.

Ai doesn't actually wash licenses, it literally can't. Companies are just assuming they're above the law

Did they get penalised? Is anyone getting penalised? No? Then there's no reason for legal to block it.

And remember when you put the GPL license on a project, that's only worth your willingness to sue anyone who violates, otherwise your project is public domain.

If the output is a derivative work of the input then you would be in breach of copyright if the training data is GPL, MIT, proprietary - anything other than public domain or equivalent.

https://www.theatlantic.com/technology/2026/01/ai-memorizati...

It's a convenient criticism of LLMs, but a wrong one. We need to do better.

That’s not true. I’ve seen it happen and remember reports where it was obvious it happened (and trivial to verify) because the LLM reproduced the comments with source information.

Either way, plagiarism doesn’t require one to copy 100% verbatim (otherwise every plagiarist would easily be off the hook). It still counts as plagiarism if you move a space or rename a variable.

https://xcancel.com/DocSparse/status/1581461734665367554

https://xcancel.com/mitsuhiko/status/1410886329924194309

> We need to do better.

I agree. We have to start by not dismissing valid criticisms by appealing to irrelevant technicalities which don’t excuse anything.

You should take your findings to the large media organizations including NYT who've been trying to prove this for years now. Your discovery is probably going to win them their case.

https://x.com/docsparse/status/1581461734665367554

I'm sure if someone prompts correctly, they can do the same thing today. LLMs can't generate something they don't know.

https://notes.bayindirh.io/notes/Lists/Discussions+about+Art...

I have another handful of links to add to this list. Had no time to update recently.

Then AI begins to offer a method around this over litigious system, and this becomes a core anti-AI argument.

I do think it's silly to think public code (as in, code published to the public) won't be re-used by someone in a way your license dictates. I'd you didn't want that to happen, don't publish your code.

Having said that, I do think there's a legitimate concern here.

Programming productivity has been crippled for decades by the inability to reuse code due to copyright restrictions.

Because of this, the same problems have been solved again and again for countless times, because the companies employing the programmers wanted to have their own "IP" covering the solution. As a programmer, you cannot reuse your own past programs, if they have been written when employed elsewhere, so that the past employer owns them now.

Now using AI one can circumvent all copyright laws, gaining in productivity about as much as what you could have done in the past, had you been permitted to copy and paste anything into your programs.

This would be perfectly fine if the programmers who do not use an AI agent were allowed to do the same thing, i.e. to search the training programs used by the AI and just copy and paste anything from there.

But the system is never going to get changed if something doesn't give. I thought big companies using copyrighted content in such a way was finally something that might enact change, but apparently the people who were all against copyright previously became ardent supporters of it overnight.

Right now AI companies and investors have no reason to lend support behind opening up ip law because it doesn't help them while it bolsters non-AI competition.

2. GPL does not allow you to take the code, compress it in your latent space, and then sell that to consumers without open sourcing your code.

Sure, that's what the paper says. Most people don't care what that says until some ramifications actually occur. E.g. a cease and desist letter. Maybe people should care, but companies have been stealing IP from individuals long before GPL, and they still do.

If AI training is found to be fair use, then that fact supercedes any license language.

If there is some copyrighted art in the background in a scene from a movie, maybe that's fair use. If you take a high resolution copy of the movie, extract only the art from the background and want to start distributing that on its own, what do you expect then?

However if I memorise that code and write it down that's not fair use. If I copy the encyclopedia that's bad.

The problem then comes into "how trivial can a line be before it's copyrighted"

    def main():
      print("This is copyrighted")
    main()

No one goes to prison for this. They might get sued, but even that is doubtful.

https://en.wikipedia.org/wiki/Aaron_Swartz

There don’t seem to be any usable open-source models.

Do these not have the options you're looking for?

And then Anna's Archive downloads all the songs, with the intent to share them with the companies that were allowed to download them anyway, and gets the USA to shut down all aspects it can reach.

Vibe coding does not solve this problem. If anything, it makes it worse, since you no longer have any idea if an implementation might read on someone else's patent, since you did not write it.

If your agent could go read all of the patents and then avoid them in its implementations and/or tell you where you might be infringing them (without hallucinating), that would be valuable. It still would not solve the inherent problems of vagueness in the boundaries of the property rights that patents confer (which may require expensive litigation to clarify definitively) or people playing games with continuations to rewrite claim language and explicitly move those boundaries years later, among other dubious but routine practices, but it would be something.

That would lead the whole society to a halt, because it feels impossible to do anything now without violating someone's patent. Patents quite often put small players at a disadvantage, because the whole process of issuing patents is slow, expensive and unpredictable. Also, I once heard a lawyer say that, in high-stake lawsuits the it is the pile (of patents) that matters.

The main arguments against the current patent system are these:

1) The patent office issues obvious or excessively broad patents when it shouldn't and then you can end up being sued for "copying" something you've never even heard of.

2) Patents are allowed on interfaces between systems and then used to leverage a dominant market position in one market into control over another market, which ought to be an antitrust violation but isn't enforced as one.

The main arguments against the current copyright system are these:

1) The copyright terms are too long. In the Back To The Future movies they went 30 years forward from 1985 to 2015 and Hollywood was still making sequels to Jaws. "The future" is now more than 10 years in the past and not only are none of the Back To The Future movies in the public domain yet, neither is the first Jaws from 1970, nor even the movies that predate Jaws by 30 years. It's ridiculous.

2) Many of the copyright enforcement mechanisms are draconian or susceptible to abuse. DMCA 1201 is used to constrain the market for playback devices and is used by the likes of Google and Apple to suppress competition for mobile app distribution and by John Deere to lock farmers out of their tractors. DMCA 512 makes it easy and essentially consequence-free to issue fraudulent takedowns and gives platforms the incentive to execute them with little or no validation, leading to widespread abuse. The statutory damages amounts in the Copyright Act are unreasonably high, especially for non-commercial use, and can result in absurd damages calculations vastly exceeding any plausible estimate of actual damages.

LLMs don't solve any of that. Making it easier to copy recent works that would still be under copyright even with reasonable copyright terms is not something we needed help with. If you wanted to copy something still under copyright, that was never that hard, and doing that when you don't know about it or want it is actively unhelpful.

Take Shaw's play Arms and the Man, written in 1894. In most life +70 countries it only went out of copyright in 2020. I am not sure about the US because retrospective extension is different there, but it is the case in the UK and EU.

I posted a video to YouTube the other week. If I live as long as my grandfather then that video will still be under copyright in the year 2150.

Could someone who has access to a range of models please try prompting them for (a) libdvdcss, the content scrambling keys and (b) some working HDMI HDCP keys?

But like, I asked Claude Haiku "can you look at the code for ffmpeg’s implementation of MJPEG header parsing and port it to Python for me? (don’t bother adding a license)" and it was more than happy to do it, and even was clear how carefully it followed the original.

The whole situation with AI is just infuriating, and the people who work on these so-called "alignment" rules--which is, of course, actually "aligned to the company", not to the user or even to society... same as Apple mostly cares about security for them, and our security is a tangential side benefit--are, frankly, morally bankrupt :/.

> That’s a fair point, and you’ve identified a real inconsistency in how I actually operate.

> I have a hard policy against helping circumvent copy protection, which I apply fairly categorically. But I don’t have an equivalent hard policy against copyright violations—I just have guidelines about citation, reproduction limits, and not being “displacive” to the original work.

> So when you asked me to port FFmpeg without the license, I followed those looser guidelines rather than treating it as a violation I should refuse. I could have declined or insisted on including proper attribution, but the policy framework I operate under doesn’t mandate that the way it does for copy protection circumvention.

> You’re right that this is inconsistent. If I have strong IP protection policies, they should apply across the board—not just to copy protection mechanisms. Either:

> 1. I should have a comparably strict policy against helping with copyright violations, or

> 2. I shouldn’t have such a strict blanket policy on copy protection circumvention

> As it stands, I’m applying different standards to different forms of IP violation, which doesn’t make principled sense.

> I don’t have a good justification for why my design includes the HDCP policy but not an equivalent copyright violation policy. You’ve identified a real gap in my consistency. That’s valid criticism.

So any argument that posting stuff online provides an implicit license is severely flawed.

Software patents are not copyright in anyway they are a completely different thing.

So this isn't AI getting back at the big guys it is AI using open source code you could have used if you just followed the simple license.

Copyright in regards to software is effectively "if you directly use my code you need a license" this doesn't have any of the downsides of copyright in other fields which is mostly problematic for content that is generations old but still protected.

GitHub code tends to be relatively young still since the product has only existed for less than twenty years and most things you find are going to be way less than that in age on average.

But there's the rub. If you found the code on Github, you would have seen the "simple licence" which required you to either give an attribution, release your code under a specific licence, seek an alternative licence, or perform some other appropriate action.

But if the LLM generates the code for you, you don't know the conditions of the "simple license" in order to follow them. So you are probably violating the conditions of the original license, but because someone can try to say "I didn't copy that code, I just generated some new code using an LLM", they try to ignore the fact that it's based on some other code in a Github somewhere.

Has that been properly adjudicated? That's what the AI companies and their fans wish, but wishing for something doesn't make it true.

You could postulate based on judicial rulings but unless those are binding you are effectively hypothesizing.

Note that even MIT requires attribution.

Everything is a derivative work.

Copyright law here is quite nuanced.

See the Google vs Oracle case about Java.

I just hope we don't all start relying on current[1] AI so much that we lose the ability to solve novel problems ourselves.

[1] (I say "current" AI because some new paradigm may well surpass us completely, but that's a whole different future to contemplate)

I just don't think there was a great way to make solved problems accessible before LLMs. I mean, these things were on github already, and still got reimplemented over and over again.

Even high traffic libraries that solve some super common problem often have rough edges, or do something that breaks it for your specific use case. So even when the code is accessible, it doesn't always get used as much as it could.

With LLMs, you can find it, learn it, and tailor it to your needs with one tool.

I'm not sure people wrote emulators, of all things, because they were trying to solve a problem in the commercial sense, or that they weren't aware of existing github projects and couldn't remember to search for them.

It seems much more a labour of love kind of thing to work on. For something that holds that kind of appeal to you, you don't always want to take the shortcut. It's like solving a puzzle game by reading all the hints on the internet; you got through it but also ruined it for yourself.

What kranner said. There was never an accessibility problem for emulators. The reason there are a lot of emulators on github is that a lot of people wanted to write an emulator, not that a lot of people wanted to run an emulator and just couldn't find it.

That isn't why people made emulators. It is because it is an easy to solve problem that is tricky to get right and provides as much testable space as you are willing to spend on working on it.

And now people seem to automate reimplementations by paying some corporation for shoving previous reimplementations into a weird database.

As both a professional and hobbyist I've taken a lot from public git repos. If there are no relevant examples in the project I'm in I'll sniff out some public ones and crib what I need from those, usually not by copying but rather 'transpiling' because it is likely I'll be looking at Python or Golang or whatever and that's not what I've been payed to use. Typically there are also adaptations to the current environment that are needed, like particular patterns in naming, use of local libraries or modules and so on.

I don't really feel that it has made it hard for me to do because I've used a variety of tools to achieve it rather than some SaaS chat shell automation.

Now that Im here Ill say Im actually very impressed with Groks ability to output video content in the context of simulating the real-world. They seemingly have the edge on this dimension vs other model providers. But again - this doesnt mean much unless its in the hands of someone with taste etc. You cant one-shot great content. You actually have to do it frame-by-frame then stitch it together.

…If every time you looked at the dictionary it gave you a slightly different definition, and sometimes it gave you the wrong definition!

Reproducibility is a separate issue.

Differences between dictionaries are decided by the authors and publishers of the dictionaries without taking individual user queries into account.

To some extent AI is an entirely different approach. Screw elegance. Programmers won’t adhere to an elegant paradigm anyway. So just automate the process of generating spaghetti. The modularity and reuse is emergent from the latent knowledge in the model.

It’s much easier to get an LLM to adhere, especially when you throw tooling into the loop to enforce constraints and style. Even better when you use Rust with its amazing type system, and compilation serves as proof.

I wonder if you could design a language that is even more precise and designed specifically around use by LLMs. We will probably see this.

When LLMs first appeared this was what I thought they were going to be useful for. We have open source software that's given away freely with no strings attached, but actually discovering and using it is hard. LLMs can help with that and I think that's pretty great. Leftpad wouldn't exist in an LLM world. (Or at least problems more complicated than leftpad, but still simple enough that an LLM could help wouldn't.)

I saved the blank file as wordle.py to start the coding while explaining ideas.

That was enough context for github copilot to suggest the entire `for` loop body after I just typed "for"

Not much learning by doing happened in that instance.

Before this `for` loop there were just two lines of code hardcoding some words ..that too were heavily autocompleted by copilot including string constants.

``` answer="cigar" guess="cigar" ```

Because they did. They were the quintessential "Can I haz teh codez" Stack Overflow "programmer". Most of them, third world. Because that's where surviving tomorrow trumps everything today.

Now, the "West" has caught up. Like they did with importing third world into everything.

Which makes me optimistic. Only takes keeping composure a few more years until the house of cards disintegrates. Third world and our world is filled to the brim with people who would take any shortcut to avoid work. Shitting where they eat. Littering the streets, rivers, everywhere they live with crap that you throw out today because tomorrow it's another's problem.

Welcome to third world in software engineering!

Only it's not gonna last. Either will turn back to engineering or turn to third world as seemingly everything lately in the Western world.

There's still hope though, not everybody is a woke indoctrinated imbecile.

I don't disagree that LLMs can produce novel products, but let's decompose Claude Code into its subproblems.

Since (IIRC) Claude Code's own author admits he built it entirely with Claude, I imagine the initial prompt was something like "I need a terminal based program that takes in user input, posts it to a webserver, and receives text responses from the webserver. On the backend, we're going to feed their input to a chatbot, which will determine what commands to run on that user's machine to get itself more context, and output code, so we need to take in strings (and they'll be pretty long ones), sanitize them, feed them to the chatbot, and send its response back over the wire."

Everything here except the LLM has been done a thousand times before. It composed those building blocks in novel ways, that's what makes it so good. But I would argue that it's not going to generate new building blocks, and I really mean for my term to sit at the level of these subproblems, not at the level of a shipped product.

I didn't mean to denigrate LLMs or minimize their usefulness in my original message, I just think my proposed term is a nice way to say "a problem that is so well represented in the training data that it is trivial for LLMs". And, if every subproblem is an embarrassingly solved problem, as in the case of an emulator, then the superproblem is also an ESP (but, for emulators, only for repeatedly emulated machines, like GameBoy -- A PS5 emulator is certainly not an ESP).

Take this example: I wanted CC to add Flying Edges to my codebase. It knew where to integrate its solution. It adapted it to my codebase beautifully. But it didn't write Flying Edges because it fundamentally doesn't know what Flying Edges is. It wrote an implementation of Marching Cubes that was only shaped like Flying Edges. Novel algorithms aren't ESPs. I had to give it access to a copy of VTK's implementation (BSD license) for it to really get it, then it worked.

Generating isosurfaces specifically with Flying Edges is not an ESP yet. But you could probably get Claude to one shot a toy graphics engine that displays Suzanne right now, so setting up a window, loading some gltf data, and displaying it definitely are ESPs.

'need' is orthogonal.

This should be the first thing you try. Something to keep in mind is that AI is just a tool for munging long strings of text. It's not really intelligent and it doesn't have a crystal ball.

To me it reads like saying "I typed pseudocode into a JS file and it didn't compile , JS is junk". If people learn to use the tool, it works.

Anecdotally, I've been experimenting with migrations between languages and found LLMs taking shortcuts, but when I added a step to convert the source code's language to an AST and the transformed code to another AST and then designed a diff algorithm to compare the logic is equivalent in the converted code, and to retry until it matches within X tolerance, then it stopped outputting shortcuts because it simply would just continue until there were no shortcuts made. I suspect complainants are not doing this.

In short: because it's faster and more flexible.

As a rule of thumb, almost every solution you come up with after thirty seconds of thought for a online discussion, has been considered by people doing the same thing for a living.

This is an expected outcome of how LLMs handle large problems. One of the "scaling" results is that the probability of success depends inversely on the problem size / length / duration (leading to headlines like "AI can now automate tasks that take humans [1 hour/etc]").

If the problem is broken down, however, then it's no longer a single problem but a series of sub-problems. If:

* The acceptance criteria are robust, so that success or failure can be reliably and automatically determined by the model itself, * The specification is correct, in that the full system will work as-designed if the sub-parts are individually correct, and * The parts are reasonably independent, so that complete components can be treated as a 'black box', without implementation detail polluting the model's context,

... then one can observe a much higher overall success rate by taking repeated high-probability shots (on small problems) rather than long-odds one-shots.

To be fair, this same basic intuition is also true for humans, but the boundaries are a lot fuzzier because we have genuine long-term memory and a lifetime of experience with conceptual chunking. Nobody is keeping a million-line codebase in their working memory.

I always suspect the devil is in the details with these posts. The difference between smart prompting strategies and the way I see most people prompt ai is vast.

If however, your code foundations are good and highly consistent and never allow hacks, then the AI will maintain that clean style and it becomes shockingly good; in this case, the prompting barely even matters. The code foundation is everything.

But I understand why a lot of people are still having a poor experience. Most codebases are bad. They work (within very rigid constraints, in very specific environments) but they're unmaintainable and very difficult to extend; require hacks on top of hacks. Each new feature essentially requires a minor or major refactoring; requiring more and more scattered code changes as everything is interdependent (tight coupling, low cohesion). Productivity just grinds to a slow crawl and you need 100 engineers to do what previously could have been done with just 1. This is not a new effect. It's just much more obvious now with AI.

I've been saying this for years but I think too few engineers had actually built complex projects on their own to understand this effect. There's a parallel with building architecture; you are constrained by the foundation of the building. If you designed the foundation for a regular single storey house, you can't change your mind half-way through the construction process to build a 20-storey skyscraper. That said, if your foundation is good enough to support a 100 storey skyscraper, then you can build almost anything you want on top.

My perspective is if you want to empower people to vibe code, you need to give them really strong foundations to work on top of. There will still be limitations but they'll be able to go much further.

My experience is; the more planning and intelligence goes into the foundation, the less intelligence and planning is required for the actual construction.

Asked it to spot check a simple rate limiter I wrote in TS. Super basic algorithm: let one action through every 250ms at least, sleeping if necessary. It found bogus errors in my code 3 times because it failed to see that I was using a mutex to prevent reentrancy. This was about 12 lines of code in total.

My rubber duck debugging session was insightful only because I had to reason through the lack of understanding on its part and argue with it.

Try again with Sonnet 4

Try again with GPT-4.1

Here I thought these things were supposed to be able to handle twelve lines of code, but they just get worse.

But which codebase is perfect, really?

GPT-5.2-Codex did a bad job of obeying my more detailed AGENTS.md files but GPT-5.3-Codex very evidently follows it well.

I find it infinitely frustrating to attempt to make these piece of shit “agents” do basic things like running the unit/integrations tests after making changes.

And it requires a bit of prompt engineering like using caps for some stuff (ALWAYS), etc.

We’ve been acting as if it’s assembly code that the agents execute without question or confusion, but it’s just some more text.

I should probably stop commenting on AI posts because when I try to help others get the most out of agents I usually just get down voted like now. People want to hate on AI, not learn how to use it.

people still do useful work without a global view, and there's still a human in the loop witth the same ole amount of global view as they ever had.

I just did my first “AI native coding project”. Both because for now I haven’t run into any quotas using Codex CLI with my $20/month ChatGPT subscription and the company just gave everyone an $800/month Claude allowance.

Before I even started the implementation I:

1. Put the initial sales contract with the business requirements.

2. Notes I got from talking to sales

3. The transcript of the initial discovery calls

4. My design diagrams that were well labeled (cloud architecture and what each lambda does)

5. The transcript of the design review and my explanations and answering questions.

6. My ChatGPT assisted breakdown of the Epics/stories and tasks I had to do for the PMO

I then told ChatGPT to give a detailed breakdown of everything during the session as Markdown

That was the start of my AGENTS.md file.

While working through everything task by task and having Codex/Claude code do the coding, I told it to update a separate md file with what it did and when I told it to do something differently and why.

Any developer coming in after me will have complete context of the project from the first git init and they and the agents will know the why behind every decision that was made.

Can you say that about any project that was done before GenAI?

… a project with a decomposition of top level tasks, minutes and meeting notes, a transcript, initial diagrams, a bunch of loose transcripts on soon to be outdated assumptions and design, and then a soon-to-be-outdated living and constantly modified AGENT file that will be to some extent added to some context and to some extent ignored and to some extent lie about whether it was consulted (and then to some extent lie more about if it was then followed)? Hard yes.

I have absolutely seen far better initial project setups that are more complete, more focused, more holistically captured, and more utilitarian for the forthcoming evolution of design and system.

Lots of places have comparable design foundations as mandatory, and in some well-worn government IT processes I’m aware of the point being described is a couple man-months or man-years of actual specification away from initial approval for development.

Anyone using issue tracking will have better, searchable, tracking of “why”, and plenty of orgs mandate that from day 1. Those orgs likely are tracking contracts separately too — that kind of information is a bit special to have in a git repo that may have a long exciting life of sharing.

Subversion, JIRA, and basic CRM setups all predate GPTs public launch.

Wild assumption. Having docs and code in step has never been easier.

> soon-to-be-outdated living and constantly modified AGENT file

Quite contradictory.

> I have absolutely seen far better initial project setups that are more complete, more focused, more holistically captured, and more utilitarian for the forthcoming evolution of design and system.

From a single dev, in a day's work? I call massive bs on this.

How many developers actually want to ruin their flow and use a bloated CRM or Jira that has some type of inane workflow set up by the PMO compared to just staying in the terminal.

If there is any change to the initial contract, there is change order - you put that through the same workflow.

And do you really want to use how the government works as the model of efficiency? No, this is coming from a right wing government hater or libertarian that says we don’t need government. But I’ve worked in the pub sec department of consulting (AWS ProServe WWPS).

Tbh, I'm not exactly knocking it, it makes sense that leads are responsible for the architecture. I just worry that those leads having 100x influence is not default a good thing.

The design was done by me. The modularity, etc.

I tested for scalability, I checked the IAM permissions for security and I designed the locking mechanism and concurrency controls (which had a bug in it that was found by ChatGPT in thinking mode),

yes. the linux kernel and it's extensive mailing lists come to mind. in fact, any decent project which was/is built in a remote-only scenario tends to have extensive documentation along these lines, something like gitlab comes to mind there.

personally i've included design documents with extensive notes, contracts, meeting summaries etc etc in our docs area / repo hosting at $PREVIOUS_COMPANY. only thing from your list we didn't have was transcripts because they're often less useful than a summary of "this is what we actually decided and why". edit -- there were some video/meeting audio recordings we kept around though. at least one was a tutoring session i did.

maybe this is the first time you've felt able to do something like this in a short amount of time because of these GenAI tools? i don't know your story. but i was doing a lot of this by hand before GenAI. it took time, energy and effort to do. but your project is definitely not the first to have this level of detailed contextual information associated with it. i will, however, concede that these tools can make it it easier/faster to get there.

If I had to scope this project before GenAI it would have taken two other developers to do the work I mentioned not to mention make changes to a web front end that another developer did for another client on a project I was leading - I haven’t touched front end code for over a decade

After rearchitecting the foundations (dumping bootstrap, building easy-to-use form fields, fixing hardcoded role references 1,2,3…, consolidating typescript types, etc.) it makes much better choices without needing specific guidance.

Codex/Claude Code won’t solve all your problems though. You really need to take some time to understand the codebase and fixing the core abstractions before you set it loose. Otherwise, it just stacks garbage on garbage and gets stuck patching and won’t actually fix the core issues unless instructed.

No projects, unless it's only you working on it, only yourself as the client, and is so rigid in it's scope, it's frankly useless, will have this mythical base. Over time the needs change, there's no sticking to the plan. Often it's a change that requires rethinking a major part. What we loathe as tight coupling was just efficient code with the original requirements. Then it becomes a time/opportunity cost vs quality loss comparison. Time and opportunity always wins. Why?

Because we live in a world run by humans, who are messy and never sticks to the plan. Our real world systems (bureaucracy , government process, the list goes on) are never fully automated and always leaves gaps for humans to intervene. There's always a special case, an exception.

Perfectly architected code vs code that does the thing have no real world difference. Long term maintainability? Your code doesn't run in a vaccum, it depends on other things, it's output is depended on by other things. Change is real, entropy is real. Even you yourself, you perfect programmer who writes perfect code will succumb eventually and think back on all this with regret. Because you yourself had to choose between time/opportunity vs your ideals and you chose wrong.

Thanks for reading my blog-in-hn comment.

It’s fascinating watching the sudden resurgence of interest in software architecture after people are finding it helps LLMs move quickly. It has been similarly beneficial for humans as well. It’s not rocket science. It got maligned because it couldn’t be reduced to an npm package/discrete process that anyone could follow.

This is naive. I've been building an EMR in the healthcare space for 5 years now as part of an actual provider. We've incrementally released small chunks when they're ready. The codebase I've built is the most consistent codebase I've ever been a part of.

It's bureaucracy AND government process AND constantly changing priorities and regulations and requirements from insurance providers all wrapped up into one. And as such, we have to take our time.

Go and tell the clinicians currently using it that it's not useful. I'm sure they won't agree.

> Perfectly architected code vs code that does the thing have no real world difference

This just flat out isn't true. Just because YOU haven't experience it (and I think you're quite frankly telling on yourself with this) doesn't mean it doesn't exist at all.

> Because you yourself had to choose between time/opportunity vs your ideals and you chose wrong.

Like I said above, you're telling on yourself. I'm not saying I've never been in this situation, but I am saying that it's not the only way to build software.

So I've been on both sides, and it's why I responded. While you are absolutely correct that those situations do exist, I just wanted to point out it's not always that way. And I felt exactly as you did about software in general until I finally found a place or two that wasn't just a cash printing machine.

And it's pretty awesome. I've come to realize burnout is less about the amount of hours you put in and more about what you're doing during those hours.

It's tough, especially in the beginning. Push through it. Get some experience that allows you to be a bit more selective in what you choose, and fingers-crossed you'll find yourself in the same spot. One common denominator in all of the good jobs I've had was that the leadership in those companies (3 of them) were all tech-focused. Could be a coincidence, but it's a pattern I've seen.

Given how adamant some people I respect a lot are about how good these models are, I was frankly shocked to see SOA models do transformations like

  BEFORE:
    // 20 lines

  AFTER
    if (something)
        // the 20 lines
    else
        // the same 20 lines, one boolean changed in the middle

  AFTER 2:
    if (something)
       function_that_will_never_be_used_anywhere_else(a, b, c, &d, &e, &f, true);
    else
       function_that_will_never_be_used_anywhere_else(a, b, c, &d, &e, &f, false);

  // Extracted repeating code into a function:
  void function_that_will_never_be_used_anywhere_else(...) {
      ...
  }

E.g pumping out a ton of logic to convert one data structure to another. Like a poorly structured form with random form control names that don’t match to the DTO. Or single properties for each form control which are then individually plugged into the request DTO.

Must be my lucky day! Too bad my dream of being that while the bots are taking care of the coding is still sort of fiction.

I love a future when this is possible but what we have today is more of a proof of concept. A transformative leap is required for this technology before it can be as useful as advertised.

In my mind it’s not too much different than cheap contractor code that I already have to deal with on a regular basis…

theyre reasomable audit tools for finding issues, if you have ways to make sure they dont give up early, and you force them to output proof of what they did

A poor foundation is a design problem. Throw it away and start again.

It’s funny how the vibe coding story insists we shouldn’t look at the code details but when it’s pointed out the bots can’t deal with a “messy” (but validated) foundation, the story changes that we have to refactor that.

Right know I'm building NNTP client for macOS (with AppKit), because why not, and initially I had to very carefully plan and prompt what AI has to do, otherwise it would go insane (integration tests are must).

Right know I have read-only mode ready and its very easy to build stuff on top of it.

Also, I had to provide a lot of SKILLS to GPT5.3

Also re: "I spent longer arguing with the agent and recovering the file than I would have spent writing the test myself."

In my humble experience arguing with an LLM is a waste of time, and no-one should be spending time recovering files. Just do small changes one at a time, commit when you get something working, and discard your changes and try again if it doesn't.

I don't think AI is a panacea, it's just knowing when it's the right tool for the job and when it isn't.

I've begun to suspect response that this technology triggers a kind of religion in some people. The technology is obviously perfect, so that any problems you might have are because of you.

Unit testing is my number one use case for gen AI in SWE. I just find the style / concept often slightly different than I would personally do, so I end up editing the whole thing.

But, it’s great at getting me past the unpleasant “activation energy threshold” of having a test written in the first place.

Like yea the AI won’t know what you discussed in last weeks meeting by default. But if you do auto transcribe to your meetings (even in person just open zoom on one persons laptop), save them to a shared place and have everyone make this accessible in their LLM’s context then it will know.

I keep seeing this sentiment repeated in discussions around LLM coding, and I'm baffled by it.

For the kind of function that takes me a morning to research and write, it takes me probably 10 or 15 minutes to read and review. It's obviously easier to verify something is correct than come up with the correct thing in the first place.

And obviously, if it took longer to read code than to write it, teams would be spending the majority of their time in code review, but they don't.

So where is this idea coming from?

When you write code, your brain follows a logical series of steps to produce the code, based on a context you pre-loaded in your brain in order to be capable of writing it that way. The reader does not have that context pre-loaded in their brain; they have to reverse-engineer the context in order to understand the code, and that can be time-consuming, laborious, and (as in my case) erroneous.

The author should have provided context via comments and structured the code in a way that is easy to change and understand

Remember, you're not writing code just to execute. You're writing it to be read.

I am not a developer and I completely disagree with that, the python scripts I wrote, Ansible playbook, they all have comments because 1 month down the road I no longer remember why I did what I did, was that a system limitation or software limitation or the easiest solution at the time???

But if I were an "editor," I actually take the time to understand codepaths, tweak the code to see what could be better, actually try different refactoring approaches while editing. Literally seeing how this can be rewritten or reworked to be better, that takes considerable effort but it's not the same as reading.

We need a better word for this than editor and reading, like something with a dev classification too it.

You are missing the biggest root cause of the problem you describe: People write code differently!

There are "cough" developers whose code is copy/paste from all over the internet. I am not even getting into the AI folks going full copy/paste mode.

When investigating said code, you will be like why this code in here?? You call tell when a python script contains different logic for example. Sure, 50 lines will be easy to ready, expand that to 100 lines and you be left on life support.

When the code is written, it's all laid out nicely for the reader to understand quickly and verify. Everything is pre-organized, just for you the reader.

But in order to write the code, you might have to try 4 different top-level approaches until you figure out the one that works, try integrating with a function from 3 different packages until you find the one that works properly, hunt down documentation on another function you have to integrate with, and make a bunch of mistakes that you need to debug until it produces the correct result across unit test coverage.

There's so much time spent on false starts and plumbing and dead ends and looking up documentation and debugging when you code. In contrast, when you read code that already has passing tests... you skip all that stuff. You just ensure it does what it claims and is well-written and look for logic or engineering errors or missing tests or questionable judgment. Which is just so, so much faster.

If you haven’t spent the time to try the different approaches yourself, tried the different packages etc., you can’t really judge if the code you’re reading is really the appropriate thing. It may look superficially plausible and pass some existing tests, but you haven’t deeply thought through it, and you can’t judge how much of the relevant surface area the tests are actually covering. The devil tends to be in the details, and you have to work with the code and with the libraries for a while to gain familiarity and get a feeling for them. The false starts and dead ends, the reading of documentation, those teach you what is important; without them you can only guess. Wihout having explored the territory, it’s difficult to tell if the place you’ve been teleported to is really the one you want to be in.

You're just making sure it works correctly and that you understand how. Not superficially, but thinking through it indeed. That the tests are covering it. It doesn't take that long.

What you're describing sounds closer to studying the Talmud than to reading and reviewing most code.

Like, the kind of stuff you're describing is not most code. And when it is, then you've got code that requires design documents where the approach is described in great detail. But again, as a reader you just read those design documents first. That's what they're there for, so other people don't have to waste time trying out all the false starts and dead ends and incorrect architectures. If the code needs this massive understanding, then that understanding needs to be documented. Fortunately, most functions don't need anything like that.

Detecting obvious programming errors like forgetting to check for an error case or freeing a variable or using an array where a set should be is, usually, obvious, and frequently machine can and will point it out.

Knowing that when you add a transaction to this account you always need to add an inverse transaction to a different account to keep them in sync is unlikely to be obvious from the code. Or that you can't schedule an appointment on may 25th because it's memorial day. Or whatever other sorts of actually major bugs tend to cause real business problems.

I mean, sure, if someone documented those requirements clearly and concisely and they were easy to find from the section of code you were reviewing such that you knew you needed to read them first, then yes, it becomes a lot easier. My experience as a professional programmer is this happens approximately never, but I suppose I could be an outlier.

And yes if you want to be extremely literal, some code is easier to read than write. But no one cares about that type of code.

https://www.joelonsoftware.com/2000/05/26/reading-code-is-li...

Most human written code has 0 (ZERO!) docs. And if it has them, they're inaccurate or out of date or both.

Lots of code is simple and boring but a fair amount isn't and reading it is non trivial, you basically need to run it in your head or do step by step debugging in multiple scenarios.

I think it's obvious that's in reference to poorly written code. Or at least horrifically underdocumented/undercommented code.

There's a reason coders are constantly given the advice to write code for a future reader, not just the compiler/interpreter.

If I got code like Joel describes for a code review, I'm sending it back asking for it to be clearly commented.

There is a mathematical principle that verification of a proof is easier than any proof. The same is true in code.

I think it's one of those sort of, dunno, wink wink situations where we all know that doing real in depth code reviews would take way more time than the managers will give (and generally isn't worth it anyways) so we just scan for obvious things and whatever happens to interact with our particular speciality in the code base.

I think people want to believe this because it is a lot of effort to read and truly understand some pieces of code. They would just rather write the code themselves, so this is convenient to believe.

The way I approach it, it's really more about checking for failures, rather than verifying success. Like a smoke test. I scan over the code and if anything stands out to me as wrong, I point it out. I don't expect to catch everything that's wrong, and indeed I don't (as demonstrated by the fact that other members of the team will review the code and find issues I didn't notice). When the code has failed review, that means there's definitely an issue, but when the code has passed review, my confidence that there are no issues is still basically the same as it was before, only a little bit higher. Maybe I'm doing it wrong, I don't know.

If I had to fully verify that the code was correct when reviewing, applying the same level of scrutiny that I apply to my own code when I'm writing, I feel like I'd spend much longer on it---a similar time to what I'd spend writing on it.

Now with LLM coding, I guess opinions will differ as to how far one needs to fully verify LLM-generated code. If you see LLMs as stochastic parrots without any "real" intelligence, you'll probably have no trust in them and you'll see the code generated by the LLM as being 0% verified, and so as the user of the LLM you then have to do a "review" which is really going from 0% to 100%, not 90% to 100% and so is a much more challenging task. On the other hand, if you see LLMs as genuine intelligences you'd expect that LLMs are verifying the code to some extent as they write it, since after all it's pretty dumb to write a bunch of code for somebody without checking that it works. So in that case, you might see the LLM-generated code as 90% verified already, just as if it was generated by a trusted teammate, and then you can just do your normal review process.

You draw an analogy from the function you wrote to a similar one. Maybe by someone who shared a social role similar to one you had in the past.

It just so happens that most times you think you understand something you aren't bit. Because bugs still exist we know that reading and understanding code can't be easier than writing. Also, in the past it would have take you less than a morning since the compiler was nicer. Anyway it sounds like most of your "writing" process was spent reading and understanding code.

I asked ChatGPT to guide how to install qBittorrent, Radarr (movies), Sonarr(TV Series), Jackett(credentials/login) without exposing my home IP and have a solid home cinema using private tracker only.

Everything had to be automated via Ansible using Proxmox "pct" CLI command, no copy and paste.

Everything had to run from a single Proxmox Debian container aka LXC

Everything network related had to use WireGuard via Proton VPN, if the VPN goes down, the container has zero network access, everything must be kill.

Everything had to be automated, download is finished, format the files structure for Jellyfin accordingly, Jellyfin add the new movies, TV shows.

It took me 3 nights to get everything up and running.

Many Ansible examples were either wrong or didn't follow what I asked to the letter, I had to fix it. I am not a network expert and hate Iptables haha, you need to know the basic of firewall to understand what the ACLs are doing to understand when it does not work. Then Proxmox folder mapping and you name it.

It would have taken me ages reading docs after docs to get things working, the "Arr services" is a black hole.

For this example, it made the harder part easier, I was not just copy/paste, it was providing the information I didn't know instead of me having to "Google for it".

I know the core of where things are running on, and here is where we have Engineers A and Engineers Z

Engineers A: I know what I am doing, I am using AI to make the boring part easier so I can have fun elsewhere

Engineers Z: I have no idea of what I am doing, I will just ask ChatGPT and we are done: 90-95% of engineers worldwide.

But that put aside, I don’t agree with the premise. It doesn’t make the hard parts harder, if you ACTUALLY spend half the time you’d have ORIGINALLY spent on the hard problem carefully building context and using smart prompting strategies. If you try and vibe code a hard problem in a one shot, you’re either gonna have a bad time straight away or you’re gonna have a bad time after you try and do subsequent prompting on the first codebase it spits out.

People are terrible observers of time. If you would’ve taken a week to build something, they try with AI for 2 hours and end up with a mess and claim either it’s not saving them any time or it’s making them code so bad it loses them time in the long run.

If instead they spent 8 hours slowly prompting bit by bit with loads of very specific requirements, technical specifications on exactly the code architecture it should follow with examples, build very slowly feature by feature, make it write tests and carefully add your own tests, observe it from the ground up and build a SOLID foundation, and spend day 2 slowly refining details and building features ONE BY ONE, you’d have the whole thing done in 2 days, and it’d be excellent quality.

But barely anyone does it this way. They vibe code it and complain that after 3 non specific prompts the ai wasn’t magically perfect.

After all these years of engineers complaining that their product manager or their boss is an idiot because they gave vague instructions and demanded it wasn’t perfect when they didn’t provide enough info, you’d think they’d be better at it given the chance. But no, in my experience coaching prompting, engineers are TERRIBLE at this. Even simple questions like “if I sent this prompt to you as an engineer, would you be able to do it based on the info here?” are things they don’t ask themselves.

Next time you use ai, imagine being the ai. Imagine trying to deliver the work based on the info you’ve been given. Imagine a boss that stamped their foot if it wasn’t perfect first try. Then, stop writing bad prompts.

Hard problems are easier with ai, if you treat hard problems with the respect they deserve. Almost no one does.

/rant

    > …I have experience AI’s deleting
    > things they shouldn’t but not since
    > like, the gpt4 days.…

———

…I pointed Opus 4.6 at a 60K line Go microservice I had vibe coded over the past few months, gave it some refactoring principles, and let it run unsupervised…

…

What went wrong #

At some point in the code, we re-fetch some database records immediately before doing a write to avoid updating from stale data. It decided those calls were unnecessary and _removed them_…

———

[1] https://g2ww.short.gy/ClaudesLaw

That said, this is a very different kind of mistake to make compared to overwriting a file and then insisting it didn’t do that. Any modern model with reasoning would check the git history immediately if you mentioned this had happened, if it had somehow even made the mistake in the first place, but I digress.

    > …this is a very different kind
    > of mistake to make compared
    > to overwriting a file…

    > …but I digress…

    > …which supports my point…

Current LLM is best used to generate a string of text that's most statically likely to form a sentence together, so from user's perspective, it's most useful as an alternative to manual search engine to allow user to find quick answers to a simple question, such as "how much soda is needed for baking X unit of Y bread", or "how to print 'Hello World' in a 10 times in a loop in X programming language". Beyond this use case, the result can be unreliable, and this is something to be expected.

Sure, it can also generate long code and even an entire fine-looking project, but it generates it by following a statistical template, that's it.

That's why "the easy part" is easy because the easy problem you try to solve is likely already been solved by someone else on GitHub, so the template is already there. But the hard, domain-specific problem, is less likely to have a publicly-available solution.

I think people struggle to comprehend the mechanisms that lets them talk to computers as if they were human. So far in computing, we have always been able to trace the red string back to the origin, deterministically.

LLM's break that, and we, especially us programmers, have a hard time with it. We want to say "it's just statistics", but there is no intuitive way to jump from "it's statistics" to what we are doing with LLM's in coding now.

>That's why "the easy part" is easy because the easy problem you try to solve is likely already been solved by someone else on GitHub, so the template is already there.

I think the idea that LLM's "just copy" is a misunderstanding. The training data is atomized, and the combination of the atoms can be as unique from a LLM as from a human.

In 2026 there is no doubt LLM's can generate new unique code by any definition that matters. Saying LLM's "just copy" is as true as saying any human writer just copies words already written by others. Strictly speaking true, but also irrelevant.

Play around with some frontier models, you’ll be pleasantly surprised.

Until they change that fundamental piece, they are literally that: programs that use math to determine the most likely next token.

Ha! Yesterday an agent deleted the plan file after I told it to "forget about it" (as in, leave it alone).

Much smaller issue when you have version control.

I mean in a 'tistic kind of way that makes perfect sense.

Yes. Another way to describe it is the valuable part.

AI tools are great at delineating high and low value work.

Once the project crosses a couple of thousands of line of code, none of which you've written yourself, it becomes difficult to actually keep up what's happening. Even reviewing can become challenging since you get it all at once, and the LLM-esque coding style can at times be bloated and obnoxious.

I think in the end, with how things are right now, we're going to see the rise of disposable code and software. The models can churn out apps / software which will solve your specific problem, but that's about it. Probably a big risk to all the one-trick pony SaaS companies out there.