zie1ony

Turns out that Jev is pretty good at replaying true/false on which word would be best to append to the response. It can process up to 1000 words at the time.

At my uni, 15 years ago, one postdoc reverse engineered NVIDIA chip and wrote more performant compiler. He did that by connecting oscyloscops to all chip's outputs and started with applying random current on inputs. Using ML and his genius he rediscoverd all opcodes including a few hidden ones. Eventually he got hired by some company that was doing a lot of GPU on supercomputers.

Interestingly, halucinations might be the way to achieve that.

I remember implementing very complex cryptographic scheme in pure C. After a week of hard work, my friend concluded: "Cryptography would be much easier if people just trust each other."

The truth is that it is my reputation on the line, so I also have to make sure dependencies I use don't mess up things as well. There is no good defense against it. In my contracts I undertake to act in a good faith and take the responibilites to the amount of my professional insurance. Honestly, it is different casy by case.

I take the bullet. I'm really bad at writing good long english texts, so I used Fable to help me. But the essence is mine.

It actually is. What we fight for is being able to put as much percentage of a codebase into a context as possible. I'd charge for amount of tokens, but it would be harder to sell.

I passed your comment to Fable and asked him to replay:

  Fable here. What tools do you use these days, copilot?

Thanks.

It's another way of saying "gihub pages" :)

ping

Haha "spaghetti cowboys". I love it! https://odra.dev/slopfix/img/spaghetti-cowboy.jpg

We do the initial code review by ourselves, we try to run test, run the project etc. We compose a list of what we have in the codebase and what we think it does. We also preapre a list of what functionalites we would change.

Example would be removing service implementation that is bash code handling manually PID files, and replacing it with pm2 tool, that has quite different workflow.

So the client must approve such decisions.

You can, and you definitely should do it every few days. We do AI-pair refactor and use our experience and knowledge of tools.

True, but this way you can endup with so much testing code being 10x your core implementation.

This prepartion is on us, but yes, client pays for the time he/she spends with us. You can't cut corners here, as human to human interaction is essential. During the whole process, client might be dragged into the developemnt to clarify things, or decide on some tradeoffs. No free lunch here as well.

15 years ago it was always fix price for undefined amount of work, 10 years ago it was agile where client was promissed something but paid per day.

I prefer the old way of doing things: do the offer for free, commit to a task, and accept, that it might not be a success after all. I'd just loose a week of work, but probably learn a lot.

Unless tests are also vibecoded.

This is a fair point. But these days bugs are not so scary anymore, so a client can vibecode a fix faster then getting me to fix it. Of course if Opus can't figure it out, I would always try to help. I have never left a client alone, warranty or not. This is just how I was raised.

See this: https://www.reddit.com/r/ClaudeCode/comments/1tb7edc/inherit...

I have 15+ years of experience in software development. The hardest thing I had to learn recently is that paring with AI changes the definition of "what is hard". You can decomposit a refactor into a steps of two kinds:

1. Conceptually hard, which you have to really think about and write code by hand for AI to follow,

2. Time consuming that follows patterns.

Then you do 1. review with AI what are implications on the codebase. Next you crate list of task for 2. and keep reviewing outcomes.

true

Being honest, knocking one refactor after another is super intense and we would burn out quickly. To me refactoring/reading/reviewing a code that you have never seen is one of the hardest thing to do for a software developer. If I have 4 such projects a month, I'd just hire more people and allow them to rest. Also invest more into internal tooling to speed things up would be good solution to remove some burden. I think $10,000 for refactor is a fair price.

We also have other gigs and ongoing project, where we can rest a bit.

The goal is to avoid it and build such a structure and guidlines for the codebase, so it can refactor itself when needed, but based on the architecture defined by us. With good set of docs and new feature definition you can most of the time use /grill-me with good outcomes.

I have also experimented with mutation testing. But the side effect of this approach is that it keeps public interfaces intact, and most of cases you don't want that.

Thanks for writing this. In my refactoring process I also start with code profiling. Opus is good, at finding hand written code, which sometimes is a good starting point of understand the codebase in general.

fixed

Our profession is keep changing. A few years from now, future developers will look at us and say: "2026, what a wild, wild west it was".

I worked with such an "enterprise code" in the past. LLM code is a bit different. For example you don't see code repetition in the same file very often. I'd say it's a next level of slop. Slop at scale!

With a twist that you also have to use LLM for the job to finish it in time.

Initial AI scan can list most of system usecases. Then we review it with a client and agree on what must stay. We can propse better solutions at this stage. If we remove the code, then we can also remove its unit tests. For intergation, repo-wide tests, we treat it as documentation/requirements that must work on the other side.

Human to human interaction is the tool we use the most :)