I have a feeling that people who got bogged down in step 3 were the kind of people who write a lot of wordy corporate boilerplate with multiple levels of abstraction for every single thing. AKA "best practices" type coding.

For me the most important part of a project is working out the data structures and how they are accessed. That's where the rubber meets the road, and is something that AI struggles with. It requires a bit too high a level of abstract thinking and whole problem conceptualization for existing LLMs. Once the data structures are set the coding is easy.

And the article is overstating it as well. My confidence in the LLM's ability to reduce the "how" part is primarily based on "am I doing something the LLM is good at?". If I'm doing HTML React where there's a million examples of existing stuff, then great. The more novel what I'm asking is, the less useful the LLM becomes and the more stuff I need to handcode is. Just as with self-driving cars, this is a challenge because switching from "the LLM is generating the code" to "I'm hand-tweaking things" is equivalent to self-driving disconnecting randomly and telling you "you drive" in the middle of the highway. Oh and I've caught the LLM randomly inserting vulnerabilities for absolutely no reason (e.g. adding permissions to the iframe sandbox attribute when I complained about UI layout issues).

It's a useful tool that can accelerate certain tasks, but it has a lot of sharp edges.

I agree, they are very much exaggerating both time spent writing code, as well as the amount of time LLMs shave off. LLM coding very much does NOT take “near zero time,” I would argue that sometimes it can take the same amount of time or longer, compared against simply knowing what you are doing, with tools you know how to use, referring to documentation you know how to interpret, understanding the systems around, the business around, what team A and C need in two quarters so we better keep it in mind… etc.

I think you're overly painting that process as a waterfall method. In reality, i think its more of a loop. You do the loop a bunch of times and the solution gets better and better. The act of coding sometimes exposes a lot more of the requirement questions you didn't even know to ask in the first few steps.

So anything that can let you iterate the loop faster is good. The analogy is kind of like if you can make your compile and tests faster, its way easier to code. Because you don't just code and test at the very end, you do it as part of a thinking loop.

[Replying to the quoted part.]

So when it is convenient, the waterfall model is suddenly modern again?

The waterfall model didn't work, because many inefficiencies and wrong assumptions are found when writing code. This is also the advantage of Lisp and other languages that are malleable and not like a block of concrete.

LLMs are like a block of concrete in that they spit out the same (plagiarized) solutions over and over again. They remove you from the code, they impede flow state due to the constant interactions and outsource your thinking to some GPUs in California.

This waterfall rationalization is just one of the latest absurdities in the LLM blogging industrial complex.

I'm somebody who used to think your way until very recently (long-time vim user, fast typer, etc.).

I'd recommend you give `aider` specifically a try. It's slowly taken over more and more of the "what" and "how" buckets outlined in the article, especially for large-surface-area code bases.

It turns out, for me at least, there is a big mental activation hurdle between "what" and "how". I need a lot of focus time to pivot between "what" and "how" efficiently, especially for work that spans large parts of the codebase, and work that I'm not super excited about doing. Using `aider` has lowered this activation threshold dramatically. It's made "writing code" about as simple as talking about a technical solution with an intelligent colleague.

I usually follow the format (1) describe the context of the app / problem you're trying to solve (2) describe what you know the solution will look like (3) ask it for clarifying questions / if it needs any examples or context to know the problem space better, and if the solution makes sense / do they see any issues with it? (4) ask it to outline the solution in greater detail, do not write code (5) add any clarifications, now do the thing.

i.e. it's kind of similar to interacting with a super fast, eager, indefatigable junior engineer. Sometimes it misses things or misunderstands, but not nearly enough to make the juice not worth the squeeze. These days, I'd say I spend more time reading/editing claude-generated code, writing commit messages, and managing deployments than I do writing code. It's a higher level of abstraction and I get way more leverage out of the deal. The code I'm writing is, on balance, better than the code I wrote before. It took maybe a few months to get here, but I'm happier for giving it a shot.

