You don’t have anything to worry about. Chatgpt is super useful but it’s not great at wholesale coding just yet

This is based on someone else’s reply I read once. Developers have been trying to put themselves out of their own jobs since the beginning. Automating/scripting things, creating tools, IDEs, etc.

Development is so much more than generating/writing boilerplate code. Code plays such a small role as opposed to figuring out how to solve a problem or even figuring out what the problem is in the first place.

I spent several days figuring out why an HTTP POST in prod wasn’t working. But an identical one was working locally. Turns out there was an application server change that deceased the max request param size. The Dockerfile was configured so that the patch version (semver) was updated automatically. This was a super interesting challenge (felt like Sherlock Holmes with this one).

Try having ChatGPT/etc. figure that one out.

All of this hubbub might produce some kind of toolset that could augment what we already do (i.e. IDE). But replacing people entirely? I don’t think so.

Nope, I fully agree with you.

These “AI” tools have no more understanding of what they crap out than a toddler who has learned to swear (someone else made that comparison, I’m just borrowing it).

Have you ever done a code review with someone, asked about a specific part, and they say “I dunno; I copied it from GPT and it just seems to work” ? I have, and it’s absolutely infuriating. Yeah, they could have copied the same from Stack Overflow, I suppose, but I’d treat it the same. But somehow they expect copy/paste from an “AI” to get a pass?

Even without dipping into the “replacement theory” of it, these kinds of tools just allow people who don’t know what they’re doing to pretend like they do while creating a mountain of technical debt. Even experienced devs who use it are starting down a slippery slope, IMO.

I think everyone in the software industry is feeling this right now. It was the same way with NFT’s, Blockchain, AR, Even back in the late 2000’s everyone wanted Social Media (crazies). This too shall pass.

Maybe in 6 months, maybe in 2 years, we will hit a point where the limitations and use case are understood well enough and it will just be another tool in our belts and not the end all.

My advice, just smile to your boss and say “sure let’s try it”. Learn something new and look forward to the next one.

Having an AI help you code is like having a junior developer who is blazing fast, enthusiastic and listens well. However it doesn’t think about what it writes. It does no testing and it doesn’t understand the big picture at all. For very simple tasks, it gets the job done very fast, but for complex tasks no matter how many times you explain it. It is never going to get it. I don’t think there’s any worry about AI replacing developers any time in the foreseeable future.

The issues with LLM’s for coding are numerous - they don’t produce good results in my experience, there’s plenty of articles on their flaws.

But… they do highlight something very important that I think we as developers have been guilty of for decades… a large chunk of what we do is busy work; the model definitions, the api to wrap the model, the endpoint to expose the model, the client to connect to the endpoint, the ui that links to the client, the server-side validation, the client-side validation, etc. On and on… so much of it is just busy work. No wonder LLM’s can offer up solutions to these things so easily - we’ve all been re-inventing the wheel over and over and over again.

Busy work is the worst and it played a big part in why I took a decade-long break from professional software development. But now I’m back running my own business and I’m spending significant time reducing busy work - for profit but also for my own personal enjoyment of doing the work.

I have two primary high-level goals:

1. Maximise reuse - As much as possible should be re-usable both within and between projects.
2. Minimise definition - I should only use the minimum definition possible to provide the desired solution.

When you look at projects with these in mind, you realise that so many “fundamentals” of software development are terrible and inherently lead to busy work.

I’ll give a simple example… let’s say I have the following definition for a model of a simple blog:

User:
  id: int generate primary-key
  name: string

Post:
  id: int generate primary-key
  user_id: int foreign-key(User.id)
  title: string
  body: string

Seems fairly straight-forward, we’ve all done this before - it can be in SQL, prisma, etc. But there’s some fundamental flaws right here:

1. We’ve tightly coupled Post to User through the user_id field. That means Post is instantly far less reusable.
2. We’ve forced an id scheme that might not be appropriate for different solutions - for example a blogging site with millions of bloggers with a distributed database backend may prefer bigint or even some form of UUID.
3. This isn’t true for everything, but is for things like SQL, Prisma, etc. - we’ve defined the model in a data-definition language that doesn’t support many reusability features like importing, extending, mixins, overriding, etc.
4. We’re going to have to define this model again in multiple places… our API that wraps the database, any clients that consume that API, any endpoints that serve that API up, in the UI, the validation, and so on.

Now this is just a really simple, almost superficial example - but even then it highlights these problems.

So I’m working on a “pattern” to help solve these kinds of problems, but with a reference implementation in TypeScript. Let’s look at the same example above in my reference implementation:

export const user = new Entity({
    name: "User",
    fields: [
        new NameField(),
    ],
});

export const post = new Entity({
    name: "Post",
    fields: [
        new NameField("title", { maxLength: 100 }),
        new TextField("body"),
    ],
});

