Two Programming-with-AI Approaches

I attempted the approach of having an AI write the code while I casually audited it, but the results didn’t work out well for me. It kept adding bugs and logical errors that were hard to find. I was using Cursor along with Claude 3.5 Sonnet, and perhaps my use case was too complex. What have you built using this methodology?

It is actually not just an AI-related problem. It can apply to traditional code generators too.

For example, if you want to access a database, you can write the SQL queries yourself, possibly taking advantage of some tools to help you build it. But in the end, that's your code.

Another approach is to take a tool that analyzes the database schema and generate the database access code for you (ORM). That's not really your code anymore, and if you make changes, you are expected to do them from the tool.

These two approaches have their pros and cons, but if you don't make a distinction between fully generated code and at least partially hand written code, you are going to make a mess.

This style of programmer post is strange. We are asked to take it on faith that quality results have been achieved, despite being given no evidence that anyone has deeply tested any of it.

This is faith-based programming.

I can’t do anything with this advice.

in the middle there is pair programming with ai, see for e.g. aider: https://aider.chat/

> modularisation is an approach to software construction that I generally tend to avoid - as a human writing code I just find it confusing and high overhead

How baffling.

Anyone who avoids modularisation or considers it 'overhead' has never worked on a large system; or, has only worked on small over-engineered projects.

In large projects, it is physically impossible to 'be across' everything that's happening in the code.

The only, and I do mean only way to work effectively in a code base like this is to become familiar with a small part of it, clearly identify the boundaries of 'this part' and make sure that your changes happen only with that context where you:

- understand the side effects

- understand the domain

- can work effectively.

That is what modularisation is.

It is not 'making an NPM package for lpad'; the rough size of 'code you can keep track of' is very obvious to most people; when the code gets bigger than that you need to break it up into modules with clearly defined boundaries.

You then learn the boundaries.

The boundaries are smaller than the code.

You can therefore work effectively by understanding a subset of the code (my module + the boundaries of the modules I interact with) which is strictly < (my module + the content of the modules I interact with).

...

Amazingly, the same thing applies to LLMs that applies to people!

For small projects, you can just go in and do whatever you like and it'll be fine; for larger ones, you have to split it into smaller parts and do each part independently.

Absolutely right... but, surely not surprising to anyone?

...

Here's a pro-tip for you LLM work:

You can easily pick the size to use for modules based on the volume of code inside it.

Compare the size and complexity of the API for interacting with the module (class, crate, whatever) with the implementation details. I use 'lines of code + documentation + examples for the LLM to use it' as my vague metric.

If you're doing an 'lpad' and the implementation is <= the size of the API, don't bother to make it a module. You're wasting your time.

When the implementation gets ~10x the size of the API, split it.

It ain't rocket science. LLMs are good at writing glue code from well defined APIs.