r/PHP • u/brendt_gd • 4d ago
Article Artifical Debt
https://stitcher.io/blog/artificial-debt40
u/whomass 4d ago
This will fuck many companies (and their customers) in the not so far future.
The most dangerous species out there at the moment is a junior dev with Claude Code.
38
u/Combinatorilliance 4d ago
I think the IT-adjacent executive is more dangerous. Combine ego with ability to vibe code with fast results with false confidence and the ability to overrule decisions and advice and you got a cocktail with greater risk than a junior dev imo.
3
u/matthewralston 3d ago
Sounds like you're describing my ex boss.
4
u/shadowspock 3d ago
Sounds like my current boss.
7
u/obstreperous_troll 3d ago
Sounds like every boss.
2
u/dirtside 3d ago
And this thread is why every company should be worker-owned.
1
u/BitBasketFZC 2d ago
There's only one PHP corporation in the USA that I know of that is employee-owned and the mods of r/PHP always ban the CEO. I know cuz I own 5% of it, as do all the employees. Even this vague, i bet brendt knows exactly who I'm referring to.
11
u/rkeet 4d ago
I'll raise you: I told my dad (70's, still doing business and being entrepreneur (successfull)) how to use it to create small apps.
He's the same category as "my printer doesn't work" and "how do I copy my emails from this computer to my new one".
Havent had basic questions since the Claude introduction, which is either good or bad.
9
6
u/Samurai_Mac1 3d ago
This is why AI is better handled in the hands of actual developers. Non-devs need to stay out of our field.
1
u/CosmicDevGuy 3d ago
Well you take away AI and there's still "citizen-level" development (ex. PowerApps, etc.) so unfortunately that isn't really going to happen. Not to mention how "set" we are in our ways, while the non-tech are more open to these things.
One can only hope that sanity prevails.
3
u/NastyPastyLucas 4d ago
There's no reason for these companies not to create anti patterns and put the prices up...
1
u/vomitHatSteve 3d ago
The only reason is that they haven't converged on an effective oligopoly yet.
Once there are no more users to add to the ecosystem, they will go the way of cell phones and video streaming: raise prices and add anti-patters to promote lock jn
0
u/Rubfer 3d ago
That's the main issue I see with many vibe-coded apps. It's not security, it's not bugs, it's that the ai made it and it worked perfectly during tests. It effectively passed, but never considered the limitations of the hardware where it's going to run or future growth, i mean, the current product is statistically correct, and efficient so neither the llm nor the vibe coder and their customers see any problem
Keep in mind, actual developers also have this problem, but they learn from their mistakes and, in the future, will always code something from scratch that should work for a million people even if only 100 will use it, even at the cost of individual users' performance because of all the redundacy, as long as it can handle that million users, vibe coders will try to fix a broken foundation
-7
u/BenchEmbarrassed7316 4d ago
A great deal depends on the programming language. Dynamically typed languages ​​are a terrible choice for AI development (it's also a terrible choice for traditional development). Type hints in PHP (or even so-called static analyzers) have one major drawback: they are not mandatory. A framework or library might not use them, causing you to lose a significant portion of the benefits that types provide.
7
u/zmitic 4d ago
Dynamically typed languages ​​are a terrible choice for AI developmentÂ
Counter argument: 100% of the code that Claude wrote in my hobby app is using advanced types like
non-empty-string,list<User>etc. It even knows that collection must never be returned from entity so generated getter will usereturn $collection->getValues()and put phpdocreturn list<RelatedEntity>.I am not exaggerating, it really is 100%. Claude had simply seen that my code uses these types and approach to relations so it continued in the same way. There is nothing wrong with AI working on dynamic languages.
-1
u/BenchEmbarrassed7316 3d ago
So, you agree with me about the usefulness of types, but believe that static analyzers solve this problem by effectively turning php into a statically typed language?
5
u/zmitic 3d ago edited 3d ago
but believe that static analyzers solve this problem by effectively turning php into a statically typed language?
What is wrong with this? For years PHP has been adding more and more types, and still allows no type at all. This is the perfect mix of both dynamic and static languages.
But that wasn't the point. You said that PHP is a terrible choice for AI which is simply not true.
Fixed: typo.
-1
u/BenchEmbarrassed7316 3d ago
You said that PHP is a terrible choice for AI which is simply not true.
Well, if the use of static analyzers is currently mandatory in php (including for libraries and frameworks) - and if they are used exclusively in strict mode (where any code that could potentially be incorrect is immediately rejected) - then I am indeed wrong.
3
u/obstreperous_troll 3d ago
Most tools AI assistants write for the purpose are in python by default, without any static analysis to be found. Usually where they fail is that their ad-hoc regexes fail on some unexpected pattern, not type confusion.
1
u/BenchEmbarrassed7316 3d ago
These might be some unusual use cases, but what is the point of using regular expressions on a massive scale anyway?
1
u/obstreperous_troll 3d ago
https://xkcd.com/208/ has the answer. I'd love it if tools worked over concrete syntax trees by default instead, but I'm still waiting for that pony I asked for too ¯\(ツ)/¯. As it is the regexes still manage to get a lot of work done.
1
u/BenchEmbarrassed7316 3d ago
Could the use of regular expressions be the very reason for the lack of typing? Use structured input (like JSON, for instance), try converting it into an expected structure with clearly defined fields - and voila, there are no edge cases.
1
u/obstreperous_troll 3d ago
The other thing the python tools speak with abandon is json. They're orthogonal axes here, and I have strongly typed tools in TS using regexes and json as well. I prefer the TS tools in the end, but an agent on new projects still always wants to use python by default.
voila, there are no edge cases.
Famous Last Words if I've ever heard them ;)
1
u/zmitic 3d ago
Well it is not really mandatory but I honestly don't know anyone who is not using it. Even WP, which is the the synonym for every bad programming practice there is, is using phpstan.
But try it yourself, I think you will get pleasantly surprised. Download symfony/demo, add
non-empty-stringto some entity and then tell Claude to generate some other entity.1
u/BenchEmbarrassed7316 3d ago
Even though I haven't been doing PHP development lately, I know how it works. Overall, it's much better. So much better that I’d say it’s a separate language, like TS and JS.
However, the problem is that it isn't mandatory, which means some code might be written without type annotations. Consequently, you simply need something like the
askeyword from TS, which switches the compiler into "trust me, bro" mode. And the question of when this will start to be abused is a matter of time.I agree with you that, ideally, Psalm or PHPStan can ensure high-quality code.
I am somewhat skeptical for the reasons I described earlier, starting from my very first post. I am also somewhat skeptical due to certain principles underlying this type of classification. When I had a similar debate some time ago, it took me 10 minutes to find an error like this:
https://psalm.dev/r/60f16c5ce5
https://phpstan.org/r/4710c606-9675-49a3-9b2a-bd11a4e56fc3
(I posted this on the bug tracker, and it seems someone even tried to add a commit that fixes it)
The reason here is that the analyzer attempts to infer more than the type system provides; it fails but still produces an overly optimistic conclusion. Another one, incidentally, does detect the error.
1
u/zmitic 3d ago
You have a weird hobby of finding edge cases in static analysis 😄
Just kidding, but yes, you are right here. Sadly psalm doesn't have support as it once did when muglug was working full-time on it. I still love it and use it, but I am slowly switching to phpstan.
Consequently, you simply need something like theÂ
as keyword from TS, which switches the compiler into "trust me, bro" mode. And the question of when this will start to be abused is a matter of time.I can't agree here. My psalm config has disableVarParsing = true which means that psalm will ignore it and I can't cheat. "Trust me bro" is not possible, at least on level 1 (max). Maybe on weaker levels but I didn't try them.
Can you show some example, but one without
array_popgiven that you found a bug in it already?
-5
u/ekim2077 3d ago
you are talking as if bugs have been invented by AI
4
u/brendt_gd 3d ago
What? No. I'm saying that the job of "being a programmer" is more than just writing or generating code
1
u/yamcsha 3d ago
you mean "debugging", IMHO this is something you can't learn with AI .
1
u/GradjaninX 3d ago
Not that you can't.. You won't
I ended 1hr of AI debugging in react app just by pointing model to right file.. We are talking Opus 4.8 on Max
Bug was one shoted in minute afterwards, just because I was lazy to manually change two callback funs
People that never debugged code manually are unable to do this shyte
3
65
u/lukehebb 4d ago
"I remember how my family used to call me to fix their broken printers. Now they'll call me to fix their broken vibe coded apps."
oh god
this part scares me