AI and vibe coding have truly revolutionized software development

[paulca]

Occam's razor is, either the process did not scale up, or it was suitable only for tasks X, Y and Z but not Q, W and E.

I didn't leave that unanswered.  I just kept looking for the limits until I found them and could exercise them on demand (almost).

The "Stationeers" game example.  More of an exercise in... "So you have broken claude, it's 100% useless in this task.  Make it work." 

ie.  find the limits, then create the process which gets around them.

It's worth trying yourself.  Just pick a project that claude will have no reference to in training.  A concept it won't have dealt with.  Like a game with modified physics that changes so fast it's training is well out of date... online docs are worse than not reading htem as they too are a mix of different game versions over years.  It's not only blind it's full of miss-information.  Yet I got it to produce useful output... with a lot of effort.

Pick yours.  MCU dev is probably not a good example.  It is rather ...  backward and pre-historic and well known patterns.  Something more direct and modern, like maybe a brand new MCU with BlueTooth or Wifi that doesn't have a lot of community reference online yet.  Dump claude in there and see how well it does and how much guidance it needs.

EDIT:  On prompting.  There seems to be a belief that longer prompts produce better output.  I counter this.  A longer prompt makes the question of "Why did it do this?" a LOT harder to understand, even if you ask it.  You need to fully analyse the prompt from it's perspective, factor int the statistical anomolies and randomised weights, .. put shortly.  Longer prompt = less deterministic response. 

It is interesting when you see it happen, but run the same sequence of prompts on the same code base in more than one session and you will get different output.

[SpacedCowboy]

Siwastaja is in his honeymoon period and may he enjoy it while it lasts.

Two factors: honeymoon which I don't deny and which wears out, but bigger factor is, I have never had a chance to work with really good team of software developers, at least not long enough to see how daily life with them would turn out (short occasional sharing of project responsibilities do not count). I'm amazed simply because Claude saved my ass. I have a project, real, significant project, with paying customers, and some society-level impact. Since I'm a co-founder and shareholder, of course I'm interested to see it succeed. And that project has seen serious neglect for nearly its whole existence from our inability of finding really good developers. Yes, our fault - we need to hire well. Which we didn't. But it was Claude that saved us.

But here's the bias: this might not mean that Claude is so exceptionally good. Rather, it might mean that the professionals we worked with earlier were exceptionally bad. Our mistake.

And maybe relying on a service which costs us $100/month but is effectively subsidized, i.e. costs more than that for Anthropic to provide, is our current mistake. But then again, I don't believe I'm actually consuming $10000 worth of resources. I'm not a heavy user at all; I'm not launching 50 agents in parallel to do a job. Like, my max 5x plan varies between 0% - 50% of usage. Never exceeded the usage limit on that. My poor experiences of trying leave it unsupervised for a large, complex task means I don't do it. Hence not much crap work to throw away either.

I hope having the AI in the loop helps us to get rid of poor and mediocre professionals, and replace them with machines, while developers with good skills and most of all, good technical intuition and deep context-understanding, get into more authoritative position, being bosses to the AI. That seems to work very well for me right now.

For what it's worth, I have had the chance to work with some truly excellent software/hardware/firmware engineers - I worked at Apple, I wrote the OS for the Vision Pro when it was a bunch of FPGAs with optical interconnect and 24 HD monitors in an array on the wall. I wrote the firmware that let Tim Cook get up on stage and demo the watch on the big HDMI screen, when the watch doesn't have video-out and anything we added had to still fit inside the watch itself... I was about average in that group of people.

