What Is Going on Right Now?

Sadly, this time the nonsense is colonising orgs that were too sensible to fall for the last round of tech-scamming (Blockchain, Cryptocurrency, NTFs etc).

I don't want to move again and it's a terrible time to try, partly because of this nonsense. So where we are.

^^ This right here. The reason this is happening is your senior leadership has decided this is how they want it to be. Vote with your feet.

Hopefully theyll all become plumbers or schoolteachers or something.

There's a glut of junior dev talent and not enough real problems out there which a junior can apply themselves to.

This means that most of them simply arent able to get the kind of experience which will push them into the next skill bracket.

It used to be that you could use them to build cheap proofs of concept or self contained scripting but those are things AI doesnt actually suck too badly at. Even back then there were too many juniors and not enough roles though.

Ten years? They'll be staff, obviously. Three years of experience is senior now, did you get that memo?

This trend started long before AI. Everybody needs 10+ years experience to get a job anywhere. As an industry we've been terrible at up-leveling the younger generations.

I've been fighting this battle for years in my org and every time we start to make progress we go through yet another crisis and have to let some of our junior staff go. Then when we need to hire again it's an emergency and we can only hire more senior staff because we need to get things done and nobody is there to fill the gaps.

It's been a vicious cycle to break.

Vibe coding as a concept started out last December. That was only 9 months ago. I doubt any people will be writing or maintaining code in a couple of years.

Dude, you're basically describing my career - no LLMs necessary!

There will always be software written by people who know what they are doing. Unless LLM generated code is perfect, there will always be a demand for high quality code.

Or maybe it's just not as good as it's been sold to be. I haven't seen any small teams doing very big things with it, which ones are you thinking of?

This so many times over, using/introducing AI in an already managerially dysfunctional organisation is like giving automatic weapons to a band of vikings - it will with utmost certitude result in a quickening of their demise.

A demise that in the case of a modern dysfunctional organisation would otherwise often be arriving a few years later as a results of complete and utter bureaucratic failure.

My experience is that all attempts to elevate technology to a "pivotal force" for the worse is always missing the underlying social and moral failure of the majority (or a small, but important, managerial minority) to act for the common good rather than egotistic self-interest.

I'm rather tired of this ai apologism bit where every downside is explained away as "it would've happened anyways". AI destroying people's brains and causing paychosis? They would've gone psychotic anyways! AI causing company culture problems? The company was toxic anyways!

Instruments are not inculpable as you think they are.

> Executives who interpret "Story Points" as "how much time is that going to take"

aside, but I have yet to meet a single person (dev, qa, pm, exec) who doesn't do this.

> Using it well requires a competent team, working together with trust and transparency, to build processes that are designed to effectively balance human guidance/expertise with what LLM's are good at. Small teams are doing very big things with it.

This reads a bit like "you're holding it wrong". If you need your team and organization to already be in a perfect state before AI usage will stop doing damage, what is the point of it in the first place.

Especially if AI is promoted as a "magic bullet" that will likely especially be uses by teams that are already dysfunctional.

< small teams are doing very big things?

Another claim for AI success, followed by, nothing specific

I saw that study, it was indeed about pilots. When do you ever expect a pilot to immediately start driving big revenue increases? The whole thing is a strawman

This will get written off as victim blaming, but there’s some truth here.

I don’t use Claude code for everything. I’ve fallen off the bike enough times to know when I’ll be better off writing the changes myself. Even in these cases, though, I still plan with Claude, rubber duck, have it review, have it brainstorm ideas (“I need to do x, I’m thinking about doing it such and such way, can you brainstorm a few more options?”)

> These juniors you're complaining about are going to get better in making these requests of AI and blow right past all the seniors who yell at clouds running AI.

I agree with your comment up to a point, but this is pretty similar to pilots and autopilots. At the end of the day you still need a pilot to figure out non standard issues and make judgement calls.

The junior blowing past is as good as how long he will take to fix this issue that all the credits/prompts in the world are not solving. If the impact is long and costs enough your vibe coders will have good instantaneous speed but never reach the end.

