More rules should mean better output. That's the intuition. I spent weeks building a comprehensive CLAUDE.md — 200 lines covering naming conventions, security rules, error handling, architectural patterns, import ordering, type safety requirements, and more. I was proud of it. I'd thought through every scenario. Then I scored the output. 79.0 / 100. My carefully crafted documentation was actively
Three days of guided exercises. Today — no template, no "here's the complete code, just copy and paste." Just a brief: based on what you know — build your WishList contract. A personal WishList where only the owner can fulfill a wish. Small enough to finish in one session. Not so small that the decisions made themselves. Code: github.com/alena-dev-soft/solidity-learn/contracts/04day/ The first thi
Day 3: Voting, Sybil Attacks and Identity Day 3 was the first day that felt like actual software engineering rather than syntax tourism. The task: write a voting contract. Simple enough on the surface - until you start poking at the security model and realize the whole thing has serious gaps in its logic. What looked like a toy example turned out to be a good proxy for real system design problem
Day 2: Access Control Counter.sol - a little better than "Hello World", right? The goal: write a simple Counter contract - increment, decrement, reset - // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; contract Counter { uint256 public count; address public owner; constructor() { owner = msg.sender; count = 0; } function increment() public {
A .NET Dinosaur in Web3 — Day 1: First Smart Contract I've been writing .NET for many years. Today I deployed my first smart contract. I'd like to share my journey into Web3 — every single day. I love what I do — really. I'm a .NET Dinosaur and Azure-passionate developer, Instead of drowning in YouTube tutorials and boring courses, I did something Think of it as a personal trainer who never judg
Have you ever looked at code you wrote six months ago and thought: "Who wrote this monster?"? Relax, it happens to all of us. In software engineering, writing code that a machine understands is the easy part. The real challenge is writing code that other humans (including your future self) can understand, maintain, and scale. This is exactly where Software Design Principles come into play. In this
Part 1 of 5 in The New Engineering Contract — what it means to lead engineers when AI is doing more of the coding. SWE-CI tested 18 AI models across 71 consecutive commits. Most broke something on commit 47 they'd already broken on commit 1. That's not an intelligence problem. That's a learning system that isn't learning. A paper made me uncomfortable this month. Not because of what it found about