It's been eye opening. I've always held that if you can't cleanly express and communicate an idea then you just don't understand it well enough.

And yet here is a wealth of accumulated complexity that I can't "just simply" write down. I can micro manage an AI - but its faster to write manually.

This is obvious to a human but I don't need to specify which to use where... I need to be explaining the rules by which we determine which variables are compile time, cook time, need designer live-edit, are local runtime variables or are replicated live.
This is a semester of lessons not a prompt.

Tried today to write down the unwritten rules of programming so that a mindless AI assistant can follow them. These implicit rules that a human intuits from context.
Seperate your design time data from local data and from live/replicated data.

These concepts all exist in the juicy brains of the development team I work with and are well understood but I don't rightly know how to communicate those years of experience to a prompt.
I'm not attempting AI at work - I'm dealing with a simpler complexity and in a real project I think it'd sink.

Internal knowledge has been a big worry for me. At one time I'll be considering the serialisation costs, cache coherency, replication strategy, performance implications, design/edit behaviour, and security concerns as well as the business logic I'm trying to write.

This is also fair - and we are more familiar with addressing those modes of communication.

I'm used to recognising patterns and idioms. The contextual retrieval kicks in and "oh this needs to be like that" happens very naturally in code in a way it wasn't happening at the spec/prompt level.
But, I can follow TDD down a similar route and still write good code that does the wrong thing. IDK

Very True.
I was surprised how hard it was writing the spec for something I could just write code for.

Promptineering did feel a lot like TDD in its spec-first approach, and deploying my juicy brain to thunk about the problem in great detail was valuable.

Part of the problem is learned behaviour.

The illusion of progress my willing assistant provided could easily have led me very far astray. This is partly a skill issue using a new tool, but I think also a flaw in a tool that provides something that looks right and yet is not.

I need to find a blog/journal platform to write longform.

OK I think I have to qualify "poor code" and "good code" on this one. With underthought, its possible to follow rabbit holes and dead ends. One can write clean code that passes review but solves the wrong problem and the sum total of work well done just isn't worth toffee.

Well, that's where I hesitate I think. At each iteration I had to read and understand the code to work out what was wrong and how to tune the prompt. Understanding of syntax mattered for sure.
I'm going to return to the experiment and see how I can improve, my worry is that poor code may be easier.

Yeah, it maybe is. Maybe. I did spend most of my time analysing and describing the problem.
A flaw in my methodology is I chose code and a problem I'm very familiar with, I don't know how that biases the result.
I was surprised how hard it was to explain the spec compared to just tests and code.

I don't understand your comment. Can you elaborate?

But to answer your question ... a similar number of lines as a human would manually write in a similar amount of time. Between 50% and 200% of a senior programmer.

This could be a bias caused by in my inexperienced prompt iteration and the rate I could review and correct the generated code.

That said, is features per line of code a measurement of density, brevity, elegance or something else? And should it not suggest fewer lines of code is better? Function by function and class by class maybe yes.. module by module?

Lines of code becomes a proxy for the time spent reading it?

You jest, but it is a question.

I don't know I've seen a good metric for programmer productivity, not an objective one. Claims of faster or slower or 10x should be met with scepticism until such parameters are established.

Yet at some level more code must mean more code, which is the goal.

Yes, VS Code Claude Haiku 4.5

A project and set of "light" library and engine code that contains a few tech demos. Its not representative of a full size project but its not far off.

4 - The cognitive load of using this tool was higher than traditional development, however with experience it may become easier. Learning new skills is expected to be hard and this requires new skills, so it would be unreasonable to write it off from this experience.

3 - I was not protected from mistakes and errors of implementation and architecture however these were not measurable worse (in this small sample size) than mistakes I could make manually. The only protection from those appears to be years of experience.

2 - The painful specificity of writing a prompt is an exercise in communicating thoughts, assumptions, contextual understanding, and domain specific knowledge and a process that may otherwise be lost. Including the prompt as a multiline comment should be mandatory in an production environment.

1 - This tool is faster at typing than I am. But the bottleneck in engineering is not typing rate.
If it managed to improve the thinking/typing ratio it may be possible to use this tool to increase productivity.

Just tried an AI assisted programming tool for the first time.

I work in a specialist field where there are few or zero examples online that these models have trained on.

Opinions are forming.

Don't wirry about it. Language evolves, be a trendsetter.

Spent the morning moving code to a non-allocating branchless cache coherent model so I can send it to worker threads and sometimes I wonder about myself.
It's going to be like ten microseconds faster.
It'll scale like crazy and will never need looking at again, but I think I'm hyperfixating. :(

Whether you watched the Muppets Christmas Carol or Die Hard this year, I'd like to wish you a lovely Christmas.
I hope you've had a good year on balance, even after everything, and the warmth of the season fills your heart.
Second star to the right, light speed until morning, engage.

Programmers brunch! Sat around all morning, discussing problems that programmers have.
I wrote good code, turning a difficult problem into an easy problem and solved it well.
Then sipping coffee staring at "C4706 - assignment used as a condition" - a bad habit I picked up and I guess should stop.

Congratulations to #RocketWerkz and #KittenSpaceAgency for their progress, and making one small step for kittenkind in their public build.
Space games in custom engines are my jam! Great work gang, wishing you the very best in the next leg of the journey, and I am looking forward to seeing more.

Just discovered, via a brief power outage, that parts of my house only work because of a polluted DNS cache and rebooting the system correctly resulted in broken things not working.
Now I have to fix things.

This week in #EliteDangerous .

Vanguards is live! Join the ranks, discover squadrons to join, fight side-by-side, pool resources, and explore the galaxy together.

Play your way.

Thanks to all the members of the team that made this come together.