Skip Navigation

codeinabox

@ codeinabox @programming.dev

Posts
681
Comments
88
Joined
5 mo. ago

London based software development consultant

  • Ship types, not docs

    Jump

  • Regardless of what the author says about AI, they are bang on with this point:

    You have the truth (your code), and then you have a human-written description of that truth (your docs). Every time you update the code, someone has to remember to update the description. They won't. Not because they're lazy, but because they're shipping features, fixing bugs, responding to incidents. Documentation updates don't page anyone at 3am.

    A previous project I worked on we had a manually maintained Swagger document, which was the source of truth for the API, and kept in sync with the code. However no one kept it in sync, except for when I reminded them to do so.

    Based on that and other past experiences, I think it's easier for the code to be the source of truth, and use that to generate your API documentation.

  • I Started Programming When I Was 7. I'm 50 Now and the Thing I Loved Has Changed

    Jump

  • I Started Programming When I Was 7. I'm 50 Now and the Thing I Loved Has Changed

    Jump

  • There is much debate about whether the use em-dash is a reliable signal for AI generated content.

    It would be more effective to compare this post with the author's posts before gen AI, and see if there has been a change in writing style.

  • I Started Programming When I Was 7. I'm 50 Now and the Thing I Loved Has Changed

    Jump

  • This quote on the abstraction tower really stood out for me:

    I saw someone on LinkedIn recently — early twenties, a few years into their career — lamenting that with AI they “didn’t really know what was going on anymore.” And I thought: mate, you were already so far up the abstraction chain you didn’t even realise you were teetering on top of a wobbly Jenga tower.

    They’re writing TypeScript that compiles to JavaScript that runs in a V8 engine written in C++ that’s making system calls to an OS kernel that’s scheduling threads across cores they’ve never thought about, hitting RAM through a memory controller with caching layers they couldn’t diagram, all while npm pulls in 400 packages they’ve never read a line of.

    But sure. AI is the moment they lost track of what’s happening.

    The abstraction ship sailed decades ago. We just didn’t notice because each layer arrived gradually enough that we could pretend we still understood the whole stack. AI is just the layer that made the pretence impossible to maintain.

  • Stop Closing the Door. Fix the House.

    Jump

  • Even if the bubble pops, the existing large language models will remain, as will AI assisted coding.

  • The Software Quality and Productivity Crisis Executives Won’t Address

    Jump

  • Instead, most organisations don’t tackle technical debt until it causes an operational meltdown. At that point, they end up allocating 30–40% of their budget to massive emergency transformation programmes—double the recommended preventive investment.

    I can very much relate to this statement. Many contracts I've worked on in the last few years, have been transformation programmes, where an existing product is rewritten and replatformed, often because of the level of tech debt in the legacy system.

  • A Software Library with No Code

    Jump

  • I originally shared this after stumbling upon it in one of Martin Fowler's posts.

    The article reminds me of how my mother used to buy dress patterns, blueprints if you will, for making her own clothes. This no code library is much the same, because it offers blueprints if you wanted to build your own implementation.

    So the thing that interests me is what has more value - the code or the specifications? You could argue in this age of AI assisted coding that code is cheap but business requirements still involve a lot of effort and research.

    To give a non-coding example, I've been wanting to get some cupboards built, and every time I contact a carpenter about this, it's quite expensive to get something bespoke made. However, if I could buy blueprints that I could tweak, then in theory, I could get a handyman to build it for a lower cost.

    This is a very roundabout way of saying I do think there are some scenarios where the specifications would be more beneficial than the implementation.

  • Separate community for AI coding?

    Jump

  • Thank you everyone for your input. I have created a separate community, !aicoding@programming.dev, for AI coding related discussions.

  • Separate community for AI coding?

    Jump

  • I agree with you on that point, and the same could be said about the meat and dairy industry. However I don't think the answer is censoring discussions about cooking beef or chicken.

  • Separate community for AI coding?

    Jump

  • You can't compare racist posts, which are a form of hate speech and a breach of this instance's code of conduct, with discussions about topics that you don't agree with.

  • The imminent risk of vibe coding

    Jump

  • Gas Town’s Agent Patterns, Design Bottlenecks, and Vibecoding at Scale

    Jump

  • Expensive as hell! 🤑

    Yegge describes Gas Town as “expensive as hell… you won’t like Gas Town if you ever have to think, even for a moment, about where money comes from.” He’s on his second Claude account to get around Anthropic’s spending limits.

    I can’t find any mention online of the per-account limits, but let’s conservatively assume he’s spending at least $2,000 USD per month, and liberally $5,000.

  • Breaking the Spell of Vibe Coding

    Jump

  • I am not surprised that there are parallels between vibe coding and gambling:

    With vibe coding, people often report not realizing until hours, weeks, or even months later whether the code produced is any good. They find new bugs or they can’t make simple modifications; the program crashes in unexpected ways. Moreover, the signs of how hard the AI coding agent is working and the quantities of code produced often seem like short-term indicators of productivity. These can trigger the same feelings as the celebratory noises from the multiline slot machine.

  • The Death of Software Development

    Jump

  • Where did you get the impression that the author is an inexperienced developer and finance bro? The introduces himself as someone who started programming from the age of eleven.

    I’m Michael Arnaldi, Founder and CEO of Effectful Technologies — the company behind Effect, the TypeScript library for building production-grade systems. I’ve been programming most of my life. I started at 11 with the goal of cracking video games. Since then, I’ve written code at every level: from kernel development to the highest abstractions in TypeScript.

  • 10 things I learned from burning myself out with AI coding agents

    Jump

  • I think the most interesting, and also concerning, point is the eighth point, that people may become busier than ever.

    After guiding way too many hobby projects through Claude Code over the past two months, I’m starting to think that most people won’t become unemployed due to AI—they will become busier than ever. Power tools allow more work to be done in less time, and the economy will demand more productivity to match.

    Consider the advent of the steam shovel, which allowed humans to dig holes faster than a team using hand shovels. It made existing projects faster and new projects possible. But think about the human operator of the steam shovel. Suddenly, we had a tireless tool that could work 24 hours a day if fueled up and maintained properly, while the human piloting it would need to eat, sleep, and rest.

    In fact, we may end up needing new protections for human knowledge workers using these tireless information engines to implement their ideas, much as unions rose as a response to industrial production lines over 100 years ago. Humans need rest, even when machines don’t.

    This does sound very much like what Cory Doctorow refers to as a reverse-centaur, where the developer's responsibility becomes overseeing the AI tool.

  • Code Is Cheap Now. Software Isn’t

    Jump

  • This article is quite interesting! There are a few standout quotes for me:

    On one hand, we are witnessing the true democratisation of software creation. The barrier to entry has effectively collapsed. For the first time, non-developers aren’t just consumers of software - they are the architects of their own tools.

    The democratisation effect is something I've been thinking about myself, as hiring developers or learning to code doesn't come cheap. However, if it allows non-profits to build ideas that can make our world a better place, then that is a good thing.

    We’re entering a new era of software development where the goal isn't always longevity. For years, the industry has been obsessed with building "platforms" and "ecosystems," but the tide is shifting toward something more ephemeral. We're moving from SaaS to scratchpads.

    A lot of this new software isn't meant to live forever. In fact, it’s the opposite. People are increasingly building tools to solve a single, specific problem exactly once—and then discarding them. It is software as a disposable utility, designed for the immediate "now" rather than the distant "later."

    I've not thought about it in this way but this is a really good point. When you make code cheap, it makes it easier to create bespoke short-lived solutions.

    The real cost of software isn’t the initial write; it’s the maintenance, the edge cases, the mounting UX debt, and the complexities of data ownership. These "fast" solutions are brittle.

    Though, as much as these tools might democratise software development, they still require engineering expertise to be sustainable.

  • All my new code will be closed-source from now on - Marc J. Schmidt

    Jump

  • I had originally meant to post it here, but I accidentally posted it to a different instance.

  • “Because of GenAI, coding is no longer the bottleneck”

    Jump

  • Thank you! I've added the image to the post as well.

  • LLMS Are Not Fun

    Jump

  • I use AI coding tools, and I often find them quite useful, but I completely agree with this statement:

    And if you think of LLMs as an extra teammate, there's no fun in managing them either. Nurturing the personal growth of an LLM is an obvious waste of time.___

    At first I found AI coding tools like a junior developer, in that it will keep trying to solve the problem, and never give up or grow frustrated. However, I can't teach an LLM, yes I can give it guard rails and detailed prompts, but it can't learn in the same way a teammate can. It will always require supervision and review of its output. Whereas, I can teach a teammate new or different ways to do things, and over time their skills and knowledge will grow, as will my trust in them.