← Back to context

Comment by Kon5ole

18 days ago

I have to admit I'm flip-flopping on the topic, back and forth from skeptic to scared enthusiast.

I just made a LLM recreate a decent approximation of the file system browser from the movie Hackers (similar to the SGI one from Jurassic park) in about 10 minutes. At work I've had it do useful features and bug fixes daily for a solid week.

Something happened around newyears 2026. The clients, the skills, the mcps, the tools and models reached some new level of usefulness. Or maybe I've been lucky for a week.

If it can do things like what I saw last week reliably, then every tool, widget, utility and library currently making money for a single dev or small team of devs is about to get eaten. Maybe even applications like jira, slack, or even salesforce or SAP can be made in-house by even small companies. "Make me a basic CRM".

Just a few months ago I found it mostly frustrating to use LLM's and I thought the whole thing was little more than a slight improvement over googling info for myself. But the past week has been mind-blowing.

Is it the beginning of the star trek ship computer? If so, it is as big as the smartphone, the internet, or even the invention of the microchip. And then the investments make sense in a way.

The problem might end up being that the value created by LLMs will have no customers when everyone is unemployed.

Yeah I’m having a similar experience. I’ve been wanting a standard test suite for JMAP email servers, so we can make sure all created jmap servers implement the (somewhat complex) spec in a consistent manner. I spent a single day prompting Claude code on Friday, and walked away with about 9000 lines of code, containing 300 unit tests for jmap servers. And a web interface showing the results. It would have taken me at least a week or two to make something similar by hand.

There’s some quality issues - I think some of the tests are slightly wrong. We went back and forth on some ambiguities Claude found in the spec, and how we should actually interpret what the jmap spec is asking. But after just a day, it’s nearly there. And it’s already very useful to see where existing implementations diverge on their output, even if the tests are sometimes not correctly identifying which implementation is wrong. Some of the test failures are 100% correct - it found real bugs in production implementations.

Using an AI to do weeks of work in a single day is the biggest change in what software development looks like that I’ve seen in my 30+ year career. I don’t know why I would hire a junior developer to write code any more. (But I would hire someone who was smart enough to wrangle the AI). I just don’t know how long “ai prompter” will remain a valuable skill. The AIs are getting much better at operating independently. It won’t be long before us humans aren’t needed to babysit them.

  • So what'd your prompt look like, out of curiosity? I hear about all these things that sound quite impressive, but no one ever seems to want share any info on the prompts to learn or gain insight from.

    • It was nothing special. I can't seem to pull up the initial prompt, but it was something like this:

      > Build a thorough test suite for JMAP in this directory. The test suite will be run against multiple JMAP servers, to ensure each server implements the JMAP spec consistently and correctly. In this directory are two files - rfc8620.txt and rfc8621.txt. These files containing the JMAP core and JMAP email specs. Read these files. Then make a list of all aspects of the specifications. For each, create a set of tests which thoroughly tests all aspects of a JMAP server's behaviour specified by the RFCs, including error behaviour. The test suite should be configurable to point at a jmap server & email account. The account will contain an empty mailbox (error if its not empty). The test suite starts by adding a known set of test emails to the account, then run your tests and clear the inbox again. Write the test suite in typescript. The test runner should output the report into a JSON file. Start with a project plan.

      If you haven't tried claude code or openai's codex, just dive in there and give it a go. Writing a prompt isn't rocket science. Just succinctly say the same things you'd say to a very competent junior engineer when you want to brief them on some work.

My team of 6 people has been building a software to compete with an already established piece of software written by a major software corporation. I'm not saying we'll succeed, I'm not saying we'll be better nor that we will cover every corner case they do and that they learned over the past 30 years. But 6 senior devs are getting stuff done at an insane pace. And if we can _attempt_ to do this, which would have been unthinkable 2 years ago, I can only wonder what will happen next.

  • > My team of 6 people has been building a software to compete with an already established piece of software written by a major software corporation.

    How long until that the devs at that major corporation start using an LLM? You think your smaller team can still compare to their huge team?

    • If the goal is to simply undercut the incumbent with roughly the same product than it doesn't really matter if the incumbent starts using LLMs too as their cost structure, margin expectations, etc. are already relatively set.

  • Yeah I’m curious how much the moat of big software companies will shrink over the next few years. How long before I can ask a chatbot to build me a windows-like OS from scratch (complete with an office suite) and it can do a reasonable job?

    And what happens then? Will we stop using each others code?

