I can only imagine that people who say things like:
> If you use AI for anything else, and in particularly if you use it to generate code, you're wasting your time.
Have not used frontier models in at least a year.
It is nearly inconceivable to me that I would ever go back to writing code by hand, in any context. Even if no new model was ever released, the combination of GLM 5.2 and DeepSeek V4 flash is more than sufficient to do real work. It's not hard to imagine that a distillation of Mythos/5.6S or whatever is a couple generations away will push me even further in this direction.
Do you not enjoy coding? I'm not trying to be snarky, just a genuine question. People used to enjoy it but lately all I see are people talking about they "no longer have to do it"
I see both sides of the argument people endless have over this. I have been hesitant to take a solid position, first because I suck at coding and second because I dont really have a dog in this fight.
The only context I have is my friend in HVAC from many years ago that went to a school that taught everything manually because they wanted people to have a deep understanding of it. What happens to code in the future when people don't have a deep understanding?
I enjoy getting into the zone while listening to synthwave and banging out code. But I'm not going to ignore that I can code most programs 100x as fast using claude code. I don't enjoy coding so much that I will spend 8 hours getting a side project together when I could get more done in 30 minutes with AI.
I personally love coding! unfortunately for me the agents are much faster at it and often more correct, especially after iteration. Guiding AI is more efficient currently.
Speaking only for myself, I _love_ coding. But I haven't done refactoring by applying a needle (with a steady hand) to a roll of magnetic tape in _YEARS_ /snark.
I love monkey-patching some python or js. But never have I ever suggested that anyone would should do it. Writing everything in Haskell sounds lovely but I wouldn't advise that either.
I honestly don't care what language I'm writing in. LLMs bring us back to the smalltalk days: your code is data and your data is code. LLMs bring a translation layer so that even if you're writing some high-level language, some DSL that exists only on some 1-off platform that no one else is aware of, _everybody_ has access to a self-bootstrapping codebase.
I feel more empowered to _code_ than ever: now, every single input carries semantic weight that gets carried through the "compiler." Every claim of determinism can much more easily be fuzz-tested and made more robust. "'sup, this broke, fix yo" and "Would you be so kind as to fix this error?" contain semantic context that actually affects the output of the generated code. That restores empowerment around code _authorship_ while still preserving the guarantees we want from the published artifact.
"Deep understanding" doesn't disappear when you gain the ability to be more expressive. "Deep understanding" disappears when people become incurious.
ok but a lot of coding used to be fighting package managers, discovering bugs in dependencies, dealing with deploy baloney, etc, not just "solving puzzles" or "architecting the backend"
Yeah the rose colored glasses some people seem to have about how fun doing everything by hand was in the past and how well most people did those things continues to astonish me
There are certain things I enjoy coding by hand, in exactly the same way I like using a manual coffee grinder. Coding can be enjoyable.
But most of the time coding is a means to an end. I bet your friend in HVAC was not told to use a manual drill to have a deeper understanding of how to make holes for installation. AI is simply a power tool.
People have said this about virtually every new writing technology, from pencils to typewriters, from computers to spell-check.
Personally I would never use AI for writing, but it's absolutely a power tool for coding. I still need to think about what needs to be generated, and why. For now, I still need to guide the model based on my experience. And in the end, I'm on the hook to approve what's created. If anything, I have more time to think about what I'm making, because I'm not busy building the CRUD for a web app for the 100th time.
I enjoy building things. I do not enjoy the act typing out code by hand.
> Do you not enjoy coding? I'm not trying to be snarky, just a genuine question
To follow this debate through, to maximize coding enjoyment, shouldn't we be avoiding compilers? They take away a lot of the code we need to write. Frameworks as well?
I don't think the joy of coding comes simply from writing lots of code. It's the act of precisely expressing one's internal thoughts into an physical medium, and watching it take effect. Using AI as an intermediary makes it less enjoyable. It's like a painter telling his speedy assistant what he wants to paint, and reviewing every attempt until it looks like what he was aiming for. Obviously the painter won't find that as fulfilling and meaningful. And a skilled painter probably won't be quite as happy as if they'd done it personally. The act of painting is a primary driver, not just having a finished painting at the end.
High level languages are analogous to airbrushes or paint rollers, not assistants. They let you paint faster, at the cost of making some things impossible that you would be able to do with a fine paintbrush. Unlike the assistant/LLM, they do not make artistic decisions for you, and their behavior is predictable.
Idk, when you have nothing to prove just let the assistant do it. As the painter I can give direction then take a nap since I'm not getting any younger.
Compilers don't take away the code we need to write; they translate it into a different formal language that emphasizes and de-emphasizes various aspects of its meaning.
LLMs are categorically a different thing. Instead of soundly translating between formal languages, they adjust how you interact with the formal language.
The enjoyment people get from coding has absolutely nothing to do with the pure volume of code they produce, to the point that this has long been a cliche!
> LLMs are categorically a different thing. Instead of soundly translating between formal languages, they adjust how you interact with the formal language.
Yeah, equating LLMs with compilers is sloppy thinking (though, I'm sure some sloppy thinkers will defend to death). It's an over-eager pattern match, not everything that takes input and produces output is the same kind of thing.
I bet in our new AI utopia, we'll get more sloppy thinking. All kinds of people will be talking about how they used to think, but now they "no longer have to do it."
Thanks for the honesty and I think I get it. The AI doing the code leap frogs you to a finished product which is the reward. I do worry about craftmanship in that scenario though.
The finished product alone does not have to be the reward. The reward can still be building a great tool, a great application, etc. With AI we can build it 100x faster, freeing us up to think deeper about our test coverage, our design, our scaling, our observability.
There is no excuse for lazy execution using AI, that is, IMO, equivalent to shoddy software engineering. it's just faster and more accessible now. "AI slop" is just poor execution delivered more quickly.
The onus is still on the human in the drivers seat to deliver quality outcomes.
How can building an application feel like a reward when you're not the one who built it?
And before you post the obvious response, no, if you're truly "100x faster", you're not reading or even thinking about anything the AI is outputting. The time math doesn't add up.
You seem to have a narrow definition of "build it". LLMs don't have agency. If I build software using an LLM I built it. Just like if I build a house out of lumber from a lumber mill, I built it even though I didn't hand carve the 2x4s.
Now, what if you order a construction crew for building your house? What if you also hire an architect to design the plan? And an overseer who manages everything?
Surely at some point you would stop saying "I built this house", even if you ordered and financed it?
I love coding and I always have - arguably moreso now, if you can still call it coding.
For me, it is not about the syntax nor the mechanics of typing though. My enjoyment comes from thinking about problems and breaking them down, or thinking about what architecture would best serve them. I guess I'm meant to be a systems design guy, so I'm lucky that AI-coding fits this well (AI models have limited context windows, relative to the size of codebases, so doing the big picture thinking is still important, and fun for me).
Yes - I think that's fair. I'm happy to concede the term coding - I still enjoy the process of telling my computer to build something I've envisioned. It's now much faster, and I get to do more of the big-picture thinking and ideation, which I thoroughly enjoy.
> The only context I have is my friend in HVAC from many years ago that went to a school that taught everything manually because they wanted people to have a deep understanding of it. What happens to code in the future when people don't have a deep understanding?
What happen is that their boss gets a 3 page email screed with pictures of how they fucked up the thermostat wiring in trying to gerry-rig a new heat pump/air handler that supports only electric resistance backup heat into my house which has an oil boiler for backup. And I get shit from my wife about why our $10k new heat pump is blowing cold air on her during defrost cycles.
I don’t know but to me it seems a bunch of people should learn proper typing. There is no way in world that AI is faster in solving/writing problems than you are when you can maneuver your idea/vim properly and have proper domain knowledge and mental model of your codebase. I think it’s genuinely 10x as fast. Just on execution and then if you write it you keep mental model, decide details and you don’t lose context.
Like honestly I’m losing my mind, when people claim I haven’t written code in a year. You had the wrong job your whole life and whilst you think you are so frontier now by using agenst your market value is actually decreasing.
Imagine a painter saying, I’m so happy I don’t have to paint anymore.
Or a tennis player. I’m so happay that I don’t have to play tennis anymore.
Obviously I'm just one guy, but I maintain what I said w/ typing happily at 120+wpm. I think I could break 150 if I switched to colemak or dvorak, which I've been considering.
I don't think my job was ever to type fast, nor do I make any claim that I'm ontologically better than someone writing code by hand - but for what I need to do, I'm way faster now.
You might think he's an AI shill, but I was pretty compelled by simonw's post and idea - "your job is to deliver code that works" [1]. I think I can deliver more code that I can prove to work, faster now. The productivity is nice, but as I've said on other parts of the thread, it's also just fun to spend more time thinking, less time hitting the semicolon on my keyboard?
Coding for other people is like playing tennis for other people. You're signed as a tennis player to win. If a robot could play for you and win more games for you, you might consider using it. Now, I'm not saying AI tools let you "win," but I am saying a lot of people don't code "for the love of the game;" they code to keep the lights on.
Also the jury's out on if they're losing market value. We have yet to see which way the wind blows, but I personally think the genie might be out of the bottle on this one.
Full disclosure: I'm personally working up the courage to quit, take a fat paycut (maybe) and do something bucholic with the rest of my working life. I don't find much enjoyment in the tech landscape anymore (I'm 37).
Sorry but you are just wrong. Perhaps if you are working on tiny problems in very small projects. Beyond that AI is simply many times faster regardless of how fast you type.
Really if you think about it AI will know everything and you can quickly get the answer for whatever right from inside your smart glasses.
We all become knowledge experts especially when the data we see inside our glasses is always 100% correct. This could take Years but that's where we are heading and Im sure no one now likes the sound of it.
How are you verifying all the code that's generated? Do you think that verifying properly would take you as much effort as the original implementation would've?
Sometimes, I will review every line, test the front-end in a staging environment, verify the backend contract, et cetera. Over time, though, I realized that many of these reviews just didn't result in any necessary changes. The current model (with guidance/claude.md/etc) was able to one-shot the task.
Not to overly personify, but imagine how you might treat a junior colleague. You start by reviewing everything they do with a microscope, later you review the broad-strokes, and eventually, for low-stakes or well-scoped tasks, you just play with the demo and the ticket and approve it.
Otherwise it's not materially different than a pre-AI world - you've got sample I/O, test cases, hand-review, look at the application on different screen sizes, contrive some edge cases, test against a spec if there is one - et cetera.
I think this is the real problem. I am sympathetic towards automated code synthesis.
But without formal verification and a human reviewing specifications to ensure alignment, I think code will end up being broken in unexpected ways or drift away from the original intent.
The same way that I verified all of the code that was written before AI. Just because you hand type the code doesn't mean that you don't have to test and verify. I can test much more thoroughly with AI that without.
I still think internal tools are kind of in a category closer to end-user applications. They are limited in how widely they are used, and therefore they don't have to be as solid as say libraries used by millions.
I ask because I think there's a huge difference between the two.
People making end-user applications might think they can tolerate more errors and bloat from AI.
Just because they can get away with doing that with AI (and that's debatable) does not mean that people can also get away with that in developing tools, libraries, languages etc. The errors, bloat and instability bubbles up exponentially as people build on it.
There seems to be this fallacy of "I don't have to write code anymore, therefore nobody will have to write code anymore."
Generally end-user applications, depending on how you classify internal tools. I'm generally very happy with the output of Opus 4.X with a moderately structured CLAUDE.md and some investment in detection/avoidance of anti-patterns (Next.js+ts). I imagine that the bitter lesson is true here, and these heuristic guidelines will become increasingly unnecessary w/ smarter models.
Library-type work has mostly been side/toy projects, although fwiw, with a standard/spec on hand (CommonMark for example), I'm also happy w/ the output. It's often possible to "close the loop" and have the coding agent autonomously iterate until the standard is adhered to.
Thanks for the answer. From what I can see, most people who are enthusiastic and optimistic about AI use are producing end-user apps, internal tools (limited use) or just hobby libraries. The fuzziness may be tolerable on the edges of immediate use.
Creating something that is solid enough for widespread, reliable building is just in another category. And I wish people recognized this distinction more when they say we don't need to look at code anymore.
Judging by parent's CV, it kind of looks like they are relatively new to the industry and working in areas where they are heavy on the greenfield side of the equation. I get the sense that they've probably had some good success on smallish projects where they are in charge of keeping it all in their head. That's not to say that isn't earned or otherwise valuable experience, but it surely is not the way a lot of software projects are situated. Parent: I hope you won't take my comment here as a slight. I mean no offense, just pointing out what I think is probably valuable context.
Yes - this is certainly true. I would have to concede that I could not speak to how my thesis would map onto a truly colossal codebase.
That said - I would (again, maybe naively) suppose it's not hugely different - much of the work I do occurs in code where many people have and will work on it, and where the size of the codebase dwarfs model context windows.
In that case, I feel the same - current frontier models, when properly oriented to a task, with some assist on the big-picture thinking - are more than capable of generating good code that can slot into big codebases with many moving pieces. Of course, I'd have to point to other people's work to defend this, but I think that's still pretty reasonable especially against the declared "LLMs are worse than useless for generating code".
> Recently, there's a lot of talk about AI allegedly finding security flaws in software. That is an unsubstantiated claim. As such, it would need to be verified by a non-machine, and arguably, the verification process would require the same amount of effort or more than would be required to find the issue to begin with.
This is simply not true. Security flaws are a great use-case for AI specifically because they're easy to verify. If you can drive a program to segfault based on inputs, you've got a good indicator it is, in fact, a security vulnerability (at minimum a DoS, but usually you find out later it was exploitable). You could even have the AI generate an exploit PoC. Shell? Valid hole. Done.
The bad use cases for AI are the ones where it's as or more expensive to verify correctness as it would have been to find the solution in advance.
> Recently, there's a lot of talk about AI allegedly finding security flaws in software. That is an unsubstantiated claim. As such, it would need to be verified by a non-machine, and arguably, the verification process would require the same amount of effort or more than would be required to find the issue to begin with.
Once a security issue is found, it is often far less effort to verify it. Digging through millions of lines of codes to find high-probability vulnerabilities is the hard part.
Right at the outset it opines that AI finding vulnerabilities ("allegedly") is useless because people have to verify those vulnerabilities, which is such a logically braindead bit of nonsense that I knew it was going to be worthless, and somehow it got even worse with every subsequent paragraph.
I get that there are people who are scared, and the change is coming fast and hard and there is a lot of doom and concerns, but good god do people think authoring or upvoting shit like the submitted nonsense is going to stem the tide or change the path? Pathetic.
I don't really agree with this. I was VERY skeptical about AI, but then I started using frontier models everyday, and my feelings have changed dramatically. I use AI to refine designs. I use AI for "where are all the codepaths where we return an HTTP 499 error". I use AI to write code (in "manually accept edits" mode, and I am picky about every single diff) and the results are really good. Most of the time, exactly what I typed in. Doing stuff like "add this config and plumb it through the helm chart" is amazing. Editing Go templates that generate YAML is absolutely miserable, it is my least favorite task. Claude gets it right without fuss every time.
I have not stopped engineering software, but I type in less code. I still understand every line in our codebase and why it's there, but I spend a lot less time dealing with the mechanics. LLMs are super impressive for the software engineering work I do. I don't have a fleet of agents making 20 major changes to the codebase every day. I do about as much work with AI as I did before I used AI. But I think the quality has gone way up, and I am a stickler for pretty perfect code. Claude keeps me honest and reduces the cost of exploring alternate approaches, writing hairy tests, doing refactors, keeping docs up to date, keeping production stable and understandable, etc.
I basically do not agree with this article at all. Frontier models are like switching from dabbrev-mode to IntelliSense, something I was very resistant to at the time. "It's important that I know the APIs that I use everyday." Not really. Having your IDE remember whether it's HasPrefix(string, substring) or HasPrefix(substring, string) frees up my brain for something more important and I couldn't live without it. AI is the same way. It's a tool that makes me better at my work. Yes, it's expensive. That's the only downside I see. I am lucky that I can use as much Fable 5 as I want at work... I always feel bad when I share something that it did that was cool with someone who can't afford it. But costs will come down. I think this AI think is here to stay in the software engineering space. I don't think it removes the need for qualified software engineers at the controls. At least today.
Yeah. I would personally refuse to add Helm to a system but the complicating factors are 1) customers ask for it by name (why I relented at my last job where we made self-hosted k8s software) 2) people we hire know how to use it. So while I find it unpleasant from a computer science purity standpoint, it is pretty popular and gets the job done. I have to save my energy for things that matter and improve the experiences of the customers, not design the 900th way to deploy stuff to Kubernetes. So ... I am happy to let Claude double-check my {{ brace }} nesting or whatever. If something is Objectively Terrible but tooling smooths over it, I can let it live without a fight.
> The real question is, who can verify that what the AI built is good and true? Recently, there's a lot of talk about AI allegedly finding security flaws in software. That is an unsubstantiated claim. As such, it would need to be verified by a non-machine, and arguably, the verification process would require the same amount of effort or more than would be required to find the issue to begin with.
Came for the bad AI take, stayed for the P=NP claim.
Has the author used an LLM to brainstorm architecture, explore trade-offs, challenge assumptions, or refine a design? Models are not just 'a data distiller'. "How could I implement X feature in Y project?" requires systematic planning. The agentic paradigm is about balancing (expensive) human and (cheap) machine cognition. Frontier models chew through requirements and if you don't like what they come up with you can TALK to them about it.
I think a lot of people who write about AI haven't been regular old, run-of-the-mill software devs in a while.
For small companies, or large companies broken into small teams, I'm not really sure why there's this assumption that AI will "take care of all the trivial code." Someone has to transmute the project manager's wishes into working code, and it's never going to be the product manager. From that point of view, whether I'm cobbling the code together from Stack Overflow snippets or using AI to generate it, my job hasn't changed all that much.
I neither fear the reaper nor do I dismiss the impact GPTs have had on the industry. I just don't think small development teams' mandates have changed that much, apart from a somewhat faster pace of development (work expands to fill the vacuum, after all).
The idea that it only reveals missing abstractions and that this is bad, is pretty off the mark in a lot of ways.
First off, there's plenty of cases where it make no sense for me to spend all my time abstracting everything possible in my pipeline. Maybe I'm a game developer who doesn't want to spend all my time abstracting away all the initial scaffolding for game prototype and just make a dang game prototype.
Or maybe the abstraction would needs to much confirmation to not really be any different than code (again, games.)
Or maybe the LLM is indeed a perfectly good abstraction for such a task, reliable and customizable.
Just keep writing abstractions all the way up the chain until you're so abstracted that you take english input and can product whatever is asked for, and, oh right.
This article starts off by saying AI can be useful for question-answering, but then quickly states that if you're using AI to generate code "you're wasting your time:"
> The reason AI is a bad tool is that generally speaking, it is completely opaque.
The author is missing the fact that you can use those great question-answering and knowledge distillation capabilities to ask the AI questions about the code it wrote.
Later, they write:
> Who is going to verify that it is doing what it is supposed to?
What? If you hire a writer to write a blog post, who is going to verify that they didn't just fill in gibberish? It's you. You there, in the front. You're the one.
If you can't find any way to independently verify that the software is doing what you think it should do, I don't think you have any business generating it, whether you use AI or code it by hand. That's like commissioning a portrait of someone you've never seen.
Is this satire? That's my most charitable interpretation.
This smells like it was written by someone who doesn't actually write code. How does one make the logic leap that any code AI is able to write, is only because that code is "trivial"? The author doesn't even bother defending that claim.
I suppose the only other charitable interpretation would be to say, "Well then 99% of the code I'm paid to write is 'trivial'." If that's the case, then you have to separate "code as means to an end" (which is clearly well within the wheelhouse of AI) from "code as a mathematical art" which is okay, but the latter doesn't pay my bills or create value for my clients.
In this article you can learn that it takes the same amount of effort to verify if a security hole is real, as it takes to find it in the first place. (?)
I think this is correct. When I was coming up in software engineering, it was fairly accepted that the "bus factor" of a project should only increase. Any kind of vibe coding makes that bus factor exactly one... and if a service goes down, you're stuck.
I can prompt a fix or a new feature, have it coded in a couple of minutes, and I have enough domain knowledge to look at a diff and understand what's happening pretty quickly. It is ABSOLUTELY faster. And if Claude goes down, I could easily keep working.
I think most tools, according to the UNIX philosophy, do one thing (and do it well). AI is a tool that does _a lot_ of things...to various degrees of success. While you can verify that the output of `sed` or `grep` is valid, you can't with 10k lines of code you have no context on (without _significant_ effort).
Same with Gimp, Firefox, and your terminal. Tools, all, do many easily verifiable things. AI isn't verifiable without an existing framework, and that's why it's so "good" at rewriting code from language A to language B, but not at zero-to-one building real world software.
It is, I think. I published the article on BCN (the preface is me, the rest is a reader submission) and I find I agree with relatively little of the article, but I think it has observations worth looking at, even so.
Or the users?
At some point it either works or it doesn’t.
And I can use AI to write 100 api tests and run them in the pipeline on day 1 when that would probably be a year 2 project otherwise.
And I can document business decisions in plain english and the AI will read those and almost certainly honor them.
AI (in its current state) is phenomenal for research on just about any topic; you can dive deep and cross-reference the material more easily than ever.
AI (in its current state) is not so good at actually doing things; we're a long ways off from simply speaking software into existence.
we're a long ways off from simply speaking software into existence
I wanted a Chinese language tutor that uses a local LLM to generate sentences and evaluate my translations. I asked Claude to build that, and an hour later it was working pretty much exactly how I imagined it.
It's true that there's a lot more to shipping serious projects than getting the code to work, but you can absolutely speak software into existence today.
I get their point, but they are probably wrong. Not saying the AIs will not get better and better. They probably will, but I see a chance that there are smaller and smaller gains and the AIs cant make those gains happen.
But coding with llm's doesnt say its shoddy code per se. I view it as: We used to use hand saws to make cabinets. Then we had tracksaws. Then we had CNC saws...
You still need to understand woodworking to make a nice table in all these scenarios.
All those things (handsaws, tracksaws, CNC saws) are analogous to deterministic, clearly designed tools (assemblers, compilers, language servers). The jump to LLMs is a jump to a completely different category.
> Maybe being passionate about something you build, understanding it fully, owning it completely, and abstracting it properly
This is the actual job description. It doesn't matter whether AI is used for writing the literal code.
All that can really be said is that AI alone is inadequate for this job. None of this back and forth has ever really been about AI.
So, can we just cut the crap already and go back to the clarity we used to have on this? Bad leadership leads to bad outcomes. Bad leadership wants to use any tool at their disposal to micromanage and cut costs. Bad leadership is terrified of a younger and more capable workforce that will replace them. Bad leadership will do everything to deflect blame including calling you "out of touch" for not using AI enough or at all.
Not all workplaces are like this. I am actually glad AI has put a massive spotlight on these longstanding tensions.
Aging is happening faster than AI. It's far more likely there will be a time soon when all these software devs will no longer code because they're management (or burned out and changed careers). It's more important to start thinking about your integrity now before your lack of it gets you fired in the future anyway. I don't blame young people for being so naive, but this is a blindspot. Get a grip now.
Great article. Yes, often what's needed are better (rock-solid) abstractions that we can manipulate around quickly and confidently (think Abelson/Sussman SICP style), not a machine that can take good guesses at piles of spaghetti code.
I can only imagine that people who say things like:
> If you use AI for anything else, and in particularly if you use it to generate code, you're wasting your time.
Have not used frontier models in at least a year.
It is nearly inconceivable to me that I would ever go back to writing code by hand, in any context. Even if no new model was ever released, the combination of GLM 5.2 and DeepSeek V4 flash is more than sufficient to do real work. It's not hard to imagine that a distillation of Mythos/5.6S or whatever is a couple generations away will push me even further in this direction.
Do you not enjoy coding? I'm not trying to be snarky, just a genuine question. People used to enjoy it but lately all I see are people talking about they "no longer have to do it"
I see both sides of the argument people endless have over this. I have been hesitant to take a solid position, first because I suck at coding and second because I dont really have a dog in this fight.
The only context I have is my friend in HVAC from many years ago that went to a school that taught everything manually because they wanted people to have a deep understanding of it. What happens to code in the future when people don't have a deep understanding?
I enjoy getting into the zone while listening to synthwave and banging out code. But I'm not going to ignore that I can code most programs 100x as fast using claude code. I don't enjoy coding so much that I will spend 8 hours getting a side project together when I could get more done in 30 minutes with AI.
I personally love coding! unfortunately for me the agents are much faster at it and often more correct, especially after iteration. Guiding AI is more efficient currently.
Speaking only for myself, I _love_ coding. But I haven't done refactoring by applying a needle (with a steady hand) to a roll of magnetic tape in _YEARS_ /snark.
I love monkey-patching some python or js. But never have I ever suggested that anyone would should do it. Writing everything in Haskell sounds lovely but I wouldn't advise that either.
I honestly don't care what language I'm writing in. LLMs bring us back to the smalltalk days: your code is data and your data is code. LLMs bring a translation layer so that even if you're writing some high-level language, some DSL that exists only on some 1-off platform that no one else is aware of, _everybody_ has access to a self-bootstrapping codebase.
I feel more empowered to _code_ than ever: now, every single input carries semantic weight that gets carried through the "compiler." Every claim of determinism can much more easily be fuzz-tested and made more robust. "'sup, this broke, fix yo" and "Would you be so kind as to fix this error?" contain semantic context that actually affects the output of the generated code. That restores empowerment around code _authorship_ while still preserving the guarantees we want from the published artifact.
"Deep understanding" doesn't disappear when you gain the ability to be more expressive. "Deep understanding" disappears when people become incurious.
ok but a lot of coding used to be fighting package managers, discovering bugs in dependencies, dealing with deploy baloney, etc, not just "solving puzzles" or "architecting the backend"
Yeah the rose colored glasses some people seem to have about how fun doing everything by hand was in the past and how well most people did those things continues to astonish me
There are certain things I enjoy coding by hand, in exactly the same way I like using a manual coffee grinder. Coding can be enjoyable.
But most of the time coding is a means to an end. I bet your friend in HVAC was not told to use a manual drill to have a deeper understanding of how to make holes for installation. AI is simply a power tool.
> AI is simply a power tool
I could not disagree more strongly
Using a power tool does not erode your ability to think about how to build a shelf.
Using AI to write for you absolutely erodes your ability to think about what you're writing, be it software or blog posts
People have said this about virtually every new writing technology, from pencils to typewriters, from computers to spell-check.
Personally I would never use AI for writing, but it's absolutely a power tool for coding. I still need to think about what needs to be generated, and why. For now, I still need to guide the model based on my experience. And in the end, I'm on the hook to approve what's created. If anything, I have more time to think about what I'm making, because I'm not busy building the CRUD for a web app for the 100th time.
I enjoy building things. I do not enjoy the act typing out code by hand.
> Do you not enjoy coding? I'm not trying to be snarky, just a genuine question
To follow this debate through, to maximize coding enjoyment, shouldn't we be avoiding compilers? They take away a lot of the code we need to write. Frameworks as well?
I don't think the joy of coding comes simply from writing lots of code. It's the act of precisely expressing one's internal thoughts into an physical medium, and watching it take effect. Using AI as an intermediary makes it less enjoyable. It's like a painter telling his speedy assistant what he wants to paint, and reviewing every attempt until it looks like what he was aiming for. Obviously the painter won't find that as fulfilling and meaningful. And a skilled painter probably won't be quite as happy as if they'd done it personally. The act of painting is a primary driver, not just having a finished painting at the end.
The problem with your argument is that it's the same argument machine coders used against high level languages :)
High level languages are analogous to airbrushes or paint rollers, not assistants. They let you paint faster, at the cost of making some things impossible that you would be able to do with a fine paintbrush. Unlike the assistant/LLM, they do not make artistic decisions for you, and their behavior is predictable.
Idk, when you have nothing to prove just let the assistant do it. As the painter I can give direction then take a nap since I'm not getting any younger.
Compilers don't take away the code we need to write; they translate it into a different formal language that emphasizes and de-emphasizes various aspects of its meaning.
LLMs are categorically a different thing. Instead of soundly translating between formal languages, they adjust how you interact with the formal language.
The enjoyment people get from coding has absolutely nothing to do with the pure volume of code they produce, to the point that this has long been a cliche!
> LLMs are categorically a different thing. Instead of soundly translating between formal languages, they adjust how you interact with the formal language.
Yeah, equating LLMs with compilers is sloppy thinking (though, I'm sure some sloppy thinkers will defend to death). It's an over-eager pattern match, not everything that takes input and produces output is the same kind of thing.
I bet in our new AI utopia, we'll get more sloppy thinking. All kinds of people will be talking about how they used to think, but now they "no longer have to do it."
I usually like to write elegant code using Python and frameworks like Django.
The pleasure comes from the "the only right lines of code" instead of "the most lines of code".
Thanks for the honesty and I think I get it. The AI doing the code leap frogs you to a finished product which is the reward. I do worry about craftmanship in that scenario though.
The finished product alone does not have to be the reward. The reward can still be building a great tool, a great application, etc. With AI we can build it 100x faster, freeing us up to think deeper about our test coverage, our design, our scaling, our observability.
There is no excuse for lazy execution using AI, that is, IMO, equivalent to shoddy software engineering. it's just faster and more accessible now. "AI slop" is just poor execution delivered more quickly.
The onus is still on the human in the drivers seat to deliver quality outcomes.
How can building an application feel like a reward when you're not the one who built it?
And before you post the obvious response, no, if you're truly "100x faster", you're not reading or even thinking about anything the AI is outputting. The time math doesn't add up.
You seem to have a narrow definition of "build it". LLMs don't have agency. If I build software using an LLM I built it. Just like if I build a house out of lumber from a lumber mill, I built it even though I didn't hand carve the 2x4s.
Now, what if you order a construction crew for building your house? What if you also hire an architect to design the plan? And an overseer who manages everything?
Surely at some point you would stop saying "I built this house", even if you ordered and financed it?
I have a wrist pain from typing a lot. I prefer to generate and then audit. Just make changes one file at a time and then review and commit.
So I go from typing to prompting and reviewing diffs.
There is no way I install an agent on my laptop so I stick to web UI
I love coding and I always have - arguably moreso now, if you can still call it coding.
For me, it is not about the syntax nor the mechanics of typing though. My enjoyment comes from thinking about problems and breaking them down, or thinking about what architecture would best serve them. I guess I'm meant to be a systems design guy, so I'm lucky that AI-coding fits this well (AI models have limited context windows, relative to the size of codebases, so doing the big picture thinking is still important, and fun for me).
> arguably moreso now, if you can still call it coding
I pretty strongly think it doesn't resemble coding even a little
Yes - I think that's fair. I'm happy to concede the term coding - I still enjoy the process of telling my computer to build something I've envisioned. It's now much faster, and I get to do more of the big-picture thinking and ideation, which I thoroughly enjoy.
Depends on the writer.
> The only context I have is my friend in HVAC from many years ago that went to a school that taught everything manually because they wanted people to have a deep understanding of it. What happens to code in the future when people don't have a deep understanding?
What happen is that their boss gets a 3 page email screed with pictures of how they fucked up the thermostat wiring in trying to gerry-rig a new heat pump/air handler that supports only electric resistance backup heat into my house which has an oil boiler for backup. And I get shit from my wife about why our $10k new heat pump is blowing cold air on her during defrost cycles.
I don’t know but to me it seems a bunch of people should learn proper typing. There is no way in world that AI is faster in solving/writing problems than you are when you can maneuver your idea/vim properly and have proper domain knowledge and mental model of your codebase. I think it’s genuinely 10x as fast. Just on execution and then if you write it you keep mental model, decide details and you don’t lose context.
Like honestly I’m losing my mind, when people claim I haven’t written code in a year. You had the wrong job your whole life and whilst you think you are so frontier now by using agenst your market value is actually decreasing.
Imagine a painter saying, I’m so happy I don’t have to paint anymore. Or a tennis player. I’m so happay that I don’t have to play tennis anymore.
wtf is going on?
Obviously I'm just one guy, but I maintain what I said w/ typing happily at 120+wpm. I think I could break 150 if I switched to colemak or dvorak, which I've been considering.
I don't think my job was ever to type fast, nor do I make any claim that I'm ontologically better than someone writing code by hand - but for what I need to do, I'm way faster now.
You might think he's an AI shill, but I was pretty compelled by simonw's post and idea - "your job is to deliver code that works" [1]. I think I can deliver more code that I can prove to work, faster now. The productivity is nice, but as I've said on other parts of the thread, it's also just fun to spend more time thinking, less time hitting the semicolon on my keyboard?
[1]: https://simonwillison.net/2025/Dec/18/code-proven-to-work/
Edit: should have used [1] in the first place instead of an asterisk.
Coding for other people is like playing tennis for other people. You're signed as a tennis player to win. If a robot could play for you and win more games for you, you might consider using it. Now, I'm not saying AI tools let you "win," but I am saying a lot of people don't code "for the love of the game;" they code to keep the lights on.
Also the jury's out on if they're losing market value. We have yet to see which way the wind blows, but I personally think the genie might be out of the bottle on this one.
Full disclosure: I'm personally working up the courage to quit, take a fat paycut (maybe) and do something bucholic with the rest of my working life. I don't find much enjoyment in the tech landscape anymore (I'm 37).
Sorry but you are just wrong. Perhaps if you are working on tiny problems in very small projects. Beyond that AI is simply many times faster regardless of how fast you type.
Really if you think about it AI will know everything and you can quickly get the answer for whatever right from inside your smart glasses.
We all become knowledge experts especially when the data we see inside our glasses is always 100% correct. This could take Years but that's where we are heading and Im sure no one now likes the sound of it.
There's parts I enjoy, parts I dislike and parts I hate with a passion.
However, I love putting something in front of users, seeing them use it and get value out of it. And AI lets me get there 10x faster.
How are you verifying all the code that's generated? Do you think that verifying properly would take you as much effort as the original implementation would've?
I guess I'm of two minds on it.
Sometimes, I will review every line, test the front-end in a staging environment, verify the backend contract, et cetera. Over time, though, I realized that many of these reviews just didn't result in any necessary changes. The current model (with guidance/claude.md/etc) was able to one-shot the task.
Not to overly personify, but imagine how you might treat a junior colleague. You start by reviewing everything they do with a microscope, later you review the broad-strokes, and eventually, for low-stakes or well-scoped tasks, you just play with the demo and the ticket and approve it.
Otherwise it's not materially different than a pre-AI world - you've got sample I/O, test cases, hand-review, look at the application on different screen sizes, contrive some edge cases, test against a spec if there is one - et cetera.
I think this is the real problem. I am sympathetic towards automated code synthesis.
But without formal verification and a human reviewing specifications to ensure alignment, I think code will end up being broken in unexpected ways or drift away from the original intent.
The same way that I verified all of the code that was written before AI. Just because you hand type the code doesn't mean that you don't have to test and verify. I can test much more thoroughly with AI that without.
Have you ever worked in a company? Have you ever worked in a F100?
Companies are paying for software, not for owning the code.
1000% this person has no idea what they are talking about.
Are you writing code for end-user applications, or for tools or libraries that other stuff is built with?
Both. And internal tools. And infrastructure scaffolding a la terraform. And visual design.
And frontier models routinely crush all the above in a way I couldn't, at speeds unattainable to mere flesh and blood like me.
I still think internal tools are kind of in a category closer to end-user applications. They are limited in how widely they are used, and therefore they don't have to be as solid as say libraries used by millions.
Not the guy you asked, but honestly, I'm not sure which one of those I'd consider better use cases, not worse.
I ask because I think there's a huge difference between the two.
People making end-user applications might think they can tolerate more errors and bloat from AI.
Just because they can get away with doing that with AI (and that's debatable) does not mean that people can also get away with that in developing tools, libraries, languages etc. The errors, bloat and instability bubbles up exponentially as people build on it.
There seems to be this fallacy of "I don't have to write code anymore, therefore nobody will have to write code anymore."
There seems to be this fallacy of "I don't have to write code anymore, therefore nobody will have to write code anymore."
I see a lot more of "AI coding doesn't work well in this specific case, therefore it's entirely useless".
Generally end-user applications, depending on how you classify internal tools. I'm generally very happy with the output of Opus 4.X with a moderately structured CLAUDE.md and some investment in detection/avoidance of anti-patterns (Next.js+ts). I imagine that the bitter lesson is true here, and these heuristic guidelines will become increasingly unnecessary w/ smarter models.
Library-type work has mostly been side/toy projects, although fwiw, with a standard/spec on hand (CommonMark for example), I'm also happy w/ the output. It's often possible to "close the loop" and have the coding agent autonomously iterate until the standard is adhered to.
Thanks for the answer. From what I can see, most people who are enthusiastic and optimistic about AI use are producing end-user apps, internal tools (limited use) or just hobby libraries. The fuzziness may be tolerable on the edges of immediate use.
Creating something that is solid enough for widespread, reliable building is just in another category. And I wish people recognized this distinction more when they say we don't need to look at code anymore.
Judging by parent's CV, it kind of looks like they are relatively new to the industry and working in areas where they are heavy on the greenfield side of the equation. I get the sense that they've probably had some good success on smallish projects where they are in charge of keeping it all in their head. That's not to say that isn't earned or otherwise valuable experience, but it surely is not the way a lot of software projects are situated. Parent: I hope you won't take my comment here as a slight. I mean no offense, just pointing out what I think is probably valuable context.
Yes - this is certainly true. I would have to concede that I could not speak to how my thesis would map onto a truly colossal codebase.
That said - I would (again, maybe naively) suppose it's not hugely different - much of the work I do occurs in code where many people have and will work on it, and where the size of the codebase dwarfs model context windows.
In that case, I feel the same - current frontier models, when properly oriented to a task, with some assist on the big-picture thinking - are more than capable of generating good code that can slot into big codebases with many moving pieces. Of course, I'd have to point to other people's work to defend this, but I think that's still pretty reasonable especially against the declared "LLMs are worse than useless for generating code".
nailed it
> Recently, there's a lot of talk about AI allegedly finding security flaws in software. That is an unsubstantiated claim. As such, it would need to be verified by a non-machine, and arguably, the verification process would require the same amount of effort or more than would be required to find the issue to begin with.
This is simply not true. Security flaws are a great use-case for AI specifically because they're easy to verify. If you can drive a program to segfault based on inputs, you've got a good indicator it is, in fact, a security vulnerability (at minimum a DoS, but usually you find out later it was exploitable). You could even have the AI generate an exploit PoC. Shell? Valid hole. Done.
The bad use cases for AI are the ones where it's as or more expensive to verify correctness as it would have been to find the solution in advance.
This statement is just ridiculous:
> Recently, there's a lot of talk about AI allegedly finding security flaws in software. That is an unsubstantiated claim. As such, it would need to be verified by a non-machine, and arguably, the verification process would require the same amount of effort or more than would be required to find the issue to begin with.
Once a security issue is found, it is often far less effort to verify it. Digging through millions of lines of codes to find high-probability vulnerabilities is the hard part.
Pure sophistry, divorced from reality.
It starts with the assumption that nothing coming from AI can be useful or trusted and uses that to demonstrate that AI is not useful or safe.
Right at the outset it opines that AI finding vulnerabilities ("allegedly") is useless because people have to verify those vulnerabilities, which is such a logically braindead bit of nonsense that I knew it was going to be worthless, and somehow it got even worse with every subsequent paragraph.
I get that there are people who are scared, and the change is coming fast and hard and there is a lot of doom and concerns, but good god do people think authoring or upvoting shit like the submitted nonsense is going to stem the tide or change the path? Pathetic.
I don't really agree with this. I was VERY skeptical about AI, but then I started using frontier models everyday, and my feelings have changed dramatically. I use AI to refine designs. I use AI for "where are all the codepaths where we return an HTTP 499 error". I use AI to write code (in "manually accept edits" mode, and I am picky about every single diff) and the results are really good. Most of the time, exactly what I typed in. Doing stuff like "add this config and plumb it through the helm chart" is amazing. Editing Go templates that generate YAML is absolutely miserable, it is my least favorite task. Claude gets it right without fuss every time.
I have not stopped engineering software, but I type in less code. I still understand every line in our codebase and why it's there, but I spend a lot less time dealing with the mechanics. LLMs are super impressive for the software engineering work I do. I don't have a fleet of agents making 20 major changes to the codebase every day. I do about as much work with AI as I did before I used AI. But I think the quality has gone way up, and I am a stickler for pretty perfect code. Claude keeps me honest and reduces the cost of exploring alternate approaches, writing hairy tests, doing refactors, keeping docs up to date, keeping production stable and understandable, etc.
I basically do not agree with this article at all. Frontier models are like switching from dabbrev-mode to IntelliSense, something I was very resistant to at the time. "It's important that I know the APIs that I use everyday." Not really. Having your IDE remember whether it's HasPrefix(string, substring) or HasPrefix(substring, string) frees up my brain for something more important and I couldn't live without it. AI is the same way. It's a tool that makes me better at my work. Yes, it's expensive. That's the only downside I see. I am lucky that I can use as much Fable 5 as I want at work... I always feel bad when I share something that it did that was cool with someone who can't afford it. But costs will come down. I think this AI think is here to stay in the software engineering space. I don't think it removes the need for qualified software engineers at the controls. At least today.
> Editing Go templates that generate YAML is absolutely miserable, it is my least favorite task. Claude gets it right without fuss every time.
As I understood it, the article's thesis is that your system shouldn't require "Go templates that generate YAML" in the first place.
Which is the sort of thing I'm very sympathetic to, but seems overstated here. There's a balance to strike.
Yeah. I would personally refuse to add Helm to a system but the complicating factors are 1) customers ask for it by name (why I relented at my last job where we made self-hosted k8s software) 2) people we hire know how to use it. So while I find it unpleasant from a computer science purity standpoint, it is pretty popular and gets the job done. I have to save my energy for things that matter and improve the experiences of the customers, not design the 900th way to deploy stuff to Kubernetes. So ... I am happy to let Claude double-check my {{ brace }} nesting or whatever. If something is Objectively Terrible but tooling smooths over it, I can let it live without a fight.
> The real question is, who can verify that what the AI built is good and true? Recently, there's a lot of talk about AI allegedly finding security flaws in software. That is an unsubstantiated claim. As such, it would need to be verified by a non-machine, and arguably, the verification process would require the same amount of effort or more than would be required to find the issue to begin with.
Came for the bad AI take, stayed for the P=NP claim.
Has the author used an LLM to brainstorm architecture, explore trade-offs, challenge assumptions, or refine a design? Models are not just 'a data distiller'. "How could I implement X feature in Y project?" requires systematic planning. The agentic paradigm is about balancing (expensive) human and (cheap) machine cognition. Frontier models chew through requirements and if you don't like what they come up with you can TALK to them about it.
I am really annoying by these post (not yours, but op), they are basically the reverse of linkedin.
Between LinkedIn that is packed with AI slope, and HN which is "I am smarter than you, AI is awful"...Where are the interesting news?
I think a lot of people who write about AI haven't been regular old, run-of-the-mill software devs in a while.
For small companies, or large companies broken into small teams, I'm not really sure why there's this assumption that AI will "take care of all the trivial code." Someone has to transmute the project manager's wishes into working code, and it's never going to be the product manager. From that point of view, whether I'm cobbling the code together from Stack Overflow snippets or using AI to generate it, my job hasn't changed all that much.
I neither fear the reaper nor do I dismiss the impact GPTs have had on the industry. I just don't think small development teams' mandates have changed that much, apart from a somewhat faster pace of development (work expands to fill the vacuum, after all).
The idea that it only reveals missing abstractions and that this is bad, is pretty off the mark in a lot of ways.
First off, there's plenty of cases where it make no sense for me to spend all my time abstracting everything possible in my pipeline. Maybe I'm a game developer who doesn't want to spend all my time abstracting away all the initial scaffolding for game prototype and just make a dang game prototype.
Or maybe the abstraction would needs to much confirmation to not really be any different than code (again, games.)
Or maybe the LLM is indeed a perfectly good abstraction for such a task, reliable and customizable.
Just keep writing abstractions all the way up the chain until you're so abstracted that you take english input and can product whatever is asked for, and, oh right.
This article starts off by saying AI can be useful for question-answering, but then quickly states that if you're using AI to generate code "you're wasting your time:"
> The reason AI is a bad tool is that generally speaking, it is completely opaque.
The author is missing the fact that you can use those great question-answering and knowledge distillation capabilities to ask the AI questions about the code it wrote.
Later, they write:
> Who is going to verify that it is doing what it is supposed to?
What? If you hire a writer to write a blog post, who is going to verify that they didn't just fill in gibberish? It's you. You there, in the front. You're the one.
If you can't find any way to independently verify that the software is doing what you think it should do, I don't think you have any business generating it, whether you use AI or code it by hand. That's like commissioning a portrait of someone you've never seen.
Is this satire? That's my most charitable interpretation.
This smells like it was written by someone who doesn't actually write code. How does one make the logic leap that any code AI is able to write, is only because that code is "trivial"? The author doesn't even bother defending that claim.
I suppose the only other charitable interpretation would be to say, "Well then 99% of the code I'm paid to write is 'trivial'." If that's the case, then you have to separate "code as means to an end" (which is clearly well within the wheelhouse of AI) from "code as a mathematical art" which is okay, but the latter doesn't pay my bills or create value for my clients.
In this article you can learn that it takes the same amount of effort to verify if a security hole is real, as it takes to find it in the first place. (?)
This article feels weirdly anachronistic with talking points I haven't really heard anyone mention since like 2023.
I'd welcome someone pointing out where I'm wrong in my critique of this critique..
"The reason AI is a bad tool is that generally speaking, it is completely opaque."
"The real question is, who can verify that what the AI built is good and true?"
Well, you? The developer? The person responsible for using the tool, no?
Isn't this article just saying, "using a tool blindly and not checking the result" is bad? Which, of course, it would be.
I think this is correct. When I was coming up in software engineering, it was fairly accepted that the "bus factor" of a project should only increase. Any kind of vibe coding makes that bus factor exactly one... and if a service goes down, you're stuck.
I can prompt a fix or a new feature, have it coded in a couple of minutes, and I have enough domain knowledge to look at a diff and understand what's happening pretty quickly. It is ABSOLUTELY faster. And if Claude goes down, I could easily keep working.
I think most tools, according to the UNIX philosophy, do one thing (and do it well). AI is a tool that does _a lot_ of things...to various degrees of success. While you can verify that the output of `sed` or `grep` is valid, you can't with 10k lines of code you have no context on (without _significant_ effort).
Same with Gimp, Firefox, and your terminal. Tools, all, do many easily verifiable things. AI isn't verifiable without an existing framework, and that's why it's so "good" at rewriting code from language A to language B, but not at zero-to-one building real world software.
100%. Author's point is more like "don't vibe code if you have to maintain it".
The code is your responsibility, and it's your responsibility to understand it and maintain it (using the tools your have available).
Strange article. If their point was "…but vibe coding is really tempting, so you have to exercise a lot of discipline" I'd be on board.
It is, I think. I published the article on BCN (the preface is me, the rest is a reader submission) and I find I agree with relatively little of the article, but I think it has observations worth looking at, even so.
the problem is that a lot of AI use is done blindly. how much of that bun rewrite in rust was verified by a human?
Or the users? At some point it either works or it doesn’t. And I can use AI to write 100 api tests and run them in the pipeline on day 1 when that would probably be a year 2 project otherwise. And I can document business decisions in plain english and the AI will read those and almost certainly honor them.
Condescending, ignorant, and the author doesn't know what he is talking about.
I'll not explain why, and that would be as deep as the author explanation of his coping.
Why those articles get to hacker news?
Yes.
AI (in its current state) is phenomenal for research on just about any topic; you can dive deep and cross-reference the material more easily than ever.
AI (in its current state) is not so good at actually doing things; we're a long ways off from simply speaking software into existence.
we're a long ways off from simply speaking software into existence
I wanted a Chinese language tutor that uses a local LLM to generate sentences and evaluate my translations. I asked Claude to build that, and an hour later it was working pretty much exactly how I imagined it.
It's true that there's a lot more to shipping serious projects than getting the code to work, but you can absolutely speak software into existence today.
The AI posts will continue until morale improves.
Honestly, I am starting to feel it’s Groundhog Day every day here, reaching the same discussion we’ve been having for years now.
I get their point, but they are probably wrong. Not saying the AIs will not get better and better. They probably will, but I see a chance that there are smaller and smaller gains and the AIs cant make those gains happen. But coding with llm's doesnt say its shoddy code per se. I view it as: We used to use hand saws to make cabinets. Then we had tracksaws. Then we had CNC saws... You still need to understand woodworking to make a nice table in all these scenarios.
All those things (handsaws, tracksaws, CNC saws) are analogous to deterministic, clearly designed tools (assemblers, compilers, language servers). The jump to LLMs is a jump to a completely different category.
> Maybe being passionate about something you build, understanding it fully, owning it completely, and abstracting it properly
This is the actual job description. It doesn't matter whether AI is used for writing the literal code.
All that can really be said is that AI alone is inadequate for this job. None of this back and forth has ever really been about AI.
So, can we just cut the crap already and go back to the clarity we used to have on this? Bad leadership leads to bad outcomes. Bad leadership wants to use any tool at their disposal to micromanage and cut costs. Bad leadership is terrified of a younger and more capable workforce that will replace them. Bad leadership will do everything to deflect blame including calling you "out of touch" for not using AI enough or at all.
Not all workplaces are like this. I am actually glad AI has put a massive spotlight on these longstanding tensions.
Aging is happening faster than AI. It's far more likely there will be a time soon when all these software devs will no longer code because they're management (or burned out and changed careers). It's more important to start thinking about your integrity now before your lack of it gets you fired in the future anyway. I don't blame young people for being so naive, but this is a blindspot. Get a grip now.
Great article. Yes, often what's needed are better (rock-solid) abstractions that we can manipulate around quickly and confidently (think Abelson/Sussman SICP style), not a machine that can take good guesses at piles of spaghetti code.