>That last part is actually the easiest

If it were, the median e.g. business analyst should be getting paid significantly more than the median software engineer. That's not what the data shows, however.

>I can genuinely say in all of my programming projects, I spent more time understanding the problem than writing code.

This is almost trivially true for anyone who understands the problem via writing code, though.

For many developers the first couple of items isn't a thing, we're just given requirements and the designs. At most, you can point out issues and do time estimates.

For my current job coding is 90% of my time. The rest is meetings, deployments, ticket management. Most of the time coding isn't particularly hard, but it sure consumes lots of time. I've had many days with 1000+ line diffs.

> That last part is actually the easiest

The last part is wrong, unless it's purely greenfield.

Instead, you first need to read and then modify existing code and ensure it can later be still understood and easily/safely changed by whoever works on it. That is the hard part that is totally missed here.

> Traditionally, coding involves three distinct “time buckets”: > Why am I doing this? Understanding the business problem and value

> What do I need to do? Designing the solution conceptually

> How am I going to do it? Actually writing the code

This is why when people call programmers coders it feels wrong imo

I expect this is fairly domain dependent. Not all programming is CRUD endpoints, some of it is genuinely finicky.

At least for me, one example of such programming is low-level database adjacent systems programming, it can take an extreme amount of fiddling to get it to work as you intended, even if you have a clear idea of what you want to implement.

Though, in the cases where the last part is hard and time consuming, LLM-based tools are not going to be of particularly big help (and in fact, is personally where I tend to disable CoPilot because it is more likely to be a distraction than useful).

I think you've nailed the key point. A lot of "coding" isn't actually writing code, but understanding the problem space and designing a good solution. If I'm spending too long wrestling with the implementation, it's usually a sign that I didn't fully grasp the problem upfront or my design is flawed. Good tooling helps, for sure, but it's no substitute for solid problem analysis.

I can imagine that those who prefer a hands-on approach might spend more time understanding the problem, as they need to read through the code and debug to identify what is wrong.

> With Claude, that time cost has plummeted to nearly zero

Only for short code you want to throw away.

If you care about the quality of the code -- how it is organized, naming things, meaningful tests it's not.

LLMs have gotten so much better at code that I'm surprised I still don't vibe code, but it's just laughable at how bad they are stil -- test cases that just add fluff and just how "autistic" they seem and how much they miss in context that a human would not miss.

I recently changed some code where a null was returned previously and what I really needed was sort of a java Optional but with a Reason for why the value returned was not present -- I called it AdviseDecision -- it had 2 constructors -- either the value returned or the reason a value could not be computed.

I then asked Gemini 2.5 to refactor a piece of code that dealt with the null previously.

Gemini 2.5 could not jump to the conclusion that it was not possible for both the computation result or the failure to compute could not be null at the same time.

Anyway, the examples of when LLMs fail are becoming the exception and it shows how good they have gotten, but I would never says cost time plummeted to nearly zero.

For me the biggest advantage is that even though I only get about a 30% programming speed boost, I get a 300% productivity boost because I procrastinate much less, because for me it's easier to fix/modify the LLMs tasteless code than getting over the initial bump of starting from scratch.

It probably is a contradiction then that I say LLMs are so bad and so good at the same time.

> I spent more time understanding the problem than writing code.

This. Yet more often than I would like the challenge is not understanding the business side of the side problem but dealing with the existing code...

Overall I find that each one of the three time buckets are equally important and I strive to iterate quickly between them. Pretty often the existing code somehow challenges the assumptions I made in the two previous steps, both business-wise and design-wise.

The final piece (writing code) eating more than 10% of your dev time "for decades" is a good indicator to find a new career imo.

> With Claude, that time cost has plummeted to nearly zero.

not sure if anyone knows. how good would a bigquery-sql to scala parser generated code would be? can i use it without having to dig into generated code?

I'll second this. The last part is the easiest and the one I spend the least around of time on.