I agree with you, and share the experience. Something changed recently for me as well, where I found the mode to actually get value from these things. I find it refreshing that I don't have to write boilerplate myself or think about the exact syntax of the framework I use. I get to think about the part that adds value.

I also have the same experience where we rejected a SAP offering with the idea to build the same thing in-house.

But... aside from the obvious fact that building a thing is easier than using and maintaining the thing, the question arose if we even need what SAP offered, or if we get agents to do it.

In your example, do you actually need that simple CRM or maybe you can get agents to do the thing without any other additional software?

I don't know what this means for our jobs. I do know that, if making software becomes so trivial for everyone, companies will have to find another way to differentiate and compete. And hopefully that's where knowledge workers come in again.

  • Exactly. I hear this "wow finally I can just let Claude work on a ticket while I get coffee!" stuff and it makes me wonder why none of these people feel threatened in any way?

    And if you can be so productive, then where exactly do we need this surplus productivity in software right now when were no longer in the "digital transformation" phase?

    • I don't feel threatened because no matter how tools, platforms and languages improved, no matter how much faster I could produce and distribute working applications, there has never been a shortage of higher level problems to solve.

      Now if the only thing I was doing was writing code to a specification written by someone else, then I would be scared, but in my quarter century career that has never been the case. Even at my first job as a junior web developer before graduating college, there was always a conversation with stakeholders and I always had input on what was being built. I get that not every programmer had that experience, but to me that's always been the majority of the value that software developers bring, the code itself is just an implementation detail.

      I can't say that I won't miss hand-crafting all the code, there certainly was something meditative about it, but I'm sure some of the original ENIAC programmers felt the same way about plugging in cables to make circuits. The world of tech moves fast, and nostalgia doesn't pay the bills.

      1 reply →

    • Smart devs know this is the beginning of the end of high paying dev work. Once the LLM's get really good, most dev work will go to the lowest bidder. Just like factory work did 30 years ago.

      7 replies →

It seems like every quarter or two, I hear a story just like yours (including the <<Wow! We've quietly passed an inflection point!>> part).

What does that tell me?

It tells me that I shouldn't waste my time with a tool that's going to fundamentally change in three to six months; that I should wait until I stop hearing stories like this for a good, long while. "But you're going to be left behind!", yeah, maybe. But. I've been primarily a maintenance programmer for a very long time. The "bleeding edge" is where I am very, very rarely... and it seems to work out fine.

New tools that are useful are nice. Switching to a radically different tool every quarter or two? Not nice. I've got shit to do.

  • I don't see the interface changing much in 3-6 months, and definitely not fundamentally.

    Sure, there will probably be some changes around MCP, skills, AGENTS.md and similar, but I don't see them as big changes, and you can use the tools now without those things.

    • > I don't see the interface changing much in 3-6 months, and definitely not fundamentally.

      This is as insightful as a fellow noting that both a caulk gun and a shotgun have a fixed handle and movable trigger and genuinely wondering why an expert user of the former would ever have even a moment's trouble learning to use the latter.

I have not had the success you mention with programming… I still feel like I have to hold its hand all the way.

Regardless..

> The problem might end up being that the value created by LLMs will have no customers when everyone is unemployed.

This mentality is why investors are scrambling right now. It’s a scare tactic.

> The problem might end up being that the value created by LLMs will have no customers when everyone is unemployed.

I'm not a professional programmer, but I am the I.T. department for my wife's small office. I used ChatGPT recently (as a search engine) to help create a web interface for some files on our intranet. I'm sure no one in the office has the time or skills to vibe code this in a reasonable amount of time. So I'm confident that my "job" is secure :)

  • > Im sure no one in the office has the time or skills to vibe code.

    the thing you are describing can be vibe coded by anyone. Its not that teachers or nurses are gonna start vibecoding tmrw, but the risk comes from other programmers outworking you to show off to the boss. Or companies pitting devs against each other, or them mistakenly assuming they require very few programmers, or PMs suddenly start vibe coding when threatened for their jobs.

I have to admit the last 6-8 weeks have been different. Maybe it’s just me realizing the value in some of these tools…