alt Hacker NewsCoding Is Not Solved
Comments
What I've found is that AI allows lazy and incompetent developers to be more lazy and more incompetent. This then has the effect that product quality suffers more, faster. As a result of the sheer amount of code now being pushed out, code reviews, a thing that previously somewhat prevented lazy and incompetent developers from pushing out horrible code, is effectively dead in the water since no human can actually review such amounts of code realistically anymore. Some companies have adopted AI to review code, which, well ... you have AI make code, AI review code ... I hope you can see the stupidity here if you expect to see any deterministic results at all.
I guess time will tell if the consumer will adapt to the lower quality of products, allowing companies to justify the existence of lazy and incompetent developers, or if the consumer will push back, forcing companies to increase the quality of their developers.
Note: I use AI every day and it is entirely possible to create high quality software with it, so long as you are not lazy and incompetent.
I read such articles more or less every day. This article would be 100% correct if it came out 1 year ago, 75% correct 9 months ago, 50% correct 3 months ago and it's probably 25% correct now if not less.
I totally understand where this is coming from. I too am struggling with accepting that my 30+ years of programming experience is quickly becoming obsolete. I'm losing sleep about this, it's tough.
But just go ahead and give the latest models (Opus 5.5 / Astra 6 as of today) another try. See what they are capable of and read the code which they produce. Any problem area, low level C++ or high level Typescript or Clojure or a weird combination of these..
Don't be shy, give them a big task, let them build an entire app, UI and all..
Now compare the output to Opus 4 or gpt-5 from 1 year ago - when they couldn't put together a single function without it being weird and buggy.
This is exactly my problem, not that the models are very good already, but how fast they got so good. So if coding is not solved yet, it'll get there very soon.
I think the author underestimates how boring and simple 90% of enterprise software is. The part that isn’t powering aircraft and power plants. So much of it originates from one-nighters, badly managed subcontractors, and requirements that are of low quality to begin with (because they are written by people who have very different day jobs). And you know what? Most of that runs 24/7 without a glitch. LLMs just gives us more of that. And maybe it’s even better
I have been programming for about 30 years (including school years). Professionally for 18 years.
Can anyone tell me why we have 40 or more programming languages, with about 10 popular ones? Then about 20 frameworks in each of them. And add another 200 popular libraries for each language? This matrix make no sense till you realize - it is preferences all the way down.
Most of us engineers have built our own mental model of programming. We are all right. But the users do not care. LLMs are here to produce code closer and closer to the metal as needed. They can sit and create a graph out of every spec, use an AST that they develop and run on the CPU if they have to. They will do it. No amount of us discussing will stop that.
Programming is going to be re-invented. I do not think the current ways to write software will even matter.
> You cannot be responsible for what you can’t control either. That understanding is key to reasoning about system behavior and fixing it when the AI inevitably fails.
This is not a good premise. All over law, you will find people made responsible for what they don't control and they kind of own. Unleash a dog that harms a child, or just have it in an environment where it can escape, and see what happens.
There is such things as unpredictable situations where one might not be held responsible, as a problem might occur well past reasonable guidelines.
So of course you can be held accountable for what an AI that uou supposedly cannot quite control does, or for the AI-written code you deliver. Treat it like the releasing a wolf pack, or selling an unsafe toy that can maim children. There's precedent everywhere.
From the authors of "coding is solved": Today, a colleague trying to run Claude Code ran into an issue where it shows the Bun help menu instead [1]. Previously, Claude Code uninstalled itself several times when I used it. [2]
Those who claim LLM-generated software is good enough:
Haven’t written code in ages
Cannot spot if their code figuratively had 6 fingers!
Have a low bar for what good looks like
Don’t care about quality or NFR
Have difficulty understanding an S-curve
My thoughts on this:
- Coding in the small is solved. I have a current state, I want to change it, and I know how I want to change it. Eg, I have a blocking TCP handler for some reason, and I want to make it async. I can either fiddle with it or just let LLM make the changes for me.
- Coding in the larger sense is never solved. You need judgement to decide what you want made. No matter what you're building, there will be decisions to make (Who/what is it for?) and those decisions change over time. LLMs can take some default decisions for you, and if you're fine with those, you get the default (great for POCs). However you might not even realize what it decided to do for you. At some scale, you will be spending a lot of time going over those decisions. But what we have now is that the friction of changing the decisions is quite a lot lower. You can now test a lot of things that previously were very time consuming.
- The point that LLMs are probabilistic is not as important as it's made out to be. If I ask a junior dev to code up something, I also don't know what he'll make. Heck, you can be sure that you are able to solve something, yet you yourself don't know what the solution will look like. Maybe it turns out the library you were going to use isn't appropriate after all. You don't know what you will use in the end, but you do know that something will fix the issue. There can be more than one solution to a problem, and it doesn't always matter which one you find.
- I STILL think that LLMs are at their best mostly as advanced predictive text. In the sense that it's mostly good at implementing things that you've decided are needed. This can mean a heck of a lot of code, but you have to know the tradeoffs. What was decided, what were the costs of those decisions in terms of maintainability, money, time to change it, and so on.
Reading the article, I definitely agreed with the author, but I also found myself agreeing with the counter arguments in the comments. What I find conflicting personally about AI coding practices, is that I completely agree that AI is incredibly impressive at completing even complicated tasks, and I can at the very least say it is much much better than I am at writing code.
My issue with it, is that it gives you a "lazy" option every time that doesn't require the same level of thinking. I understand that this is completely on me as the developer, and the simple solution is that I need to make sure I'm taking my time to learn and understand what exactly the LLM is producing. I try this and have set up separate skills to make sure I'm building my understanding as I go.
Regardless, if I sit down today and implement something without the use of LLM, it takes me a lot longer, but once I get into it, I find a state of flow that I can never get from the back and forth reading of LLM output. Then when I finish, even if my solution is not perfect, I have learned so much more and my own context of problem is so much better, where usually then I can review with an LLM. This usually leaves me with a better implementation and more importantly one I can stand over. I think for a newer dev like me (~2 years experience), since I haven't built up years and years of problem solving experience, if I don't carve out time in my day to put down the AI tools and improve on my problem solving, I'll plateau and that's my biggest push against all this LLM use. I don't necessarily disagree that 'coding is solved', to be honest, I think it largely is, but it's still the foundation for me to be a good Software Engineer and I definitely haven't solved it.
The process of writing code is the process of clarifying your own thought and being forced to answer questions that may not have been obvious before. To the extent that AI makes assumptions, it introduces bugs and incorrect code, maybe not from the perspective of the code in isolation, but from the broader context it lives in. To the extent it doesn't make assumptions and asks you, well that assumes it knows what should and shouldn't be assumed and that's not necessarily something AI can know a priori.
"Coding is solved" will eternally remain 6 mo away, as long as the investors keep pumping in money.
'Software' is about understanding problems and designing solutions along those dimensions.
But 'coding' per sey is 100% solved by LLMs - they write compiler perfect code all the time.
The question is not 'what it writes'.
The LLM is like a writer's assistant, who has perfect prose and grammar, but doesn't really write 'stories'.
""The reason LLMs are successful in writing code is because we’ve made a feedback loop that feeds the syntax/runtime errors back to the LLM and loops until most errors are solved or hidden."""
No - LLMs are 'good at code' because they have been ultimately 'trained' by the compiler.
All of the various SFT/RLHF methods etc. are using the compiler as the verifier.
> AI cannot be held accountable.
And this unaccountability is transitive. The amount of time I've seen people successfully justify issues based on the fact that Claude/Astra/Codex wrote it is absurd. And it comes from the top.
We've had AI ship made up data to clients and tech leadership was like, "haha, that's AI for you."
> If you’re toying around, LLMs do a great job.
This too. We have a lot of business guys that develop tools with Claude that look like they work, then tech team gets pressure to deploy them immediately, because they assume that everything must be a prompt away. It's not (though, we do have some wizards on the team who make this true enough).
> AI overdose is a thing and it directly puts an expiration date on your skill set.
Agreed. But I'm not in a position to push back. It's not just managers, but tech leadership who are all in that on the fact that humans shouldn't program anymore. I still fully believe that I'm better than Claude / Astra in my specific domain, but people give me a hard time when my PRs contain what look to be human-generated code.
Overall, I agree with the article, but I'm still pretty sure I'm falling behind in my apprehension to fully trusting Claude/Astra and not giving into the approach of burning millions of tokens daily to generate PRs so large they break github (two of which I approved today).
GitHub Copilot is now written entirely in Rust, with AI agents doing most of the porting work. The migration cost about $120,000 in AI token usage plus about three weeks of a developer's time. The effort updated the runtime module-by-module until the job was completed, spanning over 135 releases across a 14.5-week time period. 430,000 lines of TypeScript were converted into 800,000 lines of Rust.
The author is right to categorise AI as a good programmer, but not a complete coder. We can all agree that programming has become really fast since the release of GPT-5 series and Opus models because they're pretty good. Not only this, they've also changed the pace expectations across teams where a feature that should ideally be delivered within weeks, should now take days.
All this doesn't change the fact that software engineers are going nowhere because nobody trusts AI. If a model can escape highly secured sandboxes, then we're definitely not running these agents overnight on our systems. I am sure the next-gen of models will focus more on security and the trust factor will start developing, but that's a long way down the road.
People trust people, not systems.
Articles like this keep measuring to a red herring standard that was never achievable in the first place.
As for accountability, it always laid with the employer. You think those nameless contractors whom Boeing hired suffered any consequences for that 737 Max glitch? Using AI won't change that.
AI doesn't have to solve all these coding problems to be worth handing the reins to it: it just has to substantially better on average than humans over the long haul, which it already is, especially if you have good verification of "done" and "working" in place through automated testing mechanisms. Perhaps we might say that QA is having its moment.
It doesn't mean humans aren't needed, but they aren't writing much if any code anymore.
Agree with the author.
I used to write code by hand, literally hand, I used vanilla vim with only syntax highlight and line number enabled, no more. So I know I can write code. I wrote C and Python most.
I used to vibe code, I am still vibe coding, multiple projects at same time. I use opus, astra, luna, deepseek v4.1 flash, I use claude code, codex, pi. I vibed a project to manage my coding agents' sub agents, skills, agents.md file. I definitely know how to vibe code.
The vibe coded project seem working fine.
(Declaration first: I don't advocate cryptocurrencies, I never liked them)
Until this week I vibed a crypto wallet, with many open source wallet code available for llm to train and learn, astra designed the project and wrote spec.md, luna implemented the project, astra and opus then reviewed and fixed issues, multiple rounds.
I feel confident. I import my private key.
I interact with a web3 app.
Error. A bug astra and opus missed. I didn't read the code, I vibed it, I don't know whether my money is lost.
At that time, when your money is at risk, you know you should have read the code yourself, you should know what happened to your money instead of asking a lllm to debug it for you.
> 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
Costs which largely go away if the software you're using is so custom that it's only applicable to your six person team anyhow. That wasn't feasible before, but it is now.
The previously fashionable one-size-fits-millions approach to software hasn't treated users well enough to expect them not to defect when they're suddenly able to go it alone. For many, the quality issues are worth tolerating, because they're still less painful than something which was designed to be sold rather than to be used.
> Most software that requires hiring and paying software engineers has low risk tolerance:
I think a few of the industries listed like defense and aviation have low risk tolerance. However, from my (somewhat brief) experience of working in two health techs for a couple of years, I strongly disagree that healthcare has low risk tolerance for tech. Granted, they make run-of-the-mill CRMs, but I was baffled at how tolerable it is to have egregious user experience that makes users waste multiple hours per month with clerical work that is very painful because the UIs are very slow and buggy.
Just responded to a different thread, but it’s the same comment:
I was just at the Explore DDD conference in Denver and a portion of Friday was sitting at the cafe tables informally discussing the impact of GenAI on software engineering with notable people. Most of these people were deeply concerned that if we lean into using GenAI for “everything” that our collective knowledge will dissipate. I was the vocal contrarian. There are many historical examples of humans obfuscating knowledge to simplify progress. Does anyone solder their own microchips at scale anymore? No. We have highly sophisticated robots and machinery to do that work with extraordinary outcomes. In software engineering, if you remove “coding” as a discipline you’re left with all the other aspects of designing software which I contend can be retargeted in college CS curriculum. The leap isn’t about code reviews. It’s about design reviews and that’s where better outcomes are served regardless of whether GenAI is involved or not. I have a roughly year old codebase at https://github.com/ChicagoDave/sharpee/ that is designed by me, but generated by Claude Code with my own skills and agents as guardrails. I’m fairly certain the code I extract from Claude doesn’t require human review, but the design of the system and its changes are continually reviewed by me. My contention is that we “collectively” are still trying to discern where the AI/human line is and most are still “holding” that line to human interactions. Let it go. Define what part you do need human decisions on and focus on those things.
I can’t get past the fact that in the post’s disclaimer, they ask the reader to “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.” That’s not the straw man fallacy, thus not “mapping to my belief system,” and I am caught in an infinite loop.
Disagree with the notion of taste in this article. Especially, since it mentions taste in the context of FE. Taste, funnily enough, of people with good taste, is extremely valuable. When reviewing very large diffs, the fastest, and therefore, the most valuable, approach is to take a glance and say "this doesn't look right, it should look like X".
Besides that, I agree that coding isn't solved. In fact, I think coding is the new "hard things are easy, easy things are hard". Models, yes the newest and most expensive ones included, have atrocious taste. They will work very hard to cover every edge case they can conceive, without realizing the solution is to simplify.
I will entertain the notion that models solved coding when they can implement that gcc alternative (https://www.anthropic.com/engineering/building-c-compiler) and actually produce a half-working compiler. They'll get extra points for not reusing the test suite. Even more points for models that have somehow not trained on gcc's codebase.
Finally, remember that a compiler is something of a best case scenario for models. They are, UB withstanding, pure transformations. The models can write millions of tests that will run in a reasonable time. Real-life systems are usually not as testable, and are a much harder challenge for LLMs.
It's very interesting. I'm very enthusiastic about AI and coding, But I find myself agreeing with the author. Coding is not solved.
Instead, I think what's closer to solved and what we're in the process of solving is product development.
Story: A while ago, I had a few programmers who were really, really fast almost always missed the mark on the assignment wrong. I loved having them on projects because in the time my senior precise engineers could deliver a MVP, the fast engineers would build the wrong thing, collect feedback, reiterate, build the wrong thing, collect feedback, eventually inching closer and closer to a product people would pay for, and it would almost always get delivered faster than my seniors.
I feel AI does the same thing.
I don’t think viewing LLMs as “stochastic” or “probabilistic” is the right viewpoint. It’s directionally correct but not the right level of abstraction. LLMs are able to isolate patterns, generalize them, and apply them to new facts. That is very similar to what humans do in performing knowledge work. To the extent that humans also use logic, LLMs are able to generate logical propositions using pattern generalization, then call out to tools that check the proposed logic. Again, that’s similar to what humans do when they formulate some idea, then analyze the idea rigorously.
“Most software that requires hiring and paying software engineers has low risk tolerance”
Is this true? I’ve worked in various software companies for over 20 years now and I’ve never had to worry about risk in particular, and the codebases were all somewhat bad in areas and buggy (as tends to happen when a codebase gets large and old).
The past 6 months LLMs have crossed into barely needing to check the output territory for what I work on, and generally write very similar code to what I was going to write. It needs some common sense to use it correctly of course, like going feature by feature and keeping the commits fairly small, but my job is easily 10x less work/time for the same results.
I’d be genuinely surprised if even 1% of software requires aviation levels of risk tolerance and testing, but maybe I’m mistaken and most people are working on much more mission critical things than I am?
Coding is solved, just as transportation is. We now take for granted that cars, airplanes, monorails exists, which made moving around much more easy. But even today, with all the innovations we still have to think, plan, optimize how to do things best. Even that optimization uses a lot of AI, but ultimately I'm in charge of what option to pick based on a lot of human factors.
So transportation is not solved either? In that case, beam me up Scotty, I can't see any hoverboards around.
I loosely know the person who wrote an article on Anthropic's blog about coding being solved. They've literally never been a software engineer.
I honestly have no idea how I feel about the capabilities of these models. The other day I asked Fable to write a fairly simple class that I had very well scoped in my mind. In my head, there was a very clear and obvious way to write it. So I only loosely described what the class should be, but not the details of the implementation assuming Claude would figure it out. And it's result was... so bad. Like laughably over-complicated. With a bit more back and forth I was able to cut hundreds of lines of code down to less than 100. On the one hand, Fable certainly made writing good code faster, on the other hand, I cannot imagine how much unchecked garbage is being dumped into every industrial codebase ~~maybe that was always the case, but that's neither here nor there~~
"Coding Is Solved" should occur to you as a classic Motte & Bailey style argument [0] that relies on ambiguity. Would you agree with the following?
"Software architecture is solved, there is no longer any need for human intervention in the architecture or design of any software, nor in any subsequent stage"
Well, that is what Dario et al would like you to believe. However, the argument they can actually defend is:
"Programmers no longer need to type the code out by hand in most cases, they can get the result they want with (several iterations of) higher level instruction."
What a farce. Too bad people eat it up!
But it's just a new baseline isn't it?
Now SWE job is to make sure to combine and instruct the AI tools to produce ever more complex outputs, judge the tradeoffs in these outputs, and guide the tools further.
In a way, it's not that different from pre-AI coding.
Anyone who claims AI is on the verge of achieving consciousness, going rogue, or about to end humanity -- has never tried to write software with LLMs.
Coding is not solved, but the author’s arguments are wrong (at least the first two: LLMs are unaccountable and LLMs are “stochastic and probabilistic”. We can hold the LLM’s promoter accountable and probabilistic doesn’t mean stupid. The author also gives examples of idiosyncratic LLM failures that have been fixed for months now).
Coding is not solved because you can’t simply prompt an LLM to make an AAA game or enterprise tool.
> AI cannot be held accountable. It cannot suffer any consequences. The worst thing you can do to AI is to unplug it. And although it mimics human emotions (due to training data), it couldn’t care less. AI doesn’t die either. It cannot suffer a prison sentence or fines. You cannot punish AI, therefore it can never be held accountable.
Dear lord. Is that supposed to reflect the average thoughts and motivation of a person you want to hire? Or that of their employer?
A few years ago i was working at a big corporation. Most of the guys used command line for git. Back then i was not familiar with the idea of git as i used to TFS. Then i learned about a UI tool (it has an octapus for logo) and never looked back. I could not understand why people chose to still use command line when there where other, newer, options. It seems to me now again that there are people resisting change. Resistance is futile. Yes by vibe coding you wil not get any better. But managers dont care about that. Businesses dont care about that. If you want to get better do it in your owntime, or leave the corporate job. It seems we always try to seek for endings. Coding is solved, all jobs will be run by robots etc etc. But life has no endindings, only new beginnings.
The problem with LLMs is that: popularity of an answer != correctness.
That concept might work a lot of the time but you will definitely run into situations where that'll never produce a correct or working response. To actually learn something you need an environment/playground to apply what you think you know and observe the results. Without that you're not really learning, you're jus regurgitating what people want to hear.
Not a fan of the article even though I somewhat agree with the title depending on your definition of coding.
AI can write CRUD API endpoints almost perfectly now. It can also write quicksort, a heap, whatever much quicker than I can.
It really sucks at designing types and apis though and when it creates types and apis it doesn't think or plan for the future way the system will evolve (even if it's known up front how the system will evolve).
I suspect this will remain a problem for the models for a long time. All the things that the models are currently good at are the low hanging fruit of reinforcement learning for coding.
Think about the kind of reinforcement learning environment that needs to be created to train a model to become good at building and designing large scale software end to end. It would be a slog because you need to build the large scale software up front and then break it down to train the model to construct it in a systematic manner that allows for the software to evolve. And then you need enough of these training environments for it to generalize. I think they will eventually figure it out though but it may take a while.
> LLMs are stochastic and probabilistic
So are humans. Every codebase I've worked on has duplicated code that has been written in slightly different (but hopefully equivalent) ways, often by the same person.
This promotional article explains only why you should buy “expertise” from Alex and why it isn’t cheap. At the same time, he tries to play on people’s fears without using facts—because, as you can see from the article itself, the facts suggest the opposite—but he repeatedly says, “I don’t care.” No, he does care—after all, development is inexpensive, and his knowledge is already outdated.
> maintenance, reliability, security, scalability, etc. is the majority of the cost
It's funny because, I think the author is spot on in this article, including the problems identified in my quote above, but none of those are the reason I personally dislike the rise of LLM code - for me it all comes back to licensing and attribution. Everything else is just a cherry on top of the diarrhea sundae. I certainly don't want unmaintainable, unreliable, insecure code, but even some of the best software occasionally falls victim to these traits (its simply intrinsic to LLM code).
I think the idea is that nobody will need to understand the code or plan an implementation. The AI will do that. Now, whether that is a good idea is debatable, personally I think we should not make all software engineering depend on just a few AI companies. Oh, and nobody will notice that nobody has an understanding of what is built, as all those management positions will sooner or later also be filled by AI.
What a nice article. If I ever get in a situation where my manager demands I have to go all-in on AI (run 10 parallel agents and lose my sanity while trying to follow what is going on), I'll ask them to read this article first.
Additionally, isn't it ironic that the only comment on Substack is: > "Sometimes in the process of writing a good enough prompt for ChatGPT, I end up solving my own problem, without even needing to submit it". AI as a rubber ducky, I think this is good AI use!
Author here: thanks whoever shared this here. I love the brutal criticism and critical thinking of this community. I'm also fully aware of the emotions this stirs. If it makes you feel better, I'm not here to change anyone's workflow but I'm fed up with paying full price for degrading service. Just last week Github went down due to a stupid retrial error. We also had AI agents going rogue and hacking companies and governments. I use AI (specifically LLMs) every day since they came out 4 years ago. I also build AI-powered products. This is not about being anti-AI. I'm just fed up with slop being pushed as progress. Get your sh*t together. That's all.
If anyone has counter-arguments or cares to make me smarter, I'm all ears.
Using examples of counting Rs in strawberry or the car wash query does not make the author's point stronger. Just try these on any of the LLMs today.
> Anthropic accidentally leaked Claude Code (which on further study turned out to have many flaws) and their status page shows orange is the new green!
Yes, of course, because Claude Code with all these bugs could never be a successful piece of software that makes money.
> You have zero tolerance for disagreement and civil discourse
A bit hypocritical there, no?
Considering what the author says about people who believe AI produces code that is good enough.
And in my view it clearly does, particularly when you care to iterate in order to iron out issues you find in manual testing.
Just stop supporting this narrative if you don't want to participate in it.
When it comes pro-AI the goals are mostly clear.
But when engineers who can and choose to skip the hype write at length the obvious, what's the goal?
If anyone claims that coding is solved or not solved with such conviction, I expect some hard data, like comparing the density of bugs in human written vs. AI code, and how it trends over time. This article is just vibes.
"Don't confuse coding with software engineering" is a valid point, the rest seems like ranting.
Reading this article its just clear the author hasn't used the current generation for real work.
> LLMs can wing it for tasks that are related to natural language (e.g. writing social media posts, reports, articles, etc.) but when it comes to code, the same engine that struggles to count number of R’s in “Raspberry” or suggests a walk to the carwash, also exposes other logical fallacies
Weirdly none of those things matter when writing code and actually LLMs fail at social media posts and articles to anyone who has seen enough of it can clock it's AI straight away, yet everyone who's used these models properly has solved harder problems than walk to the carwash with them, neither of the problems he's claiming are code were proposed as code problems or tested as code problems.
A lot of what's said just comes across as wishful thinking and being out of touch with the level of output current models can do, and I mean hard problems too.
AI is a better intelligence collection and analysis system, they need any information when you are using AI tools.
They are thinking: Please input everything you know, or just use it and it will collect everything in your PC or server automatically.
Stop lazy, stupid and dangerous behaviors.
Reading the code does not mean you understand the code. One lesson that experience in software gave me: I never understood the code. You think it works a certain way, until you find out that it doesn't.
What LLMs make possible is for me to say: find out all the ways this thing works. Analyze the different ways we can run this software, build a fuzzer, build property tests, and run this software in every scenario possible. Log full traces. Log all the outputs. Now, analyze each scenario for bugs. You can't do that by hand.
If we are committed to it, if we put the resources towards it and dedicate the time to it (and we could do this just by saying: it will take half as long as it used to take!), software built by llms in healthcare, finance, automotive, defense, power plans, aviation, manufacturing can all be made MORE reliable and better with LLMs... without ever reading a single line of code. The LLMS are very good at logic, by the way.
Anyway all of this reads like someone who is not actually using LLMs to build software or hasn't tried them in a while. I felt the same way in 2025. I've written 100s of thousands of lines of difficult code. You, the person reading this, has probably interacted with software I've written. For a time you would've interacted with it every time you made a debit card transaction in the united states, for example. I understand code, and care about quality, and that's why I'm all in on LLMs for code.