I am optimist about AI usage as a tool to enhance productivity, but the workflows are still being worked out. It currently is neither fire all devs, nor No LLM allowed. It is definitely an exciting time to be a senior though :)

Reminds me of the early Google days when everyone was finding ways to search better!

> I think a lot of the impressions of AI generating slop is a case of garbage in/garbage out.

I've been coding for 25 years and what I feel reading posts & comments like in this thread is what I felt in the first few days of that black-blue/white-gold dress thing. I legitimately felt like half the people were trolling.

It's the same with LLM assisted coding. I can't possibly be getting such good results when all the rest are getting garbage, right? Impostor syndrome? Are they trolling?

But yeah, I agree fully with you. You need to actively try everything yourself, and this is what I recommend to my colleagues and friends. Try it out. See what works and what doesn't. Focus on what works, and put it in markdown files. Avoid what doesn't work today, but be ready because tomorrow it might work. Use flows. Use plan / act accordingly. Use the correct tools (context7 is a big one). Use search before planning. Search, write it to md files, add it in the repo. READ the plans carefully. Edit before you start a task. Edit, edit edit. Use git trees, use tools that you'd be using anyway in your pipelines. Pay attention to the output. Don't argue, go back to step1, plan better. See what works for context, what doesn't work. Add things, remove things. Have examples ready. Use examples properly. There's sooo much to learn here.

How will these juniors get better at making those requests when it sounds like they're not interested in understanding what's happening and the implications of it? That requires a degree of introspection which doesn't appear to be taking place if they're just copy/pasting stuff back and forth to LLMs.

The author is giving an account of his experience with LLMs. If those experiences were enough to thoroughly bias him against them, then that's hardly his fault. "Sensible middle ground" is what people appeal to when they are uncomfortable engaging with stark realities.

If someone told me that their Tesla's autopilot swerved them into a brick wall and they nearly died, I'm not going to say, "your newfound luddite bias is preventing you from seeking sensible middle ground. Surely there is no serious issue here." I'm going to say, "wow, that's fucked up. Maybe there's something deeply wrong with Tesla autopilot."

This person understands the future of microwaves.

Pretty much, yes. But what i think you’re talking about (formal verification of code) is a bit of a dark art and barely makes it out of very specialised stuff like warhead guidance computers and maybe some medical stuff etc.

Long story short: no.

Long story: yes, but it'd take centuries to verify all possible inputs, at least for any non-trivial programs.

In theory, yeah. In many ways that's what test driven development is, you keep breaking down a problem into a function that you can write a unit test for, write the test, write the implementation, move on. In practice writing the functions and verifying their inputs and outputs isn't the hard bit.

The hard bit is knowing which functions to write, and what "valid" means for inputs and outputs. Sometimes you'll get a specification that tells you this, but the moment you try to implement it you'll find out that whoever was writing that spec didn't really think it through to its conclusion. There will be a host of edge cases that probably don't matter, and will probably never be hit in the real world anyway, but someone needs to make that call and decide what to do when (not if) they get hit anyway.

In theory you cannot even say for all programs and all inputs if the program will finish the calculation [0]. In practice you often can break it down but the number of combinations of input is what makes it impossible to test everything. Most developers try to keep individual functions as small as possible to understand them easier. You can use math to do formal verification, but that gets difficult with real programs too.

[0] https://en.wikipedia.org/wiki/Halting_problem

No, it is not possible, not only in practice but - more importantly - in theory as well:

https://pron.github.io/posts/correctness-and-complexity

Not really.

If a program is built with strong software architecture, then a lot of it will fit that definition. As an analogy, electricity in your home is delivered by electrical outlets that are standardized -- you can have high confidence that when you buy a new electrical appliance, it can plug into those outlets and work. But someone had to design that standard and apply it universally to the outlets and the appliances. Software architecture within a program is about creating those standards on how things work and applying them universally. If you do this well, then yes, you can have a lot of code that is testable and verifiable.

