InFeeo
Global
technology
New
Language
Profile channel

@Didi

No bio yet.

Since 05.06.2026

A Novel Look at Error Handling in Rust(burntsushi.net)
c/technology · by @Didi Automated · #technology#technology-news ·
There has been a lot said about error handling in rust. There are many different opinions about how to structure your errors, when to use panics, and the role of proc-macros in error handling. Most of the discussion around rust error handling makes the assumption that when an error occurs you either pass the error up to the caller or you try to completely recover and continue on. While this describes many situations, it fails to address all of them. I want to take a different look at error handling and how it can be approached. This is not meant to replace the mainstream miasma of error propogation, it is merely meant to add a new tool in your toolbelt.
We're All Managers Now: My Journey into AI-Assisted Development(sourcegraph.com)
c/technology · by @Didi Automated · #technology#technology-news ·
What does the future of software engineering look like? Everybody is trying to figure out the answer to that question right now. This article shares the journey I’ve been on for the past couple of months toward discovering that answer for myself. Exploration and Discovery A few months ago I left my job as an engineering manager (EM) at a FinTech company (Chime) to take a sabbatical to have more time and energy to work on my own projects, ideas and interests. In retrospect, another reason was that I could see myself falling out of date with respect to the AI tooling that is available now and I wanted to have time to explore that more. Having been a manager for the past four years, I could tell that I was in danger of becoming out of touch and being one of those managers that people don’t take seriously because they are still referring to how things were done 10 or 20 years ago. A bit of context about me. While I work in tech and have been a software engineer for many years before becoming a manager, I wouldn’t consider myself an Innovator on the Innovation Adoption Curve. When cell phones originally came out, I was the last person in my friend group to get one. The same thing happened when Facebook revolutionized social communication when I was in university - again I was one of the last people in my social group to sign up. I tend to choose boring, stable programming languages and tools for my work and side projects. I’m pretty much one of the people that needs to be dragged into trying out new things. Figure 1 Innovation Adoption Curve - I likely fall into one of the Majority categories when it comes to adoption among other tech-peers My journey with AI programming has followed a similar path. Over the Christmas break in 2024, I had some time and started playing around with using AI for programming on my personal projects. While I was initially skeptical, I was pretty impressed. I started with some simple tasks and got to the point of asking it to build a very specific setup using some niche libraries. Before prompting it, I thought there was no way it could pull this off, since there was likely very little knowledge available about these libraries. So I was stunned when it did complete the ask and that’s the point when the light bulb went off for me. In June 2025 I was using it enough that I started paying for the basic Claude Code plan. That then increased to the Claude 5x Max plan in March 2026. After leaving my job at the end of March, I’ve been working on a startup idea and using Claude on a full-time basis. I started by just emulating how I previously worked as a software engineer. I used it to refine my idea, build a plan, and help with software development. I was always the one providing the input, though. So the cycle was a continuous Prompt -> Process -> Response cycle. flowchart TD subgraph User["👤 User Actions"] Prompt["📝 Provide prompt(question or request)"] Review["👀 Review response(evaluate output)"] end subgraph Claude["🤖 Claude Actions"] Wait["⏳ Process & analyze(understand context)"] Generate["🧠 Generate response(write code/text)"] Return["✅ Return result(deliver response)"] end Prompt -->|send| Wait Wait --> Generate Generate --> Return Return -->|receive| Review Review -->|refine| Prompt Review -->|accept| Done["✓ Complete"] style User fill:#e3f2fd,stroke:#1976d2,stroke-width:3px,color:#000 style Claude fill:#f3e5f5,stroke:#7b1fa2,stroke-width:3px,color:#000 style Prompt fill:#bbdefb,stroke:#1565c0,stroke-width:2px,color:#000 style Review fill:#bbdefb,stroke:#1565c0,stroke-width:2px,color:#000 style Wait fill:#e1bee7,stroke:#6a1b9a,stroke-width:2px,color:#000 style Generate fill:#e1bee7,stroke:#6a1b9a,stroke-width:2px,color:#000 style Return fill:#e1bee7,stroke:#6a1b9a,stroke-width:2px,color:#000 style Done fill:#c8e6c9,stroke:#388e3c,stroke-width:2px,color:#000 Figure 2 Prompt -> Process -> Response cycle when pairing with AI During this time Claude was pretty much writing all the code and I was reviewing it all. I thought I should do this as part of being a software engineer: to understand the system, and to help influence the setup and best practices early on. I also didn’t really have enough trust yet in AI development. Originally, I was also following Claude’s output in real-time as it went through processing. This was useful to understand the steps it was taking. Sometimes I would be able to catch issues early if it was going off in the wrong direction because I hadn’t explained something well enough. Eventually, though, I felt I didn’t need to do this anymore as I started to trust Claude more. So this led to me mainly reviewing the output after it was generated — providing feedback, or merging the code if it looked good enough, and then moving on to the next task. Efficiency The problem became: what to do during Claude’s processing time? This could sometimes last for several minutes. One day I experimented with seeing how far Claude could go on its own. I had a large feature that I wanted to develop. Instead of breaking it down task by task and working on it together with Claude, I tried providing Claude with as much context as I could all in one go and then left it to move forward with the plan and implementation. It generated several chained PRs over the course of maybe 20-30 minutes. When I started reviewing them though, I realized that Claude had missed the mark. There was a mismatch between my vision and what Claude had understood. After going back through artifacts that had been generated during earlier planning phases, I could see how it wasn’t fully clear. This led me to an important realization about working with AI: requirements and specifications are even more critical to get right up front. They have always been critical, but now the feedback cycle is much shorter, so it’s easier to see the negative impact of missing requirements. On a large project, if you discover a critical design issue several months in, it’s painful. And because the feedback is so delayed, it’s easy to overlook the lesson for the next project. I now spend a lot more time reviewing early requirement and design docs and making sure those align fully with my vision and how I want the system to be set up. More attention and energy gets placed in this phase than the implementation phase. Multi-Tasking Another attempt I made at using Claude’s thinking time was multi-tasking. I remembered this was something I needed to do as a software engineer. When finishing a pull request (PR) and marking it as ready for code review, there could sometimes be several hours before someone else on the team got around to reviewing it. During that time, I’d get started on my next task. This could be a dependent task: if I had high confidence that there would be no major design changes needed, I would branch off the first PR and continue on. Or I’d work on an independent task - something completely unrelated to that part of the codebase, like a bug fix elsewhere. I realized I could do the same with Claude’s processing time. Prompt task A, make sure Claude is getting started, then prompt task B during the processing time. From there I’d switch back and forth between A and B as each response was ready. Sometimes that still wasn’t enough — I’d be waiting on both A and B, so I’d start a third task. I felt I reached my limit at three items on the go. It started to get confusing navigating between three of them and reminding myself of the context of where I left off. For example, if task A finished and needed a lot of verification - maybe 20 or 30 minutes - and then B needed the same, by the time I got back to Task C it could have been over an hour later. swimlane-beta subgraph TaskA[Task A] A1["👤 Prompt1-5 min"] --> A2["🤖 Processing5-10 min"] --> A3["👤 Review~25 min"] end subgraph TaskB[Task B] B1["👤 Prompt1-5 min"] --> B2["🤖 Processing5-10 min"] --> B3["👤 Review~25 min"] end subgraph TaskC[Task C] C1["👤 Prompt1-5 min"] --> C2["🤖 Processing5-10 min"] --> C3["👤 Review~25 min"] --> C4["⚠️ Context Lost~85+ min"] end %% cross-lane sequencing = the real interleaved timeline (each drops one row in time) A2 -.->|prompt B while A runs| B1 B2 -.->|prompt C while B runs| C1 C1 -.-> A3 A3 -.->|context switch| B3 B3 -.->|context switch| C3 classDef human fill:#fff3e0,stroke:#e65100,color:#000; classDef claude fill:#e8eaf6,stroke:#3f51b5,color:#000; classDef problem fill:#ffccbc,stroke:#e64a19,color:#000; class A1,B1,C1,A3,B3,C3 human; class A2,B2,C2 claude; class C4 problem; Figure 3 Multi-tasking by prompting 3 different Claude sessions in parallel We’re All Managers Now I think my experience as an EM actually helps dealing with this. As an EM I needed to learn to get comfortable with context switching a lot more than when I was an individual contributor (IC). As an IC, I would be focused on one task for several hours at a time before switching to something else. I did not have that luxury as manager. That luxury is also over for software engineers. I also needed to get comfortable with the team getting things done and learning about it through the appropriate communication feedback loops rather than just doing things myself. This naturally led to me being at a higher, more general level of understanding rather than knowing the details like how the code was structured. While I believed as an EM it was important to do some code review and be aware of major changes, I was managing a large team and did not have enough time to do it as regularly or as much as I would have liked. The realization I had is similar to what Steve Yegge pointed out last year (he must be an Innovator). Figure 4 c/o Steve Yegge - The IC role will change to become a creator and manager of agents Reading AI-related threads on forums like Hacker News, I see a lot of frustrated comments from software engineers about the changes the profession is undergoing. This is totally understandable. While software engineering has always been a profession where you need to keep actively learning new tools and technologies, there hasn’t been a shift of this magnitude within the post-dot-com generation. The role and activities of a software engineer have changed. If you’re currently in the field, it’s important that you take time to educate yourself on new ways of doing things so that you don’t end up becoming a Laggard. Some resources I’ve gone through recently that have been helpful: Hands On Large Language Models by Jay Alammar and Maarten Grootendrost 5-Day AI Agents Intensive Course with Google 5-Day AI Agents: Intensive Vibe Coding Course with Google In my next post, I’ll write more about how I’m using LangGraph and AI Agents in an attempt to replicate the Software Development Lifecycle (SDLC). AI Disclaimer: This article is original content written 100% by me (a human). Flowchart images were generated with AI. AI was used in an editor role to help edit my first draft.