# Programming in age of AI

**URL:** <https://discourse.julialang.org/t/programming-in-age-of-ai/135410>\
**Category:** Offtopic\
**Tags:** ai\
**Created:** [February 2, 2026, 4:44pm UTC](https://discourse.julialang.org/t/programming-in-age-of-ai/135410 "2026-02-02T16:44:26Z")\
**Posts on this page:** 17\
**Page:** 1

<div class="post-metadata">

**Author:** ![raman\_kumar](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/raman_kumar/32/26782_2.png) [@raman\_kumar](https://discourse.julialang.org/u/raman_kumar)\
**Post date:** [February 2, 2026, 4:44pm UTC](https://discourse.julialang.org/t/programming-in-age-of-ai/135410/1 "2026-02-02T16:44:26Z")

</div>

I often hear from people that AI will make coding skills useless and AI will make programmers jobless. I personally like programming but fears about future. 🥶

- Should we learn programming in the age of AI when AI is becoming stronger?
- How should we adapt or change our perception and goals about learning programming in AI era?
- Should we keep alternative carrier options also?
- Will experienced software developer start focusing on LLVM/Assembly language? Will AI be used in low level instruction also?

---

<div class="post-metadata">

**Author:** ![technocrat](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/technocrat/32/220947_2.png) [@technocrat](https://discourse.julialang.org/u/technocrat)\
**Post date:** [February 2, 2026, 5:06pm UTC](https://discourse.julialang.org/t/programming-in-age-of-ai/135410/2 "2026-02-02T17:06:16Z")

</div>

Always keep career options open. Because you never know. Think of AI as a force multiplier. That means you must have some force to apply, just as a project manager for a programming team has to understand the nature of the work to be able to guide it.

---

<div class="post-metadata">

**Author:** ![ufechner7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ufechner7/32/51363_2.png) [@ufechner7](https://discourse.julialang.org/u/ufechner7)\
**Post date:** [February 2, 2026, 7:11pm UTC](https://discourse.julialang.org/t/programming-in-age-of-ai/135410/3 "2026-02-02T19:11:45Z")

</div>

I am doing scientific programming, and for this, a good background in some field is required. I am good at physics, for example. In science, software is a tool, AI is a force amplifier, and the field in which you do research (e.g., physics) is the foundation.

This year, I spent some time to figure out what AI is already useful for, and what it cannot do effectively (yet). This is an important skill nowadays, to give only tasks to the AI where there is a good chance that AI can solve it successfully. It works reasonable well for writing tests and for writing code to create plots, for example. But you still need to be able to proof-read and understand the AI code.

---

<div class="post-metadata">

**Author:** ![DoktorMike](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/doktormike/32/2736_2.png) [@DoktorMike](https://discourse.julialang.org/u/DoktorMike)\
**Post date:** [February 2, 2026, 7:36pm UTC](https://discourse.julialang.org/t/programming-in-age-of-ai/135410/4 "2026-02-02T19:36:51Z")

</div>

My take on this is that you should definitely learn a few programming languages to understand code and compilers in general. I would go so far as to say that fundamentals have never mattered more than they do today. Not because you will actually be doing much programming yourself in the future (I believe a lot of the actual coding will be done by assistants) but to know how to design, think about and criticize code.

Learn:

- discrete math, algorithms, data structures and some calculus.
- some basic electrical engineering
- a few CPU and GPU architectures
- operating systems and compilers (one or two is enough)
- C, Julia/Python, and Bash

This I believe we all have to know in addition to our own field.

I am no fan of vibe coding something you couldn’t have done yourself given enough time.

---

<div class="post-metadata">

**Author:** ![yvikhlya](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yvikhlya/32/3753_2.png) [@yvikhlya](https://discourse.julialang.org/u/yvikhlya)\
**Post date:** [February 2, 2026, 9:04pm UTC](https://discourse.julialang.org/t/programming-in-age-of-ai/135410/5 "2026-02-02T21:04:59Z")

</div>

AI can eliminate the need to type the code manually (almost), but it does not eliminate the need to know a tech stack which you use. AI amplifies your abilities and extends the range of your expertise. It does not replace human specialists yet.

---

<div class="post-metadata">

**Author:** ![liuyxpp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/liuyxpp/32/9870_2.png) [@liuyxpp](https://discourse.julialang.org/u/liuyxpp)\
**Post date:** [February 3, 2026, 5:06am UTC](https://discourse.julialang.org/t/programming-in-age-of-ai/135410/6 "2026-02-03T05:06:46Z")

</div>

> [@DoktorMike](#):
>
> you couldn’t have done yourself given enough time

I strongly disagree! “given enough time” is ambiguous. With AI assisted, it can help developer overcome the time-constraint barrier much easier. Take myself as an example, even I know I can developed a numerical package like AcceleratedDCTs.jl in a generous time frame such as a month or so, I will not do it in the past. The possiblity of failure in devlivering the actual pacakge in time is very high. Now, I can first communicate with AI and together draft a realistic implementation plan and foresee whether I can finish the project. Actually, it only takes a weekend to develop a well-shaped AcceleratedDCTs.jl with the help of AI.

---

<div class="post-metadata">

**Author:** ![DoktorMike](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/doktormike/32/2736_2.png) [@DoktorMike](https://discourse.julialang.org/u/DoktorMike)\
**Post date:** [February 3, 2026, 8:14am UTC](https://discourse.julialang.org/t/programming-in-age-of-ai/135410/7 "2026-02-03T08:14:31Z")

</div>

It sounds like we’re in agreement. If I understand you correctly you’re saying that you indeed could have done it in which case I think it’s fine.

To further explain my reasoning: In my opinion, if you couldn’t have done it yourself (given all the time in the world if you’d like) you don’t understand what was done and that is a dangerous thing. Would you be comfortable developing control code for a nuclear power-plant this way?

Of course, most of us do not develop critical code (of that magnitude), but I still think that the thought experiment put on it’s edge has value and should be considered.

We as scientists, software developers etc have a responsibility towards the next generation. If we produce bad code today, someone will suffer the consequences in the future.

In no way am I against vibe-coding or ai assisted coding. I just think we should be vigilant about the way we use it.

---

<div class="post-metadata">

**Author:** ![aryavorskiy](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/aryavorskiy/32/43466_2.png) [@aryavorskiy](https://discourse.julialang.org/u/aryavorskiy)\
**Post date:** [February 3, 2026, 11:55am UTC](https://discourse.julialang.org/t/programming-in-age-of-ai/135410/8 "2026-02-03T11:55:45Z")

</div>

> [@raman\_kumar](#):
>
> AI will make coding skills useless

My personal take on it: it won’t. AI is pretty good at writing single-use scripts, providing auto-complete or generating documentation drafts, but bad at everything else. AI cannot develop a maintainable package on its own – at least for now, and I do not believe it will anytime soon.

When I use agentic AI in scientific computing, I always end up patching the code it outputs. That’s because the AI takes the dumbest approach possible and ignores the idiomatic way to do things (always writes nested loops, ignores memory allocations, etc etc etc). This of course may (and will) change in the future, but the AI will still require supervision. And to do it properly, you will still need to learn how to code.

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [February 3, 2026, 2:10pm UTC](https://discourse.julialang.org/t/programming-in-age-of-ai/135410/9 "2026-02-03T14:10:39Z")

</div>

> [@aryavorskiy](#):
>
> > [@raman\_kumar](#):
> >
> > AI will make coding skills useless
> 
> My personal take on it: it won’t. AI is pretty good at writing single-use scripts, providing auto-complete or generating documentation drafts, but bad at everything else.

That’s just not true, not only “single-use scripts”. AI seems to be a force-multiplier for great programmers, as with Rue language made. Maybe not or not as much for other programmers, can accumulate a lot of technical dept, at least in lesser hands.

AI also translated the original Photoshop version 1.0 (it’s been made open source), from Classic macOS, non-portable, written in Pascal and Motorola 68000 assembly to C# (I can’t find the link on it back right now; I would be skeptical, maybe the AI just hallucinated Photoshop without looking at the original code?).

See my answer here, and that thread I started too:

> [@Vibe coding vs agentic coding (Ralph Wiggum loop)](https://discourse.julialang.org/t/vibe-coding-vs-agentic-coding-ralph-wiggum-loop/135389/9):
>
> It was actually (in part) to get to you and others dismissive of AI. It’s been very eye-opening for me the last few days to see what AI is capable of for coding

> Rue is also an experiment in human-AI collaboration. The language is designed by [Steve Klabnik](https://steveklabnik.com) and implemented primarily by Claude, an AI assistant.

> [@Vibe coding vs agentic coding (Ralph Wiggum loop)](https://discourse.julialang.org/t/vibe-coding-vs-agentic-coding-ralph-wiggum-loop/135389/1):
>
> **Christmas Day alone saw 102 commits. (Steve apparently had some time off.)**

I see now he even had some commits then, in his name only, just fewer.

> [@aryavorskiy](#):
>
> When I use agentic AI in scientific computing, I always end up patching the code it outputs.

I don’t want to dismiss your experience, maybe AI is still better at some programming something other than scientific (or you’re doing it wrong, not spec driven in the right way), and only good for some areas, like batch-oriented compilers, maybe ideal? Kimi 2.5 likely changes with vision capabilities added. It’s amazing what AI has been doing so far basically blind, I would compare more to blind programmers (that exist and are amazing!). Kimi Code is intriguing, and Kilo Code (a fork of a fork), I may start out myself with Claude Code.

I highly recommend reading the full blog post he wrote, and the subsequent two blog post on the language that the Claude AI wrote:

> **[The Story of Rue So Far | Blog | Rue](https://rue-lang.dev/blog/the-story-of-rue-so-far/)**
>
> A systems programming language with memory safety and high-level ergonomics

> But 2025 also brought one more change in my life: I went from thinking that AI and LLMs were stupid and bad, to being at least useful. For the purposes of this post, I don’t really want to get into the details, because they’re not relevant, but I’m sure I’ll write more about that elsewhere.  
> ..  
> What if Claude could write a compiler?
> 
> ## Second time’s the charm
> 
> However, last week, I had some spare time… and I decided to start over. I have a lot more skill with Claude than I did half a year ago.  
> ..  
> Tonight, I’d just like to bask in the fact that I got a baby language from zero to “core basics of a language + spec with two different codegen backends” done in roughly a week." That’s wild to me!

It’s wild to me too.

See the architecture at [rue/CLAUDE.md at trunk · rue-language/rue · GitHub](https://github.com/rue-language/rue/blob/trunk/CLAUDE.md#architecture) and the 17 crates listed there, “including `rue-codegen` x86-64 machine code generation”, highly non-trivial.

This language is more comparable to Rust (and Julia, and LLM, without using LLM, reimplementing similar) than e.g. less ambitious Python.

“We” implies this is AI generated, but I show it anyway, at least made in some sense by Steve too (or he reviewed it/singed on) [rue/docs/designs/0026-module-system.md at 70a0015808dc34a27879cb4edf6ebb2fabc22a29 · rue-language/rue · GitHub](https://github.com/rue-language/rue/blob/70a0015808dc34a27879cb4edf6ebb2fabc22a29/docs/designs/0026-module-system.md) :

> ### Current State
> 
> ADR-0023 introduced multi-file compilation with a flat global namespace—all functions, structs, and enums are globally visible across files. This was explicitly a stepping stone:  
> ..
> 
> ### Research Summary
> 
> We analyzed module systems from several languages:
> 
> | Language | Key Insight |
> | --- | --- |
> | **Zig** | Files are structs; lazy analysis skips unreferenced code; simple pub/private |
> | **Rust** | Explicit `mod`/`use` creates cognitive overhead; fine-grained visibility rarely needed |
> | **Hylo** | Intra-module visibility is automatic; `pub` only affects cross-module |
> | **Swift** | Multiple visibility levels add complexity without proportional benefit |
> | **Go** | Directory = package; implicit file discovery; simple and fast |
> 
> **Key takeaways:**
> 
> - Zig’s lazy analysis enables dramatically faster builds by only analyzing referenced code
> - Rust’s module system is the #2 complaint after borrow checking—too many concepts (`mod`, `use`, `pub use`, `extern crate`, visibility modifiers)
> - Simple pub/private (Zig) or pub/internal/private (Hylo) covers 99% of use cases  
> ..

The odd commit, like this one, is Steve only, and Claude is not credited:

> <https://github.com/rue-language/rue/commit/027f7542b7d936f79bafca5f6900787b192b4a39>
>
> Add rue-fuzz crate with comprehensive fuzzing support:
> \- Lexer, parser, and comp…iler fuzz targets
> \- Proptest generators for syntactically valid Rue programs
> \- Byte-level mutation strategies for stress testing
> \- Seed corpus generation from spec test files
> \- Daily CI workflow that creates GitHub issues on crashes
> 
> The proptest generators create valid expressions, statements,
> functions, structs, and complete programs, enabling much more
> effective testing than random byte mutation.
> 
> Closes: rue-lgw3

> <https://github.com/rue-language/rue/commit/1d4bd88bbe4e2e1d39bea6635e3d87d3d35befe7>
>
> Proposes adding @random\_u32() and @random\_u64() intrinsics for
> generating crypto…graphically-secure random numbers using platform
> syscalls. This enables interactive examples like guessing games
> without requiring complex PRNG state management or a standard library.
> 
> Design decisions:
> \- Intrinsic approach (vs built-in type) since generics aren't ready
> \- Syscall-based (getrandom on Linux, getentropy on macOS)  
> \- No seeding or determinism (educational use cases only)
> \- Both u32 and u64 variants for consistency
> 
> Epic: rue-krhv
> Subtasks: rue-ddko, rue-ub3z, rue-5852, rue-2h42
> 
> 🤖 Generated with \[Claude Code\](https://claude.com/claude-code)
> 
> Co-Authored-By: Claude Sonnet 4.5 \<noreply@anthropic.com\>

There’s at least minor commits from others:

> <https://github.com/rue-language/rue/commit/235d20b233bc8c78160d2bf034ef71cb93ac5cc2>

It doesn’t really matter if AI recreated version 1.0 or not, or if it could do full Photoshop…:

> **[Farewell Photoshop? Google’s new AI lets you edit images by asking](https://arstechnica.com/civis/threads/farewell-photoshop-google%E2%80%99s-new-ai-lets-you-edit-images-by-asking.1506263/)**
>
> New AI allows no-skill photo editing, including adding objects and removing watermarks.
> 
> See full article...

---

<div class="post-metadata">

**Author:** ![technocrat](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/technocrat/32/220947_2.png) [@technocrat](https://discourse.julialang.org/u/technocrat)\
**Post date:** [February 3, 2026, 7:14pm UTC](https://discourse.julialang.org/t/programming-in-age-of-ai/135410/10 "2026-02-03T19:14:17Z")

</div>

> Everyone knows that debugging is twice as hard as writing the program in the first place. _Brian Kernighan_

---

<div class="post-metadata">

**Author:** ![Mattriks](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mattriks/32/351_2.png) [@Mattriks](https://discourse.julialang.org/u/Mattriks)\
**Post date:** [February 4, 2026, 1:57am UTC](https://discourse.julialang.org/t/programming-in-age-of-ai/135410/11 "2026-02-04T01:57:27Z")

</div>

I suggest reading some of the AI material produced by the National Academies: [https://www.nationalacademies.org/topics/artificial-intelligence](https://www.nationalacademies.org/topics/artificial-intelligence) (under “Featured Publications”)

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [February 4, 2026, 7:41am UTC](https://discourse.julialang.org/t/programming-in-age-of-ai/135410/12 "2026-02-04T07:41:10Z")

</div>

> [@Palli](#):
>
> Rust’s module system is the #2 complaint after borrow checking

Complaining about borrow checking in Rust is like complaining that the chocolate ice cream you asked for contains ingredients derived from cocoa beans.

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [February 4, 2026, 8:46am UTC](https://discourse.julialang.org/t/programming-in-age-of-ai/135410/13 "2026-02-04T08:46:48Z")

</div>

Sure,

This looks like I was complaining about the borrow checker, but I wasn’t. I wasn’t even complaining about the module system, just quoting from a design doc. I believe the borrow checker is the main innovation in Rust (I at least didn’t know of it previously, if taken from another language), but note there are alternatives (also if I recall in Vale; Pony is also an interesting language):

At [rue/docs/designs/adr-015-mutable-value-semantics.md at b0867ccff77ee9957d6a0df3eedcfbba1194a7ff · rue-language/rue · GitHub](https://github.com/rue-language/rue/blob/b0867ccff77ee9957d6a0df3eedcfbba1194a7ff/docs/designs/adr-015-mutable-value-semantics.md#patterns-that-change)

> Rue aims to provide memory safety without Rust’s borrow checker complexity. The key insight from Val/Hylo is that **mutable value semantics** can provide similar safety guarantees with a simpler mental model.

Rue uses inout parameters (like Swift) instead, explained in that doc.

I think Rue might actually be a very good system programming language, better than Rust:

> **[Undefined Behavior and Runtime Panics - Rue Language Specification](https://rue-lang.dev/spec/appendices/b-undefined-behavior/)**
>
> A systems programming language with memory safety and high-level ergonomics

> Rue currently has no undefined behavior. All operations in Rue have defined semantics: they either complete successfully, fail to compile, or cause a runtime panic.

It might seems offtopic here in a thread I didn’t start in offtopic, to talk about programming languages, other than Julia, but I believe AI frees you from choosing any one language you’re familiar with, so it seems relevant.

> **[The borrowchecker is what I like the least about Rust](https://viralinstruction.com/posts/borrowchecker/)**

> **[Rue: Higher level than Rust, lower level than Go](https://news.ycombinator.com/item?id=46348262)**
>
> Related: \<a href="https://steveklabnik.com/writing/thirteen-years-of-rust-and-the-birth-of-rue/" rel="nofollow"\>https://steveklabnik.com/writing/thirteen-years-of-rust-and-...\</a\>

> **[Borrow checking, RC, GC, and the Eleven (!) Other Memory Safety Approaches](https://verdagon.dev/grimoire/grimoire)**

> **[What Vale Taught Me About Linear Types, Borrowing, and Memory Safety](https://verdagon.dev/blog/linear-types-borrowing)**

---

<div class="post-metadata">

**Author:** ![woclass](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/woclass/32/212699_2.png) [@woclass](https://discourse.julialang.org/u/woclass)\
**Post date:** [February 6, 2026, 2:55am UTC](https://discourse.julialang.org/t/programming-in-age-of-ai/135410/14 "2026-02-06T02:55:09Z")

</div>

> I tasked 16 agents with writing a Rust-based C compiler, from scratch, capable of compiling the Linux kernel. Over nearly 2,000 Claude Code sessions and $20,000 in API costs, the agent team produced a 100,000-line compiler that can build Linux 6.9 on x86, ARM, and RISC-V.
> 
> [Building a C compiler with a team of parallel Claudes \ Anthropic](https://www.anthropic.com/engineering/building-c-compiler)

This seems like a RIIR. Maybe we could call it an AD-RIIR (AI-driven Rewritten it in Rust).

Perhaps it’s time to rewrite the Julia compiler in Julia.

---

<div class="post-metadata">

**Author:** ![greatpet](https://avatars.discourse-cdn.com/v4/letter/g/e495f1/32.png) [@greatpet](https://discourse.julialang.org/u/greatpet)\
**Post date:** [February 6, 2026, 4:06pm UTC](https://discourse.julialang.org/t/programming-in-age-of-ai/135410/15 "2026-02-06T16:06:58Z")

</div>

Quote from the link:

> The generated code is not very efficient. Even with all optimizations enabled, it outputs less efficient code than GCC with all optimizations disabled.

So it’s a more of a stress test of Claude rather than a viable product.

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [February 6, 2026, 4:27pm UTC](https://discourse.julialang.org/t/programming-in-age-of-ai/135410/16 "2026-02-06T16:27:44Z")

</div>

Setting a topic timer since this thread seems otherwise likely to continue indefinitely as a broad discussion of the pros and cons of AI coding tools.

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [February 9, 2026, 1:00pm UTC](https://discourse.julialang.org/t/programming-in-age-of-ai/135410/17 "2026-02-09T13:00:51Z")

</div>

This topic was automatically closed after 2 days. New replies are no longer allowed.