If someone thinks the last part is the most difficult, then they probably aren't an actual programmer.

> That last part is actually the easiest, and if you're spending inordinate amount of time there, that usually means the first two were not done well or you're not familiar with the tooling (language, library, IDE, test runner,...).

I'm not sure if you're familiar with modern JS frameworks.

How do you understand the problem without writing any code?

It's possible that people's experiences are different to yours because you work on a specific type of software and other people work on other specific types of software.

> So much of programming is just learning a new API or framework.

Once you're good at it in general. I recently witnessed what happens when a junior developer just uses AI for everything, and I found it worse than if a non-developer used AI: at least they wouldn't confuse the model with their half-understood ideas and wouldn't think they could "just write some glue code", break things in the process, and then confidently state they solved the problem by adding some jargon they've picked up.

It feels more like an excavator: useful in the right hands, dangerous in the wrong hands. (I'd say excavators are super useful and extremely dangerous, I think AI is not as extreme in either direction)

I've been using it to learn Lean, the proof assistant language, and it's great. The code doesn't always compile, but the general structure and approach is usually correct, and it helps understand different ways of doing things and the pros, cons, and subtleties of each.

From this it has me wondering if AI could increase the adoption of provably correct code. Dependent types have a reputation for being hard to work with, but with AI help, it seems like they could be a lot more tractable. Moreover, it'd be beneficial it the other direction too: the more constraints you can build into the type system of your domain model, the harder it will be for an AI to hallucinate something that breaks it. Anything that doesn't satisfy the constraints will fail to compile.

I doubt it, but wishful thinking.

Yep, I absolutely relate to this. ChatGPT happened to come out right when I needed to learn how to use kubernetes, after having used a different container orchestrator. It made this so much easier.

Ever since, this has been my favorite use case, to cut through the accidental complexity when learning a new implementation of a familiar thing. This not only speeds up my learning process and projects using the new tool, it also gives me a lot more confidence in taking on projects with unfamiliar tools. This is extremely valuable.

Also agree. I've been playing with Godot for some super simple game dev, and it's been surprisingly fantastic at helping me navigate Godot's systems (Nodes, how to structure a game, the Godot API) so I can get to the stuff that I find enjoyable (programming gameplay systems).

No, it's not perfect and I imagine there's some large warts as a result, but it was much, much better than following a bog-standard tutorial on YouTube to get something running, and I'm always able to go refactor my scripts later now that I'm past initial scaffolding and setup.

> primordial swamp of data science

This deeply resonates with me every time I stare at pandas code seeking to understand it.

Yep, same. I'm an old hand at pandas, and writing a 300 line script in pandas and asking Claude to rewrite it to polars taught me polars faster than any other approach I've used to learn a new framework.

I am pretty much in the same boat, although I was never that advanced a dev to begin with.

It is truly amazing what a superpower these LLM tools are for me. This particular moment in time feels like a perfect fit for my knowledge level. I am building as many MVP ideas as quickly as I can. Hopefully, one of them sticks with users.

> LLM also don't tend to question its own decisions in the past, and will stick with them unless explicitly told.

Dangerous as well, is that LLMs won't (unless aggressively prompted to) question your own decisions either, in contrast to something like a mentor which would help you discover a better way, if there is one.

> LLM also don't tend to question its own decisions in the past

An attribute I would like to see is the ability for an LLM to express justified self-doubt. Likewise (and perhaps directly related) would be the ability to self-critique prior to providing an answer. It's possible they are already steered to do this; if so I would like to see more of that dialogue surfaced to the user.

[dead]

Simon Willison nailed exactly this 2 years ago:

> I've been thinking about generative AI tools as "bicycles for the mind" (to borrow an old Steve Jobs line), but I think "electric bicycles for the mind" might be more appropriate.

> They can accelerate your natural abilities, you have to learn how to use them, they can give you a significant boost that some people might feel is a bit of a cheat, and they're also quite dangerous if you're not careful with them!

https://simonwillison.net/2023/Feb/13/ebikes/

If you and Lebron both had mech-suits you'd be equal in strength. Actually you might find that maybe you communicate better with the machine as you've had to communicate a lot more for work and have further refined those neural patterns. So actually, I would expect those with exceptional communication skills and creativity to be the best able to take advantage of AI. In a world where functional code in any language can be spat out at 1000 tokens/s, it matters a lot more that you can communicate your vision than understanding the inscrutable byte-level architecture of ARM-64 or how to write a CUDA kernal, or how to use a static class properly.

Analogies are traps for the mind.

What if LLMs are cars for the mind not bicycles?

Both I and Usain Bolt get a Prius. Who is faster at the shopping mall? What will happen to our fitness? Who will be the next Usain Bolt and would we even care?

I don't think bicycle analogy is adequate. It seems that they are more like cars. And if we follow that analogy, it suggests that the direction of the evolution will depend on whether we make our society dependent on being able to drive cars and grow fat from lack of activity or use them in a more mindful 'for purpose intended' way.

> If everyone has AI, then competitively no one has AI, because that means you are what drives the differences.

Except everyone doesn't have AI. Only huge corporations with billion dollar data centers do. What happens when Sam Altman decides to de-prioritize you? The little toy model you downloaded from github won't cut it.

These AI tools shift a lot of power into a few Silicon Valley companies. Keep those skills sharp, you'll need them. Best case scenario, the VC money bonfire runs out of fuel before 3 companies own the entire software industry.

On my side we've refrained from hiring people/training people due to AI. Its mostly been a good decision especially at the frontend layer where those teams are starting to do more with less. Don't get me wrong - I don't like the path the SWE profession is going and I'm not an AI fan for a variety of reasons. But at the same time I don't want to over hire and have no work for the people to do (i.e. the bottleneck being business ideas, regulation, ability to iterate in our domain, etc rather than tech). I can't just "work faster" and "ship more" - you start hitting other bottlenecks. Over hiring is not a great problem to manage either; morale at the very least decreases as people have no work to do.

The people in those bottlenecks anecdotally are seeing pay increases btw which goes to show - the inefficient get the spoils.

ceos found AI as escape hatch for their over hiring during pandemic boom year.

they were just playing to this market reaction

layoffs = bad

layoffs because of AI = good

This is my experience as well. I've been skeptical for a long time, but recent releases have changed my mind (it's important to try new things even if skeptical). Large context windows are game-changers. I can't copy/paste fast enough.

