caiocdcs | blog

A Year Using AI to Code

2026-01-03T00:00:00+00:00

Last year started using AI tools more seriously. Thought it'd be another productivity fad that would fade away. It didn't.

Early 2025</h2>
Beginning of 2025 mostly ignored the autocomplete stuff. Partly didn't want another subscription, partly stubborn, and partly didn't want to train myself to just accept whatever suggestions popped up. Tried some local alternatives but they were either way too noisy or just wrong most of the time.
Eventually started using Copilot at work. It was decent for mechanical stuff - renaming fields across files, that kind of thing. Still had to review everything but cut down on the grind.
Then came MCP and started using Copilot more at work, learning about agents, MCPs, LLMs. Built a few toy ones. Interesting for a bit. One boring thing was learning how much prompts matter and how the world now depends on markdown files trying to guide AI agents to do things right. Love markdown so at least we don't have a new language to learn for this.

Agents</h2>
Mid-year got access to Claude Code and that changed things. With Copilot was mostly in control, asking for help with side tasks; with an agent this changed. Could ask for more and type less but at the end still have to review code and sometimes it's really bad code.
After so many years feel like my way of programming changed. Before spent time thinking and structuring how to code, trying to avoid clutter and keep the principles learned - KISS, SOLID. Tried many approaches: full TDD with red-green, starting with diagrams or class structures first. Nowadays have a mix that works but with an agent had to rethink this process.
Whenever want to use an agent, usually for boring tasks, need to spend time writing the first prompt. This is one of the main reasons AI sometimes makes programming boring - instead of writing structured code, writing prose hoping the AI gets it. No compiler for prompts, no type checker, just vibes. So many ways a prompt can go wrong.
Example - asked it to add tests and refactor something. It added tests but the wrong kind, just mocks testing that mocks got called, not actual behavior. The refactor added helper functions that looked clean but didn't simplify anything. Ended up deleting most of it and rewriting the tests myself.
This happened multiple times. Agents produce plausible code but not necessarily maintainable code.
Also there's setup fatigue. End up with style guidelines, project docs, how to run tests, commit format, all in markdown for the agent. Like having project notes but weird writing documents to tell a machine how to write code. Then preferences change and now maintaining those docs too. This will always be a work in progress because our way of coding is mutable and we're always improving.
After finishing setup was using agents all the time - small modifications, tests, refactoring, learning. This part is good. The barrier to try new languages, frameworks, OS concepts dropped a lot. Can experiment with stuff that would've sat on the TODO list forever.

October Burnout</h2>
Around October everything was AI. Work, commuting, feeds, blogs, conversations. Only escape was my wife - she works in arts and is not the most tech person, and that was honestly a breath of fresh air. Was helping with some AI discovery stuff and got overwhelmed.
Just stopped at some point. No model news, no takes, no comparisons. Focused on other things.
Got into self-hosting during that break and really liked it. Used AI to learn Proxmox faster (already knew Linux but Proxmox has quirks), built some small tools - tracking media, importing recipes to Mealie, random glue scripts. Nothing fancy but satisfying.
During the break saw many developers going from ignoring AI to being excited and starting to do cool stuff with it. And as new models launched at the end of the year they were even better.
This is where AI works well - lowers barrier to experimentation. Can try things that would've been postponed indefinitely. But try to treat it like a study partner, not copy-paste machine. If don't understand what it generated, slow down.

What Works Now</h2>
Past the hype. Here's what stuck:
Code reviews - catches mechanical stuff like "this path returns without releasing a resource". Not deep insights but helpful on tired days. Don't want AI writing and AI reviewing but as extra eyes for boring checks? Works.
Learning - when in unfamiliar territory helps get unstuck. Gives starting points and vocabulary to ask better questions.
Test scaffolding - if know what to test, generates decent boilerplate. If let it decide what matters, get useless tests. So write the test cases, it handles setup code.
Scripts - quick one-offs, migrations, boring automation. Usually verbose but beats starting from scratch.

