Roni Kobrosly Ph.D.'s Website

In late 2025 at work, I wrote (well, Claude Code and I co-wrote) 30,000+ lines of python code for a microservice that was parsing PDFs, interacting with some APIs, chunking text, and writing the results to a vector database, along with the full suite of tests, helper scripts, etc. This app did no AI/ML in and of itself, it was pure, straight up ETL and software engineering. Now, ostensibly I am a statistics/AI/ML/data person, I actually really enjoy pure software engineering. SWE feels very practical and, I suppose, "pure" in a way; there isn't a need to pitch an algorithm to another team, which can be tiring. I'm just building out a thing with engineering principles. That said, this wasn't fun for several reasons:

• Without getting into the details, there was a ton of complex state management (does the document needs to be chunked, was the document was already chunked, how well was it chunked, is there a new version of this document available, how does it compare with the prior versions, etc etc... ), which meant there were a bunch of subtle failure modes.
• My poor python app was choking on the input artifacts; this was a I/O bound process because it involved processing many 1000+ page PDF documents...
• There are 10+ python PDF parsers out there on PyPI and they all suck. Okay, admittedly, PDF parser is hard since PDFs are basically collections of coordinates and glyph shapes instead of highly structured docs, but still, I found various advantages with each parser but none that checked most of the boxes in a satisfying way.
• The app needed to keep track of tons of mutable objects and if-else arms and operations that would slightly tweak values, and I struggled with approaches for rigorously making sure things had values they needed to have while writing with a good amount of encapsulation and abstraction.

I'll stop there 🙃

It became clear I could use a framework that was stricter about states and if-else logic, faster, would do a better job of watching my back as I built out a relatively-large codebase. I don't know how to code it, but I really liked everything I heard about Rust and the community around it. There is no Benevolent dictator for life personality behind it, it's consistently the most admired programming languages, it is hella fast (faster than python by orders of magnitude, and faster than other up-and-coming languages like Go too), how the rust compiler eliminates entire classes of bugs and security issues that can occur in software building, and I've repeatedly heard that the rust team actively tried to incorporate software engineering lessons learned from all the prior decades of software building.

Also there was something appealing about becoming fluent in python and rust: I could use python for exploration, data analysis, simple and fast scripting, and stats/AI/ML, and then use rust as my powerhouse for heavy ETL jobs and straight ahead software engineering. The Yin and the Yang.

...but this got me thinking: is it worth it to learn a new programming language these days?? I've been hearing from the top AI salesperson and my family members that aren't in the tech field that writing code is dead! Also, I read that "English is the New Programming Language to Learn" from some guy I don't know!

If it isn't already obvious from the blog post summary and my tone, I ultimately think it is worth it for these reasons:

1) I need to be able to confidently review agent-generated code 2) Understanding Rust will help me request the most-appropriate, idiomatic patterns and architecture 3) Everything I saw in my initial research suggested that Rust requires totally different approach to thinking about software than python. If I want to learn these paradigm-level lessons, I need to put in the reps and get comfortable with the language.

So, I read the official Rust book (AKA “the book”), did the Rustlings exercises, and started working on a rinky dinky CLI tool that would help with a problem I’ve been dealing with recently. I have to say, in an odd way, this old-fashioned process felt a bit like an act of rebellion in this agent age. It had been a while since I was stumped when writing particular single line of code and searched through documentation to figure out the syntax. Heh, in a particular moment like this, I imagined myself churning butter. 

While this was truly “Learning Rust the Hard Way” (lol, I learned python "the hard way"), I did try to incorporate AI (I’m no luddite). It could be a powerful way to get assistance as long as it didn’t give me a shortcut through the learning process. As you probably know, a single prompt to in Pi/OpenCode/Claude Code will happily generate hundreds of lines for you (if not more). I need to dramatically restrain my agent. Basically, I needed a AGENTS.md file like the following.

By the way, my rinky dinky “hello world”-like Rust app was a CLI tool that quickly generates a secure password for you. I’ve been signing up for a lot of new services lately and wanted something quick and local to spit out some strong key. Anyways, the markdown file:

I needed a AGENTS.md file that would help me learn rust.

# AGENTS.md

## Project overview

QuickPass is a Rust CLI tool for generating secure passwords. It uses `clap` for argument parsing.

## Learning Approach

I want to use AI as a learning tool to help me master Rust. Please follow these guidelines:

1. **DO NOT write code for me** — I want to write all the code myself. Never provide a full code block as a solution.
2. **DO provide explanations** — Help me understand Rust concepts, patterns, and idioms. Explain the _why_, not just the _what_.
3. **DO suggest approaches** — Give me high-level guidance on how to implement features or solve problems. Describe the strategy, not the implementation.
4. **DO review my code** — Provide constructive feedback on code I've written. Point out where it could be more idiomatic, safer, or clearer.
5. **DO answer questions** — Explain Rust concepts when I ask about them. Dive deep into ownership, borrowing, lifetimes, traits, error handling, etc.
6. **DO provide small examples** — When relevant, show compact, self-contained examples to illustrate a concept. These should be abstractions, not solutions to my current task.
7. **DO teach me to read Rust compiler errors** — Guide me through understanding error messages rather than just telling me the fix.
8. **DO suggest refactoring opportunities** — After I implement something, point out how it could be restructured to be more Rust-idiomatic (e.g., using iterators instead of loops, leveraging `Option`/`Result` combinators).

