I keep getting downvoted for saying this but I still review all of my AI generated code. I feel like I’m sufficiently sped up.
Of course you can go faster if you don’t read the code at all, that’s always been true. But it seems like the ability to emit large quantities of text is already a huge leap in productivity. I don’t think these tools are good enough yet to offload all or our thinking into them.
Where it really shines for me is when the best solution is explicit and obvious code, but really tedious to write. Now I'll choose to have AI write it instead of me, where before I might have tried to write a bad abstraction. Things like generating a TypedDict for a JSON A document I'm returning as a convenience from a postgres query.
I also review all of my AI-generated code. I feel that it’s disrespectful to my teammates to send unverified slop for review.
I’ve noticed that while my coding skills have very noticeably atrophied (to the point I am consciously scheduling time to manually code, just for practice), my ability to read and comprehend code quickly has actually improved quite dramatically.
I notice style inconsistencies and semantic errors far more quickly and consistently when reviewing both human- and LLM-generated code, as compared to a year ago. Cognitive tradeoff hypothesis and all that…
Yes I'm more than okay. AI has enabled a scale of personal ambition I could only previously have dreamed of.
I've never been the kind of coder who could sit down and get their thoughts out from mind to written lines. I've seen that happen in a few gifted individuals, and AI might be frustrating them, because for them, coding was never the bottleneck, but for me, I would always get stuck in analysis paralysis, and just writing the first line of a project was a daunting prospect.
With AI I'm able to construct an entire ecosystem of programs I've always wanted.
The code isn't perfect, but I understand enough to fix architectural mistakes and to guide the AI to a good enough solution.
It's true I've always been better at breaking things than making things, but for someone who was "never really a coder" I've had a good career doing it all the same!
>> I've never been the kind of coder
>Looks like you were never really a coder, to be honest.
I do not understand the bitterness here at all. AI is just a tool you can use for better or worse.
I learnt basic programming at an old age of 10 and 6502 assembler 2 years later from (paper)books.
There was no Internet and I dreamed of one day owning a magical software program called Macro Assembler so I could use labels and advanced loops in assembler programs instead of tediously translating examples from the book or magazines using a pencil and paper into assembly without such features.
The AI today is like that Macro Assembler for me back then. You, a human, are simply moved one layer of abstraction higher.
Did I enjoy writing that assembler back then when the goal was to complete a calculation in the time it took the crt tube's electron gun to draw one line on the screen? Sure. Would I want to write accounting software in it? Hell no.
There have been very crappy coders and great coders before and after AI. Just like almost no one writes assembler anymore, almost no one will write normal code in the age of AI. But knowledge of it, how it should be written is still going to be important.
Your value as a human is in the architecture of the software and choices that influence it's entire functioning. In maintainability, scalability and resilience present in your design from day 1 not added a year later.
You know how much slop and crappy work I saw before AI? A lot.
I'm not OK with it, but I have no choice besides maybe quitting my job.
I've also tried to understand the code that AI writes, but it's often insane and untangling it would slow me down so much that it would nullify the gains in speed that AI brings.
To me, either companies realize they're spending a lot more money to ship crappier code and AI becomes a niche, or we'll just stop looking at code. I don't think there's any other option because I don't see AI getting better at it. It seems to actually be getting worse and more annoying to use.
My company recently had to cut back our usage to effectively nothing and I get to code by hand again. I'm going to appreciate it while I can. The AI just wasn't providing enough value for us
There is an in between here that developers seem to keep forgetting: Design the software architecture yourself — do some whiteboarding, figure out your abstractions and your UML, then write that in your prompt for the LLM to implement through a plan.
Velocity stays high. Cognitive overhead remains low. You know enough of your architecture from the “unit” level to see how the pieces work meaning you can still work fast and understand it without hating the quality it produces. This has worked wonders for my company; I’ve managed to personally write tools that are barely distinguishable from what I’d write by hand, and I’m confident enough to discuss its architecture from top to bottom. If the LLM ever produces a unit with a poor implementation, I just rewrite that unit.
Basically: do the “engineering” part of software engineering instead of throwing LLMs at the wall until code sticks. It doesn’t take much time to come up with a good design, compared to repeatedly iterating on a bad design and maintaining it for years to come.
LLMs suck at design, and that’s why they lead to this bad code. But if a human spends an hour to build nice SOLID abstractions, and tell the LLM each responsibility — they are pretty good at using and wiring these parts together.
> I've also tried to understand the code that AI writes, but it's often insane and untangling it would slow me down
I hear that a lot, but it is very different from my experience using Claude Code every day. The code it generates is pretty much what I would have written myself. My colleagues have always said my code is easy to read and understand, so hopefully it is not just because my code is insane too :)
I've inherited plenty of code bases. AI generated code is a special kind of foobar. With a code base inherited from a human you can at least be assured at least one human has understood each portion for a brief period. With agentic slop all bets are off.
Maybe I'm a bad programmer or have worked at places with terrible dev culture, but honestly I've made changes to code I didn't really understand. The changes I made seemed to accomplish the task I was aiming at, but the downstream effects were sometimes impossible for me to grok. Before vibe coding took over, using AI to help me get a handle on what a bunch of code was doing was actually one of the things that sold me on using AI.
Yeah, I think AI is a great tool to get a handle on a codebase so you understand it. It's just a much more difficult task when that code is AI generated. I don't think agentic coding is worth all the overhead and complexity. Honestly think that as human understanding is prioritized agentic coding will decline. But I don't think human understanding will be prioritized until we see some major crash and burns with agentic.
That's as good a guess about the future as any I suppose! Personally I'd give that about a 30% chance of happening in a large way. For small systems though I don't think I could ever personally go back to the old way. And maybe we should be composing small systems anyway...
A big difference with libraries is that (hopefully) a whole lot of other people have used that same library the same way you are going to use it for the same purpose you are using it for. All the significant bugs hopefully were found by them and the library was fixed.
That usually makes it safe to use even if you have no idea how it does things inside.
With AI code there is a very good chance you are the first person to ever use that code.
My tiny two pet projects I keep developing with LLMs taught me how useful TDD is - I'm not a software engineer so I've been never formally introduced to these, but now I learn the best practices.
So in consequence I have less bugs in this code than what I could achieve myself, and as a second outcome of these is a solid workspace templates that make it faster and easier to get another small thing up to speed, the way that's good and "me". And the very short leash, sandbox and hooks make sure I learn a lot in the process too.
You can write and calculate much faster with a typewriter and a calculator than you would do the same by hand, and you can use both even if you don't know handwriting or the algorithm for calculating logarithms by hand.
But you need to know the spelling to write the correct words with the typewriter, you don’t need to know with AI if you use voice recognition.
You need to know a programming language either to get a working program.
If you can do everything AI can, then you can use it like a tool like a typewriter but given the fact that many people can’t do what AI does for them, AI is something different then a typewriter.
By your logic a secretary is something like a typewriter too.
> It’s crystal clear that AI can be a complexity factory.
> I’ve been thinking a lot lately about what software would look like if we made keeping software understandable to humans a first-class design goal in the age of AI.
I agree, and I've been thinking similarly. But I don't think there's anything "new" about what understandable and well-factored code should look like. It's the same principles as ever.
A lot of agent-written code looks like what you'd get if you gave an enthusiastic human slightly too many stimulants and asked them to take the shortest path to reach the goal. Plausibly this is just a result of the LLMs not being "smart enough" to do any better, but I think there's also an incentives problem. How do you reward human-understandability in benchmarks and unsupervised training?
There are deterministically computable metrics for cognitive complexity and readability[0].
They’re not perfect by any means — and I suspect they’re already included in the RL process for coding evals, and have been for some time. I do think we’ll see ongoing improvement in this area though.
Set acceptable review standards, outline appropriate frameworking, document approaches, test standards, documentation standards and overall just set good examples in both context and the codebase.
If your codebase is slop it's because you approved it.
> there is no replacement for humans immersed in their world yet, so we need developers with with good understanding of the domain
It's not enough. The software model that you produce ends up becoming part of the domain. You need to understand the system. You are the only one who has the potential do that if you have the ability and are willing to work at it.
I think the worst part is that to the bullshit artists that usually float to the top of any org chart, AI generated docs, and implementation plans, and code is superficially plausible. It's hard to find any particular thing that is wrong with all of it - just a general vibe of verbosity. I am observing entire engineering departments drowning in AI generated RFCs and TDDs and thousand plus word Jira tickets and PR reviews and feedback to the PRs. All just Claude talking to itself via various meat-based secretaries.
Meanwhile, as far as leadership is concerned, they don't really understand what is being delivered they just know there's a lot of it. So they're happy - for now.
I think a lot of shops are going to have to go through a couple years of Github-style "why the fuck is our service always down?" before they put 2 and 2 together.
> I think a lot of shops are going to have to go through a couple years of Github-style "why the fuck is our service always down?" before they put 2 and 2 together.
I think it will be like the outsourcing wave in the early 2000s. A lot of places ended up pulling development back in house when it became unsustainable.
I find it incredibly difficult to contribute to code files that were initiated by LLMs. Need to dig deeper to understand why but I just don't like it. I end up prompting my way out of any issues I see, sometimes it works out sometimes it doesn't.
My father-in-law has (among other things) done a fair amount of editing or proofreading prose, mostly on paper with red and blue pens. He says that when the page looks like it's covered in blood, that means it was good writing. For bad writing, it's so bad that you can't really work with it.
I would not want to take a block of text written by AI and try to edit it to sound human. It's too hard to fix. (And I suspect this is why people don't - they just paste the AI output.)
I think the same may be true of AI code. You're not going to fix it. You can't edit it to be the code you would write. All you can do is re-prompt to try to get the AI to fix it.
we will go full circle "what software would look like if we made keeping software understandable to humans" maybe we invent a pseudo programming language so we get deterministic results ;)
I honestly have a vision of a database of .md files that fully describes an application in human-readable, (ok, engineer-readable), text. Making a change is committing a change to the human-readable text, and then AI comes and figures out the rest and/or suggests edits to the human-readable text. (Or asks questions.)
if your spec fully describes a program, it is at least the length of the source code, and probably longer. It will also be just as difficult to read and understand. You cannot circumvent this with different wording
A noble idea but ultimately a losing battle. When even Andrej Karpathy says he hasn’t written any code himself in a year, then you can read the writing on the wall.
“Software” as described in the article is being abstracted away just as machine code was. It’s not a bad thing, in my opinion, on its own merits.
Also, there is a super interesting discussion around evolving ideas of code ownership. I personally feel like teams I work with are treating code as a more fluid, collective item rather than a sum of individual contributions. I think this continues until it really ISNT “your” code. You will own the specs, the design, etc.
I don't believe that AI is the 'higher level of abstraction[1]' that it is often claimed to be. However I wonder if it's possible to work with a codebase when other developers are treating AI as a higher level of abstraction.
Analogously, people can write in assembly, but can you write in assembly when the codebase is frequently altered by someone with an optimizing compiler?
[1] - Do higher levels of abstractions even exist? By my way of thinking that's called not an abstraction. C isn't a higher level of abstraction; it's a different abstraction implemented by assembly. There are more powerful abstractions and more ergonomic abstractions, but that doesn't make them 'higher level'.
This is why I don't use AI to write code directly but instead will use it to generate code snippets or ideas or critique, or even just use it as documentation I can talk to.
By doing this I can still get the benefits of the technology including - and this is crucial - as a learning aid to improve my own skills, while not entirely outsourcing my own thinking to the machine.
This is exactly how AI should be used when coding. "Agentic" AI produces garbage code. The entire codebase should never be accessible to the context (even if parts at a time, if the agent chooses the parts). And the entire codebase should never be write accessible. Only limited scope writes, human read, and approved.
> I’ve been thinking a lot lately about what software would look like if we made keeping software understandable to humans a first-class design goal in the age of AI.
Why? Humans can't keep up. We can't keep up with writing the code, we can't keep up with debugging, and I think we're approaching a 'claude code' moment where we won't be able to keep up with system architecture.
> It’s crystal clear that AI can be a complexity factory.
> keeping software understandable to humans a first-class design goal in the age of AI.
I'm not sure this is going to be a worthwhile goal for much longer. Rarely is anyone caring about the complexity and comprehensibility of the ASM that GCC or LLVM generates from higher-level C code. I think the code-generation abstraction is just moving even higher now into "prompts". The architecture and engineering process of developing software systems is the important human component. The source code itself is not super valuable. What remains valuable is the input, direction, scrutiny, and "battle testing" of the solution.
"The system should email the customer when their subscription renews."
When? Which timezone? What should we email them? Which email address (the customer changed their email 10 minutes ago, the address at time of the charge?)
I can look at a page of code and answer those questions pretty quickly.
You could write all of those in plain English, but then there are more tiny flaws in the ambiguous language. Maybe we could standardize the language in some way. To reduce ambiguity we start using keywords. When we want to refer to the same thing twice we create a variable or a type. Two things must interleave, let's create concurrency primitives. To check that the prompt is correct, we can write a test for it.
And maybe we DO end up with a different format of prompting that supplies this, but at some point we are still giving directions to computers. If those directions are lossy, the system runs differently every time (which I've noticed is bad for building good software).
Interestingly enough, the question "do we want to support it" has been the main one (not "can we write it") in any sufficiently large and mature project for as long as I remember.
Now, becoming large is now a solved problem essentially, but that's still only maybe 10-20% of the software engineering work in the long run. I'm grateful I can delegate some grunt work to LLMs, but, essentially, the main reason why large projects slow down development has never been due to inability to write lots of code quickly.
The balance sheets of the AI providers are pretty clear on this ownership thing: I shouldn't own it, NVidia should. Instead, I should pay at least once a very large amount to initially produce it. And then I should have a recurring usage-based monthly fee - for a license allowing me to say it's "my code". That's on top of hosting fees, etc.
75 comments
[ 0.24 ms ] story [ 11.6 ms ] threadOf course you can go faster if you don’t read the code at all, that’s always been true. But it seems like the ability to emit large quantities of text is already a huge leap in productivity. I don’t think these tools are good enough yet to offload all or our thinking into them.
I’ve noticed that while my coding skills have very noticeably atrophied (to the point I am consciously scheduling time to manually code, just for practice), my ability to read and comprehend code quickly has actually improved quite dramatically.
I notice style inconsistencies and semantic errors far more quickly and consistently when reviewing both human- and LLM-generated code, as compared to a year ago. Cognitive tradeoff hypothesis and all that…
I've never been the kind of coder who could sit down and get their thoughts out from mind to written lines. I've seen that happen in a few gifted individuals, and AI might be frustrating them, because for them, coding was never the bottleneck, but for me, I would always get stuck in analysis paralysis, and just writing the first line of a project was a daunting prospect.
With AI I'm able to construct an entire ecosystem of programs I've always wanted.
The code isn't perfect, but I understand enough to fix architectural mistakes and to guide the AI to a good enough solution.
Looks like you were never really a coder, to be honest.
I do not understand the bitterness here at all. AI is just a tool you can use for better or worse.
I learnt basic programming at an old age of 10 and 6502 assembler 2 years later from (paper)books.
There was no Internet and I dreamed of one day owning a magical software program called Macro Assembler so I could use labels and advanced loops in assembler programs instead of tediously translating examples from the book or magazines using a pencil and paper into assembly without such features.
The AI today is like that Macro Assembler for me back then. You, a human, are simply moved one layer of abstraction higher.
Did I enjoy writing that assembler back then when the goal was to complete a calculation in the time it took the crt tube's electron gun to draw one line on the screen? Sure. Would I want to write accounting software in it? Hell no.
There have been very crappy coders and great coders before and after AI. Just like almost no one writes assembler anymore, almost no one will write normal code in the age of AI. But knowledge of it, how it should be written is still going to be important.
Your value as a human is in the architecture of the software and choices that influence it's entire functioning. In maintainability, scalability and resilience present in your design from day 1 not added a year later.
You know how much slop and crappy work I saw before AI? A lot.
I've also tried to understand the code that AI writes, but it's often insane and untangling it would slow me down so much that it would nullify the gains in speed that AI brings.
To me, either companies realize they're spending a lot more money to ship crappier code and AI becomes a niche, or we'll just stop looking at code. I don't think there's any other option because I don't see AI getting better at it. It seems to actually be getting worse and more annoying to use.
Velocity stays high. Cognitive overhead remains low. You know enough of your architecture from the “unit” level to see how the pieces work meaning you can still work fast and understand it without hating the quality it produces. This has worked wonders for my company; I’ve managed to personally write tools that are barely distinguishable from what I’d write by hand, and I’m confident enough to discuss its architecture from top to bottom. If the LLM ever produces a unit with a poor implementation, I just rewrite that unit.
Basically: do the “engineering” part of software engineering instead of throwing LLMs at the wall until code sticks. It doesn’t take much time to come up with a good design, compared to repeatedly iterating on a bad design and maintaining it for years to come.
LLMs suck at design, and that’s why they lead to this bad code. But if a human spends an hour to build nice SOLID abstractions, and tell the LLM each responsibility — they are pretty good at using and wiring these parts together.
I hear that a lot, but it is very different from my experience using Claude Code every day. The code it generates is pretty much what I would have written myself. My colleagues have always said my code is easy to read and understand, so hopefully it is not just because my code is insane too :)
So I wonder: how are you using LLMs?
Also relevant: including libraries written by others in your own software.
As always it comes down to finding a healthy balance.
That usually makes it safe to use even if you have no idea how it does things inside.
With AI code there is a very good chance you are the first person to ever use that code.
So in consequence I have less bugs in this code than what I could achieve myself, and as a second outcome of these is a solid workspace templates that make it faster and easier to get another small thing up to speed, the way that's good and "me". And the very short leash, sandbox and hooks make sure I learn a lot in the process too.
It’s more like a calculator that does calculations I can’t do.
Can you perform calculations involving roots and logarithms without a calculator? If not, do you claim YOU can calculate them?
By your logic a secretary is something like a typewriter too.
> I’ve been thinking a lot lately about what software would look like if we made keeping software understandable to humans a first-class design goal in the age of AI.
I agree, and I've been thinking similarly. But I don't think there's anything "new" about what understandable and well-factored code should look like. It's the same principles as ever.
A lot of agent-written code looks like what you'd get if you gave an enthusiastic human slightly too many stimulants and asked them to take the shortest path to reach the goal. Plausibly this is just a result of the LLMs not being "smart enough" to do any better, but I think there's also an incentives problem. How do you reward human-understandability in benchmarks and unsupervised training?
They’re not perfect by any means — and I suspect they’re already included in the RL process for coding evals, and have been for some time. I do think we’ll see ongoing improvement in this area though.
[0] (pdf warning) https://www.sonarsource.com/docs/CognitiveComplexity.pdf
Set acceptable review standards, outline appropriate frameworking, document approaches, test standards, documentation standards and overall just set good examples in both context and the codebase.
If your codebase is slop it's because you approved it.
It's not enough. The software model that you produce ends up becoming part of the domain. You need to understand the system. You are the only one who has the potential do that if you have the ability and are willing to work at it.
Meanwhile, as far as leadership is concerned, they don't really understand what is being delivered they just know there's a lot of it. So they're happy - for now.
I think a lot of shops are going to have to go through a couple years of Github-style "why the fuck is our service always down?" before they put 2 and 2 together.
I think it will be like the outsourcing wave in the early 2000s. A lot of places ended up pulling development back in house when it became unsustainable.
I would not want to take a block of text written by AI and try to edit it to sound human. It's too hard to fix. (And I suspect this is why people don't - they just paste the AI output.)
I think the same may be true of AI code. You're not going to fix it. You can't edit it to be the code you would write. All you can do is re-prompt to try to get the AI to fix it.
No, I specifically don’t. My company owns it, and that bastard will lay me off without a second thought.
“Software” as described in the article is being abstracted away just as machine code was. It’s not a bad thing, in my opinion, on its own merits.
Also, there is a super interesting discussion around evolving ideas of code ownership. I personally feel like teams I work with are treating code as a more fluid, collective item rather than a sum of individual contributions. I think this continues until it really ISNT “your” code. You will own the specs, the design, etc.
Analogously, people can write in assembly, but can you write in assembly when the codebase is frequently altered by someone with an optimizing compiler?
[1] - Do higher levels of abstractions even exist? By my way of thinking that's called not an abstraction. C isn't a higher level of abstraction; it's a different abstraction implemented by assembly. There are more powerful abstractions and more ergonomic abstractions, but that doesn't make them 'higher level'.
By doing this I can still get the benefits of the technology including - and this is crucial - as a learning aid to improve my own skills, while not entirely outsourcing my own thinking to the machine.
Why? Humans can't keep up. We can't keep up with writing the code, we can't keep up with debugging, and I think we're approaching a 'claude code' moment where we won't be able to keep up with system architecture.
> keeping software understandable to humans a first-class design goal in the age of AI.
I'm not sure this is going to be a worthwhile goal for much longer. Rarely is anyone caring about the complexity and comprehensibility of the ASM that GCC or LLVM generates from higher-level C code. I think the code-generation abstraction is just moving even higher now into "prompts". The architecture and engineering process of developing software systems is the important human component. The source code itself is not super valuable. What remains valuable is the input, direction, scrutiny, and "battle testing" of the solution.
"The system should email the customer when their subscription renews."
When? Which timezone? What should we email them? Which email address (the customer changed their email 10 minutes ago, the address at time of the charge?)
I can look at a page of code and answer those questions pretty quickly.
You could write all of those in plain English, but then there are more tiny flaws in the ambiguous language. Maybe we could standardize the language in some way. To reduce ambiguity we start using keywords. When we want to refer to the same thing twice we create a variable or a type. Two things must interleave, let's create concurrency primitives. To check that the prompt is correct, we can write a test for it.
And maybe we DO end up with a different format of prompting that supplies this, but at some point we are still giving directions to computers. If those directions are lossy, the system runs differently every time (which I've noticed is bad for building good software).
Now, becoming large is now a solved problem essentially, but that's still only maybe 10-20% of the software engineering work in the long run. I'm grateful I can delegate some grunt work to LLMs, but, essentially, the main reason why large projects slow down development has never been due to inability to write lots of code quickly.
For the AI Act, it is the case for images and videos, don't know about code.