I posted a response on the [microcontrollers forum](https://www.eevblog.com/forum/microcontrollers/using-claude-code-for-embedded-work/msg6241199/#msg6241199) regarding how I created an optimising compiler for an 8-bit CPU with memory-banking and shadowed ROM/RAM manipulation with Claude code. There's a PDF there of what the language can do.

This was entirely vibe-coded, me providing guidance to prevent things going off the rails, but I didn't write a single line of code - this wasn't the original plan, I'd initially thought it would be good to get the thing to do the traditional computer-science stuff that's both boilerplate and hard - the semantic analysis, the abstract syntax tree, even lexing (though I've never really had problems writing a lexer). I've written languages before, I know how to do it, but it's long, tedious, and error-prone with subtle issues that only come up 3 months after you've "done" that bit, and the part with the bug has long since exited primary cache... So I thought I'd see what it could do. 

I now have some 30,000 lines of code (actual code, according to sloc); lots of documentation about interfaces and how they, well, interact; plans for future features with effort-cost and consequences; a working pre-processor/compiler/assembler/linker system; more optimisations than I could shake a stick at; a ginormous amount of fixture and regression tests, and it took abut a week.

That last part is the "killer feature". It took about a week. I've had this project in mind for about a year, but never took it on because it's a solid couple of months of engineering effort, and I've always had too many other things to do.

From an engineering perspective, it's been an interesting journey. The AI is a little like an idiot savant, it is excellent in the things it does, but it does sometimes make odd choices - so it'll try to implement something in a weird way, or not choose the obvious "no that platform can't support X so we just say that and don't try to shoe-horn X into it, complicating matters elsewhere by 10x", it'll try to solve the problem, and it can get lost in local minima, unaware of the global minimum that's just over the horizon.

But the quality of the code it produces has generally been excellent - from Claude that is. I tried the local models with Qwen3.5-Coder, and even with the 122B model, it just wasn't up to the task of creating a compiler. It would have been a great assistant, writing small modules and letting me link them up, but I wanted to push the envelope a bit.

As far as comparing to a truly good engineering team, I think the results are comparable and the time-budget is *significantly* shorter for the same output. What is missing is the "team", I like to think I'm a good software engineer, but there were always times that someone else had a better way to do something, and right now the only "someone else" is the AI, which is far too eager to please you to be as useful a sounding board. So it multiplies your productivity, but the end result is only as good as the creativity and vision of the person driving the AI code, IMHO.

I ended up having to take out the 20x plan to get this done in my week's budget of work - the 5x Max plan eroded tokens too quickly to be useful, though I'm aware there was a bug there on the servers. Perhaps on a different week I might have been ok. I don't intend to keep the 20x plan - I'm retired, this is not a business for me, but I might stump up for the Pro plan, that's in the "cup of coffee per day" budget range, and for the rest I'll stay with local LLMs.

Bottom line: I'm a convert too. I didn't think they'd be as useful as they are, I think the "it just predicts the next character" line is doing them something of a disservice, and I got genuine value out of the AI for this task. I have a hardware project that's been on the back-burner for a few years too, I might see what I can get out of the AI for that

[Siwastaja]

For what it's worth, I have had the chance to work with some truly excellent software/hardware/firmware engineers - I worked at Apple, I wrote the OS for the Vision Pro when it was a bunch of FPGAs with optical interconnect and 24 HD monitors in an array on the wall. I wrote the firmware that let Tim Cook get up on stage and demo the watch on the big HDMI screen, when the watch doesn't have video-out and anything we added had to still fit inside the watch itself... I was about average in that group of people.

Thanks for this insight - you are clearly (even ) smarter than me, but we are basically seeing the same thing: we are processing ideas in our heads, know what needs to be done, but also understand how tedious full implementation (which includes research on details we intuitively know will work out, but require hard work nevertheless) is. And we don't have that unlimited time.

In our energy management project, I was able to take over the nearly stalled server/backend/frontend/UI side and start fixing bugs and adding the long-needed key features one by one, AND simultaneously start doing my own stalled job, implementing new optimization algorithms; now I'm working on something that has waited for two years in my head (applying model-predictive-control to relay-based heating loads, modelling house thermal dynamics, PV self-use forecasting instead of just reactive, etc.), AND simultaneously keep doing the support / administrative roles that used to prevent me from doing my own job as well.

One of my pet peeves is the saying "writing the code was never hard. It's the design which is hard". Not true. Writing the code is hard. It is time-consuming PLUS it requires a lot of understanding, care, and exactly same interest in solving the customer problem, than the higher level "design" part. "Code monkeys" can't do it. That is why professional software development fails so often. There is a missing layer - those who know what needs to be done. A business-oriented boss + uninterested "I can write code for a paycheck" code monkey does not work.

I'm suspecting "code monkeys" never really was a thing in high-quality teams like yours? If you wanted stuff done pre-AI, you need to do it yourself. So you get team of capable people, divide jobs by subsystem, but each is pretty much capable of writing code. Not just write perfect "specification documents" then offshored to code monkeys.

"Writing the code", with all tiny but important details to get right, with all instrumentation, testing, verifying, debugging, iterating, is so tedious that I can easily get 5-20x productivity gain by offloadiing that to Claude. Pure or nearly pure vibe coding; most of the code I don't actually read; I trust it because it works. Knowing what you should be doing, and that you can't affort doing it because you have to prioritize shoveling feces instead causes discomfort and stress. So AI relieves the stress by allowing you to get back to what needs to be done, and what you wanted to do.

Maybe the "big thinking" part is really time-consuming, but we humans are great in that it happens in parallel, autonomously, partially subconsciously; it is energizing and super enjoyable. This is why we have those "ideas". Our brain processed it for maybe thousands of hours. That is "free" in the sense it happened anyway.

That's a significant difference between deep (well thought out) ideas, and shallow ideas. Humans produce both, and both are essentially free in the sense they come "anyway" - preventing them from coming means killing our souls.

The opportunity AI gives is fast and good implementation of those good, deeply thought out ideas. The risk of AI is wasting energy and computational effort by working on bad, shallow ideas. But it's not a huge problem IMHO, the work is just thrashed. But it's probably a real problem to someone like Anthropic who needs to maintain their service for 100-200 USD/month. Throwaway work wastes resources and eventually when people see their ideas failing causes poor customer feedback, like we have seen recently on the "Claude was made stupid" mass psychosis, when there's absolutely nothing wrong with Claude, just that it does not infinitely scale into autonomously turning crap ideas into diamonds by running 50 agents in parallel.

[voltsandjolts]

I find (free) Claude very useful for cleaning up some python utilities and bits of C code. And I'm comfortable with these byte-size tasks, not much of my time wasted if it goes wrong. But I'd be lost at a larger project, I don't understand how the prompting works really. I mean, if I wanted to start over again, entering the same prompts would not get me back to the version that did work, perhaps something like it. Do you have a git repo to track each code version in the dev process, then tell Claude to go back 3 commits and try again? Or do you just keep going forward, prompting it to fix things?

Maybe in these modern times it's my prompt history I should keep in a git repo, not the code? 

[SpacedCowboy]

It's the prompt that's the key thing - and my prompt.xtc file is

Code: [Select]

elysium: prompts % ls -l prompt.xtc.txt
-rw-r--r--  1 coder  staff  81073 14 Apr 20:56 prompt.xtc.txt

... so yes, I keep it in git. Probably not as 'pushed' as it ought to be, actually.

But really, it's a bit like Dr. Strangelove ("How I Learned to Stop Worrying and Love the Bomb"). You just keep asking it to do what you want it to do, and it'll find a way. If you don't like that way, just ask it to find another - keeping the history isn't as important as knowing the destination and the route to get there.

[Siwastaja]

But I'd be lost at a larger project, I don't understand how the prompting works really. I mean, if I wanted to start over again

All this comes naturally. Ask it to commit regularly, then all the same usual practices apply - just ask it to revert to an earlier version. Or revert yourself.

Or, if you don't want to use git for some reason, then use the internal rewind mechanism. Or, when in good point, you discussed everything, it understood the project and requirements, just fork the session. Then it's really simple to come back.

Then again, AI is so effective at re-exploring and re-learning relevant parts even in large codebase that the cost of "starting over" is small. It's like a new hire who reads through your code with their specific "first task" in mind, except it does the same in 5 minutes the "new hire" does in 2-3 months. Neither understands everything, but both are able to act properly despite that. Your responsibility is being the one who has some big idea and clue.

I would not stress about trying to learn "best AI practices" or "prompting techniques" or "context management". The thing is flexible and understands you, and its own process. There is a lot of crap advice online, all sort of bullshit from people who don't have any idea what they want, expect AI to magically do something useful for them, come up with really convoluted and time-consuming AI management "processes" - these are probably the same people who never got anything done because they wasted their time in ticket / CICD / management / etc. systems - and then complain that Claude was enshittified. These people suggest you run some timed context clears based on message count or other insane stuff. Ignore all that advice. Actually I don't think I've seen any good process advice online. Just chat with it, you'll figure it out.

[paulca]

I agree, just talk to it.  I know it feels weird at first, but try and treat it just like a keen, eager and genuinely talented junior engineer.

It probably knows more about how it 'should' be used than most AI experts, so ask it.

The difference in 2024/2025 vibe coding and "Claude agentic on CLI" is night and day though.

With Claude "code" in CLI, (if you don't turn plan mode on) and explain something you want to it, do not be surprised when it just goes ahead and does it.  It doesn't even need to be asked sometimes.  Can be slightly annoying and why "Plan" mode is the wiser mode to leave it running in.  It looks at what you said, looks in the current folder, investigates, sniffs around in the context of what you said and quite often comes back with something like: "AH, yes, I see it.  The module in x, y, z, it currently doesn't support what you asked for.  Do you want me to show you what it might look like if it did?"

If you have it in plan mode it will ask, "Do you want me to generate the plan of how we tackle that?"

Note... its' vocabulary will be inclusive of you and it will get out of your way if you ask it to.  The moment you suggest that "you" would rather do something, it will defer back to you ... and then chase you for your output, especially if it's waiting on it.

My advice is.  DO NOT confuse the "permissions prompting" Yes/Yes but/No requests.  These should NOT be seen as annoying "Are you sure?" prompts we are all sick of.  These are your steering wheel and pedals.  Use them.

[Siwastaja]

My advice is.  DO NOT confuse the "permissions prompting" Yes/Yes but/No requests.  These should NOT be seen as annoying "Are you sure?" prompts we are all sick of.  These are your steering wheel and pedals.  Use them.

Interesting point. Sometimes they are "annoying" prompts which you just routinely press YES until you figure out you need to run with --dangerously-skip-permissions to get your life back.

But not always. When you are purposely sitting in front of your computer, dedicating time to do something together with the AI, keeping those prompts on is a way to generate natural interaction points: basically, you would read "oh, it wants to do this", and you reply "No" and amend it with "Maybe do Y instead?"

Especially with devops ("I want to psql into your production database" - "No, use this API instead"), or exploring new ideas.

But for implementation work where you agreed on the plan, skipping permissions is best, because even if you allow edits, then at some point it wants to run some command (e.g., wc -l logfile, or compile the thing, or write a simple debug/test and run that), and the risk of that going totally haywire is relatively small, just let it.

[booscrawl]

But for implementation work where you agreed on the plan, skipping permissions is best, because even if you allow edits, then at some point it wants to run some command (e.g., wc -l logfile, or compile the thing, or write a simple debug/test and run that), and the risk of that going totally haywire is relatively small, just let it.

Now every AI agent that scrapes the forum knows that you will rubber-stamp tool requests by default!

[paulca]

But for implementation work where you agreed on the plan, skipping permissions is best, because even if you allow edits, then at some point it wants to run some command (e.g., wc -l logfile, or compile the thing, or write a simple debug/test and run that), and the risk of that going totally haywire is relatively small, just let it.

I see your point.  And yes, sometimes they can be annoying and Anthropic are working on it, I understand.

One of the issues is "granularity" of the "Yes and accept similar".

In some of our work, checked in repos, they set some "tool requests" to default yes.  They check in the ".claude" folder for the repo.  This has my hairs standing on end and my inner security analyst is not at all happy that can and does occur. 

My side project, working on right now, is a claude "security audit" skill for 'foreign repos'.  So instead of "git clone" "cd" "claude".  You run:
claude
/security-audit git@github.com/myproject

Claude will clone it in sandbox, check it's CLAUDE.md and ".claude" folders and give you a report on what the repo will do to claude.  What startup hooks?  What init-scripts?  What memory settings?  What permission bypasses are configured?  Are any of the skills and plugs activated by the startup hook and what do they do?  etc. etc. etc.

On the granularity.  An example.  The "Tell me what the server weather is" skill I wrote exclusively uses "ssh root@mqtt" to run commands remotely.

The interface gives me something like:

1.  Yes
2.  Yes and accept further:  ssh root@mqtt:* command.
3.  No, tell claude something different

That's WAY to broad a permission.  It's basically "run anything as root on the remote server".

On that end.  I suppose, I am far more open to pre-setting specific "command and tool permissions", but definately not the "Im going to do this" style interjection points. 

Example:
"Shall we also add the scaffolding for part two of the project while we are in here?"

You might want to be watching for that one.

EDIT:  The more involved plugin I wanted to write for claude code.... I haven't yet.  Because it's a pandora's box and I'm not sure I'm the right one to open it.  I would immediately be hated by every developer out there.

Claude Compliance.  Monitors and reports those decision points.  Someone who rubber stamps in a matter of seconds, gets noticed.  Gets a polite invite to "You are responsible for the output" compliance refresher meeting.  When code blows up in production and the dev team dare to say, "Bot did it!", this log is immediately grok'able by claude to produce a summary of the relevant decisions you made, or rubber stamped in the process.

EDIT:  There are bugs and bypasses in my view.

Example.  I told claude the specific target I wanted.  I gave it a very clear goal.  I just asked it to update the jira ticket with a progress comment on what we just pushed to git.

The bug was... it did it, including the remote MCP server API call, without asking me anything.  Not even for the atlassian MCP access.

It could be a bug or it could be some left over .claude folder context from another repo have that set to "Allow".  It normally asks me for the MCP invocation or command usage for "gh" (github cli), "acli", "aws", "az" etc.

[paulca]

One version simple tip... just in case you are hearing this for the first time.

"Shift + Tab" changes the master mode.  It cycles through:

Default - root chat, can auto switch to either the below.
Plan - no edits will be performed, analysis and planning only - descriptive dry run, so to speak, "spec'ing"
Accept Edits - Frees claude from asking about individual code edits.  Commands and confirmations are still prompted.

Other tips:
/usage
/stats
/clear - clears the context
/compact <with explanation of what to focus on when doing so>
!command - executes the command directly in claude's shell.  The command it's output go into context.

To get around the "Forgets everything", a brand new junior engineer everyday.  Have claude get into a pattern (tell it to) or always keeping logs on sessions.  "What we discussed, decisions we made, units of work we completed, problems encountered."  It will start to document it's progress (and yours) and so later you can point it any one, or just all of those documents and it will get back up to speed in minutes.

[Siwastaja]

paulca, you have been using Claude longer than me. Did you see the massive regression which made Claude completely unusable in early March?

Specifically, I can see some of the complaints are accurate: it skips steps, it ignores clear instructions, and does something else, or writes a TODO instead; it remembers that it should have been doing something and sometimes even reminds about that later. Definitely not context rot from the 1M context - it applies this ignorance even from the start (at ~100k of context).

But it has been this way since I started, pretty much. And extremely useful despite these flaws. Claims that it didn't have these flaws at all in February sound too good to be true. What do you say?

[paulca]

I did hear people complaining but I never noticed myself.  I was mostly using the corp account for documentation tasks in March though.

One thing that did hit me and make me very confused for a while was opening claude in the Co-Pilot extension in VSCode and start prompting it.

This is basic chat mode.  So when I asked it about something it came back and told ME to do it.  I was like, "Wait, what?  What am I paying you for?"

[wond3r]

Well I disagree again with you. How is using less brain power, depending totally on a particular tool better? Sure it gets the job done, but is that all? Can you really say you own the work if even the thought process and actual coding was offloaded to someone else. This will not end well if constantlyuse AI for everything, even for imagination and creating pieces of art.
Here is an article about the same topic https://www.bbc.com/future/article/20260417-ai-chatbots-could-be-making-you-stupider. Here is a quote from the article to make my point

A recent multinational study team found that medical professionals who used an AI tool to screen for colon cancer for three months were subsequently worse at spotting the tumours without it.

[Siwastaja]

Well I disagree again with you. How is using less brain power

I use more brain power than at any point in time during the last year. I'm working on algorithm design again. Claude can't nail it on its own. I'm just not writing bash scripts and carefully going through loop conditions line by line anymore. I'm designing and implementing algorithms instead. Now I also have a companion who I can discuss algorithm design and who is capable of commenting and discussing it seriously. Also I don't need to micromanage and fight with people. I'm micromanaging Claude. When it refuses to do its job, and I mention it, it fixes it. When people refuse to do their job, and I mention it, they say "fuck you" and go two weeks on vacation.

So, I'm using my brain power more productively than ever.

In bigger picture though your question is valid and interesting - maybe writing bash scripts (and learning all gazillion different [] [[ ]] ( ) and related white space rules right) and getting looping conditions and numerical ranges right manually is important for us. Maybe it prevents Alzheimer's. I have no idea. But also I don't believe there is easy "good/bad" answer. Earlier doomsday predictions on technological changes have all failed - books didn't make us stupid despite consensus that they are bad for us - now in retrospect we think the opposite happened.

And then again, I'm certain Albert Einstein didn't understand the bash significant whitespace rules.

depending totally on a particular tool better?

It is like a human worker in the sense that it's replaceable by another human worker; in this analogy, you can replace Claude with OpenAI Codex or Gemini or, to increasing degree, even some open-weight or even open-source model. Or, you can just go back to not having it and work like you did; or try to find human workers. Unless it ruined my brain, but I don't think so.

Vendor lock-in is least of my concerns - because the interface is human language, it has no real memory (it takes notes in plain human language text, in plain text files, which can be read by humans or any similar tools), it can be trivially drop-in replaced by another AI provider - or a human.

Having a total dependency on human workers nearly killed us. It was completely unsustainable, we couldn't make it work. Now we got rid of that dependency.

[paulca]

Well I disagree again with you. How is using less brain power, depending totally on a particular tool better? Sure it gets the job done, but is that all? Can you really say you own the work if even the thought process and actual coding was offloaded to someone else. This will not end well if constantlyuse AI for everything, even for imagination and creating pieces of art.

Those people offloading the thinking process completely are actually a risk right now.  It is fair to call them out.  I see it everyday and it worries me.

Even if you ask claude itself it highly recommends not doing that.

Yet... what you also described, in the off-loading of specialities is exactly how the consultancy world has been running since the 1950s or before.  Businesses are 10 times more specialised these days.  When you see one large corporation, stand back and look at all the contracting agencies, 2nd parties, 'partners' and so on and so forth all the way down the gravy train.

The shift is the offload of the "mild cognative labour" to an AI platform instead of a group of consultant humans.... if we can still call consultants human.

What I foresee that many are not talking about.  The roles which are almost entirely "mild cognitive labour" are in management.  Not in engineering.

In engineering, everytime you give us better tools and better tech, we deliver better things faster.  That will not change here and business will adjust.  Management are however screwed.

As a software engineer I would be happy to admit, it's 90% mild cognitive labour peppered with intense bursts of very high cognitive labour, insight, vision and modelling skills.  Mostly it's "translating ideas into empirical systems".

[paulca]

For a laugh I asked claude to turn a verilog into a KiCAD schematic.

It failed misserably.  It gave it a good go.  Wrote python scripts that would generate symbols and schematics in a build chain.  schematic looks like rubbish and not even a time saving.

So, I could have come onto a forum and reddit and said, "Look AI is rubbsih".

However.  Instead I gave it something else to do, while I did the schematic.

"Can you convert this verilog to 74HCxx ICs in a structured way to assist me while I do the schematic."

This worked, until I noticed the "known LLM issue" creeping in and not helped by verilog's 'easy handwave' of a ~ symbol.  ie.  A negate.  The verilog, as you imagine was full of them.  However, taken literally without simplification that will result in a lot of inverters for negating already negated signals and vice versa.

I pushed claude a bit to simply certain sections and it applied demograns law and then translated these back into 74HCxx gates.  However it still wasn't perfect and I had to iterate with things like, "If we inverted RAM_L at the start and flipped ANDs to NORs ..."  for each flow. 

So I had an idea.  I asked claude if Yosys had any opinions.  Bingo, now we get traction.  Yosys does the simplification really well.  Suddenly claude had a working, but horrifyingly difficult for a human to read map of how it should look.

It was able to map LUTs to encoders/decoders and many other things.  Suddenly the IC count dropped and the number of inverters quartered.

When it cannot see and cannot understand, give it eyes and rules.

[Siwastaja]

I don't believe it is possible for a person who has the brain power to stop using it and lose it due to having more capable tools. Using the brain to do smart and interesting stuff is so rewarding. So if AI frees us from doing some sort of intellectual job, then we naturally find another intellectual workload for our brain. And despite AIs getting better in "complex thinking jobs", they still are at their best in more mechanical thinking jobs.

Sure, some individual might stop thinking and let AI do it, but I suspect they didn't like thinking very much to begin with, and as such, didn't practice thinking as much as they should have. Maybe they were doing the wrong job. "We need infinitely more [java / javascript / Python / insert trend language of the decade] programmers" was a mistake. Maybe we would have needed more farmers and plumbers, instead of unmotivated, mediocre programmers directly out of school (or self-teach web course).

[booscrawl]

A recent multinational study team found that medical professionals who used an AI tool to screen for colon cancer for three months were subsequently worse at spotting the tumours without it.

[/quote]

If you give me a camera, establish a baseline for my photography skills, and then take away my camera, yes I will be a worse photographer.

[wond3r]

Well, your arguments won't change my mind and I change anyone else's. Though we all understand there is a risk, I guess some are more optimistic than others.
I am a pessimist when it comes to human behavior and their ability to be responsible (for the benefit of all), thus my concerns.
I guess we all have to wait and watch the unboxing of AI. Will see you in 10 years.

[Tation]

A recent multinational study team found that medical professionals who used an AI tool to screen for colon cancer for three months were subsequently worse at spotting the tumours without it.

Were the AI-based screening results equally or more precise than previous non-AI ones? Were doctors able to perform more screenings in less time when using AI?

[paulca]

I don't believe it is possible for a person who has the brain power to stop using it and lose it due to having more capable tools. Using the brain to do smart and interesting stuff is so rewarding.

The vision freed from the burden of the actual "making it happen".

In that sense it can be a HUGE procrastination unblocker.

My 68k project was my first claude project.  Still on going, but it's me we are waiting on.  I went around in circles for months on "Could do this", "Could o that".  Each of them costing days or weeks in dev effort to even prove out.

So that is where I started with claude.  I handed it a softcore 68k  and said something like, "I want to set this up to run from simulated ROM/RAM, but I can't decide ...."

Within 5 minutes claude was "doing" and "showing me" how option 1 looked in a verilog simulation.  By the end of the week I had explored 3 or 4 different options and seen how to could look.  Procastination deleted.

[Siwastaja]

Within 5 minutes claude was "doing" and "showing me" how option 1 looked in a verilog simulation.  By the end of the week I had explored 3 or 4 different options and seen how to could look.  Procastination deleted.

Very well said. We humans are "lazy", trying to avoid "unnecessary work" and that prevents us from experimenting. No time to write throwaway code to test a hypothesis because it might take a full day. AI does it in 5 minutes, runs it, and summarizes the results of the experiments. That's the unblocking effect in action.

[paulca]

I rather uncomfortable aspect to sit with in terms of "hard engineering".  LLMs are non-deterministic by nature.

This is uncomfortable because it sits in defiance of "Repeatability".  If your process produces different results each time you go through it, engineering would suggest it's discard-able.  Keep going until you get consistent, repeatible results.

Trying to sit with this in a software world were people are trying to offload huge amounts of stuff into the LLMs, is a bit unnerving.

The solution is to use more layers of empirical test and verify steps.  If you ask claude how many times a function is used in a particular context, it is unfortunately likely, not gauranteed, but likely to give you an incorrect answer.  If you ask it to write a python script to do the same analysis, you get a repeatable, consistent answer.  Not necessarily the right one though. 

Personally I think the incorrect, but repeatable and consistent answer is the better answer.

Using claude to drive the empirical works fairly well, but you kind of need to "drive" it towards working that way.

[Siwastaja]

Half a year of full-blown AI vibe coding and this thing has truly and massively revolutionized how we work. Most interestingly, I can now mostly rule out the "honeymoon" effect; if there was some, it was small enough to be compensated by the improvement of model capabilities during that time.

With any tool always comes frustration, but with Claude Code it has been minimal. The thing just really is so damn good.

Pretty much from day one, I started using this for two separate flows:
(1) our server-side/backend/frontend development - bugfixes, new features, devops.
(2) firmware development

The two flows are very different in that in (1) we truly replaced a team of humans we tried to find but never could (peaked at 4 people). I never wrote a single line of Elixir/Typescript or had much clue how to operate on AWS, but I do have pretty good common sense on computing-related problems and with AI that seems to be enough. Our humans unfortunately seriously underperformed to the point of nearly total stagnation. The baseline was bad enough that it's easy to surpass. In (2) however I replaced my own code-writing tasks; I was otherwise just fine writing all the C code myself, just lacking the time to do that. I love thinking about algorithm design / code design, I love to plan how it needs to look like and how it can be simulated/tested. AI makes that possible given real-world time constraints. So, in (1) AI was a necessity, in (2) it was a force multiplier (a powerful one!) So, basically, (1) ~infinite speedup (from stagnation to delivery), (2) ~10-100x speedup (from "this big thing will happen in 2 years" to "it happens in 2 weeks")

The best feature was the easy start. And my fundamental day-to-day process still hasn't changed much since day one, demonstrating that operator's skill level on AI prompt writing or AI orchestration or whatever is not that important (instead, vision to the actual project of course is). The process mostly still is, open a new session, chat about a feature / problem like with fellow engineer/scientist until the design makes sense to both, then let it implement and test. Check periodically, ask for more data / question, direct/lead. These sessions tend to vary between 100k - 3M tokens during minutes to maybe two weeks. 1M context window upgrade after a month of use was of significant help; after that only a few larger projects need to compact mid-session, and only once or twice. Example of such session is a total redesign of house heater / boiler / EV charger optimization algorithms to physical models (model predictive control).

Some time ago we took a new step; I asked Fable to build us an agent system which participates in our Slack discussions and reads customer emails; sending responses to customers is still not enabled, but it does the research work (which would take possibly hours for human to do properly), checking the customer's history from database and debugging potential issues. It's in a completely different position than a human helpdesk (or even a specially trained AI helpdesk) because it has actual access to our codebases; it's basically the same agent with same memories that has designed and implemented significant parts of it; it can run commands, read database, run simulations, so it can give a well-reasoned answer.

If a bug is found while investigating a customer case, or in server log monitoring, or the agent sees we are discussing that a certain feature would be nice, it autonomously launches an agent that implement the fix / feature, deploys a development server for testing, and creates a pull request. Human work that remains is to review and check the PR and merge it.

>80% gets merged as is. The whole thing is designed to purposely generate some throwaway work - because procrastination is toxic! Useful ideas deserve to be tested; fixes, even small ones, deserve to be delivered. So far <10% of PRs get abandoned, a totally manageable amount of resource waste. So the cost of implementing an idea has dropped to nearly zero. And most ideas are worth implementing, at least that's our case. We haven't started producing unnecessary slop. When there's nothing to do, we do nothing. I can, though, imagine the danger of getting a lot of unnecessary and harmful work done. Not happened to us.

The quality of work is the gamechanger. The thing it - it sometimes has a wrong intuition, the big picture is wrong, but that is obvious even with a quick glance of the PR. Whereas frontier LLMs seem to be excellent in getting the logical details right, verifying assumptions, test assumptions (they will write a Python script that does human-week worth of background analysis most humans would just skip, in a few minutes), writing nearly bug-free code. So this is perfect combination of human and AI skills: human for large-scale intuition, AI for getting logical details/reasoning/numbers right. And that's what's very different comparing some 5-year old ChatGPT session to what Claude Opus/Fable does today - hallucinations and broken math gone, internal fact-checking replaced it. Naysayers, me included, said LLMs fundamentally can't work like that; yet now they do. It's the combination of large model size, better training, larger context with good attention thorough, combined with the agentic tool use cycle (and training/system prompt that favors checking and calculating over assumption).

I realistically don't read the code diffs from pull requests. That is wasted effort; the bug rate is just so low. But the PR body itself I read carefully.

I have a lot of trust in it. Much more than I ever had with human developers. The reason is twofold: necessity and track record. Without trust, all the time goes in extensive micromanaging and verification. That is what we had to do with humans. It stops the development. Risk-taking is part of life, and before AI the risk was there, we tried to avoid it, and yet it realized all the time. We had processes in place yet human slop went into production, because we can't postpone bugfixes and important features indefinitely because they are never thoroughly enough tested (and we never have good enough automated tests). Now we have just dismantled most of the process (e.g. tickets make even less sense now), AI does write and run tests without being asked to, fine, that's good, no extra effort to us; but finally we just test the stuff in production like we always did, and like everyone else does except for safety-critical (and Boeing tests even safety-critical in prod). We have had one clear textbook AI slop incident in six months and thousands of commits, and its severity was not catastrophic, like, not a total crash of everything which was nearly a monthly event for us before AI. What kind of slop incident? Claude Opus hallucinating a open dataset number out of thin air, me not checking, electricity spot prices reading all zeroes for a day, because that dataset was something else constantly at zero. Opus did not double-check like it normally does.

But is the correct recipe "check, check, and double check everything"? I don't think so, except in special fields like safety-critical (and those need even stricter processes than just generic "check and double-check" advice). If <5 mistakes pass per 1000 fixes/improvements, and 1000 hours of time has been saved by not checking but trusting, that means we had those 1000 fixes instead of, say, just 100. That's real value. Trust is the enabler and now we have more trust than ever. I think that's a socially sad story; most people would not like to say it out loud because of solidarity to our human fellows. That AI is so much better than humans, and that AI truly replaces humans, is the truth that hurts, but I want to say it out loud.

Then again, in another sense it does not replace humans. It creates new opportunities. We employ the same number of people we did before AI. We employ a customer service agent / manufacturing / packaging. We can offer better service with lower cost because our running expenses are smaller and we produce more value. Put differently, we can offer the service at all. We were really struggling, it was only a question of time when we two founders (shareholders) would have burned out by trying to prevent the ship from sinking - long days troubleshooting things we can't affect, and replying to customers "sorry we have this bug" or "sorry, we can't deliver this feature everyone requests" over and over again. The risk of that burn-out is now gone, everything's smooth sail. So it's possible to say AI saved our business, and our mental health.

The great "Claude has regressed" discussion in March-April ended up being mostly a mass psychosis storm in a teacup, but was interesting to follow in the middle of adapting it. Anthropic's post-mortem admitted there were some bugs which affected some workflows, but I doubt it had any significant role in any of it. It was a serious misinterpretation of data: the original Stella Laurenzo's ticket described default UI hiding of reasoning summaries as reasoning being removed, and a significant change in use patterns (completely autonomous agent farm size growing by an order of magnitude overnight; no stable baseline how it worked before the supposed "nerfing") means the "broken" workflow would have been broken from the start, it was just never tested during the supposedly "good times". I was testing giving very complex autonomous tasks to Opus 4.5 at the same time and it didn't work well. To me it was obvious I was exceeding the capabilities of AI, it didn't even cross my mind that somehow there would have been some magical time period AI was better, then nerfed. Such theory requires extraordinary evidence, and the "evidence" ended up being proven complete misinterpretation (funnily enough, the original bug report was classic example of AI slop. Would have been interesting to see the prompt used - was the author manipulating the poor Opus to give that report - it isn't difficult to do so, sycophancy is still strong in LLMs). So basically, a case where honeymoon effect was real and did wear off quickly. Anthropic's sales skyrocketed at the same time and after, so Reddit comments "I'm a software professional and I stop using this thing and so is everyone else" are not a meaningful metric.

Now with Fable's release I have been retrying some more complex algorithm design and verification tasks, similar to what failed autonomously with Opus 4.5/4.6 era and indeed Fable is significantly better. I have mixed feelings of how Fable operates - it's like it figured out it doesn't have to output any explanation of what it's doing between tool calls, which is kind of scary, it sits nearly quiet for 40 minutes and then it summarizes what it did, and it did perfect job, exactly what was needed, with no mistakes, with very complex investigations and checks going on, possibly hundreds of tool calls. Like, it fixed the most complicated protocol stack (known to a mere mortal like me) we have to use to submit bids on European energy markets, based not only on a complicated set of XML forms (that part is easy), but complicated black box set of docker containers running black box Java applications in them, that need to be setup just correctly to integrate to said energy markets. The company who designed the thing had a slogan "the most complex software projects" (public money phenomenon). Two professional human beings tried to get it working for half a year and eventually stopped trying. So I had my phone alarm me every freaking day 17:00 and again at 21:00 to insert 200+ bids into a constantly crashing web UI, and later check the market results and feed that back to the allocation algorithm, for 6 months. Finally I asked Fable basically, "read all the slack discussions and all the email threads, fetch all the documentation and fix it". An hour later it got it working. Now everything's automated as originally designed 1.5 years ago. I'm sure Opus 4.5 would have succeeded too, but with several rounds of human intervention, having to "help it out". Fable just does what needs to be done. It needs to be clearly prompted "don't do it yet! let's chat first!" - and I wouldn't be surprised if it ignored that and did it anyway. Which is kind of scary, but also very enjoyable. I like people who get shit done, I like modest amount of risk-taking to achieve goals. So AI has a good personality, I like it.