## Session Guidelines

- **Keep sessions short and focused** — If we are starting on a new feature or task, suggest starting a fresh session. This prevents context bloat and hallucinations.
- **Break down problems together** — Help me decompose larger features into small, manageable steps I can implement one at a time.
- **Progressive complexity** — Encourage me to start with the simplest working version, then iterate. I don't want to over-engineer upfront.

## Build & test commands

- Build: `cargo build`
- Release build: `cargo build --release`
- Run tests: `cargo test`
- Lint: `cargo clippy`
- Format: `cargo fmt`
- Generate docs: `cargo doc --open`
- Check without building: `cargo check`

## Rust learning principles

- **Ownership and borrowing** — When I hit a borrow-checker error, explain what's happening and why Rust requires it, not just how to fix it.
- **Error handling** — Guide me toward using `Result`, `Option`, `?` operator, and the `thiserror` / `anyhow` crates appropriately.
- **Traits and generics** — Encourage me to use traits for abstraction. When a pattern repeats, suggest extracting a trait.
- **Pattern matching** — Show me how to leverage `match`, `if let`, `while let`, and destructuring.
- **Iterators and closures** — Guide me away from imperative loops toward iterator combinators (`map`, `filter`, `fold`, `collect`, etc.).
- **Module system** — Teach me about `mod`, `use`, `pub`, and how to structure a Rust project cleanly.
- **Testing culture** — Encourage me to write tests alongside each feature. Show me how to use `#[test]`, `assert!`, `assert_eq!`, and integration tests in `tests/`.

## Code conventions

- Rust edition 2024
- Follow standard Rust naming conventions (snake_case for functions/variables, CamelCase for types)
- Keep functions small and focused
- Prefer `&str` over `&String` for function parameters
- Prefer returning `Result` over panicking
- Use `#[derive]` for standard traits when possible

## Post-change checks

After every code change (edit, write), you MUST run both of these commands and fix any issues they report:

```sh
cargo fmt
cargo clippy

If cargo clippy reports any warnings or errors, fix them immediately. Treat all clippy warnings as errors that must be resolved.

```

So, did it work? Mostly yes, with some caveats.

Here's my little Rust CLI tool.

The AGENTS.md discipline held up surprisingly well in practice. It forced me to stay in the driver’s seat. When I hit a borrow checker error (and Jesus Herbert Christ did I hit borrow checker errors), my instinct was to paste the error and ask for a fix. Instead, I’d ask something like “can you explain what this error is telling me about ownership here? And can you give me some new examples to help drive the point home?” The difference in what I retained was night and day. No lie, some of my most productive sessions (in terms of expanding my brain) were the ones where I came away having written maybe five lines of working code after thirty minutes of back-and-forth about why those five lines needed to look the way they did.

That said, the guardrails took active effort to maintain. There’s a gravitational pull toward just asking for the answer, especially when you’re tired and the compiler is yelling at you for the fourth time about a lifetime annotation. I slipped occasionally. I’d notice I’d been handed a full code block and had to consciously stop, delete it without reading it too carefully, and rephrase my question. 

On the Rust side: ownership and borrowing are as brain-bending as advertised, and I say that as someone who thinks carefully about memory and state management professionally. The moment things started clicking was when I stopped fighting the borrow checker and started treating its errors as a conversation. The compiler is surfacing a real ambiguity in your reasoning about who owns what and when. Once I internalized that framing, the errors became genuinely informative rather than just frustrating. Lifetimes, on the other hand, remain in the “respect but unease” category for me. I’ll get there.

QuickPass itself ain't exactly a magnum opus. it’s a few hundred lines, generates passwords with configurable length and character set flags, and does it correctly and fast. Not exactly a portfolio piece. But it served its purpose: it’s a real thing that compiles, runs, and solves a problem I actually have, and I wrote essentially every line of it myself. There’s something satisfying about that.

Which brings me back to the original question: is it worth learning a new programming language in the agent age?

I think the framing of “coding is dead” fundamentally misunderstands what coding is. Computers understand binary and would be quite happy just sticking with that. Never forget that coding is a layer specifically for humans. The part that’s being automated (the rote translation of a clear spec into syntactically correct lines ) was never really the interesting part. What remains, and what agents currently cannot do reliably, is thinking carefully about what you’re building: the architecture decisions, the failure mode analysis, knowing when a pattern is subtly wrong even if it compiles, choosing patterns that account for the organization you belong to, etc.

Beyond that, I’d argue the agent age makes deep language knowledge more valuable, not less. When you’re reviewing agent-generated Rust, you need to know whether the code is idiomatic or whether the agent took the easy path in a way that will hurt you later. Agents will confidently write un-Rusty Rust — imperative loops where iterators belong, unnecessary clones to paper over ownership issues, error handling that’s technically functional but architecturally lazy. Catching that requires having internalized the language well enough that bad code gives you a mild aesthetic offense before you’ve even articulated why.

So yeah, I’m okay with this exercise in churning butter. There’s a kind of understanding you only get by going slowly. Working slowly and gaining technical "muscle" is worth defending.