The future is coming, but you still need fundamentals to make sure the generated code has been properly setup for growth. That means you need to know what you expect your codebase to look like before or during your prompting so you can promote the right design patterns and direct the generation towards the proper architecture.

So software design is not going away. Or it shouldn't for software that expects to grow.

> The human-LLM boosting interaction exists particularly when you use the LLM in its chat form

I feel reassured to see that I'm not the only one who feels this way. With all the talk about in-IDE direct code editing, I was thinking that I was being somewhat of a luddite who feels like the chat form is the best balance between getting help from the AI and understanding/deciding how things are actually structured/working.

What you describe as #2 is more or less what I do, and I use CC to do that.

I also have both GPT and the Claude UI open and I will often flick out to one or the other (Claude seems to be a lot better at Elixir code for me than GPT) and go into “discussion” mode if I want to open the aperture on a topic.

I’m certainly never letting (not at anymore, at least) it go and wrote swathes of raw code on its own. I learned that lesson the hard way. It generates absolute nonsense if left to its own devices.

2. is mostly what works for me.

Usually when I am in the flow of writing code, I can think, write, tab away and review without breaking it. If I need a smallish (up to 100-ish lines) piece of code that I know the shape of - I would use the chat to generate it and merge it back after review.

Letting the agent rip always has led to more pain and suffering down the line :(

I've also settled on a copy-paste LLM workflow.

I can see the usefulness of agents however for (a) some tedious refactorings where the IDE features might not reach and (b) occasionally writing a first pass of a low-value module when I am low on energy.

For the rest of stuff I feel very happy with copy-paste.

Yes, price elasticity increases the demand for software work in total, including LLMs and humans. But to me at least, it is not clear that humans will increase their total amount of work as LLMs obviously do. Is it possible that LLM coding grows faster than the total, so that the human piece of cake actually shrinks?

And the only way to be 100% sure is to have written exactly the same thing before, which makes zero sense.

And just like optimizing compilers LLMs also emit code that is difficult to verify and no-one really understands, so when the shit hits the fan you have no idea what's going on.

[dead]

That's kinda obvious that's their goal especially with the current focus on coding of most of the AI labs in most announcements - it may be augmentation now but that isn't the end game. Everything else these AI labs do, while fun seems like at most a "meme" to most people in relative terms.

Most Copilot style setup's (not just in this domain) are designed to gather data and train/gather feedback before full automation or downsizing. If they outright said it they may not have got the initial usage needed to do so from developers. Even if it is augmentation it feels like at least to me the other IT roles (e.g. BA's, Solution Engineers maybe?) are safer than SWE's going forward. Maybe its because dev's have a skin in the game and without AI its not that easy of a job over time makes it harder for them to see. Respect for SWE as a job in general has fallen in at least my anecdotal conversations mainly due to AI - after all long term career prospects are a major factor in career value, social status and personal goals for most people.