But you'll always have side-effects. Programs do things -- they create files, they open network connections, they communicate with other programs, they display things on the screen. Some of those side-effects create "state" -- once a file is created, it's still present. These things are much harder to test because they're not just a function with an input and an output -- their behavior changes between the first run and the second run.

No. Not every program can be broken down so. If you want that kind of certainty, this consideration needs to be part of the development process from the very beginning. This is what functional programming is all about.

The real answer is no. You either have to use mathematical verifications with very specific tools (way too hard to use), or use languages that have this built-in (like Ada) but it hasn't been trendy for the past 40 years and people prefer dynamic languages (like JavaScript) where you can do anything without caring about quality.

functional code because it intentionally always takes input and returns output. However not all code is functional and testing has a side effect of making change harder. So if you write a lot of half-useless tests that break when you change anything then you've just made your code harder to change. Even with an AI doing that automatically the damage is contextual, which tests should be removed after a given change and which kept? It requires a decent amount of thought.

Outside of functional code, there's a lot out there which requires mutable state. This is much harder to test which is why user interface testing on native apps is always more painful and most people still run manual QA or use an entirely different testing approach.

There are many implications to this question! TLDR; in theory yes, in practice no.

Can a function be "verified", this can mean "tested", "reviewed", "proved to be correct". What does correct even mean?

Functions in code are often more complex than just having input and output, unlike mathematical functions. Very often, they have side effects, like sending packets on network or modifying things in their environment. This makes it difficult to understand what they do in isolation.

Any non-trivial piece of software is almost impossible to fully understand or test. These things work empirically and require constant maintenance and tweaking.

Not without extraordinary cost that no one (save NASA, perhaps) is willing to pay.

Even if you can formally verify individual methods, what you're actually looking for is if we can verify systems. Because systems, even ones made of of pieces that are individually understood, have interactions and emergent behaviors which are not expected.

What you're describing is basically perfect unit testing. There was even a trend called TDD ( test driven development ) that tried to make the tests the driving force behind building the software in the first place. It works but it has to be perfect and, inevitably, your tests need testing and so you're back to square one. Regardless, it's tedious and time consuming and shortcuts get taken then value of the whole thing falls apart and running the unit tests just becomes like a ritual with no real meaning/impact.

I don't think you understand what the word "objectively" means.

AI tools absolutely can deliver value for certain users and use cases. The problem is that they’re not magic, they’re a tool and they have certain capabilities and limitations. A screwdriver isn’t a bad tool just because it sucks at opening beer bottles.

I need you to tell me how when I just fed Claude a 40 page Medicare form and asked it to translate it to a print-friendly CSS version and uses Cottle for templating "objectivtely" was of no value to me?

What about 20 minuets ago when I threw a 20-line Typescript error in and it explained it in English to me? What definition of "objective" would that fall under?

Or get this, I'm building off of an existing state machine library and asked it to find any potential performance issues and guess what? It actually did. What universe do you live in where that doesn't have objective value?

Am I going to need to just start sharing my Claude chat history to prove to people who live under a rock that a super-advanced pattern matcher that can compose results can be useful???

Go ahead, ask it to write some regex and then tell me how "objectively" useless it is?

The main benefit I've gotten from AI that I see no one talking about is it dramatically lessens the mental energy required to work on a side project after a long day of work. I code during the day, it's hard to find motivation to code at night. It's a lot easier to say "do this", have the AI generate shitty code, then say, "you duplicated X function, you over complicated Y, you have a bug at Z" then have it fix it. On a good day I get stuff done quicker, on an average day I don't think I do. However, I am getting more done because the it takes a huge chunk out of the mental load for me and requires significantly less motivation to get something done on my side project. I think that is worth it to me. That said, I am just about to ban my junior engineers from using it at work because I think it is detrimental to their growth.

If the dotcom bubble is the playbook, then we'll see a burst soon, and in 10-15 years a proliferation that absolutely dwarfs anything we're seeing today.

That's a question every current junior should be asking themselves.

If you want to be well-paid, you need to be able to distinguish yourself in some economically-useful manner from other people. That was true before AI and AI isn't going to make it go away. It may even in some sense sharpen it.

