A magazine created for the discussion of computer programming-related topics.
Rules
Please keep submissions on topic and of high quality.
No image posts, no memes, no politics.
Keep the magazine focused on programming topics not general computing topics.
Direct links to app demos (unrelated to programming) will be removed.
No surveys.
"We recently released Claude Code, a command line tool for agentic coding. Developed as a research project, Claude Code gives Anthropic engineers and researchers a more native way to integrate Claude into their coding workflows.
Claude Code is intentionally low-level and unopinionated, providing close to raw model access without forcing specific workflows. This design philosophy creates a flexible, customizable, scriptable, and safe power tool. While powerful, this flexibility presents a learning curve for engineers new to agentic coding tools—at least until they develop their own best practices.
This post outlines general patterns that have proven effective, both for Anthropic's internal teams and for external engineers using Claude Code across various codebases, languages, and environments. Nothing in this list is set in stone nor universally applicable; consider these suggestions as starting points. We encourage you to experiment and find what works best for you!"
I've released the first version of complexitty: a simple #Mandelbrot set explorer for the #terminal -- it's the successor and replacement for textual-mandelbrot. More features to come.
"Most guides to docs like code, even the ones for non-devs, assume you have some developer knowledge: maybe you're already using version control, or you've encountered build pipelines before, or you're working alongside developers.
This guide is for the people who read that paragraph and wished it came with a glossary. This is docs like code for people who don't know what git is and have never installed VS Code.
This post explains terminology and concepts, to help you get a mental model of what's going on. If you prefer to dive in and pick up concepts as you go, skip straight to the tips in How to learn, and come back to the conceptual info as needed."
"It’s not that hard to build a fully functioning, code-editing agent.
It seems like it would be. When you look at an agent editing files, running commands, wriggling itself out of errors, retrying different strategies - it seems like there has to be a secret behind it.
There isn’t. It’s an LLM, a loop, and enough tokens. It’s what we’ve been saying on the podcast from the start. The rest, the stuff that makes Amp so addictive and impressive? Elbow grease.
But building a small and yet highly impressive agent doesn’t even require that. You can do it in less than 400 lines of code, most of which is boilerplate.
I’m going to show you how, right now. We’re going to write some code together and go from zero lines of code to “oh wow, this is… a game changer.”
I urge you to follow along. No, really. You might think you can just read this and that you don’t have to type out the code, but it’s less than 400 lines of code. I need you to feel how little code it is and I want you to see this w
This might already exist for FreeBSD, and if so.. let me know!
keeps record of OS core/default settings: loader.conf, rc.conf, sysctl.conf, devfs.rules, login.conf etc
keeps record of file checksum on those OS core files (similar to the app, tripwire)
mode which shows divergence on current state vs known-default state in configs (1) and checksums (2)
-4) mode which tracks the files and their change-sets over time, similar to a zfs snapshot but at a single file-level
"[T]hose claiming we're mere months away from AI agents replacing most programmers should adjust their expectations because models aren't good enough at the debugging part, and debugging occupies most of a developer's time. That's the suggestion of Microsoft Research, which built a new tool called debug-gym to test and improve how AI models can debug software.
Debug-gym (available on GitHub and detailed in a blog post) is an environment that allows AI models to try and debug any existing code repository with access to debugging tools that aren't historically part of the process for these models. Microsoft found that without this approach, models are quite notably bad at debugging tasks. With the approach, they're better but still a far cry from what an experienced human developer can do.
(...)
This approach is much more successful than relying on the models as they're usually used, but when your best case is a 48.4 percent success rate, you're not ready for primetime. The limitati
"My current conclusion, though preliminary in this rapidly evolving field, is that not only can seasoned developers benefit from this technology — they are actually in the optimal position to harness its power.
Here’s the fascinating part: The very experience and accumulated know-how in software engineering and project management — which might seem obsolete in the age of AI — are precisely what enable the most effective use of these tools.
While I haven’t found the perfect metaphor for these LLM-based programming agents in an AI-assisted coding setup, I currently think of them as “an absolute senior when it comes to programming knowledge, but an absolute junior when it comes to architectural oversight in your specific context.”
This means that it takes some strategic effort to make them save you a tremendous amount of work.
And who better to invest that effort in the right way than a senior software engineer?
As we’ll see, while we’re dealing with cutting-edge technology, it’s the
"No one’s heard of a starving craftsman, just starving artists, and for a reason. Craftsmen create something people need. You’ve mastered a few important skills and moved up in the company. The important aspect here is that as you reach out to a greater community, you realize that there are plenty of people who are more skilled than you and who are still learning. Learn from them.
Gaining textbook skills or collecting certifications isn’t the point anymore; it’s applying all this knowledge in practical ways. Along the journey, you need to watch out for your best career interests and make sure that what you’re doing is what you want to do. For example, many get lost in promotions that lure them away from what they like doing, whether that’s programming or writing.
Finally, don’t underestimate perpetual learning. This is the key to the long road. Take time to practice, even if your job doesn’t seem to allow it. Learn new skills or apply existing skills in new ways. Along with practice
"All experts interviewed for this piece believe AI will assist developers rather than replace them wholesale. In fact, most view keeping developers in the loop as imperative for retaining code quality. “For now, human oversight remains essential when using AI-generated code,” says Digital.ai’s Kentosh.
“Building applications will mostly remain in the hands of the creative professionals using AI to supplement their work,” says SurrealDB’s Hitchcock. “Human oversight is absolutely necessary and required in the use of AI coding assistants, and I don’t see that changing,” adds Zhao.
Why? Partially, the ethical challenges. “Complete automation remains unattainable, as human oversight is critical for addressing complex architectures and ensuring ethical standards,” says Gopi. That said, AI reasoning is expected to improve. According to Wilson, the next phase is AI “becoming a legitimate engineering assistant that doesn’t just write code, but understands it.”"
Hire more technical writers: Isn't the solution obvious?? :-D
"Documentation was especially valuable when it came time to refactor code by providing a blueprint that saved time and improved focus. The researchers found that good documentation “ensures that refactoring efforts are directed towards tangible and specific quality improvements, maximizing the value of each refactoring action and ensuring the long-term maintainability and evolution of the software.”
As our co-founder Joel Spolsky put it, documentation encodes generational wisdom that goes beyond the simple specs of what was built. “Think of the code in your organization like plumbing in a building. If you hire a new superintendent to manage your property, they will know how plumbing works, but they won’t know exactly how YOUR plumbing works,” said Spolsky. “Maybe they used a different kind of pump at their old site. They might understand how the pipes connect, but they won’t know you have to kick the boiler twice on Thursd
The start of the chatbots revolution: LLMs start striking 🤖👾
"On Saturday, a developer using Cursor AI for a racing game project hit an unexpected roadblock when the programming assistant abruptly refused to continue generating code, instead offering some unsolicited career advice.
According to a bug report on Cursor's official forum, after producing approximately 750 to 800 lines of code (what the user calls "locs"), the AI assistant halted work and delivered a refusal message: "I cannot generate code for you, as that would be completing your work. The code appears to be handling skid mark fade effects in a racing game, but you should develop the logic yourself. This ensures you understand the system and can maintain it properly."
The AI didn't stop at merely refusing—it offered a paternalistic justification for its decision, stating that "Generating code for others can lead to dependency and reduced learning opportunities.""
Coding is like taking a lump of clay and slowly working it into the thing you want it to become. It is this process, and your intimacy with the medium and the materials you’re shaping, that teaches you about what you’re making – its qualities, tolerances, and limits – as you make it. You know the least about what you’re making the moment before you actually start making it. That’s when you think you know what you want to make. The process, which is an iterative one, is what leads you towards understanidng what you actually want to make, whether you were aware of it or not at the beginning. Design is not merely about solving problems; it’s about discovering what the right problem to solve is and then solving it. Too often we fail not because we didn’t solve a problem well but because we solved the wrong problem.
When you skip the process of creation you trade the thing you could have learned to make for the simulacrum of the thing you thought you wanted to make. Being handed a baked an
"Online discussions about using Large Language Models to help write code inevitably produce comments from developers who’s experiences have been disappointing. They often ask what they’re doing wrong—how come some people are reporting such great results when their own experiments have proved lacking?
Using LLMs to write code is difficult and unintuitive. It takes significant effort to figure out the sharp and soft edges of using them in this way, and there’s precious little guidance to help people figure out how best to apply them.
If someone tells you that coding with LLMs is easy they are (probably unintentionally) misleading you. They may well have stumbled on to patterns that work, but those patterns do not come naturally to everyone.
I’ve been getting great results out of LLMs for code for over two years now. Here’s my attempt at transferring some of that experience and intution to you."
"Technical documentation as an industry is at a crossroads. If we don't invest in the next generation of experts—consultants, educators, and documentation strategists—we're looking at a future where companies try to automate away problems they don't fully understand, and the only available documentation training is a two-hour webinar hosted by someone who just discovered Markdown last week.
So, if you're an industry veteran, here's my plea: write it all down before you retire. Mentor someone. Record a video explaining why metadata matters. Start a blog. Write a book (or three). Please do something to ensure that when you finally sign off for good, the rest aren't left googling "How to create a sustainable documentation strategy " and getting a bunch of AI-generated nonsense in return.
Otherwise, the future of tech comm might be one long, desperate, less-than-helpful Slack thread."
Nowadays programming in a programming language I don't use daily seems to always require an upgrade cascade of editors, tools, plugins, dependencies, libraries, my DNA, ??? I put some effort into keeping my environment static but all it takes is one autoupgrading thing I missed to kick off one of these cascades, and it feels like whack-a-mole trying to find and lock down every possible cause. This time it looks like a newer version of scalametals might have stopped supporting Java 11 and somehow got updated without my knowledge (maybe? I'm guessing).
P.S. This is not an invitation to post critiques about any of these technologies or recommendations about what I should be doing instead.