Their end goal is to democratize/commoditize programming with AI as low hanging fruit which by definition reduces its value per unit of output. The fact that there is so much discussion on this IMO shows that many even if they don't want to admit it there is a decent chance that they will succeed at this goal.

> We've already started attacking the future by mocking it as "vibe coding".

The term ‘vibe coding’ was coined by OpenAI’s co-founder.

https://x.com/karpathy/status/1886192184808149383

Copy/paste coding isn't exactly a new idea, it just got a lot easier and more popular.

Have you considered, you may be working in a dysfunctional organization, spending only 5% on the activity that translates into actual value to the end user?

That's why these AI companies are racing to build a replacement for you and me, something that will spend 100% of its time actually building out functionality the customer is looking forward to.

I know, I know, spending 100% of our day coding is ridiculous because that all-hands conference call to get everyone onboard with which microservice is responsible for storing button colors absolutely has to happen first.

Yup! Anyone who is in AI right now and didn't follow the chess engine world from 15 years ago is basically a fraud. Centaurs are WORSE than chess engine alone for literally at least 15 years now.

We had all the same shit that's going on with LLM labs. Benchmarks with elo scores, leading model providers cheating (Rybka), big companies jumping in (DeepBlue), even a fucking equivalent to RAG (pre-made opening books) and I guess an analogy to prompt optimization (end game tablebases?) It's all a repeat of shit I saw in 2009.

> But the key is not jumping straight into code generation.

That's a bingo!

My workflow is to attach my entire codebase (or just the src folder + auxiliary files like sql schemas) to a Gemini 2.5 pro chat and ask it to write an implementation plan in phases for whatever feature I need, along with a list of assumptions, types, function signatures, documentation, and tests. I then spend a few minutes iterating to make sure it uses the right libraries, patterns, and endpoints. I copy paste the plan into plan.md and instruct Cursor/Windsurf/Aider/etc to implement phase 1 of the plan, saving implementation notes to plan-notes.md (both markdown files are explicitly included in the context). Keep telling it to "continue" and "keep going with the next phase" as needed. The implementation notes keep the LLM "grounded" in each step and allows creating a new chat context when it grows too long or messes up, requiring a git reset.

The alternative first step - when I'm working on an isolated module that doesn't need to know about the rest of the codebase but is otherwise quite complicated - is to have Gemini Deep Research write a report about how to implement that feature and feed that report into the planner.

The other important part is what I call "self reflection." Give the plan or research report to an LLM and ask it about improvements, pitfalls, tradeoffs, etc. and incorporate that feedback back into the plan. It helps to mix them up, so i.e. Claude and GPT review a Gemini plan and vice versa.

Theoretical limitations of multi-layer Transformer https://arxiv.org/abs/2412.02975

On Limitations of the Transformer Architecture https://arxiv.org/abs/2402.08164

Limits of Deep Learning: Sequence Modeling through the Lens of Complexity Theory https://arxiv.org/abs/2405.16674

TL;DR transformers are inherently limited with tasks requiring composition of sequential steps

Agree with most of what you said except for the "big bucks" part. Why would I pay for your product when I can ask the AI to do it? To be honest I think I would rather use that money for anything else if I can spend a little bit of time and get the AI to do it. This is quite deflationary for programming in general and inflationary for domains not disrupted all else being equal. There's a point where Jevon's Paradox fails - after all there's only so much software most normal people want and at that point tech workers value relative to other sectors will decline assuming unequal disruption.

The ability to earn the big bucks as you state is not a function of the value delivered/produced, but the scarcity and difficulty in acquiring said value. That is capitalism. An extreme example is clear air that we breathe - it is currently free, but extremely valuable to most living things. If we made it scarce (e.g. pollution) eventually people would start charging for it; potentially at extortionary prices depending on how rare it becomes.

The only exception I see is if the software encodes a domain that isn't as accessible to people and is kept secret/under wraps, has natural protections (e.g. a government system that is mandatory to use), or is complex and still requires co-ordination and understanding. This does happen, but then I would argue the value is in the adjacent domain knowledge - not in the software itself.

yeah he's really underselling the recent models' ability to do the "Designing the solution conceptually" part. I still have to be in dialogue with the AI - I ask a lot of questions, we iterate towards something - but I cover conceptual ground much more quickly this way. and then I still have to be the glue between "design" and "writing" steps, and have to manage that carefully or I get slop.

if you look at the change in capability over time, it looks like the AI are climbing this hierarchy. "Centaur" seems to already be giving way towards "research assistant". I hesitate to make predictions but I would not place money on things stabilizing here.

The SWE-bench verified score for frontier LLMs will probably reach/surpass 90% by the end of the year.

Agentic AI will learn to complete a larger and larger chunk of the practical software development process without much human input.

> GenAI takes that away.

Not for me. Put me at a company with a codebase in technology Z and I can learn it MUCH faster than starting from the docs. I will still read the docs, but everything goes far, far faster if you start me out in an existing codebase.

You can use GenAI the same way. Get a codebase that's doing a thing you're interested in immediately and dive right in. You do not HAVE to be tempted into being a passive observer, you can use it as a kickstart instead.

We've collectively spent decades trading almost anything in favor of convenience. LLMs will be the same, and AI if we get there.

I'm of the opinion that we'd be a lot better off if convenience was a lot further down our priority list.

With chess, there are some pathological cases where humans outperform the computers. I recall seeing an example where the position was almost completely deadlocked.

With the weaker engines that run on browsers, you'll still catch cases where GMs have a good understanding of the position, and it takes the engine some time before the engine's understanding catches up. -- e.g. the GM will be explaining "this position is good", but the computer eval shows +1 before then climbing to +5 after some time.

Similarly, I recall a popular technique in videos where GMs play cheaters is for the GM to then adopt a solid, defensive structure. The engines then just shuffle pieces around. (Again, I suspect that's with the weaker engines running on the computer).

Though, some of the "engine vs engine" games I've seen have involved wild and inhuman play. -- In those cases, that's where I'd doubt humans would be of much help. I don't think AlphaZero+human would beat standalone AlphaZero.

Doesn't seem true to me either, but AI can absolutely not perform an exhaustive search of the game space, there are far too many possibilities.

I doubt it will come to that. Most interactions are always going to be much easier with a dedicated UI than with a chatbot. In fact, I can't think of anything I use regularly that I'd rather replace the UI with chat.