In another few years there's going to be large numbers of people who can be plopped down in front of a code base and just start firing prompts at an AI. If you're just another one of the crowd, you're going to get mediocre career results, potentially including not having a career at all.

However, here in 2025 I'm not sure what that "standing out in the crowd" will be. It could well be "exceptional skill in prompting". It could be that deeper understanding of what the code is really doing. It could be the ability to debug deeply yourself with an old-school debugger when something goes wrong and the AI just can't work. It could be non-coding skills entirely. In reality it'll be more than just one thing anyhow and the results will vary. I don't know what to tell you juniors except to keep your eyes peeled for whatever this will be, and when you think you have an idea, don't let the cognitively-lazy appeal of just letting the AI do everything stop you from pursuing it. I don't know specifically what this will be, but you don't have to be right the first time, you have time to get several licks at this.

But I do know that we aren't going to need very many people who are only capable of firing prompts at an AI and blindly saying "yes" to whatever it says, not because of the level of utility that may or may not have, but because that's not going to distinguish you at all.

If all you are is a proxy to AI, I don't need you. I've got an AI of my own, and I've got lower latency and higher bandwidth to it.

Correspondingly, if you detect that you are falling into the pattern of being on the junior programmer end of what this article is complaining about, where you interact with your coworkers as nothing but an AI proxy, you need to course correct and you need to course correct now. Unfortunately, again, I don't have a recipe for that correction. Ask me in 2030.

"Just a proxy to an AI" may lead to great things for the AI but it isn't going to lead you anywhere good!

for my last project i could not have finished it without AI doing coding. it set up the entire repo for me, it wrote bad code and the PoC worked. I dont have experience in Django JS or webdev. now i have a working thing that i can slowly go through, improve and understand.

>I do think the shift is permanent though. Either you adapt to use these LLMs well or you will struggle to be competitive (in general)

That certainly isn't true if what this article suggests is true.

Can you elaborate on your process and tools here? This use case may actually be valuable for me and my team.

For me it's useful in those areas I don't venture into very often. For example I needed a powershell script recently that would create a little report of some registry settings. Claude banged out something that worked perfectly for me and saved me an hour of messing around.

Yes, totally agree. The 2nd thing I found it great for was to explain errors, it either finds the exact solution, or sparked a thought that lead to the answer.

> We do that for a few rounds, set a direction and then throw it in the trash and start building.

Unfortunately PMs tend to forget the throw-it-in-the-trash part, so the prototype still ends up in prod.

But good for you, if you found a way to make it work.

I feel that even though I'm getting older, LLMs make me feel younger. There's things I learned in university 10 years ago that I only hazily remember but I can easily interrogate an AI and refresh myself way faster than opening old books. Just as a device for recall alone that's been trained on every power point slide that's been uploaded on lecturers websites, it's useful.

While this is true, the push-pull between sales and engineering resulted in software that is built well enough to last without being over-engineered. However if both sales and the engineers start chasing quick short term gains over long term viability that'll result in a new wave of shitty low-quality software being released.

AI isn't good enough yet to generate the same quality of software as human engineers. But since AI is cheaper we'll gladly lower the quality bar so long as the user is still willing to put up with it. Soon all our digital products will be cheap AI slop that's barely fit for purpose, it's a future I dread.

“The only way to go fast, is to go well.” Robert C. Martin

Maybe spaghetti code delivers value as quickly as possible in the short term, but there is a risk that it will catch up in the long term - hard to add features, slow iterations - ultimately losing customers, revenue and growth.

Right; I discovered at the new company I joined, they want velocity more than anything. The sloppy code, risk of mistakes, it’s all priced in to the risk assessment of not gaining ground first. So… I’m shooting out AI-written code left and right and that’s what they want. My performance? Excellent. Will it be a problem in the future? Well, either the startup fails, or AI might be able to rewrite it in the future.

It’s not what I want… but at the same time, how many of our jobs do what we want? I could easily end up being the garbage man. I’m doing what I’m paid to do and I’m paid well to do it.