2026-08 - W2

Incentives are for losers - by Adam Mastroianni

Thought provoking essay. Might be quite difficult to “escape” from this value system.

”Coding is solved” misses the point - Waldek Mastykarz

Advanced AI sycophancy

But sycophancy can also manifest as disagreement. We should be on our guard for more sophisticated forms of sycophancy coming from newer models, and we should not feel immune from AI sycophancy just because we can laugh at the silliest examples.

That’s… quite interesting. I did not think of this way.

How to Fight Clickbait: Meta, LinkedIn & YouTube Case Studies

Interesting article, showing 3 different paths taken by 3 giant RecSys.

TDD inside the agent loop - theater or actual value?

Interesting benchmark. It seems TDD is for human (not surprisingly), so the value of it for AI agents is not there, and cost 3x more…

I think at this point there is generally more and more evidence that being overly specific about how we want a model to do something is not a sustainable approach. Instead, we should find as many ways as we can to monitor the outcomes and give feedback. That feedback should be automated wherever possible, and we need to carefully think about where we insert ourselves as arbiters of what is good and correct.

Even though I am aware that my little eval is far from representing a broad perspective on the effectiveness of TDD, it definitely hasn’t given me any new indications that all this effort is worth it. Especially not if we can find other ways to achieve the majority of TDD benefits.

I personally have stopped telling my coding agents to write tests first, let alone do TDD (which I never did, to be honest), until I see evals or other strong arguments that convince me otherwise. I’m trying to focus instead on the benefits of TDD when I use it outside of the agent loop, and exploring alternative ways to achieve them.

cost and benefits when an agent does TDD by itself

where good ideas come from (for coding agents) • Solving the decision problem

Insightful article. The author highlights the importance of engineering, and not just vibe prompting, by quoting Steven Johnson’s book “Where good ideas come from”.

  1. the adjacent possible - most “new” ideas are the next reachable step from what already exists. stairs, not teleportation.
  2. liquid networks - ideas show up when partial thoughts collide: people, yes, but also artifacts (docs, code, past debates).
  3. the slow hunch - many good ideas start half-baked. you keep them around until they meet the missing piece.
  4. serendipity - luck plus recognition; you notice the useful anomaly when it appears.
  5. error - failure is information; feedback turns wandering into convergence.
  6. exaptation - repurpose a thing built for one job into a different job. reuse as invention.
  7. platforms - stable primitives and standards let lots of people build lots of things faster and safer.

Growing as an engineer in a world of AI

They had a few traits in common: exceptional communication, perseverance in spades, lots of curiosity, and extreme ownership. And, last but not least, they could learn fast. Really fast.They had a few traits in common: exceptional communication, perseverance in spades, lots of curiosity, and extreme ownership. And, last but not least, they could learn fast. Really fast.

I’m done using AI – Brett Codes

So what did this do? Well, it made me lazy. It made me stop caring. It made me a worse programmer. It made me depressed. Because I stopped doing the hard work, I stopped learning, I stopped growing, I stopped being the one making the software. … Upon reflection, I’ve come to believe that quality software is not about how many features something has or how quickly it is built but rather how cared for it is by the designers, developers, and product people who work on it. There’s an ineffable aspect to my favorite pieces of software where I don’t think of it is as feature matrix but rather as an interface made by a human for humans that’s a joy to use. And when you build software with AI, it leads to worse software. Sure, it’s faster to build initially, but I think to the detriment of the quality of the code and the user interface and the user experience.

Beyond Senior - Creating Hope | baweaver

Be known for solving things rather than complaining about them. Complaining is cheap and easy. Fixing things is hard. Be the person who picks up a shovel and does the work.

There will always be things that happen which make bitterness tempting. You’re going to watch projects fail, migrations stall, leaders fail, technical debt accumulate, and organizations repeat the same mistakes over and over again. Over time this becomes cynicism under the guise of wisdom and experience, because a cynic can always tell you why something won’t work. With enough experience you can find a story proving any idea is doomed if you wanted to, but that’s a miserable place to be.

Don’t confuse that with wisdom.

You cannot fix everything, so don’t. Doing so will destroy you. Some problems are not worth fixing, some aren’t even yours to fix, and some require resources you won’t have. Part of growing is learning to tell the difference and not letting those limits turn into fatalism.

What you can do is grab a shovel, do the work, and through doing so give others permission to do the same.

I don’t believe there are perfect answers in this industry. Everything changes. Conditions, organizations, customers, people, reality itself has a habit of disagreeing with even our best assumptions given enough time.

What matters is whether what we built can match that moment when it happens. We do the best we can with the information available, understand the tradeoffs, preserve optionality against an uncertain future, and remain willing to change our minds when evidence contradicts us.

Moving beyond senior and becoming a leader means creating hope through both our words and our actions. Our example defines culture over time, and what others believe is even possible.

The industry fixates on force multiplication, but rarely asks what it is we’re multiplying. Are we multiplying bitterness, fear, scarcity, or helplessness? Or are we multiplying trust, generosity, curiosity, agency, and hope?

On comments

Good refresher on what good comments are.

Process as a Proxy for Motivation

My request to you is this, make life simple. For any lofty goals which you have, find a way of achieving them without too much thought. If you want to write more, dedicate some hour in every week to writing. If you want to save more money, set up a direct debit on each pay day. If you want to change your behaviours, look at your actions first.

Well said.

Deciphering Glyph :: The Futzing Fraction

Really really good article. It depicts the interactions of humans with the clankers, especially citing some biases and some good examples to illustrate author’s thoughts.

Understanding is the new bottleneck

Interesting way of tackling cognitive debt.

Techniques for understanding:

  1. explanations
  2. micro-worlds
  3. shared-spaces

SREcon25 Americas - Technical Debt as Theory Building and Practice - YouTube

Interesting take on technical debt. The presenter is using housework as a metaphor instead.

Stop sending me huge PR; a rant

Look — AI is a great tool, it really helps things move faster and can make code better, but when React came out we didn’t accept larger PRs because “React is faster to write and easier to read,” so why are we doing it now?

Addendum: are you just making giant PRs so I give up halfway through and approve it? If so, well played. Well. Played.

GitHub - inevolin/k8s-cpu-limits-analyzed: Kubernetes CPU limits make your apps (very) slow and costly · GitHub

Interesting. Might be worth getting the reviews from SREs.

Programming as Theory Building: Why Senior Developers Are More Valuable Than Ever · cekrem.github.io & Programming as Theory Building, Part II: When Institutions Crumble · cekrem.github.io

Interesting concept:

the program is not the code, it’s the theory. But where does the theory actually live? Not just in individual heads, but in the relationships between those heads. In the shared understanding built through years of working together. In the institutional memory of why we do things this way and not that way.

Coding as Craft: Going Back to the Old Gym · cekrem.github.io

The phrase “reflexive AI usage” is what triggered my strongest reaction. “Reflexive” suggests unthinking, automatic reliance. It implies delegating not just tasks but judgment itself.

What I advocate instead is intentional collaboration with AI:

  • Use AI when/if it makes sense, not by default
  • Maintain critical thinking about its outputs
  • Understand what you’re integrating before you integrate it
  • Challenge its assumptions and review its code

This approach preserves your agency as a craftsperson while still leveraging the efficiency AI can bring.

Being “Good” at Things - Jim Nielsen’s Blog

I think that’s true of so many things we do as humans: programming, design, writing, etc. If you want to be “good” at what you do, do the hard, little things that others gloss over. Do them consistently and well, with discipline and perseverance.

Well said.