NYT article "complaining" that AIs can create so much code in
so little time that there is now a glut of code and a shortage
of qualified engineers to review that code.
On Mon, 6 Apr 2026 10:41:46 -0700, Don Y <blockedofcourse@foo.invalid>
wrote:
NYT article "complaining" that AIs can create so much code in
so little time that there is now a glut of code and a shortage
of qualified engineers to review that code.
No problem. Just have a second AI review the code produced by the
first AI. For example: <https://www.sonarsource.com/solutions/code-review/ai/>
Disclaimer: I are not a programmist and have not tried any automated
code review program.
On 4/6/2026 5:44 PM, Jeff Liebermann wrote:
On Mon, 6 Apr 2026 10:41:46 -0700, Don Y <blockedofcourse@foo.invalid>
wrote:
NYT article "complaining" that AIs can create so much code in
so little time that there is now a glut of code and a shortage
of qualified engineers to review that code.
No problem. Just have a second AI review the code produced by the
first AI. For example:
<https://www.sonarsource.com/solutions/code-review/ai/>
Disclaimer: I are not a programmist and have not tried any automated
code review program.
Dunno. I have two colleagues who are making a serious effort to see if
AI can reduce their time spent coding and/or yield better code (in less >time).
So far, they describe it as comparable to teaching a child. You have to
tell it *everything* -- to the point where it would just be easier to
write the code yourself!
On Mon, 6 Apr 2026 19:42:27 -0700, Don Y <blockedofcourse@foo.invalid>
wrote:
On 4/6/2026 5:44 PM, Jeff Liebermann wrote:
On Mon, 6 Apr 2026 10:41:46 -0700, Don Y <blockedofcourse@foo.invalid>
wrote:
NYT article "complaining" that AIs can create so much code in
so little time that there is now a glut of code and a shortage
of qualified engineers to review that code.
No problem. Just have a second AI review the code produced by the
first AI. For example:
<https://www.sonarsource.com/solutions/code-review/ai/>
Disclaimer: I are not a programmist and have not tried any automated
code review program.
Dunno. I have two colleagues who are making a serious effort to see if
AI can reduce their time spent coding and/or yield better code (in less
time).
So far, they describe it as comparable to teaching a child. You have to
tell it *everything* -- to the point where it would just be easier to
write the code yourself!
The concept of using AI to design circuits and PCBs has the same
problem: the problem description can be a bigger hassle than designing
a board the old way.
And when you design the schematic and PCB yourself, you can see
possibilities and problems that the AI would not.
I'm, going to a dinner/meetup tomorrow night where the AI hardware
design boys will make their pitches. I'll try to be polite.
John Larkin
Highland Tech Glen Canyon Design Center
Lunatic Fringe Electronics
On Mon, 6 Apr 2026 19:42:27 -0700, Don Y <blockedofcourse@foo.invalid>
wrote:
On 4/6/2026 5:44 PM, Jeff Liebermann wrote:
On Mon, 6 Apr 2026 10:41:46 -0700, Don Y <blockedofcourse@foo.invalid>
wrote:
NYT article "complaining" that AIs can create so much code in
so little time that there is now a glut of code and a shortage
of qualified engineers to review that code.
No problem. Just have a second AI review the code produced by the
first AI. For example:
<https://www.sonarsource.com/solutions/code-review/ai/>
Disclaimer: I are not a programmist and have not tried any automated
code review program.
Dunno. I have two colleagues who are making a serious effort to see if
AI can reduce their time spent coding and/or yield better code (in less
time).
So far, they describe it as comparable to teaching a child. You have to
tell it *everything* -- to the point where it would just be easier to
write the code yourself!
The concept of using AI to design circuits and PCBs has the same
problem: the problem description can be a bigger hassle than designing
a board the old way.
And when you design the schematic and PCB yourself, you can see
possibilities and problems that the AI would not.
I'm, going to a dinner/meetup tomorrow night where the AI hardware
design boys will make their pitches. I'll try to be polite.
John Larkin
Highland Tech Glen Canyon Design Center
Lunatic Fringe Electronics
On 2026-04-07 14:49, john larkin wrote:
On Mon, 6 Apr 2026 19:42:27 -0700, Don Y <blockedofcourse@foo.invalid>My spies tell me that AI (Claude, specifically) is super useful in
wrote:
On 4/6/2026 5:44 PM, Jeff Liebermann wrote:
On Mon, 6 Apr 2026 10:41:46 -0700, Don Y <blockedofcourse@foo.invalid> >>>> wrote:
NYT article "complaining" that AIs can create so much code in
so little time that there is now a glut of code and a shortage
of qualified engineers to review that code.
No problem. Just have a second AI review the code produced by the
first AI. For example:
<https://www.sonarsource.com/solutions/code-review/ai/>
Disclaimer: I are not a programmist and have not tried any automated
code review program.
Dunno. I have two colleagues who are making a serious effort to see if
AI can reduce their time spent coding and/or yield better code (in less
time).
So far, they describe it as comparable to teaching a child. You have to >>> tell it *everything* -- to the point where it would just be easier to
write the code yourself!
The concept of using AI to design circuits and PCBs has the same
problem: the problem description can be a bigger hassle than designing
a board the old way.
And when you design the schematic and PCB yourself, you can see
possibilities and problems that the AI would not.
I'm, going to a dinner/meetup tomorrow night where the AI hardware
design boys will make their pitches. I'll try to be polite.
John Larkin
Highland Tech Glen Canyon Design Center
Lunatic Fringe Electronics
exploring different ways of factoring code. It'll code it up (more or
less well) in several approaches, and let you see the level of complication.
Cheers
Phil Hobbs
(Off to help sing the Hymn of Kassiani in the vigil matins for Holy >Wednesday. That's magic.)
Don Y <blockedofcourse@foo.invalid> wrote: |------------------------------------------------------------------------| |"[. . .] I have two colleagues who are making a serious effort to see if| |AI can [. . .] yield better code [. . .] | |[. . .]" | |------------------------------------------------------------------------|
Would they prefer to use formal methods?
|-------------------------------------------------------------------------| |"So far, they describe it as comparable to teaching a child. You have to| |tell it *everything* -- to the point where it would just be easier to | |write the code yourself!" | |-------------------------------------------------------------------------|
They are not the only ones who report so!
|------------------------------------------------------------------------| |"[. . .] | |Is constraint checking done on-the-fly -- or, at termination?" | |------------------------------------------------------------------------|
On-the-fly constraint enforcements can be annoying for a user.
(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)
On 2026-04-07 14:49, john larkin wrote:
On Mon, 6 Apr 2026 19:42:27 -0700, Don Y <blockedofcourse@foo.invalid>My spies tell me that AI (Claude, specifically) is super useful in
wrote:
On 4/6/2026 5:44 PM, Jeff Liebermann wrote:
On Mon, 6 Apr 2026 10:41:46 -0700, Don Y <blockedofcourse@foo.invalid> >>>> wrote:
NYT article "complaining" that AIs can create so much code in
so little time that there is now a glut of code and a shortage
of qualified engineers to review that code.
No problem. Just have a second AI review the code produced by the
first AI. For example:
<https://www.sonarsource.com/solutions/code-review/ai/>
Disclaimer: I are not a programmist and have not tried any automated
code review program.
Dunno. I have two colleagues who are making a serious effort to see if
AI can reduce their time spent coding and/or yield better code (in less
time).
So far, they describe it as comparable to teaching a child. You have to >>> tell it *everything* -- to the point where it would just be easier to
write the code yourself!
The concept of using AI to design circuits and PCBs has the same
problem: the problem description can be a bigger hassle than designing
a board the old way.
And when you design the schematic and PCB yourself, you can see
possibilities and problems that the AI would not.
I'm, going to a dinner/meetup tomorrow night where the AI hardware
design boys will make their pitches. I'll try to be polite.
John Larkin
Highland Tech Glen Canyon Design Center
Lunatic Fringe Electronics
exploring different ways of factoring code. It'll code it up (more or
less well) in several approaches, and let you see the level of complication.
Cheers
Phil Hobbs
(Off to help sing the Hymn of Kassiani in the vigil matins for Holy >Wednesday. That's magic.)
Don Y <blockedofcourse@foo.invalid> wrote: |------------------------------------------------------------------------| |"[. . .] I have two colleagues who are making a serious effort to see if| |AI can [. . .] yield better code [. . .] | |[. . .]" | |------------------------------------------------------------------------|
Would they prefer to use formal methods?
|-------------------------------------------------------------------------| |"So far, they describe it as comparable to teaching a child. You have to| |tell it *everything* -- to the point where it would just be easier to | |write the code yourself!" | |-------------------------------------------------------------------------|
They are not the only ones who report so!
|------------------------------------------------------------------------| |"[. . .] | |Is constraint checking done on-the-fly -- or, at termination?" | |------------------------------------------------------------------------|
On-the-fly constraint enforcements can be annoying for a user.
On 04/08/2026 12:37 PM, Niocl?s P?l Caile?n de Ghloucester wrote:
Don Y <blockedofcourse@foo.invalid> wrote:
|------------------------------------------------------------------------| >> |"[. . .] I have two colleagues who are making a serious effort to see if| >> |AI can [. . .] yield better code [. . .] | >> |[. . .]" | >> |------------------------------------------------------------------------| >>
Would they prefer to use formal methods?
|-------------------------------------------------------------------------| >> |"So far, they describe it as comparable to teaching a child. You have to| >> |tell it *everything* -- to the point where it would just be easier to | >> |write the code yourself!" | >> |-------------------------------------------------------------------------| >>
They are not the only ones who report so!
|------------------------------------------------------------------------| >> |"[. . .] | >> |Is constraint checking done on-the-fly -- or, at termination?" | >> |------------------------------------------------------------------------| >>
On-the-fly constraint enforcements can be annoying for a user.
(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)
"Hello, World".
On Wed, 8 Apr 2026 13:07:27 -0700, Ross Finlayson ><ross.a.finlayson@gmail.com> wrote:
On 04/08/2026 12:37 PM, Niocl?s P?l Caile?n de Ghloucester wrote:
Don Y <blockedofcourse@foo.invalid> wrote:
|------------------------------------------------------------------------| >>> |"[. . .] I have two colleagues who are making a serious effort to see if| >>> |AI can [. . .] yield better code [. . .] | >>> |[. . .]" | >>> |------------------------------------------------------------------------| >>>
Would they prefer to use formal methods?
|-------------------------------------------------------------------------| >>> |"So far, they describe it as comparable to teaching a child. You have to| >>> |tell it *everything* -- to the point where it would just be easier to | >>> |write the code yourself!" | >>> |-------------------------------------------------------------------------| >>>
They are not the only ones who report so!
|------------------------------------------------------------------------| >>> |"[. . .] | >>> |Is constraint checking done on-the-fly -- or, at termination?" | >>> |------------------------------------------------------------------------| >>>
On-the-fly constraint enforcements can be annoying for a user.
(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)
"Hello, World".
I wonder what language does the most complex Hello World program.
PowerBasic:
Print "Hello World!"
John Larkin
Highland Tech Glen Canyon Design Center
Lunatic Fringe Electronics
On 4/8/2026 12:37 PM, Niocl s P˘l Caile n de Ghloucester wrote:
Don Y <blockedofcourse@foo.invalid> wrote:
|------------------------------------------------------------------------| >>
|"[. . .] I have two colleagues who are making a serious effort to see
if|
|AI can [. . .] yield better code [. .
.] |
|[. .
.]" |
|------------------------------------------------------------------------| >>
Would they prefer to use formal methods?
In a sense, using an AI forces *some* formal methods -- in that you have
to provide the AI with a specification of what you seek. This is often
more (and more detailed) than what you would provide a human coder.
[By way of proof, gather up *any* specifications you've been given in
the past decade -- for hardware OR software designs. Honestly appraise
them
to see how little/much they convey about an "accceptable design"]
|-------------------------------------------------------------------------| >>
|"So far, they describe it as comparable to teaching a child. You
have to|
|tell it *everything* -- to the point where it would just be easier
to |
|write the code
yourself!" |
|-------------------------------------------------------------------------| >>
They are not the only ones who report so!
Depending on choice of programming language, some may be very expressive
in "describing" the solution they represent. And, of course, more
exacting.
So, if you can write the code as quickly and thoroughly as describing it, what value to the imprecise descriptive exercise?
|------------------------------------------------------------------------| >>
|"[. .
.] |
|Is constraint checking done on-the-fly -- or, at
termination?" |
|------------------------------------------------------------------------| >>
On-the-fly constraint enforcements can be annoying for a user.
Everything has constraints. They are enforced somehow and somewhere.
E.g., I can type damn near anything I want and call it a "program".
And, delude myself into thinking that it *is* -- until it encounters
the criticism of a compiler!
My washing machine (clothes) restricts the choices of various options
based on the type of wash cycle I have selected. I may *want* to
make a particular option selection but the machine simply won't offer
it to me -- change the cycle type if you want a different set of options.
My household thermostat won't let me set the heat to 100F nor the cooling
to 40F.
I designed a digital emulation of SWMBO's "bookshelf HiFi". Among other things, it supports 40 "presets" for the radio. And, the "virtual CD
player" (could have!) supports an unlimited number of CDs ("playlists").
But, the user interface is effectively a 10-key keypad. Accepting a selection as a series of keystrokes -- e.g., '2' '5' for "25" -- would significantly alter the legacy interface! This would actually select
"2". And, then a short while later, "5"! Selecting "25" would be
done as '+10' '+10' '5'. I.e., any single decimal digit implicitly
implies an "ENTER" keystroke -- without having to alter the UX to
include such a keystroke! So, you can select "1" through "9" with
a single keystroke and "10" through "40" with 2 to 5 keystrokes.
Clumsy but an essential part of the Stakeholders' Specifications!
It appears the code writing AIs expect to process text (effectively).
So, "25", "000000000000000000000000000000025", "24^H5" are all identical
and none are constrained by the interface.
with a single keystroke.
On 04/08/2026 12:37 PM, Niocl s P˘l Caile n de Ghloucester wrote:
Don Y <blockedofcourse@foo.invalid> wrote:
|------------------------------------------------------------------------| >> |"[. . .] I have two colleagues who are making a serious effort to see if| >> |AI can [. . .] yield better code [. . .] | >> |[. . .]" | >> |------------------------------------------------------------------------| >>
Would they prefer to use formal methods?
|-------------------------------------------------------------------------| >> |"So far, they describe it as comparable to teaching a child. You have to| >> |tell it *everything* -- to the point where it would just be easier to | >> |write the code yourself!" | >> |-------------------------------------------------------------------------| >>
They are not the only ones who report so!
|------------------------------------------------------------------------| >> |"[. . .] | >> |Is constraint checking done on-the-fly -- or, at termination?" | >> |------------------------------------------------------------------------| >>
On-the-fly constraint enforcements can be annoying for a user.
(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)
"Hello, World".
On Tue, 7 Apr 2026 16:38:38 -0400, Phil Hobbs ><pcdhSpamMeSenseless@electrooptical.net> wrote:
On 2026-04-07 14:49, john larkin wrote:
On Mon, 6 Apr 2026 19:42:27 -0700, Don Y <blockedofcourse@foo.invalid>My spies tell me that AI (Claude, specifically) is super useful in >>exploring different ways of factoring code. It'll code it up (more or >>less well) in several approaches, and let you see the level of complication.
wrote:
On 4/6/2026 5:44 PM, Jeff Liebermann wrote:
On Mon, 6 Apr 2026 10:41:46 -0700, Don Y <blockedofcourse@foo.invalid> >>>>> wrote:
NYT article "complaining" that AIs can create so much code in
so little time that there is now a glut of code and a shortage
of qualified engineers to review that code.
No problem. Just have a second AI review the code produced by the
first AI. For example:
<https://www.sonarsource.com/solutions/code-review/ai/>
Disclaimer: I are not a programmist and have not tried any automated >>>>> code review program.
Dunno. I have two colleagues who are making a serious effort to see if >>>> AI can reduce their time spent coding and/or yield better code (in less >>>> time).
So far, they describe it as comparable to teaching a child. You have to >>>> tell it *everything* -- to the point where it would just be easier to
write the code yourself!
The concept of using AI to design circuits and PCBs has the same
problem: the problem description can be a bigger hassle than designing
a board the old way.
And when you design the schematic and PCB yourself, you can see
possibilities and problems that the AI would not.
I'm, going to a dinner/meetup tomorrow night where the AI hardware
design boys will make their pitches. I'll try to be polite.
John Larkin
Highland Tech Glen Canyon Design Center
Lunatic Fringe Electronics
I think it's Claude _Code_ that's very good at code review, not plain
Claude. This from an article in the New York Times Magazine issue of
Sunday 22 March 2026 titled "Coding After Coders", which claims 20:1
coding effort reduction. The cost of computing is significant, but it
still may be worth it.
Joe
Cheers
Phil Hobbs
(Off to help sing the Hymn of Kassiani in the vigil matins for Holy >>Wednesday. That's magic.)
Here is the classic "Hello World" in FORTRAN IV:
Fortran
C˙˙˙˙ THE 'C' IN COLUMN 1 INDICATES A COMMENT LINE 000001
˙˙˙˙˙ WRITE(6, 10) 000002
˙˙ 10 FORMAT(12H HELLO WORLD) 000003
˙˙˙˙˙ STOP 000004
˙˙˙˙˙ END 000005
Not bad , but I'd have put "CALL EXIT" instead of "STOP"
Bad Things? could happen back in the Iron Age˙ if you used STOP˙ - so I was told anyway.
I like constraints and enforcements thereof! I am an Adaist who likes
VHDL. I like strong typing.
I do not necessarily like on-the-flyConstraints imposed on a developer occur in a relatively benign environment. The developer can adjust to meet the constraints.
constraint checking: an IDE which insists that Line X has a finished statement instead of letting me temporarily tweak Line Z before
returning to and finishing Line X could annoy me. Conversely, I of
course demand that I must finish Line X's statement by termination -
i.e. a compiler which fails to provide a criticism that Line X is
unfinished is not a compiler worth using. So I do demand enforcement!
On 4/9/2026 12:11 PM, Niocl s P˘l Caile n de Ghloucester wrote:A good example of this is the definition of an "interval":
I like constraints and enforcements thereof! I am an Adaist who likes
VHDL. I like strong typing.
Constraints go beyond "strong typing".˙ Data can be dynamic and still
tightly constrained.˙ E.g., an "A < B" constraint can't be enforced
by strong typing -- the values of A and B can dynamically vary so
you have to "run code" to ensure A is always less than B.
If this is a true invariant, it applies to all operations on A (or B).
On 4/9/2026 1:19 PM, Don Y wrote:
On 4/9/2026 12:11 PM, Niocl s P˘l Caile n de Ghloucester wrote:A good example of this is the definition of an "interval":
I like constraints and enforcements thereof! I am an Adaist who likes
VHDL. I like strong typing.
Constraints go beyond "strong typing". Data can be dynamic and still
tightly constrained. E.g., an "A < B" constraint can't be enforced
by strong typing -- the values of A and B can dynamically vary so
you have to "run code" to ensure A is always less than B.
If this is a true invariant, it applies to all operations on A (or B).
a period of time between a START point and an END point.
If (assuming just "times") the object is defined as
(start, end), then, any change to start or end has
to ensure the constraint is maintained for the composite
object throughout the "change".
This typically requires creating an atomic region bracketing
the object's manipulation to ensure nothing else "sees"
the object as it is transitioning -- and is in an inconsistent
state.
By contrast, if you define the object as (start, duration)
you can use an unsigned for duration and, if you have
atomic operators to alter start and duration data types,
then you can alter the duration *or* the start (and, thus, end)
with those operators without going to the trouble of
"manually" creating an atomic operation as required would
be required for the (start, end) implementation.
I use an RDBMS to store all persistent data. This allows me
to apply constraints on the data to prohibit "bad" data from
being introduced. And, because of that, consumers are
assured that the data retrieved meets those constraints.
There is no need for them to "re-verify" the data received
is intact.
[Consider using regular files for data and having to *parse*
those files to be sure their content is in the right format.
Then, to have to apply sanity tests to those contents to
further verify that the data "makes sense". All this because
"regular files" don't prevent users from tinkering with their
contents!!]
| Sysop: | Jacob Catayoc |
|---|---|
| Location: | Pasay City, Metro Manila, Philippines |
| Users: | 6 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 493396:30:33 |
| Calls: | 141 |
| Files: | 538 |
| Messages: | 76,283 |