CurleighBraces

Entirely agree, also things can be logically correct and well tested but not the behaviour the user intended.

Even if that's down to a bad initial prompt, or lack of data for the agent to notice the edge case I don't see how you can ever engineer a better agentic solution unless as a human you're monitoring the output.

I would argue really it's less than 9 months. At the start of the year then models/AI really weren't capable of shipping production code etc without hand holding...

Todo's left in code, mock implementations instead of fully working, people doing Ralph loops etc

It's an entirely different situation now

I admire the will power of the people able to do this.

There's just no way I could go back to writing code by hand with the temptation of AI right there in front of me.

Well, there's a fascinating insight, most orgs I've ever worked for have had the documentation produced by someone else and them implemented by the developer.

For instance the enterprise architect/solutions architect ( or whatever job title is fashionable at the time ) would write the document and then send it over to the development team and obviously that wouldn't work.

I actually adopted the conceptual/logical design from two ex Hewlett Packard engineers/architects who introduced the idea to me, probably some twenty years ago now!

Yep we're strong in many other ways, but finding the transition to AI challenging :)

Reviews have somewhat turned into, I send you the output from my AI agent of choice, and you tell your AI agent of choice to fix it :)

Thanks again for the time taken to reply :) It is appreciated.

Thanks for taking the time to reply, please take my response as earnest attempts to better myself :)

So, I think I didn't elaborate on the process enough to get the answers I was looking for. Here's what happened.

1. I would uncover a requirement from the business 2. The conceptual design would be written, high level understanding of the feature etc that was trying to be written 3. Conceptual design would be signed off 4. Logical design would take place ( I think this is basically everything from the Constraints section down in your model ) 5. Logical design would get reviewed and signed off.

Now technically everyone could and was encouraged to sign off the logical design, but in reality maybe one other person in the team would, I don't really know the reasons why.

Then implementation start, this was usually NOT me but another team member tasked with the design, and this is where the process really started to fall down with the onus being put squarely back on me as to why the design didn't work :)

I also actually tried the other approach, implement as much as possible ( because AI fast ) and then reverse engineer the design, but then that very much felt like, what the hell is the point now? I might as well just use the standard code review process.

Does that make sense? Sound familiar?

So I tried this and it failed miserably.

The documentation became the bible, and although I tried to keep the design goals at the conceptual/logical level the following would happen the moment the implementation started:

1. This is ambigous the docs need updating, please refactor your design 2. This doesn't work as the doc stated why did you get this wrong 3. The requirements have changed you need to update it

The burden to get "everything right" was absolutely lumbered of me, and the document became an easy finger pointing exercise, even if blame wasn't intended by those launching the critique the burden of "owning" the doc and the consequences of the doc was real.

Now there's a good chance that I am just a shit documentation writer, I can accept that, but honestly I feel like for the vast majority of organisations this just falls into another step of the waterfall pattern, which just doesn't work.

How do you handle this? What did I miss?

I feel it's more nuanced than this, at least for now.

It's true to say anyone can build software, but that doesn't make the software good and it's not true to say that's specifically reliant on taste.

As an example I am working with an Entrepreneur right now who has no coding experience but have successfully made a product which they have also already sold to a mid sized company.

However without my involvement and knowing the right levers to craft the AI the software just wasn't performing how it needed to despite the latest frontier models trying their hardest to achieve what he was stating.

At least for now there's still a need for experienced devs.

This reply makes me think that my original post also comes across as overly dismissive of reasonable debate around code changes.

As you've stated, years of development has made me expect a certain level of discourse as people will inevitably want to defend the quality if they think it's reasonable.

Maybe my post is a form of AI psychosis in itself....

Makes a lot of sense :) thanks for the update.

I'll try to remember to creepy stalk you for updates as the device sounds great!

Did you have any luck with the power issues on the new board?

Not sure if it's just my age but pair programming seems to have a different meaning these days.

It used to mean that two developers would literally sit next to each other, one would type and one would review as the person typed, then they would repeat.

I guess in the world of remote working it's just not practical any more.

I certainly wouldn't call, one person reviewing another persons code during the merge process pair programming at all.

That's now how it works though is it? ignoring agents

Junior dev working on feature X

Junior dev makes a lot of commits and creates PR

Senior dev reviews code, spots problems a,b,c but has reviewed all the code at this point. Feature X isn't complete it can't be merged

Junior dev fixed a,b,c now 90% of the already reviewed code might not have changed but the PR doesn't show that.

Now replace junior dev with agent.

Because I don't review everything between changes, there might be 10 small commits I review and state I am happy with, then I might prompt the agent to perform some small refactors after the review, I don't want the diff to show me everything in those 10 commits again in the diff ( like the usual PR would ) I want it only to show me new stuff.