↓ Skip to main content
  1. Posts/

The Joy of Programming with AI

·2 mins
definitepotato
Author
definitepotato
Code slinger, golang, ziglang, grokking life, tabletop games enthusiast, obsession with keebs and numbers.

If you’re new to the dev industry, welcome, you’re probably excited about AI. If you’ve been around as long as I have, the joy of solving problems is dying.

I think the rush to say software development jobs are dead is premature. It’s not dead, at least not yet. You still need someone with knowledge of how things work to guide the robots and validate the outputs. If you’re developing a product using AI and code without knowledge of code, there is an eventuality, a tipping point, when both you and the robot lack what is necessary to drive it beyond some critical mass. That’s when years of losses and hard won engineering experience come into play. Which brings me to my first gripe.

What used to be the dopamine rush of going head down solving a difficult problem, failing, trying, learning, and ultimately succeeding and coming out the other side with scars and knowledge, is now distilled into prompting AI and managing agents. I thought maybe coding with AI would feel more like buddy programming, instead the models have become so good at coding I spend most of my time prompting and reviewing code. The experience curve between a junior and a senior engineer is being flattened and software engineering feels a lot more like project management.

The real problem for me is I can’t ignore AI because not using the robots puts me at a disadvantage. I lose efficiencies and speed compared to my peers. Refactoring projects that would have taken me weeks is now a matter of a prompt or two. There’s no sense of reward or challenge. The dopamine rush is gone. Now, I get more joy from folding my laundry and seeing my t-shirts neatly stacked in my closet. I feel more accomplished patching drywall and watching paint dry.

The driving factor might be the cost of robot tokens vs human tokens because sometimes having access to infinite capital doesn’t solve a problem. Today, you still need people with knowledge (albeit fewer) and if you want to deliver a quality product you need a good team. It’s not game over yet, but it is plausible that day may arrive.

Related

Built-ins and the REPL

13 mins
Source code --> Lexer --> tokens --> Parser --> AST --> Evaluator --> value ^^^^^^^^^^^ ^^^^^ the REPL feeds this end and prints this end Two things are missing. Monkey has no way to talk to the outside world, there’s no len, no puts, nothing that can look inside a string or print to the screen. And you have no way to run Monkey except by writing a test. This chapter fixes both. We add the six built-in functions in builtins.zig, wire them into the evaluator, and write the REPL in main.zig.

Evaluation

38 mins
Source code --> Lexer --> tokens --> Parser --> AST --> Evaluator --> value ^^^^^^^^^ you are here In chapter 1 we turned our source into tokens. In chapter 2 we turned our tokens into a tree (AST). Now we’re going to walk the AST and produce values with an evaluator. Let’s return to our running example of 5 + 3 * 4. When the evaluator sees an InfixExpression node with the operator +, a left child Int(5) and a right child that is itself an Infix(*) node, it evaluates both children first. The left child is trivially 5. The right child is another infix expression, so the evaluator recurses into it, evaluates 3 and 4, multiplies them to get 12, and comes back up. Only then does it add 5 and 12. The shape of the tree tells the evaluator what to do and in what order, which is why we spent so long getting that shape right in chapter 2.