export const userPosts = new ContentCreator({
    name: "UserPosts",
    author: user,
    content: post,
});

export const blogSchema = new Schema({
    relationships: [
        userPosts,
    ],
});

So there’s several things to note:

1. Entities are defined in isolation without coupling to each other.
2. We have sane defaults, no need to specify an id field for each entity (though you can).
3. You can’t see it here because of the above, but there are abstract id field definitions: IDField and AutoIDField. It’s the specific implementation of this schema where you specify the type of ID you want to use, e.g. IntField, BigIntField, UUIDField, etc.
4. Relationships are defined separately and used to link together entities.
5. Relationships can bestow meaning - the ContentCreator relationship just extends OneToMany, but adds meta-data from which we can infer things in our UI, authorization, etc.
6. Fields can be extended to provide meaning and to abstract implementations - for example the NameField extends TextField, but adds meta-data so we know it’s the name of this entity, and that it’s unique, so we can therefore have UI that uses that for links to this entity, or use it for a slug, etc.
7. Everything is a separately exported variable which can be imported into any project, extended, overridden, mixed in, etc.
8. When defining the relationship we sane defaults are used so we don’t need to explicitly define the entity fields we’re using to make the link, though we can if we want.
9. We don’t need to explicitly add both our entities and relationships to our schema (though we can) as we can infer the entities from the relationships.

There is another layer beyond this, which is where you define an Application which then lets you specify code generation components that to do all the busy work for you, settings like the ID scheme you want to use, etc.

It’s early days, I’m still refining things, and there is a ton of work yet to do - but I am now using it in anger on commercial projects and it’s saving me time - generating types/interfaces/classes, database definitions, api’s, end points, ui components, etc.

But it’s less about this specific implementation and more about the core idea - can we maximise reuse and minimise what we need to define for a given solution?

There’s so many things that come off the back of it - so much config that isn’t reusable (e.g. docker compose files), so many things that can be automatically determined based on data (e.g. database optimisations), so many things that can be abstracted (e.g. deployment/scaling strategies).

So much busy work that needs to be eliminated, allowing us to give LLM’s a run for their money!

I will cautiously say that these tools have their use for non-programmers. For example, I have to store some data in the format that would be easy to plot. I could spend half an hour doing that in Origin each time and hope its quirks won’t crash it… or I could use my rudimentary Python knowledge to shove comments into Copilot and correct my output by trial and error and have an ugly script that would nonetheless do the task every time in 5 seconds. Or I could learn to actually program and have non-ugly scripts. But I probably won’t in the foreseeable future, because it’s very time-consuming and what I do with AI tools is for myself, not for production.

For those who program for life it’s a different story. I won’t give up my primary research tasks to AI and I hope programmers won’t give up their primary job to AI too.

https://en.wikipedia.org/wiki/Gartner_hype_cycle

Your boss is on the first peak

This sort of black box magic irks me to no end. Nobody understands it!

And that’s why it’s not going to swallow the world. It’s a toy, not a tool.

Tools behave consistently and predictably. You know what you call a tool that doesn’t behave consistently and predictably? “Broken”, that’s what.

Maybe I’m just feeling threatened, or turning into “old man yells at cloud”.

I was “old man yells at cloud” about cryptocurrency for years, and now it’s dead, exactly as I predicted.

Sometimes, the old man is right.

AI LLMs are the best rubber duck. Like a rubber duck, it’s probably not going to “solve” anything for you directly, but LLMs can be a great tool to unlock your potential.

I’ve recently started using CodeWhisperer and I’ve found I use the creation aspect much less than I do auto-complete. That may change in the future, but right now it’s pretty nice starting to type something and VSCode completes what I was going to type.

To cool down your boss, you can always tell him that he’s putting your company at great legal risk, there’s no reason to think that LLMs are not violating copyright laws and software licenses, and moreover the case might settle differently in different countries (in case you export your code).

I know what you mean! I just started in development recently and the amount of my colleagues (that I am supposed to learn from) who use ChatGPT for a lot more than they should is super annoying to me. I have a background in natural language processing but decided to go into software development because the programming was always more fun to me.

Recently some of my colleagues were looking for a package for a specific framework to do a specific task. And they just asked ChatGPT which is just NOT A SEARCH ENGINE. It came up with something that wasn’t even close to what we needed, but somehow no one looked into it. I did a quick search, read some threads on reddit and found something a lot better in 5 minutes. Luckily the Project Manager listened to me, but it was honestly so weird, because I felt like I was somehow weird for suggesting to look at what other devs recommend instead of just going with what a language model suggests, that doesn’t even use recent data.

As an artist; welcome to the club.

I agree with you - I think my main issue is that using LLMs to write code is a crutch, and over time the quality of software will decrease because it will be made by a program perfected to generate the most likely next word, rather than understanding what it’s doing. If anything, having a basic understanding of LLMs makes me trust them less.