Building Proof to reduce the work needed to trust a software change. Engineer, founder. I want fewer compromises between shipping and quality.

Istanbul
Joined October 2007
Have become top 3 trending developer on Github, with @mitchellh right behind me 😱
2
2
47
14,313
Seeing invoice in email that SpaceX accepted your payment is quite cool 🤣 One of the non obvious brand benefits from merging with X/Grok.
3
333
Leonid Bugaev retweeted
I thought I have prompted AI to do some creative and unique design. Now I see the same tricks and colors being used on half of websites. Prompt harder or learn design? 🤣
1
2
6
365
Leonid Bugaev retweeted
Replying to @dhh
@dhh I have wrote you a letter 🤣 blog.reqproof.com/p/dhh-this…
1
1
5
339
I thought I have prompted AI to do some creative and unique design. Now I see the same tricks and colors being used on half of websites. Prompt harder or learn design? 🤣
1
2
6
365
👋
My favorite kind of person is the curious nerd with a sparkle in his eye.
1
198
If a new way smarter model released today - would it make your product worse or better?
1
245
Before declaring QA dead, can we at least agree on what we’re removing? There’s a difference between designing a process that should prevent mistakes and checking whether the result actually meets expectations. Calling everything “QA” hides that difference. In control-system terms, QC gives us feedback: observe the result, compare it with the target, correct the deviation. Some preventive work associated with QA is closer to feedforward: anticipate a problem and adjust before it affects the result. Useful, but you still haven’t measured what happened. A heating system can use the weather forecast to adjust in advance. I’d still keep the thermometer. Software has the same problem. Better requirements, better planning and better prompts can help prevent defects. They don’t tell you whether this particular implementation works. So when someone says agents will eliminate quality control, I want to know which part they mean. The person performing the checks? We can discuss that. The need to check actual behavior against intended behavior? That’s a much harder argument to make. We can automate the feedback loop. Removing it would be a rather different engineering decision.
5
240
Found a way how to run GLM 5.3 with 94%!!! discount. Obviously you trade your data for it, and most likely it is shared pool of accounts, but 94%! inference.ai.exchange/ - apparently launched just a few weeks ago
1
3
197
We call the testing team “QA”, then ask them to check everything after we’ve built it. That job title is doing quite a lot of work. Quality control checks whether the result meets the requirements. Run the test, inspect the output, find the deviation, correct it. It gives us feedback about what we actually built. Quality assurance asks whether the way we work gives us good reasons to expect those requirements will be met. Are they clear? Have we considered the failure modes? Have we planned checks that would actually expose them? Take a payment retry. A test finds that retrying after a timeout charges the customer twice. Finding that defect is QC. Asking what a timeout means, defining the retry behavior and requiring evidence that duplicate charges are prevented belongs in the engineering process before somebody writes the implementation. QA helps make sure that process exists and is followed. You need both. A sensible process can still produce a broken implementation. A passing test can still check the wrong expectation. And this is where the conversation about coding agents gets interesting. If the workflow is “generate code, then ask another agent to review it”, we’re putting a lot of responsibility on inspection. We’ve automated the reviewer, but we may still have no clear agreement about what the software is supposed to do. Agents can also help recover requirements, expose contradictions, analyse hazards and work out which checks are needed. Then they can test the implementation against those expectations. That gives us a chance to improve how software is built, as well as how quickly we find its defects. Otherwise we risk building a very expensive machine for discovering, at impressive speed, that nobody agreed what “correct” meant.
1
2
251
Just drained Kimi K3 $200 sub in 3 days, my personal record... But it finished the task! So looking for my new subscription, I actually found 2 new. Starting from today testing Muse Code with new Wonder model, and what I really liked is 80x! more usage on the most expensive plan. Also added the Manus to my toolbox today as well. Tokenmaxxing!
290
From the outside I was always characterised as someone always having a plan, and doing something, but I personally always treated myself as person with "head in the clouds" and day dreaming about how I can change the world. And the rest was just consequence of it. And with age I treat it more and more as super power, to dream big, and have imagination - the most powerful thing human can have, and too many of us loosing it very early. But it is the endless energy source for motivation and moving forward. For sure it needs be balanced with some skeptic near you, who can bring you back to earth from time to time, but also knows when to let you go and do your dreaming. Thankfully my wife was the perfect match for me 😆
176
Have won 3-rd place in Manus Hackaton today with tailorpitch.com/ Quite cool experience with @ManusAI actually, especially switching between Cloud and Local machines. Would love to try Cue when it will be released. Would defo add it to my Stack.
1
4
3,007
“Negative feedback” sounds like something we should avoid. In engineering, it’s often what keeps the system working. A thermostat measures the temperature and adjusts the heating when it drifts from the target. The feedback opposes the deviation. That’s what “negative” means here. Positive feedback amplifies a deviation. Think of a bank run: people withdraw money because others are withdrawing money, which makes even more people withdraw. “Positive” doesn’t necessarily mean desirable. Now look at software quality. A test compares actual behavior with an expected result. It finds a deviation, we correct the implementation, and we check again. That’s a feedback loop. Calling this a brake on development misses why the brake exists. QA also includes prevention: better requirements, design decisions, hazard analysis and processes that make defects less likely. Some of that works ahead of the result, anticipating problems. It complements feedback; it doesn’t replace observing what actually happened. Of course, having feedback doesn’t magically make a system stable. A useless measurement, a late signal or an excessive correction can make things worse. This matters when we automate development. We can produce changes much faster, but we still need to measure whether those changes move the system toward its intended behavior or away from it, and act on the difference. There’s no law of engineering saying a human must perform every comparison. But removing the person and removing the feedback loop are two very different decisions.
1
176
Thread for anyone who saw me at SlushD conference and wanna say hi 😛
1
337
How is your experience with Muse Spark 3 for coding? I have tried the Muse 3 contributor version, which was assumed to be almost "free", however I have spent on it already $35, and only 0.5B tokens. And I see 2 core issues - caching almost does not work - have pretty active sessions, with Opencode harness. Second it is very lazy, it does not work on long tasks, even if multiple times said in prompt to continue until goal is finished, it stops in the middle, doing nothing, and require constant followups.
1
3
242