What Bothers Me</h2>
Tech debt - great at "make it work", bad at "make it maintainable". Ship code that looks plausible, then six months later debugging abstractions that exist because they sounded good in prose. Can produce code faster means producing debt faster too.
Security - running way more generated code now. More dependencies, more scripts. Containers help but not enough. Simon Willison writes about this</a> - need better local sandboxing.
Garbage code - barrier to shipping basically zero. Idea to deployed code very fast. Sounds great until realize it means garbage everywhere. Not code that breaks immediately - code that barely works, gets merged, then nobody understands why it exists later. More code being written faster doesn't mean better software, sometimes just means more mess to clean up.
Niche areas - really specific domains in math, science, biology are still hard. Think this will improve but needs more data and experts guiding the process. Not an expert here though.
Real time info - AI getting better at searching internet but internet has a lot of bad information. Models present questionable info with confident tone. Now double-check more, especially security stuff or anything that looks too clean.
The prompt problem - when an agent fails it's hard to debug. Don't get a stack trace, get "I interpreted your sentence differently". Sometimes fastest fix is stop prompting and start coding.
The data thing - why moving off GitHub. Microsoft trained Copilot on public repos (mine included, no permission) and now sells it back. Use AI tools but the "take everyone's code, ask later" approach is annoying.
Jobs</h2>
Don't know where this goes. Don't want to be "AI supervisor" reviewing diffs all day. Like programming because like solving problems and building systems, not reading generated code.
Feel like jobs will change but don't know to where. Hope it's a place where can still code and not only write prompts and review diffs as most directors and VPs are leaning towards.
Now</h2>
Still using AI, trying to be intentional. Reviews, learning, test boilerplate, scripts, everyday tasks - not just basics anymore, using it for more of the day-to-day coding work.
The shift isn't "AI writes my code now". It's using it for more everyday stuff and spending more time reviewing. Balance went from writing most code myself to guiding and reviewing generated code, deciding what to keep, fix, or rewrite. And as models get better at general tasks, find myself relying on it more. Each new release handles more complex stuff and makes fewer obvious mistakes, so the trust increases even if the concerns don't go away.

This post ended up long and there's nothing really new here - just random thoughts about the journey and things read and learned last year. The AI trend will continue this year and the burden to keep updated with the market and environment is real.
For now using AI for boring stuff - test boilerplate, documentation, scripts - and increasingly for everyday coding tasks. The balance shifted. Not writing all the core logic myself anymore, more reviewing what it generates and deciding what's worth keeping. And as models keep getting better at handling general tasks, find myself using it more. Each release handles more complex stuff with fewer mistakes, so reliance increases even if concerns remain.
When writing prompts feels like a chore instead of programming, that's the signal to close the chat and write code.

Why I Like Garbage Collection

2025-10-11T00:00:00+00:00

