// HACKER NEWS — CYBERSECURITY
Coding Is Not Solved
Disclaimer: you are about to read a lot of opinions, many of them have references but some are the result of my own experience building with AI and building AI systems in the past 4 years. Regardless, beware of the straw-man fallacy: just because one argument doesn’t map to your belief system, it doesn’t mean the rest are invalid. I should also say upfront that I’m not anti-AI. If you’ve been following my work, you know that I was an early adopter of not only using LLM-powered coding tools, but building my own harness, teaching these topics and building LLM-powered products. It’s not about fear of AI but rather challenging the brain-dead narrative that asserts “coding is solved” and engineering is about “taste” now.
Tell me you don’t understand software without literally using those words!!!
People who claim “LLMs can write decent code” don’t understand how code works. Sure, creation is much cheaper, but anyone who has run software in production at scale knows that maintenance, reliability, security, scalability, etc. is the majority of the cost. These are commonly known as NFR (non-functional requirements).
In my experience even the Functional Requirements (what the code is supposed to do) is NOT a solved problem yet. There’s a bit of Dunning-Kruger effect at place where the people who don’t read the output are more confident in it.
As a veteran developer holding 2 engineering degrees (hardware and systems engineering), I can list 3 types of products that do not strictly require reading the code:
Personal software: scratching an itch, automation, DIY patches, etc.
POC (proof of concept): demonstrating technical feasibility and product viability
Weaponized AI: acknowledge the risk and deliberately point it at a target to cause harm
Notice the commonality: the first 2 have high risk tolerance while the last one weaponizes the inherent risk.
Most software that requires hiring and paying software engineers has low risk tolerance: