I follow the same process. I have a design in mind for the problem at hand, but I don't reveal it to Codex. I go back and forth a bit to see if its proposals are better than mine. I go back and forth on tradeoffs of various approaches. And then I ask it to compare its proposals with mine. I "win" most of the time but there are many times where it shows a me a better, or simpler approach, or makes me rethink the solution altogether.

Once this is done, the mechanical coding parts are mostly routine (for codex)

Despite the cynical sibling reply, I also feel like there's real value here. Contrary to the meme, I don't think Claude just tells me I'm brilliant, but really does push back on directions that are unproductive, helps identify when a part is overcomplicated or a dependency has become redundant, etc. Those are important things to have at least a sightline on before getting too deep into the code, even (or maybe especially) in a world where an awful lot of code can be created basically for free.

>> and still largely understand the code [...] ,that, I feel has made me a better engineer

the cynic in me would say that a good engineer should fully understand the code you write.

I'm not suggesting that AI is the problem here - you could vibe code with the AI have have it explain the reasoning and patterns - or else tell it to use 'simpler' patterns from the outset. For any one problem in software engineering, there are always multiple solutions; some slower, some faster, some more flexible etc. The code you produce should, imo, but at the level that you can understand it.

How can you reason about code you don't fully understand? How can you judge the future impact (technical debt and the cost of maintenance) of your projects?

A.I makes it easier to get yourself into problems early on.

One strategy I use in the planning phase is even when I know how I'd implement the solution, I ask the Claude/Codex how they would solve the problem or implement the feature without giving them any clues - and then compare their solutions to my own. Often I am pleasantly surprised by alternative ways of doing things and ideas that we integrate into the final design.

"yes exactly. Too many people ask AI to one-shot complex tasks, and wonder it behaves like a junior asked to rush something."

Because this version of AI is worth 10 trillion dollars.

While the pragmatic versions from realists you can find all over this thread are ultimately probably less of a speed boost than just having your CEO/local micromanager be conveniently on vacation during critical periods when the work actually gets done.

My personal experience with trying to front-load tons of planning and speccing out with LLMs is that at best it's a small improvement on code quality but with considerably more time spent.

As a result I've abandoned the idea of having LLMs generate code except for very small, localized and tightly scoped things. They really can't produce much more than a function or a small module without shitting the bed (last time I vibecoded was with Opus 4.6, Composer 2 and GPT-5.4). I use it almost entirely as another signal in analysis, which naturally makes it fit in better because all the other signals (reading the code, stepping through the code, writing the code myself) are already there so when the LLM points things out the information it actually renders can be taken in much more easily (and seen through more easily when it's false or irrelevant).

I think it's neat that people find fun ways to develop, but I think dressing up vibecoding in a fancy dress and layering SpecLang, sometimes in multiple steps, on top of it, is an exercise in trying to use the tool more instead of trying to use it in its most useful capacity.

Even fully planned it’s still no better than a junior dev. You’re leaving out how much back and forth you have the ai do on itself, which you’d have on a junior dev too. In the end does it matter if it’s giving you what you want? Guess not really. But let’s not act like it’s crazy good when you’re still doing a lot of rounds of revisions on something an experienced dev would know to do right the first time.

I think that in general, people need to understand that they need to invest most of their time in the planning phase. High level plan, then spec are the baseline imo

I've stumbled upon that too! Funnily I see it having two forms:

1. Some bad idea gets embedded into the context that you just can't argue away

2. Some important idea gets lost in compression and the ai wheres off into funland without recourse.

In both cases if is often better to start over or just do it yourself. I sometimes find myself asking for a summary, editing it and then using the edited one to seed a new session.

Edit: s/Finland/funland/

A lot of people say you need to go through at least three versions of something before it is mature - and v3 is not something you can design upfront. You need to see v1 both in code, and at runtime. Use it, get the feedback, and iterate. This is where AI tightens that loop immensely.

Lost you in the last paragraph - features are not "copy pasting because you already have all the building blocks" and "something may be twenty lines of code". Mid sized features often mean tearing up many layers of code across the stack to add in some sort of new capability. Tearing up existing code means there are all sorts of add-on considerations in addition to feature you are working on.

> represented in the training data

This isn’t a binary is/isn’t thing though. What if only 80% of my task is, how would I know that the other part isn’t, if I haven’t worked it through fully

What if my task is generally represented, but for my specific context, there are specific details that aren’t?

How would I know until I’ve reasoned through it myself? At that point having the LLM do the work doesn’t add much value

Meaning the code comes to you out of nowhere faster than you could write it down. At peak performance, there is no you in the process, you just not preventing it from happening. That's what flow state is. The more skills, the better tools you have (such as typing speed, fine tuned IDE) the longer you could stay there.

What an arrogant comment. You have no idea what kind of software the parent commenter is working on. If you think all software can be handled by AI then I'm afraid you're the one who doesn't know what they're doing.

I manage a component of an internal compute product which serves ~a billion idempotent use-cases per quarter and I can confidently tell you that you're incorrect.

What I haven't been able to teach AI is the full distributed nature of the system, how we progressively roll out each service (about ~30 unique ones) when we push updates -- and how to read, write, and review my code while keeping all of this in-context (because believe me, if it's not in-context, it is useless to me). Don't get me started on all the containers, K8s configs, endpoint naming conventions...

My entire stack covers bare metal, virtualisation infrastructure, storage infrastructure... I could go on. At a certain scale, it doesn't matter how fast you write something, but if what you're writing is bulletproof.

Or, if we consider the fact that an LLM’s performance depends on the task’s similarity to others in the training set, it could be that one person is doing a fairly novel task and another is doing something very well represented in online code.

This sounds like a subjective assessment. I counter with the opinion that most LLMs write technically correct, but bad code. When I read it, it makes me want to gag or poke my eyes out. I spend a lot of time wondering about what kind of person would write it like that, then I realize it’s an LLM

The tool is important but then so it's the way you use it. I've seen small LLMs produce good code and frontier LLMs produce poor quality code. Depending on context..

This is delusional. Opus 4.7 regularly produces pretty bad code.

Source trust me bro.

I've noticed that too, once you get an initial implementation it seems to always find a way to argue for keeping that approach in the name of simplicity

Like "Let's stick with what we have, its simple and it works." or "That seems overkill, let's not over complicate things"

I've got to the point where sometimes I frame my question as if I disagree with it, just to allow the AI to "agree" with me and actually critique it.

"My team mate wants to X, but I feel like that might be a bad idea. What could go wrong?", etc.

In this vein, I have a system level memory for Claude to push back and give me direct feedback when possible. So far a success as it helps cut through the sycophancy.

Huh, good point! When a colleague asks me to review their design or otherwise discuss it, I'm always looking for things they might have missed, assumptions they silently made, or corner cases that could come up. I start from the position that there is likely something missing and I need to find out what. Likewise, when I'm looking at suggestions or code or anything else from an AI, I'm assuming it made some mistakes, made some unstated assumptions, or didn't consider some corner cases, and so I'm having to carefully think through what it says to spot the mistake, rather than casually skimming it and going, "LGTM!" If it were too reliable, I might get lazy and not look too hard knowing that it's probably right anyway so there's no point trying too hard to find something. It's the same thing my juniors will sometimes do to me: don't assume I'm right just because I'm experienced - I still make mistakes too! I want to be questioned on anything that might not make sense, because even if it was intentional, the fact that the reason isn't clear is itself a problem to resolve. And I only know so many things - we all have different experiences and a junior can have just as much they can teach me as a senior.

The vast majority of corporate-employed programmers write bad code. I think maybe 10% of the people I’ve come across have shown any interest or care in the quality of code they write.

There will be a large majority of people who hold these opinions, because they weren’t capable of or didn’t care enough to write good code in the before times

> arguing that code quality doesn't matter, and quality produced by humans in the past was often terrible

You're conflating two different things. I'm one of the people arguing for the latter, but not because I don't think code quality matters but as a counter to to sudden idealization of handcrafted code.

But how do I know if something works if I don't know how it works? By testing (literally) all use cases, every single permutation of of variables? For complex programs there might not be enough time and energy in the universe to do that.

If I know what addition is, I can look at at a line that does addition and reason about it. If I just check "if it works", for all I know, the actual code is something like

    if (thing == 17)
    {
      shit_the_bed();
    }
    else
    {
      thing += other_thing;
    }

It's kinda like cheap/fake concrete: If you know something about concrete and what concrete is being used, you can roughly tell if it will last, what it will withstand. If you just go by "seems to work", "looks good", you get collapsing bridges and buildings after a few years, during heavy rainfall etc.

I treat it like other triage tasks: things could always be better, but how much effort does it take and how much better could it be?

There's a common saying that the enemy of good is perfect. It's easy to get stuck in the loop of endlessly polishing something but never actually releasing it, even without AI. It's on us to decide how good is good enough and when to stop.

Over time I've learned to be rather aggressive about cutting out work. I'll quickly ask myself how serious is the issue (does it give wrong answers? block important flows? look embarrassing? or is it just a minor annoyance?) and how much effort would it take (five minutes? two hours? three weeks?). I should be able to make that call in no more than 30 seconds. I skim through the list of 20 suggestions the AI gives, I make plans to iterate on the 3 that are serious, and I simply accept that the rest are "good enough". It's not easy - both to be willing to let issues stand and to make the decision about what is good enough - but it's an important part of the job when triaging lists of bug reports and feature requests, so it's something we need to get good at anyway.

I find that to not get into this doom loop is to make sure the solution is not overengineered in the first place. AI will pile on complexity to infinity unless you actively gate it.

This can backfire a bit on token usage where it gets a bit to trigger happy running expensive things for trivial changes. I tend to not use sub agents for this reason. I actually manage to cover most my needs on the 20$/month codex subscription. I might switch to the 200$ plan at some point. But right now I just need to be economical as our company is fairy resource constrained. That's also why I prefer Codex over Claude Code. It seems it gets the job done for less $. Another advantage is that it seems to have less need to have things like this spelled out in this level of detail.

Another thing is that unless you are doing really complicated stuff, you probably don't need the latest models running on high. I'm still on 5.4 medium with codex. I see very little reason to change that.

Part of agentic engineering is figuring out how to be economical with tokens and time. You can sacrifice one for the other of course. But there are diminishing returns as well where spending 10x more doesn't actually get you 10x more quality/results.

> once all the code seems okay, you will run THREE parallel sub-agents for code review: each looking at ALL changed code

I did some evals with a prompt like this when I had some subscription tokens to burn, a few months ago. I think using Opus 4.5. What I found was:

1. Running two subagents was somewhat useful

2. Running three started to get redundant

3. Any more than three was pointless (at least when using the same model)

However, even two were getting like 60% the same results.

Much, much more effective was splitting out into audits through different lenses:

* One looking for security issues

* One looking for whether the task was completed successfully

* One looking for performance issues

* One looking for contract/maintainability issues

* One looking at test coverage

Etc.

> as long as it continues to be tangibly better these people will still exist

Sure. But how long will that last? LLMs are getting better at programming much faster than I am.

Imagine a plot with time on the X axis and LLM skill on the Y axis. The line goes up and to the right. On the left is GPT3, or GPT3.5 with the very first glimmers of programming ability just a few short years ago. In the middle is Opus 4.7 now.

Where's the intersection point, where AI skill is higher than that of humans? Less than 10 years. I'd guess less than 5 years.

>rocket fuel

Did you write this comment with AI, or can you explain why so many people use the exact same terrible metaphor?

And you act like there hasn't been a loss once we moved away from the master craftsman style of building to the professionalized architect style of building. We cannot make a gothic cathedral amymore. also CAD, homogenized the built environment, significantly. And we have been losing a lot of traditional, artisanal craftsmen art forms over the past century. artisanal craft mounds,

There at a lot of crafts that don’t have real deep experts anymore because the work was 90% automated.

Did they? Genuine question, because I do wonder if people in some industries in the past were ever anxious about these specific things (especially skill attrition).