This isn’t even a QA level thing. If you write any tests at all, which is basic software engineering practice, even if you had AI write the tests for you, the error should be very, very obvious. I mean I guess we could go down the road of “well what if the engineer doesn’t read the tests?” but at that point the article is less about insidious AI and just about bad engineers. So then just blame bad engineers.
It just emphasizes the importance of tests to me. The example should fail very obviously when you give it even the most basic test data.
I find it best to get the agent into a loop where it can self-verify. Give it a clear set of constraints and requirements, give it the context it needs to understand the space, give it a way to verify that it’s completed its task successfully, and let it go off. Agents may stumble around a bit but as long as you’ve made the task manageable it’ll self correct and get there.
Are you trying to make a point that agents can’t use MCP based off of a picture of a tweet you saw or something?
Your real problem is that, even with all rights reserved (full copy protection), the law won’t disallow someone from running a statistical analysis on your work.
This is not really true.
The way you teach an LLM, outside of training your own, is with rules files and MCP tools. Record your architectural constraints, favored dependencies, and style guide information in your rule files and the output you get is going to be vastly improved. Give the agent access to more information with MCP tools and it will make more informed decisions. Update them whenever you run into issues and the vast majority of your repeated problems will be resolved.
The generalized learning is usually just the first step. Coding LLMs typically go through more rounds of specialized learning afterwards in order to tune and focus it towards solving those types of problems. Then there’s RAG, MCP, and simulated reasoning which are technically not training methods but do further improve the relevance of the outputs. There’s a lot of ongoing work in this space still. We haven’t seen the standard even settle yet.
So olo because it’s the middle of color?
Maybe Fallacy is a better word than Paradox? Take a look at any AI-related thread and it’s filled to the brim with people lamenting the coming collapse of software development jobs. You might believe that this is obvious but to many, many people it’s anything but.
I can read your code, learn from it, and create my own code with the knowledge gained from your code without violating an OSS license. So can an LLM.
Not even just an OSS license. No license backed by law is any stronger than copyright. And you are allowed to learn from or statistically analyze even fully copyrighted work.
Copyright is just a lot more permissive than I think many people realize. And there’s a lot of good that comes from that. It’s enabled things like API emulation and reverse engineering and being able to leave our programming job to go work somewhere else without getting sued.
Yeah I don’t think we should be pushing to have LLMs generate code unsupervised. It’s an unrealistic standard. It’s not even a standard most companies would entrust their most capable programmers with. Everything needs to be reviewed.
But just because it’s not working alone doesn’t mean it’s useless. I wrote like 5 lines of code this week by hand. But I committed thousands of lines. And I reviewed and tweaked and tended to every one of them. That’s how it should be.
I’m not sure I get your analogy. This is more to me like two people got into a bath and one went “Ooh, that’s a bit too warm” while the other screamed "REEEEEEE HOOOOOT”. The degree is the same. The response is not.
Kinda funny the juxtaposition between the programmers’ reaction to this compared to the “techies” reaction on the crosspost.
Maybe we’re still early yet so I’ll write the difference right now for posterity: Programming post is generally critical of the article and has several suggestions on how to improve the quality of agent-assisted code.
Technology post is pretty much just “REEEEEEEEEEE AI BAD”
I’ve thought about this many times, and I’m just not seeing a path for juniors. Given this new perspective, I’m interested to hear if you can envision something different than I can. I’m honestly looking for alternate views here, I’ve got nothing.
I think it’ll just mean they they start their careers involved in higher level concerns. It’s not like this is the first time that’s happened. Programming (even just prior to the release of LLM agents) was completely different from programming 30 years ago. Programmers have been automating junior jobs away for decades and the industry has only grown. Because the fact of the matter is that cheaper software, at least so far, has just created more demand for it. Maybe it’ll be saturated one day. But I don’t think today’s that day.
There are bad coders and then there are bad coders. I was a teaching assistant through grad school and in the industry I’ve interviewed the gamut of juniors.
There are tons of new grads who can’t code their way out of a paper bag. Then there’s a whole spectrum up to and including people who are as good at the mechanics of programming as most seniors.
The former is absolutely going to have a hard time. But if you’re beyond that you should have the skills necessary to critically evaluate an agent’s output. And any more time that they get to instead become involved in the higher level discussions going on around them is a win in my book.
I think it’s reasonable if you consider the kind of physical situation it might represent.
You visit a farm and there are 2 unpackaged apples. There are also 5 packages that hold 8 apples but 5 have been removed from each. How many apples are there?
Hopefully they’d come up with a better numbering system than base 10. Base 10 is the worst part of metric tbh.
Brain worms he got from eating roadkill.
As far as I understand as a layman, the measurement tool doesn’t really matter. Any observer needs to interact with the photon in order to observe it and so even the best experiment will always cause this kind of behavior.
With no observer: the photon, acting as a wave, passes through both slits simultaneously and on the other side of the divider, starts to interfere with itself. Where the peaks or troughs of the wave combine is where the photon is most likely to hit the screen in the back. In order to actually see this interference pattern we need to send multiple photons through. Each photon essentially lands in a random location and the pattern only reveals itself as we repeat the experiment. This is important for the next part…
With an observer: the photon still passes through both slits. However, the interaction with the observer’s wave function causes the part of the photon’s wave in that slit to offset in phase. In other words, the peaks and troughs are no longer in the same place. So now the interference pattern that the photon wave forms with itself still exists but, critically, it looks completely different.
Now we repeat with more photons. BUT each time you send a photon through it comes out with a different phase offset. Why? Because the outcome of the interaction with the observer is governed by quantum randommess. So every photon winds up with a different interference pattern which means that there’s no consistency in where they wind up on the screen. It just looks like random noise.
At least that’s what I recall from an episode of PBS Space Time.
The way you guys are working is not about speed. It’s procrastination. The work needs to get done. You can either do it now or you can do it when the bug reports and change requests start coming in. There’s no speed to be gained by procrastinating, often it’s the opposite.
If it was me, I’d focus on producing better code despite the pressure. You know you’ve got coworkers spending time watching YouTube instead of turning their work in or picking up the next ticket. There’s your time to ask Claude to refine and refactor the code before you commit it. Just don’t be the slow guy and you’ll be fine.
Just refactor as you go. You don’t have to over engineer things. KISS and YAGNI are valuable engineering approaches. But don’t fool yourself into thinking that turning your work in an hour or two earlier is going to make a big difference in how the higher ups see you.
Where this really starts to pay off is
Your name comes up less often when assigning bug reports since you don’t own the feature that is bugged. People notice this.
Less time spent fixing bugs means more time making new features. Means you own a larger part of the codebase. People also notice this.
When a change request comes in and you go “Oh yeah, that’s easy. I already considered that and it’s like a 1 line config/code change.” You look like a fucking wizard when this happens.
This has always been my approach. Even in places with little to no quality standards. Hell, I think it works even better in places with no quality standards because it makes you stand out more.
P.S. While you already have a job is the best time to look for a new one. Because you don’t have any real stakes for failure.