AI-written code is still your code

Natural language can be ambiguous, though.

"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).

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

>> 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.

The question of code ownership highlighted in some of the comments herein (e.g., "when you build software, you own it... "No, I specifically don’t. My company owns it...") takes me back to a paper I read years ago on password management and extrinsic risk: The basic idea was that employees have no real motivation to maintain password hygiene because they bear little to no risk of password compromise. They are asked both to be productive and to be secure, they are more likely to be sanctioned for productivity problems than security problems, so they sacrifice company security in favour of employment safety.

We've seen commentary along these lines re AI productivity gains Vs code maintenance costs and quality concerns for months/years now, but somehow, for me at least, viewing this through the lens of code ownership (literal ownership, not metaphorical/moral ownership in the 'take pride in your work and do it well, regardless' sense) makes this extrinsic risk all the more clear.

It also makes me think of the estimated billions lost to spreadsheet errors: non-programmers unaware that they were programming creating spreadsheet macros that appeared to do exactly what they wanted, but that in reality only did so most of the time, with edge cases and error handling omitted entirely, leading to significant financial losses for their employers.

In that case, the lack of sanction is far clearer: They were not programmers, they did their best, no one noticed and it wasn't their job to do so, etc.

The case of AI isn't that different, especially since it is just as available to the non-programmer as it is to the cavalier, or to the pressured junior, or to the responsible, take-ownership-and-maintain developer.

AI without governance and program management leads organizations to assume unqualified and unquantified risk with diffused responsibility; outside the small class of take-ownership-and-maintain professional, all risks are extrinsic to individuals so why should they care if it gets the job (mostly) done?

They don't and they won't.

(Reaches for popcorn to watch imminent train wrecks whilst hoping his water supply remains uncompromised.)

[dead]