Coming from a Java background, I only started experimenting with Rust for personal projects last year, and now I'm exploring Zig. To understand what garbage collection really offers, I implemented the same problem in all three languages: Java (with GC), Rust (ownership), and Zig (manual memory management). The experience taught me why GC has survived since the 1960s, and why it still matters.
What GC Actually Solves</h2>
The trivial correctness of GC is worth the hassles, in most cases. You don't have to worry about allocators or deallocators; things just work, without restriction. And it's usually fast enough if you pay attention to your object usage patterns.
Here's the same pattern in each language - creating a list of objects:
// Java: just allocate and use List<String> items = new ArrayList<>(); items.add("hello"); // memory cleaned up automatically when unreachable </code></pre>// Rust: ownership tracks cleanup let mut items = Vec::new(); items.push("hello".to_string()); // dropped automatically when out of scope </code></pre> // Zig: explicit allocation and deallocation var list = std.ArrayList([]const u8){}; defer list.deinit(allocator); // must remember to clean up try list.append(allocator, "hello"); // zig 0.15.1 you need to use the same allocator for all allocations and to deallocate </code></pre> It's a heavyweight solution, in terms of engineering, to a heavyweight problem. But GC isn't magic - you can still get OutOfMemoryErrors if you keep appending data without releasing references. And in Java, you still need to pay attention to GC configuration, even though modern GCs are much more powerful than they used to be and for each new version they continue to improve. Where GC Excels: Cycles</h2> This is where GC really shines, and where alternatives struggle most. When you have complicated, potentially cyclic referencing where links are picked up and dropped all the time - exactly where you're most likely to have memory leaks with manual or scope-based deallocation. In Zig, I had to explicitly track allocations and think carefully about when to call allocator.free()</code>. With complex data structures, it's easy to leak memory if you lose track of a pointer: // Zig: manual cycle handling const Node = struct { data: i32, next: ?*Node, }; const node = try allocator.create(Node); node.* = .{ .data = 42, .next = null }; // ... later, you must remember: allocator.destroy(node); // If nodes reference each other, you need to carefully manage cleanup order </code></pre> Rust's ownership system famously struggles with cycles too. Anyone who's tried to write a linked list in Rust knows about "Learning Rust With Entirely Too Many Linked Lists" - it's practically a rite of passage. You need Rc<RefCell<>></code> to create cycles: // Rust: cycles require reference counting use std::rc::Rc; use std::cell::RefCell; struct Node { data: i32, next: Option<Rc<RefCell<Node>>>, } let node = Rc::new(RefCell::new(Node { data: 42, next: None })); // complex ownership, potential cycles still leak without careful weak references </code></pre> // Java: cycles handled automatically class Node { int data; Node next; } Node node = new Node(); node.data = 42; // even if nodes form cycles, GC handles cleanup </code></pre> With reference counting approaches like Swift's ARC or Rust's Rc</code>, you have to think it through super-carefully to avoid leaks. With GC? You hardly have to think at all. The GC tracks reachability from root objects, not individual references, so cycles get cleaned up automatically when the whole structure becomes unreachable. What GC Doesn't Solve</h2> I learned this the hard way. We had a Java class that processed many large files, and somewhere in the processing pipeline, we weren't closing some of the files properly. The GC handled the memory just fine, but we were leaking file handles. The problem only showed up during peak periods when we processed hundreds of files - suddenly, we couldn't open any more files. We had to review the code and restructure everything to use try-with-resources, making sure every file was explicitly closed. The GC gave us memory safety, but it didn't save us from resource leaks. This is where Rust's RAII shines. When a File</code> goes out of scope, it's automatically closed: // Rust: file closed automatically { let file = File::open("data.txt")?; // use file... } // file closed here automatically </code></pre> // Java: must explicitly close try (var file = new FileReader("data.txt")) { // use file... } // file closed by try-with-resources </code></pre> // Zig: defer schedules cleanup const file = try std.fs.cwd().openFile("data.txt", .{}); defer file.close(); // you write the cleanup </code></pre> Zig takes a different approach - it gives you defer</code> to schedule cleanup code, but you're still responsible for thinking about it. GC languages require explicit resource management with try-with-resources or similar patterns. You get mental freedom from memory management, but you still need discipline for everything else. Coming from Java to Rust and then Zig, I found each step required more explicit thinking about resources. In Java, I barely thought about memory. In Rust, the compiler forces you to think about ownership. In Zig, you're on your own - the flexibility is liberating, but the responsibility is real. There's a psychological shift that happens along this journey. With Java, I trusted the GC to handle everything. Moving to Rust and then Zig, I had to let go of that trust and take control. At first it felt like a burden. Now? I kind of enjoy the power. There's something satisfying about knowing exactly what your program is doing with memory, about having that level of control. The overhead is real: more memory usage, runtime tracking costs, and read/write barriers on every pointer access. But GC completely eliminates an entire class of bugs. Why It Still Matters</h2> Garbage collection goes back to the 1960s with LISP. Interestingly, memory was too limited back then to use reference counting, which adds an extra counter to every object. Java was originally designed for severely memory-constrained environments like set-top boxes. We have millions of times more memory now, even on single board computers. Increasing RAM and CPU cores make GC overhead less problematic. Modern machines can absorb the memory overhead and background collection work more easily. The overhead that mattered then matters less now. The Takeaway</h2> GC isn't a mistake. It's the only solution that is at once fully comprehensive and trivially easy for memory management. You don't always want GC because sometimes control is important, but it's a very good idea for general use. The real limitation isn't that GC exists - it's that having solved the most ubiquitous resource problem, we sometimes forget we still need good ways to solve the other resource problems. References</h2> McCarthy, John (1960). "Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I." Communications of the ACM, 3(4), 184-195. https://doi.org/10.1145/367177.367199</a> </li> Klabnik, Steve and Nichols, Carol (2023). The Rust Programming Language, 2nd Edition. No Starch Press. https://doc.rust-lang.org/book/</a> </li> Patterson, Andrew (2022). "Zig: A programming language designed for robustness, optimality, and clarity." https://ziglang.org/documentation/</a> </li> Jones, Richard, Hosking, Antony, and Moss, Eliot (2011). The Garbage Collection Handbook: The Art of Automatic Memory Management. Chapman & Hall/CRC. ISBN: 978-1420082791 </li> </ol>
Hello World 2025-09-30T00:00:00+00:00 Why I'm Writing</h2> This is my first blog post ever. After over a decade of developing software, I've never had the courage to write about it. I finally decided to take the leap. Three things drove me to start this blog: Solidify my understanding: Writing forces me to truly grasp what I'm learning</li> Give back to the community: I want to contribute to the same community that taught me so much</li> Push my boundaries: Writing sounds terrifying, but that's exactly why I need to do it</li> </ul> Topics</h2> I'll write about: Programming languages exploration (currently Zig, but always trying new ones)</li> Java (work stuff)</li> Problems I'm solving</li> Tools that work</li> Things that don't work</li> </ul> What's Next</h2> Keep learning, keep sharing, keep growing. Thanks for reading - I hope you'll join this journey of continuous discovery and improvement. Happy coding! Want to stay updated? Subscribe to the RSS feed</a> or Atom feed</a> to never miss a post.

caiocdcs | blog

A Year Using AI to Code

Why I Like Garbage Collection

Hello World

Why I'm Writing</h2> This is my first blog post ever. After over a decade of developing software, I've never had the courage to write about it. I finally decided to take the leap.</p> Three things drove me to start this blog:</p>

Topics</h2> I'll write about:</p>

What's Next</h2> Keep learning, keep sharing, keep growing.</p> Thanks for reading - I hope you'll join this journey of continuous discovery and improvement. Happy coding!</p> Want to stay updated? Subscribe to the RSS feed</a> or Atom feed</a> to never miss a post.</em></p>

What's Next</h2>
Keep learning, keep sharing, keep growing.</p>
Thanks for reading - I hope you'll join this journey of continuous discovery and improvement. Happy coding!</p>

Want to stay updated? Subscribe to the RSS feed</a> or Atom feed</a> to never miss a post.</em></p>