Alex Fedorov | Fractional CTO | FinTech Expert

Sell dev hours for a living? AI means you can ship faster. Ship faster and you bill less. Don't, and someone cheaper eats you. Next XTC Berlin: "Get Better, Bill Less: The AI Paradox of Software Consultancies" 🗓 Tue Nov 10, 7 PM meetu.ps/e/Q4VRJ/sxprg/i

XTC Berlin is happening tonight at 19:00. If you are interested in fast iteration and quick feedback cycles, and curious how this could possibly work when software meets hardware and wetware, then join us tonight. Join me at Hardware- and Wetware-in-the-Loop: Agile Software in Regulated Industries meetu.ps/e/Q4VRG/sxprg/i

I’m excited to host tomorrow night a discussion meetup about application of Agile Software Development practices to software that involves a lot of hardware (machines, cars, etc.) and wetware (patients, taste, chemistry, etc.). XTC Berlin is an in-person meetup discussion group, where an expert presenter introduces the whole group to the topic’s foundations and the groups independently discuss the topic, share their learnings and insights, and become better and richer professionals. XTC has roots in Extreme Programming, however, because effective software development is usually more about people and less about tech, all curious people from adjacent and other professions are highly welcome. In my experience, diversity of ideas creates the best insights. If you’re in Berlin tomorrow evening, you’re invited to join us! Time: 19:00 - 21:30. Location: Hedwig-Dohm-Haus RSVP here: meetu.ps/e/Q4VRG/sxprg/i

The hardest question at the XP Unconference last year did not get an answer. It came out of a session titled "How to Detect Thinking by Humans", whose second half asked when that even matters. Somebody in it put the problem like this: "In the past, we used to use written documents to figure out if someone has thought about a problem. Now we're saying generate these documents with AI. How do I know that someone has thought about a problem? We can't use the document anymore." Think about how much of your process that breaks. Design documents. Architecture decision records. Written proposals. Pull request descriptions. Every one of those was a proxy for thinking, and the proxy worked for one reason only: producing the artefact used to require doing the thinking. The artefact is now available separately from the thinking. The related finding is worse. Writing triggers thinking, and coding is where you discover what the specification missed. Remove the human from the writing and the discovery loop never fires at all. Nobody in the session had a replacement. The reframe that came closest: treat the model as an inquiry partner, not an answer machine. Have it generate acceptance criteria as multiple choice questions for a human to answer, in place of statements for a human to nod at. What else came out of the two days: xpunconf.org/pages/insights

Most of what worked comes down to controlling what the model can see. I saw it in every technique people brought to the XP Unconference last year, all of it from their own codebases. Aggressive context clearing. Plan to markdown. Clear. Feed back only the plan. Break down the first phase. Write that to markdown. Clear again. Then implement. The reason people gave at the time is not the reason it has lasted. What has lasted is that a context compacted once erodes, and a context compacted several times erodes further, so the things that matter have to be said again. The plan on disk is how you say them again without retyping them. Hierarchical context files, one per directory level, so an agent working inside a subsystem gets that subsystem's rules and not the whole book. Sub-agents. In the room's words: "They don't need to know so much. They just need to know what they need to know." What each one narrows is the question, not the capacity. Not smaller. Narrower. So the reflex to resist is more of everything at once, not more context. A scoped worker holds an order of magnitude more than a year ago, and batching them puts large volumes through thoroughly and consistently. The other five techniques on that list: xpunconf.org/pages/insights

Only seniors are gaining. I heard it in session after session at the XP Unconference last year. Somebody put it plainly: "The assumption that every developer in any tier gets faster is simply not empirically true." The business case most organisations wrote assumed the opposite. Uniform uplift across the whole team was the model. If the gain concentrates at the top of the seniority curve, the arithmetic behind a lot of tooling budgets is wrong and nobody has gone back to check. A two to three year hiring gap for junior and mid-level engineers already exists. "The industry will pay for this", five to ten years out. The management logic that produced the gap is easy to state and hard to argue with inside a quarter. Speed is everything. Juniors are slow. We can skip them. That logic never prices what it is giving up. "One key thing junior developers bring to the table is a fresh view. They are not tainted by bad biases." Nobody there landed a fix. The trade is being made right now, in most organisations, and almost nobody has written it down. The full write-up, careers and hiring included: xpunconf.org/pages/insights

Prompt rules do not survive contact with an agent. Architecture tests do. I watched this argued out at the XP Unconference last year, by people comparing what worked in their own codebases. The reasoning is mechanical. An agent can ignore a rule written in a prompt, and it will, because a prompt is a suggestion that gets weighed against everything else in the context. It cannot ignore a test that fails the build. So move the constraint out of the prompt and into the pipeline. ArchUnit. Dependency Cruiser. CodeScene. ESLint. Biome. A second technique from the same list works the same way. Multi-model red team and blue team: one model writes, another tears it apart. The check never comes from the thing being checked. None of that is a workaround. It is the observation that a constraint only constrains when something stops a merge. The rest of what worked in real codebases: xpunconf.org/pages/insights

A session at the XP Unconference last year was called "What Happens to Accelerate?" Do your delivery metrics still work? If AI writes in seconds what used to take days, does lead time still diagnose anything? A number that used to mean the pipeline was healthy might now mean only that the typing got faster. Most of what lead time measured was never typing. It was review queues, waiting for an environment, waiting for an approval, work sitting in a batch. If none of that moved, a falling number is reporting the one part that did. The session was left open. The direction of the risk was not: AI exposes dysfunction, it does not create it. A measurement system that was already pointing at activity and not at outcomes will keep pointing there, faster, and with more confidence behind the number. If you run delivery and you have not asked what your dashboard measures now that the expensive part of the work has moved, that is the question I would put to you. The organisers' write-up, open questions included: xpunconf.org/pages/insights

