Automation for Development: A Sweet Spot for Code Generation

I’ll always remember a training session I ran years ago. The exercise was a simple programming problem, but the focus was on incremental design. I gave the class a feature to implement followed by a new one every 15 minutes. Attendees worked solo or in small groups, sharing their work at the end. Most designs were typical for the time: Java or C# code with several collaborating classes but one stood out. The attendee had written one short line of bash calling several incrementally grown scripts. I resisted the urge to say, "Wait, you're missing the point." The guy was earnest, not trying to be funny, and his solution looked elegant.

Shell script has both good and bad qualities. Its syntax can be quirky and counterintuitive, and you're at the mercy of UNIX utility commands that have grown baroque over decades. On the plus side, it's powerful. If you align with "the Unix philosophy" of small, interoperable pieces, you can accomplish a lot quickly.

Enter AI.

Code generation is undeniably controversial. We know transformer technology is prone to hallucination, necessitating thorough review of its output. There's always a risk of severe bugs slipping into production. Another often-overlooked issue is the sheer volume of generated code. Simple prompts can produce vast amounts of code, This increases the review burden. The cost of review isn't linear to the size of what's being reviewed—I'm certain of that. Anyone who thinks they no longer need to prioritize keeping things small and modular quickly learns otherwise. In fact, I'd argue it's more crucial now than ever.

That said, creating and connecting small scripts using Unix conventions seems to be a sweet spot for AI-assisted code generation. Seasoned script writers are likely familiar with many Unix command options, but let's face it: AI excels at retaining and deploying that knowledge. The beauty lies in the easy discoverability of information about generated code. If you're unsure about a command option in a pipeline, you can quickly find answers through documentation or a chat query.

This approach addresses the earlier concerns about opaque syntax and potential bugs. The key is to restrict this type of generation to non-production code. Consider all the utilities you'd like to have to aid your development process—things you want to automate but lack the time for. The advantage here is that problems are usually discovered quickly, and the "blast radius" is small. You might lose a little time, but you're not jeopardizing behavior users depend upon.

To summarize:

• Keeping things small facilitates easier and more effective review.

• Discoverability is crucial.

• AI excels at commanding large option sets, and the Unix pipeline architecture is well-proven.

• Development process automation is a form of DevOps with lower error costs compared to most other development work.

The benefits are many, the risks few.