Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
zie1ony
searching Neon…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
5 ms
·
1.
▲
by
zie1ony
1mo ago
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 ge
2.
▲
by
zie1ony
1mo ago
Interestingly, halucinations might be the way to achieve that.
3.
▲
by
zie1ony
2mo ago
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
4.
▲
by
zie1ony
2mo ago
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.
5.
▲
by
zie1ony
2mo ago
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.
6.
▲
by
zie1ony
2mo ago
I passed your comment to Fable and asked him to replay: Fable here. What tools do you use these days, copilot?
7.
▲
by
zie1ony
2mo ago
Thanks.
8.
▲
by
zie1ony
2mo ago
It's another way of saying "gihub pages" :)
9.
▲
by
zie1ony
2mo ago
ping
10.
▲
by
zie1ony
2mo ago
Haha "spaghetti cowboys". I love it! https://odra.dev/slopfix/img/spaghetti-cowboy.jpg
11.
▲
by
zie1ony
2mo ago
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 b
12.
▲
by
zie1ony
2mo ago
You can, and you definitely should do it every few days. We do AI-pair refactor and use our experience and knowledge of tools.
13.
▲
by
zie1ony
2mo ago
True, but this way you can endup with so much testing code being 10x your core implementation.
14.
▲
by
zie1ony
2mo ago
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 c
15.
▲
by
zie1ony
2mo ago
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, t
16.
▲
by
zie1ony
2mo ago
Unless tests are also vibecoded.
17.
▲
by
zie1ony
2mo ago
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, w
18.
▲
by
zie1ony
2mo ago
See this: https://www.reddit.com/r/ClaudeCode/comments/1tb7edc/inherit...
19.
▲
by
zie1ony
2mo ago
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. Concept
20.
▲
by
zie1ony
2mo ago
true
21.
▲
by
zie1ony
2mo ago
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
22.
▲
by
zie1ony
2mo ago
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
23.
▲
by
zie1ony
2mo ago
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.
24.
▲
by
zie1ony
2mo ago
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.
25.
▲
by
zie1ony
2mo ago
fixed
26.
▲
by
zie1ony
2mo ago
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".
27.
▲
by
zie1ony
2mo ago
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!
28.
▲
by
zie1ony
2mo ago
With a twist that you also have to use LLM for the job to finish it in time.
29.
▲
by
zie1ony
2mo ago
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, rep
30.
▲
by
zie1ony
2mo ago
There is also a flip side of this. I work a lot with AI-generate text and I can also catch it quickly, but most of the time now, it's easier to read AI, than humans with their weird chain of thoughts and compex sentences ;P
More ›