A team wired up an MCP so their agent could file Jira tickets automatically from error logs. They shut it down after two days. In the practitioner's words: "the amount of backlog that generated was insane." Nothing hallucinated. Nothing went rogue. The integration worked exactly as specified, at machine speed, against a log stream that had always held far more errors than anyone was ever going to triage. What had been holding that system together was that a human had to care enough to open a ticket. Nobody had ever written that rule down. The rule is writable. Not in one prompt, and not by anyone who has not done the triage themselves, but it is writable. Watch what the agent files for a few weeks. Every time it opens a ticket that should not exist, work out what you knew that it did not. Write that down. Then do it again, and keep going until the corrections stop. That is not prompt tuning. It is getting a judgement out of somebody's head one rejected ticket at a time, and nobody had ever needed to do it, because the judgement lived in a person and worked perfectly well there. "Worst case scenario is that it actually exactly does what you asked it to do. It's just not what you wanted." That is the argument for writing the rule down. It was never the argument against the agent. The failures are in there too: xpunconf.org/pages/insights

One finding survived the year. Human-friendly code is also AI-friendly. At the time it sounded almost too obvious to write down. The reason it holds is that it depends on nothing that has changed since. Not which model you use, not how you prompt it, not how much context you can buy. It is a claim about the code. The mechanism is dull, which is usually a good sign. A name that lies about what the code does forces a reader to open the body and check. It forces an agent to do the same. One behaviour spread across four unrelated files has to be found four times, by a person or by an agent, and missing the fourth breaks the change anyways. So the list has not changed. Clear boundaries. One behaviour in one place. Names that mean what they say. Tests that explain what the thing is for. Unfashionable, and it has not aged a day. Thirty sessions, and this was the one that lasted: xpunconf.org/pages/insights

Cheap building did not kill YAGNI. It promoted it. For fifteen years the defence of building only what you need was that building costs too much. The plugin system nobody asked for now takes an agent twenty minutes. That defence is dead. Cost of build was never the expensive part. Carrying was. Repairing was. Neither got cheaper. Martin Fowler wrote the arithmetic down years ago. A speculative build pays only when the probability that the need arrives as you imagined it, multiplied by what you save by having built early, beats the cost of carrying it until then plus the cost of repairing it when the need shows up in a different shape. One term collapsed. Three survived. Time to rely on the one that actually makes the difference. Repair. A wrong abstraction has to be dismantled before it can be replaced. An absent one just has to be added. A confident wrong guess is more expensive than an admitted gap. That was true when building was slow and it is true now. When a capability can be generated in an hour, at the moment the need is real, in the shape it arrived in, the option value of not building it today has gone up. Cheap creation makes this more binding, not obsolete. Your executor learned from mature codebases. Those are full of configurability, interfaces and extension points, because they earned them over years of real pressure. So that is what gets emitted, by default, on every task, whether or not anyone asked. Unrequested generality used to be an ambition. Somebody proposed it. Somebody defended it in planning. Somebody could say no. It is now the starting position, at machine volume. You will not catch it in review. Review does not scale with agent throughput, and a reviewer who has approved forty diffs is not inspecting the forty properly. It has to be refused in the commander intent, before the work starts. One more, for anyone who thinks they escaped this by not adding abstractions. Generated breadth is speculative building too. Ten capabilities produced quickly because producing them was easy carry the same cost as ten produced slowly. The difference is that nobody chose to pay it. The plugin architecture with one plugin. The flag no deployment sets. The abstraction over the only database you will ever have. Cheaper to create. Same price to own.

Tonight in Berlin: How should we train junior software professionals in the age of AI? AI makes juniors productive. But are they gaining the experience needed to become seniors? Join our group discussion at XTC Berlin: meetup.com/extreme-tuesday-c…

Improving only what you touch in the code isn't lack of ambition; it's strategic engineering. Aim for the highest impact with the least effort. 🎯 #StrategicCoding #EngineeringROI

Coding Dojos offer more than just coding challenges. They offer a chance to pair with someone else, exchange expertise, and broaden your perspective. Social learning accelerates mastery. 🤝 #CodingDojo #PairProgramming

Refactoring isn't just about improving your own code; it's a team sport. The better you get at it, the better everyone else gets at working with your code. Shared ownership amplifies your team's efficiency. #Teamwork #CodeStewardship

Ever noticed that our industry's most important practices have been called 'continuous'? That’s as frequent as it gets! Embrace the power of frequency in #SoftwareEngineering. #10xSoftwareEngineering #ContinuousDelivery

🤔 If you've spoken up about ethical issues in a project and your team doesn't listen, maybe it's time to 'vote with your feet.' Remember, your skills are valuable elsewhere too. #EthicsFirst #CareerMoves

Practices are the final piece of the #10xSoftwareEngineering puzzle. These proven methods allow us to live our principles and values without overthinking every step. #SoftwareDevelopment #Practices

📜 In engineering, the 'how' can be as important as the 'what.' If a project's means violate your ethics, it's more than acceptable to question the ends. #EngineeringEthics #ProjectManagement

Stepping out of your comfort zone is essential for rapid learning and improvement. Embrace courage and take on bigger challenges to deliver greater results. #10xSoftwareDelivery #CourageInTech