AI is making it possible for individual developers and small teams to build software systems of a size and complexity that once required much larger development organizations.
But there's a problem: AI can produce code much faster than we can personally inspect it.
This week's Ask Good Questions article pair explores what that means for software quality, architectural discipline, and developer responsibility.
Guide: When No One Can Read All the Code, Who Is Responsible?
If reading every line is no longer a realistic quality-control strategy, how do we establish confidence in the software we're building?
The Guide examines why passing tests isn't necessarily proof of correctness, why architectural constraints matter, and why trustworthy software requires evidence beyond an AI agent's declaration that everything works.
After more than forty years of programming, I'm finding that AI is changing not just how I develop software, but how I have to think about supervising it.
The Field Note explores the uncomfortable realization that working code isn't necessarily correctly designed code, and why responsible oversight must evolve as our development capabilities grow.
The central lesson: AI may write the code, but responsibility for the software still belongs to us.
Are you writing Clarion code with AI Charles, if so does AI generate pure source code or does it have a process that can be used within the AppGen and Dct?
Getting AI to write an application in pure source code would be a shock to may Clarion users and would certainly make code review and comprehension a challenge! But, I also think, given time to learn the ins and outs of Clarion the AI is going to write better code than most of us. And I am definitely on the side of good code that I can't understand, rather than bad code that I can't understand!
Yes, we're using AI to generate pure Clarion code in all sorts of forms, including classes, procedures, templates, and occasionally embed code. Most of our work is interactive, with AI generating or modifying code under our direction, rather than simply asking it to write an entire application.
We're also working on some new tools that will allow AI to interact more directly with the Clarion development environment, including AppGen and the dictionary. Our approach is somewhat different from what John Hickey has done with Clarion Assistant (CW Assistant), although we're ultimately trying to solve some of the same problems.
I think one of the important distinctions is that AI doesn't necessarily have to replace the way Clarion developers work. It can complement AppGen, templates, and the existing development process, while potentially opening up entirely new approaches.
And I agree with your last point, although I'd add one qualification. I want AI to write better code than I would, but I also want to understand what it's doing and why. That's where experience, judgment, and asking good questions become particularly important. AI may be writing the code, but I'm still responsible for the result!
Five minutes of musical satire that manages to capture almost everything I was trying to say in the article.
Plus the irony that the video itself was created with AI makes it even better.
I'm a huge advocate of AI-assisted development, but there's a world of difference between using AI to produce software and blindly trusting whatever it produces.
The question isn't whether AI can write 40,000 lines of code. It's whether anybody can demonstrate that those 40,000 lines actually do what they're supposed to do.
