Developer identity, jobs, and replacement anxiety
Whether coding as a career/moat is dying, junior role shrinkage, the 'AI ruined coding' discourse, and the emotional stakes of the transition.
22%
Best tweets about Coding
50 Best Tweets About Coding (2026)
A curated collection of the sharpest, most-shared X posts about coding—saved so you do not have to dig through the timeline yourself. Updated every two weeks.
Developers on the bugs, the tools, and the takes that get the whole timeline arguing.
- Creators
- 42
- Updated
Original Xholic analysis
What 50 top Coding posts reveal
Across 50 posts from 42 creators, stance analysis reads 100% SUPPORTIVE, but sentiment splits 44% positive, 34% neutral, 20% mixed with a single negative — the direction of the conversation is pro-agentic, and the arguments live in the details. Karpathy's agentic-inflection post is the largest outlier at 77.48x median; instruction files (CLAUDE.md, skills) is the highest-scoring theme (median 202.514); the vibe-coding-vs-agentic-engineering debate carries a 100.244 median, the second-highest theme. Replacement anxiety (22% share) and code-quality pushback provide the counterweight.
- Dominant tone
- Positive
- Median score
- 67.0
- Leading format
- Opinion
- Recent posts
- 22%
44% of posts
All-time engagement
62% of posts
Published in 90 days
Conversation map
The themes creators return to
Vibe coding vs. agentic engineering
Definitional and value debates over vibe coding, manual coding, and agentic engineering — which approach is legitimate, when, and for whom.
18%
Instruction files, skills, and rules-as-config
CLAUDE.md, AGENTS.md, SKILL.md, curated skill repos, and behavioral rule files as the new high-leverage way to steer coding agents.
14%
Coding agent and model comparisons
Head-to-head takes on Claude Code, Codex, Cursor, and models; devs now holding strong opinions about SOTA models the way they once debated languages.
12%
The agentic coding inflection point
Claims that AI coding agents crossed a qualitative threshold, making end-to-end delegation of large engineering tasks normal and disrupting the default programming workflow.
12%
Agent harness architecture and orchestration
Harness design patterns: subagents, hooks, memory, context engineering, parallel worktrees, IDEs as agent command centers, scheduling agent swarms.
10%
AI slop, code quality, and technical debt
Critiques of bloaty, unmaintainable, over-engineered agent-generated code; the compounding cost of slop; arguments about whether Good Code matters.
10%
Spec-first and think-before-code workflows
Spec-driven development, pre-mortems, planning before generation, and success-criteria-driven loops as the fix for vague-prompt failures.
2%
Tone and stance
SentimentPositive leads
Author postureSupportive leads
Performance benchmark
- Median likes
- 210
- Median reposts
- 15
- Median replies
- 18
- Median views
- 21.8K
Posts with media make up 52% of this collection. Their median all-time score is 47.4, compared with 76.0 for text-only posts.
Format mix
- Opinion62% · score 62.7
- List28% · score 40.0
- Prediction10% · score 138.9
Consensus and debate
Where creators agree, and where they do not
Shared view
Replacement anxiety is the loudest undercurrent
The largest theme (22% share, 11 tweets) covers career moats, junior-role shrinkage, and the 'AI ruined coding' discourse. The most-shared rebuttal in the evidence argues the literacy panic repeats every decade — assembly devs called C devs illiterate, and so on — and that the new leverage is knowing what to build and for whom, not typing speed.
Shared view
Tool tribalism replaces language wars
Claude Code vs. Codex vs. Cursor comparisons (12% share) show devs forming strong opinions about SOTA models the way they once debated languages. One widely-shared breakdown of a 14-year principal engineer's ~120-hour head-to-head on an 80k LOC project lands Claude as fast-but-supervised and Codex as slower-but-autonomous, ending on 'the tool isn't the skill.'
Shared view
Predictions and harness architecture are the format edge
Prediction posts carry a 138.877 median all-time score versus 62.674 for opinions. Harness-pattern content — subagents, hooks, tiered memory, parallel worktrees, agent command-center IDEs — supplies the concrete playbook underneath the more viral takes.
Open debate
The agentic inflection post is the set's biggest outlier
The single largest post in the set (77.48x median all-time score) declares that coding agents 'basically didn't work before December and basically work since,' arguing programming is 'becoming unrecognizable' and that 'agentic engineering' leverage is very high right now — while conceding it still needs high-level direction, judgment, and oversight.
Open debate
Instruction files are the highest-engagement theme
Rules-as-config (CLAUDE.md, SKILL.md, curated skill repos) is the top-scoring theme with a 202.514 median all-time score. The dominant outlier in this lane turns Karpathy's failure observations into a four-principle rules file: think before coding, simplicity first, surgical changes, goal-driven execution.
Open debate
Vibe coding vs. agentic engineering is the definitional fight
This theme carries a 100.244 median all-time score, second only to instruction files. Posts stake out a spectrum: one framing calls vibe coding the overcorrection — shipping code with security flaws and technical debt the author doesn't understand — and agentic engineering the PRD-first fix where the bottleneck shifts to the quality of your decisions. Tim Sweeney adds historical cover: roughly 70% of his Unreal 1 era
Open debate
The slop and quality backlash is real but secondary
AI slop critiques (median 82.085) argue the tradeoff explicitly: agent code is average but arrives in hours instead of a month, and 'nobody is going to let you take a month to write it carefully.' One counter-take reframes Good Code as always rare and expensive, with slop as the pre-existing human norm rather than a new failure.
What performs
Patterns behind standout posts
Text-only takes outperform media posts
Text posts carry a 75.96 median all-time score versus 47.37 for posts with media, despite 52% of the set including media. The outliers are argument-and-list posts — long-form takes, breakdowns, and repo round-ups — not screenshots.
Supportive stance masks mixed nuance
Stance analysis shows 100% SUPPORTIVE while sentiment runs 44% positive, 34% neutral, 20% mixed, and just one negative. The conversation is pro-agentic overall, but its most argued threads — slop, identity, and hand-coding's persistence — live inside the mixed bucket.
Spec-first is the smallest theme, but its argument cuts against the tool debate
The smallest theme (2% share, one tweet, 3.575 median score) argues that vague prompts, not bad models, cause most failures: it credits GitHub's Spec Kit — 95K+ stars and 8K+ forks within days, per the post — with making agents define rules, specs, and plans before generating code. It's the low-volume counterweight to tool tribalism.
Statistical standouts
- View standout post 1Score 5187.9 · 77.48× median
- View standout post 2Score 3302.3 · 49.32× median
- View standout post 3Score 2406.7 · 35.94× median
- View standout post 4Score 1029.7 · 15.38× median
- View standout post 5Score 596.0 · 8.9× median
Creator landscape
Who shapes this conversation
The five most represented creators account for 20% of the selected posts.
1. Lee Robinson
@leerob
2 posts
2. Daniel Lemire
@lemire
2 posts
3. Dr Milan Milanović
@milan_milanovic
2 posts
4. George from 🕹prodmgmt.world
@nurijanian
2 posts
5. Om Patel
@om_patel5
2 posts
6. smrati tiwari
@smratitiwa86867
2 posts
A concentrated creator set with breakout list-makers
42 creators produced 50 posts, with the top five holding a 20% placement share. Tech with Mak owns the strongest per-post performance (median 1224.46) via the CLAUDE.md explainer, while Om Patel's two posts pair the tool-comparison breakdown with a defense of vibe coding's upside, and Lee Robinson's pair Cursor data commentary with a case that code remains the right abstraction.
Since the previous snapshot
What changed since Oct 13, 2026
- 80% of the selected posts remained.
- The creator count changed by -1.
- The leading sentiment remained stable.
How this analysis was made
Themes, sentiment, stance, and post format are classified per tweet. All counts, shares, medians, creator concentration, freshness, and performance comparisons are then calculated directly from the published snapshot.
Xholic's all-time score compares engagement while accounting for reach, post age, and creator consistency. It is used for relative comparisons within this collection.
This report analyzes the exact 50-post snapshot shown below. AI identifies editorial categories and drafts explanations; all statistics are calculated from the snapshot, and every narrative claim is checked against cited posts before publication.
Best Coding tweets
Top Coding tweets from 42 creators
Ranked 01–50
- 01
@karpathy ·
It is hard to communicate how much programming has changed due to AI in the last 2 months: not gradually and over time in the "progress as usual" way, but specifically this last December. There are a number of asterisks but imo coding agents basically didn’t work before December and basically work since - the models have significantly higher quality, long-term coherence and tenacity and they can power through large and long tasks, well past enough that it is extremely disruptive to the default programming workflow. Just to give an example, over the weekend I was building a local video analysis dashboard for the cameras of my home so I wrote: “Here is the local IP and username/password of my DGX Spark. Log in, set up ssh keys, set up vLLM, download and bench Qwen3-VL, set up a server endpoint to inference videos, a basic web ui dashboard, test everything, set it up with systemd, record memory notes for yourself and write up a markdown report for me”. The agent went off for ~30 minutes, ran into multiple issues, researched solutions online, resolved them one by one, wrote the code, tested it, debugged it, set up the services, and came back with the report and it was just done. I didn’t touch anything. All of this could easily have been a weekend project just 3 months ago but today it’s something you kick off and forget about for 30 minutes. As a result, programming is becoming unrecognizable. You’re not typing computer code into an editor like the way things were since computers were invented, that era is over. You're spinning up AI agents, giving them tasks *in English* and managing and reviewing their work in parallel. The biggest prize is in figuring out how you can keep ascending the layers of abstraction to set up long-running orchestrator Claws with all of the right tools, memory and instructions that productively manage multiple parallel Code instances for you. The leverage achievable via top tier "agentic engineering" feels very high right now. It’s not perfect, it needs high-level direction, judgement, taste, oversight, iteration and hints and ideas. It works a lot better in some scenarios than others (e.g. especially for tasks that are well-specified and where you can verify/test functionality). The key is to build intuition to decompose the task just right to hand off the parts that work and help out around the edges. But imo, this is nowhere near "business as usual" time in software.
- 1.6KReplies
- 4.7KReposts
- 37KLikes
- 5.2MViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 02
@TimSweeneyEpic ·
When I was writing Unreal Engine 1, my time was divided as follows: - Around 30% went to seriously deep coding on hard problems: assembly language texture mappers, C++ BSP trees, data persistence, object oriented systems design, and networking. - Around 70% was just typing and refactoring large bodies of code needed for a complete engine feature set. This was not hard, and while I was doing it my mind was mostly on the deeper coding topics, thinking and planning for what's next. It didn't feel much different from vibe coding today, except that it was just me typing code on an IBM Model M keyboard rather than prompting it and reviewing the results. So, it has always seemed perfectly logical that we would rely on AI for that 70%, once the AI could do it with a similar quality standard as we could, which has never been perfection. It came as no surprise that, after a few years of AI model evolution, it was able to take the reigns on that 70% and free up programmers' time for more valuable tasks. What's more of a surprise is the emergence of AI as a sort of insta-Carmack able to solve hard technical problems quite cleverly and often cleanly, and that it's able to reason about and work in complex 3D scenes both by operating the tools and by directly understanding the raw data files. I abandoned assembly language in 1998 when out-of-order CPUs made much simpler C/C++ code faster, and never I missed it. If prompting through architectural documents, concept art, and design plans can transcend typing code and tweaking vertices, that will enable developers to spend their time on higher-level, higher value technical and creative tasks. What matters is the end product, whether it's a game or an engine. Anything developers can do to try out more ideas and make better software and games faster is a win for everyone.
- 985Replies
- 1.6KReposts
- 18.8KLikes
- 1.6MViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 03
@techNmak ·
Andrej Karpathy wrote something that every Claude Code user has felt but couldn't articulate. Three quotes. Read them slowly. "The models make wrong assumptions on your behalf and just run along with them without checking. They don't manage their confusion, don't seek clarifications, don't surface inconsistencies, don't present tradeoffs, don't push back when they should." "They really like to overcomplicate code and APIs, bloat abstractions, don't clean up dead code... implement a bloated construction over 1000 lines when 100 would do." "They still sometimes change/remove comments and code they don't sufficiently understand as side effects, even if orthogonal to the task." You've seen all three. Probably this week. Someone turned these three observations into a single CLAUDE[.]md file. Four principles, one install, directly addresses each quote: 1./ Think before coding Don't assume. Don't hide confusion. State ambiguity explicitly. Present multiple interpretations rather than silently picking one. Push back if a simpler approach exists. Stop and ask rather than guess. 2./ Simplicity first No features beyond what was asked. No abstractions for single-use code. No "flexibility" that wasn't requested. No error handling for impossible scenarios. The test: would a senior engineer say this is overcomplicated? If yes, rewrite it. 3./ Surgical changes Don't "improve" adjacent code. Don't refactor things that aren't broken. Match the existing style even if you'd do it differently. If you notice unrelated dead code, mention it, don't delete it. Every changed line should trace directly to the request. 4./ Goal-driven execution Transform "fix the bug" into "write a test that reproduces it, then make it pass." Transform "add validation" into "write tests for invalid inputs, then make them pass." Give it success criteria and watch it loop until done. This last one is Karpathy's key insight captured directly: "LLMs are exceptionally good at looping until they meet specific goals... Don't tell it what to do, give it success criteria and watch it go." It's a single file. Drop it into any project.
- 52Replies
- 210Reposts
- 2.1KLikes
- 184.3KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 04
@poteto ·
codebases have always contained slop. we have always been okay with this because code rarely needs to be perfect, outside of mission critical "hard" (eg embedded) software. swe is a unique form of engineering because you're often building something that constantly evolves and is almost organic - user tastes change, your mental models evolve, and features come and go. admittedly, i and many others who've been coding for a long time were initially (like back in 2024) skeptical that agents would write production code. "but what about all the slop that would enter our beautiful codebase?". well, even before, we had human slop, and there was a lot of it! if we're being truthful, most people call "code i didn't write" slop. the reality is that 99% of people (i include myself in that number) don't even know what Good Code looks like, let alone be capable of writing it. i would propose that Good Code is: • correct • bug free • fast and cost efficient to run it has always been exceedingly difficult and expensive to write truly Good Code, because for the longest time (maybe @bendlang will change that), code was not something you could cheaply and formally guarantee to have all 3 of these properties. this is why writing hard software is much more difficult and expensive, because depending on the use case, you may only get one chance and so you have to be right from the start. but the vast majority of software we use does not need to be Good Code to provide value to users. in fact, it is very likely that most software we use is not formally verifiable! we accepted some bugs in exchange for velocity and progress, so we rely on tests and o11y instead and have adopted a more incremental approach. this is a good thing! agents help us move faster, and if you're open to the idea, are capable of helping us write better code. it won't be Good Code (that is still expensive), but it is likely to be much better on average at scale. the new craft of swe is to figure out how to do this. it's your job now! if your productivity with and without agents is not significantly different, you're doing something wrong. but it's not too late to embrace it and use it as an opportunity to learn a whole new skill tree
- 332Replies
- 409Reposts
- 5.6KLikes
- 802.2KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 05
@RoundtableSpace ·
SAVE THIS: 4 GitHub repos trending this week. 1. Ponytail (~165K stars) Makes your coding agent think like "the laziest senior dev in the room." Before writing code, it checks if the code needs to exist at all. Its own benchmark with Opus 5.5: about half the code, 41% less time. https://t.co/9M6VCTNmGS 2. Matt Pocock's skills (~294K stars) Real engineering skills for agents: TDD, code review, bug diagnosis, specs, tickets. One-line install for Claude Code, Codex, Copilot and more. https://t.co/N3l1KqYr91 3. ECC (~282K stars) A full harness for coding agents: 71 agents, 311 skills, memory, hooks and security scanning. Best on Claude Code. There's a paid Pro tier, but the open-source version is free. https://t.co/L6Ab7em5Rm 4. God's Eye View (~57K stars) A 3D globe in your browser with live public data: flights, 838 satellites, ships, earthquakes and fires. Runs locally. https://t.co/BRQ4jg0xFx
- 52Replies
- 87Reposts
- 932Likes
- 133.4KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 06
@lexfridman ·
Here's my 6 hour conversation with @dhh, a legendary programmer, creator of Ruby on Rails, author, and race car driver. This was a fun and inspiring conversation on everything from the future of programming & AI to the nature of happiness & productivity to the value of family, getting married and having kids. X limits video length to 6 hours. So this full convo doesn't fit (by a few minutes). So, the first 6 hours are here on X. The full version is up everywhere else (see comment). Timestamps: 0:00 - Episode highlight 1:21 - Introduction 2:32 - Programming - early days 19:57 - JavaScript 30:16 - Google Chrome and DOJ 38:03 - Ruby programming language 45:14 - Beautiful code 1:03:15 - Metaprogramming 1:06:36 - Dynamic typing 1:13:55 - Scaling 1:26:47 - Future of programming 1:44:18 - Future of AI 1:50:13 - Vibe coding 1:58:45 - Rails manifesto: Principles of a great programming language 2:23:11 - Why managers are useless 2:32:32 - Small teams 2:38:39 - Jeff Bezos 2:53:57 - Why meetings are toxic 3:01:43 - Case against retirement 3:09:00 - Hard work 3:14:38 - Why we left the cloud 3:17:48 - AWS 3:27:07 - Owning your own servers 3:33:19 - Elon Musk 3:43:01 - Apple 3:54:48 - Tim Sweeney 4:06:22 - Fatherhood 4:32:04 - Racing 4:59:08 - Cars 5:04:26 - Programming setup 5:19:35 - Programming language for beginners 5:32:53 - Open source 5:41:46 - WordPress drama 5:53:03 - Money and happiness 6:01:56 - Hope
Watch video- 500Replies
- 916Reposts
- 8KLikes
- 4.8MViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 07
@om_patel5 ·
SENIOR ENGINEERS ARE QUIETLY SWITCHING FROM CLAUDE CODE TO CODEX AND HERE'S THE BRUTAL BREAKDOWN a 14-year principal engineer spent ~120 hours co-developing (not vibe coding) across both tools on an 80k LOC python/typescript project. here's what he found: Claude feels like an engineer on a time crunch: > speeds toward getting things working > ignores CLAUDE.md at least once per session > leaves tasks half-done mid-migration > changes tests to match what IT thinks the goal is > almost never creates new files — just bloats existing ones Codex feels like a 5-6 year senior: > stops mid-task to rethink and refactor unprompted > never once ignored AGENTS.md > doesn't extend god classes — it factors them out > does things you hadn't thought of that are actually additive > you can fire it off and come back when it's done the raw numbers: > Claude: more done per session, more cleanup every few days > Codex: 3-4x slower, but the work is just better > Codex Pro x5 ≈ Claude Max x20 in usage caps the real difference: > Claude needs a skilled, focused driver or it goes off the rails > Codex demonstrates competence and earns autonomy his verdict: > vibe coding a weekend project? Claude wins > building enterprise software? Codex wins "Claude requires a skilled, focused driver more than Codex does" both give crap output if you don't know SWE. the tool isn't the skill.
- 120Replies
- 117Reposts
- 1.2KLikes
- 146.8KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 08
@rauchg ·
Code is an output. Nature is healing. For too long we treated code as input. We glorified it, hand-formatted it, prettified it, obsessed over it. We built sophisticated GUIs to write it in: IDEs. We syntax-highlit, tree-sat, mini-mapped the code. Keyboard triggers, inline autocompletes, ghost text. “What color scheme is that?” We stayed up debating the ideal length of APIs and function bodies. Is this API going to look nice enough for another human to read? We’re now turning our attention to the true inputs. Requirements, specs, feedback, design inspiration. Crucially: production inputs. Our coding agents need to understand how your users are experiencing your application, what errors they’re running into, and turn *that* into code. We will inevitably glorify code less, as well as coders. The best engineers I’ve worked with always saw code as a means to an end anyway. An output that’s bound to soon be transformed again.
- 288Replies
- 245Reposts
- 2.6KLikes
- 316KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 09
@om_patel5 ·
a 58 year old guy just dropped the best take on vibe coding i've ever read. MD. PhD. triple board certified. been writing code since the 1970s. he said Claude Code is the biggest leap in programming he's seen in his entire career. and he's seen every single one. he said Claude Code feels like every major leap in programming history combined into one. the biggest shift he's seen in decades. he's using it to reverse engineer bus commands for his 25 year old Sony CD jukeboxes with ESP32 hardware. said doing it manually would have been "beyond laborious." then someone who had never coded before posted their first project. people started dogpiling on him for messy HTML and having a donation link. his response: who cares if it's messy HTML. the guy is posting about discovering he can build things late in life. and people are checking for em-dashes to decide if he's a bot. more good has been built for the world because of vibe coding than slop has ever been produced. we should be celebrating that, not criticizing it.
- 85Replies
- 99Reposts
- 1.3KLikes
- 129KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 10
@leerob ·
How are coding agents changing software engineering? Yapped for 15 minutes about new Cursor data we published, including: 1. Why lines of code is an imperfect measure of AI progress 2. Balancing intelligence/cost/speed for models 3. Code reviews with "Mega PRs" (1000+ lines)
Watch video- 54Replies
- 52Reposts
- 815Likes
- 58.6KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post.
- 11
@leerob ·
Code is actually the right abstraction. Too often I see the future of software engineering diminished down to, effectively, writing and reviewing markdown files. Yes, it will be hard to review thousands of lines of agent code. But maybe the takeaway is that you want less code? Rather than just giving up ("well I guess we won't read the code, or we'll read this lossy markdown summary") this should be a signal forcing you to think about better systems. - How can we make our codebase more verifiable? For example, fast/robust/stable tests, or moving to a typed language. - How can we deslop or improve the architecture/abstractions of the code generated by agents? For example, spending more time up front on the codebase architecture/types before yolo generating all of the code. - How are we going to maintain and evolve this codebase over time? The slop compounds. One great solution here is... you guessed it, learning from the past decades of software engineering! For example, you might just have the wrong abstraction entirely, leading to a ton of duplicated code. I think the markdown folks *are* right in some ways. If you are using skills every day, for many different prompts and workflows, isn't that effectively "coding with markdown"? Kinda. There's been plenty of ink spilled on the merits and benefits of skills. To me, skills make your style of working legible for agents. They don't replace code and that's not really the point. In reality, there's this messy and constantly re-evolving future in which both of these things are true: 1. Skills (and markdown) are important for how you give input to the agents and ensure high-quality code & systems are created 2. Looking at the actual code will not be replaced by markdown summaries or a collection of spec documents that ignore the lower level details of the code In summary: reality has a surprising amount of detail (and nuance)!
- 110Replies
- 97Reposts
- 1.3KLikes
- 114KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 12
@alex_prompter ·
Some of the most starred repos on GitHub right now contain zero runtime code. They're markdown files, skill configs, and prompt collections that change how AI models behave. 6 repos worth knowing about, ordered by stars: 1. obra/superpowers (200K+ stars) A full development methodology delivered as 14 SKILL. md files. Forces your coding agent to write a spec before touching code, enforces test-driven development, and isolates tasks into subagents. Works across Claude Code, Codex, Cursor, and Gemini CLI. Created by Jesse Vincent, accepted into Anthropic's official plugin marketplace. 2. andrej-karpathy-skills (170K+ stars) One CLAUDE. md file. 65 lines. Zero dependencies. Four behavioral rules distilled from Karpathy's viral observations about how AI coding agents fail: think before coding, simplicity first, surgical changes, goal-driven execution. Developer Forrest Chang turned the observations into a file you drop into your project root. Probably the highest-leverage single file you can add to any AI-assisted project. 3. mattpocock/skills (135K+ stars) Matt Pocock's personal .claude skills directory, published as a public repo. 21 skill files built from his daily TypeScript workflow. The standout is /grill-me: the agent asks 50+ detailed questions before writing a single line of code. Sessions run about 45 minutes. By the end you have a richer project spec than most PRDs produce. 4. Everything Claude Code (100K+ stars) Won the Anthropic x Cerebral Valley hackathon. 28 specialized agents, 119 skills, 60 slash commands, and a built-in security scanner. Works across Claude Code, Cursor, Codex, and OpenCode from a single AGENTS. md at the root. The closest thing to a full operating system for your coding agent. Created by Affaan Mustafa. 5. awesome-chatgpt-prompts (100K+ stars) The original LLM behavioral modification repo. A community-sourced collection of system prompts that turn ChatGPT into a Linux terminal, a Socratic teacher, a legal advisor, a debate coach. What CLAUDE. md does for coding agents today, this repo did for ChatGPT conversations years earlier. Still actively maintained. 6. awesome-claude-skills by ComposioHQ (60K+ stars) The directory. 1,000+ production-ready Claude Code skills organized by category: developer tools, document processing, data analysis, business workflows, security. Where the other five repos give you specific tools, this one gives you the map of what's available across the entire ecosystem.
- 14Replies
- 43Reposts
- 226Likes
- 22.5KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 13
@neetcode1 ·
Forgot to post on twitter - my conversation with @thdxr from @opencode Talked a lot about how programming is changing & not changing. I really enjoyed a lot of the historical takes that Dax has. He's building one of these "agentic coding" tools, so he sees the value in it, but he also has a healthy amount of skepticism. A lot of the core debates about "vibe code" vs "traditional code" aren't new. They already existed in many forms, e.g. go fast break things vs overengineering, microservices vs monolith, testing, etc. I also really resonated with his idea of competition - was probably my favorite part, but there were many great ones! 0:00 - Intro 3:56 - Dax's developer workflow 6:54 - Is code no longer written by humans? 11:32 - Competition, Claude Code 19:04 - Positioning vs Product 23:49 - Will OpenAI acquire OpenCode? 28:02 - The Future of Coding, effort vs impact 37:16 - Code Quality 42:23 - Did AI take the fun out of programming? 45:56 - Will programming skills decay long term? 51:56 - Technical skills alone are useless 58:56 - Becoming an Elite Developer Thank you to our sponsors @posthog and @greptile You can find the NeetCode podcast on YT, Spotify & Apple Podcast - links below
Watch video- 16Replies
- 19Reposts
- 569Likes
- 40.4KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 14
@gregisenberg ·
a post called "the west forgot how to code" is going viral among devs. the thesis: AI assisted devs ship faster but understand nothing. the next generation will be illiterate at the layer that matters. tbh, this panic happens every single decade. - assembly devs said C devs were illiterate. - C devs said java devs were illiterate. - java devs said react devs were illiterate. - react devs said no-code builders were illiterate. every single one of them was correct. every single one of them was also irrelevant within 10 years. the pattern is always the same. the new generation abstracts away the thing the old generation spent a career mastering. the old generation calls it dangerous. the new generation ships 10x faster & doesn't care. the market rewards speed. the cycle repeats. what's interesting is that the "illiterate" generation always wins. they win because they ship faster, build with less ego, & don't carry the baggage of what code is supposed to look like. they haven't been taught what's "proper." so they just build what works. the mass commoditization of coding is the mass democratization of building. the thing that used to take a team of 10 and $2 million now takes one person and a weekend. this means more competition. but it also means more weird, specific, niche products that never would have existed because the cost to build was too high. a million micro-products serving a million micro-audiences. the entire long tail of software just got unlocked. the people writing these posts are mourning a world where knowing how to code was a moat. it was. for decades. knowing how to code meant you had leverage that most people didn't have. that leverage is evaporating and it's uncomfortable. and I get it. I studied computer science at university. but the thing that replaced it is way more interesting. the new leverage is knowing what to build, who to build it for, and how to get it in front of them. that's harder to learn from a tutorial. that's harder to automate. & that's where the real compounding happens. the real question is "what happens when 100x more people can build" and the answer is a lot of garbage and a few things that change everything. that's always the answer. that was the answer with blogs, with youtube, with podcasts, with mobile apps. the gatekeepers always mourn the gate. that's terrifying if your identity is "I am a coder." it's the greatest opportunity in history if your identity is "I build things people want." okay, i had too much coffee. back to building.
- 114Replies
- 43Reposts
- 446Likes
- 40.5KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 15
@systematicls ·
I can't understand how professional software developers are so attached to days of manually coding. Was objectively a top-tier software engineer (e.g. hired as a quant dev to build high performance systems) and honestly not having to type another line of code feels like such a good riddance. People being so forlorn about agents being good at coding is insane to me. You can continue to ride horses as a hobby, no one can take that away from you, but you should be happy for everyone else to have engines. Coding has and should always (just) be a means to an end. The product was and always *should* be the point. It's undeniable that agents are just objectively better at getting to the point now. Go ahead and manually write code as a hobby.
- 99Replies
- 32Reposts
- 753Likes
- 58.3KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 16
@jsmasterypro ·
"AI ruined coding" is the hottest take in tech right now. But what exactly did it ruin? Writing the same CRUD endpoints for the 400th time? Debugging webpack configs? Copy-pasting from Stack Overflow? AI took away the parts I hated and left me with the parts I love: architecture, product thinking, creative problem solving. Coding hasn't been this fun for me in 7 years.
- 151Replies
- 66Reposts
- 858Likes
- 46.8KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 17
@DavidOndrej1 ·
how to ship a full app in weeks with AI. agentic engineering not vibe coding, built-in feedback loops, the exact stack, and what to steal from this episode: 1. michael writes 95% of his code with AI and he's an actual developer at convex. last 3 months, one big app, agentic engineered. this is the formula. 2. vibe coding offshores the thinking to the agent. agentic engineering means you think, the agent does the work. that one shift changes everything. 3. the model does nothing on its own. it just predicts the next token. the harness is the wrapper that gives it tools, prompts, and memory. 4. don't chase harnesses, chase models. cursor + gpt-5.5 extra high for heavy codebases, opus 4.7 max for ui only. expensive, worth it. 5. forget documentation. opensrc by vercel pulls a package's real code into your repo. then you just say "reference the codebase" and it nails the function 8 out of 10 times. 6. agents secretly rewrite code instead of reusing it. a code structure skill run after every feature kills the code smell and keeps it clean for the next session. 7. the auto-research loop, real version: greptile scores your PR out of 5, grep loop makes the agent fix its own feedback until 5/5. walk away. it won't stop. 8. context is finite. small PRs, plan before you build, chop everything into tiny chunks. bloat the context, the agent gets dumber. 9. pick tools that are all code. svelte, convex. the agent sees the whole backend, never guesses the schema. no dashboard screenshots. 10. security is cooked. agent rule: never install a package under 14 days old. password manager, authenticator app, family passphrase. voice cloning is convincing now. 11. knowledge work is about to boom harder than coding. "i'm not technical" really means "i'm not future." the edge is mindset, not a degree. i got michael (resmic) on with david ondrej to walk through the exact setup he uses to ship fast. no theory, just the workflow. if you want the clearest look at how a real dev builds with AI in 2026, watch.
Watch video- 17Replies
- 4Reposts
- 150Likes
- 7.8KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 18
@Hesamation ·
today, I watched this DHH interview for a 2nd time. his approach to AI coding is much more playful and curious than many other experienced devs, and he’s very good at articulating why. some takeaways: “the best programmers are currently more valuable than ever because they’re the ones who are able to get the most out of the ai acceleration.” in his opinion the taste, judgement, and the ability to review what AI produces are unique qualities you gain over time. “maybe we've seen the best of the golden days” seems to be true for the average programmer. the craft was valued for a set of constraints and as they loosen, the salaries would drop. “the number of projects we have tackled internally that we would never even have contemplated starting on are legion.” he does mention some of the downsides of using these tools but his curiosity for them is quite interesting. also great bits on what it means for developers to work in post-AI era. great discussion between @dhh and @GergelyOrosz.
- 1Replies
- 12Reposts
- 270Likes
- 21.1KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 19
@ryanlpeterman ·
My goal was to record a conversation completely free of "AI doomer" takes as a timeline cleanser. For this episode, I interviewed Casey Muratori (@cmuratori) who is a video game developer and programming creator also known for his talks about the history of computing. In this episode: • Surprising findings in computer history • Where bad code comes from • The only unbreakable law in software engineering • His career in the video game industry • Why you should read technical papers Where to watch: • YouTube - https://t.co/WqtFfUao5n • Spotify - https://t.co/NXizwPbnaL • Apple Podcasts - https://t.co/jOYDGtGVnt • Transcript - https://t.co/TQEnUh0l8Y Thank you to the sponsors of this episode for supporting my work: • Jira by Atlassian: Get more work done with your favorite agents and models all in one place, check them out at https://t.co/ALUmdUvqSr • WorkOS: makes your app Enterprise Ready with easy to use APIs to add SSO, SCIM, RBAC, and more in just a few lines of code, check them out at https://t.co/y8noBzFEem Chapters: 00:00 Intro 01:08 Digging into computer science history 04:08 What shocked him 16:23 Dijkstra was depressed 26:17 The personal side of goto considered harmful 35:09 The anatomy of a 35 year mistake 50:12 Clean code horrible performance 58:33 How to write high performance code 01:01:18 Where bad code comes from 01:06:37 Why design docs before code is a bad idea 01:09:20 The only unbreakable law in software engineering 01:15:57 How he got into programming 01:21:16 Why he didnt work in big tech 01:30:44 Should you work at a startup early on 01:34:52 What video game engineering is like 01:39:57 Why preventing recursion is reasonable 01:43:24 Is vibe coding bad for the industry 01:50:17 Technical reading recommendation 01:54:27 Advice for his younger self 01:56:54 Outro
Watch video- 10Replies
- 24Reposts
- 351Likes
- 62.8KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 20
@clairevo ·
I have been coding for over 20 years (!!!) and I’m sitting here, mouth agape, watching codex: - planned full refactor of core app, published in a pretty html for my review and co-authorship - iterating through loops to code piece by piece, document and update architecture plans as it goes - every loop does a browser smoke test of new features, identifies and fixes functional and visual regressions (even ones not related to the code!) - maintains lints and tests - my job is to type “ok what’s next” and occasionally auth integrations oh and on the side his buddy codex is 45 minutes into a /goal of cleaning up 4,000 emails in my inbox
- 41Replies
- 15Reposts
- 344Likes
- 26.8KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 21
@johncrickett ·
Working, good professional software engineers will continue writing code by hand. No matter how much AI they use. AI coding agents are great tools, but they’re not the right tool for every job. Being a good software engineer means knowing when they’re the right tool and when they’re not. Knowing when it’s more efficient to write the code by hand and when it’s not. Hat tip to Petar Dambovaliev who summed this up well: “The more precise you need to be the more natural language text you need to write to describe the same programming concept. So at some point it is actually faster to write the code than to try to explain to an LLM what the code should do. It is a spectrum and you should be at any moment be able to go from one to the other.”
- 72Replies
- 18Reposts
- 314Likes
- 17.8KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 22
@LBacaj ·
We’re making a fundamental tradeoff when we use these coding agents, but some of my engineering friends still don’t seem to get it. I see a lot of engineers make the argument “AI outputs still aren’t that great, code quality isn’t the same as writing it by hand.” And it’s all true, their argument is not wrong. But a coding agent can produce in a few hours what would take one of these engineers a month, or more. And I’ll even accept at face value that their well-thought-out, carefully written “artisanal code” would be better. But it would take them 10x longer to get out. So the fundamental thing we’re doing is to take this average code, generated in a day by an LLM, and try to make it a little above average. We are prompting our way onto something we can stand behind and support. And even if that extra work takes let’s say a week & it’s frustrating as hell to get it to something we can stand behind, a week is still better than spending a month or more. So that’s the tradeoff. And if you write code for money, pretty soon, nobody is going to let you take a month to write it carefully. Businesses all exist in a competitive space, if other businesses find a way to move faster by willingly making this tradeoff, they’ll all be forced to work this way. And it’s already happening and it will continue to happen. Then on top of all this, I notice many of us have this old mental model that we are writing code for other humans to extend, to work with, to add features to, etc. And in that world code quality matters a lot. But it’s unclear to me now that other humans will ever extend your code again. If these models improve even a little bit more, models will always be extending your code from now on. In that new world, you have to almost always make this tradeoff and you have to become great at it.
- 83Replies
- 38Reposts
- 473Likes
- 53.7KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 23
@lemire ·
Bjarne Stroustrup (creator of C++) recently gave an interview to the StackOverflow blog... He answers a few interesting questions... I share me thoughts after each Stroustrup's quote. 1. What is the best way to handle errors in software ? It depends... « You could terminate the program. Now you don't have the security problem and wrong results. And if you are in a server farm with 40,000 processes, that's probably the right thing to do. Then you could give some kind of error message somewhere. That's a little bit hard to do for a vector access, but in many, many cases, giving an error code will be a reasonable thing, and then you hope people test the error code. And my favorite is to throw an exception. That is, somewhere in your program, you have something that catches all exceptions, and you terminate if that's what you want to do, preferably after giving dump of the information of what caused it, so that you can fix it and you don't get it again next time. Or you have a more specific recovery mechanism, which is needed in some cases. Say if you run out of memory on a small computer that has separate memory banks, things like that. So what is the right answer to that kind of problem? The memory exhaustion, out of range access? It depends on what you're doing. » Things go wrong. What do you do when things go wrong? There is no one strategy that always work. It depends on your specific application. A reasonable option is to just stop, halt. But that's not always what is best! 2. On code guidelines... « I'm working on something called profiles. Note the plural because my experience is that different organizations, different environment, different applications have different criteria. I actually think that people who talk about memory safety and only memory safety are not very realistic. That's more propaganda than it is good engineering. » People often seek some universal coding guidelines, but that's not possible. What is unacceptable in code base A could be desirable in code base B. 3. On safety... « People do what I consider unfair attacks on C++ by using examples from badly written C. And you don't have to have badly written C, and you don't have to have badly written C++. Of course, you can find examples that crash, but you can do that in any language and you do. » I have worked, and I still work, on very large code bases that are mission critical. If you are a competent C++ programmer, you are just not going to see null pointer accesses or memory corruption. I see with students who just started to learn system programming a month or a year ago. Source: https://t.co/uUzc9qLgw1
- 14Replies
- 30Reposts
- 306Likes
- 41.1KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 24
@VaibhavSisinty ·
The difference between someone getting 20% out of Claude Code and someone getting 100% is five files. Most developers open Claude Code, type a prompt, and hope for the best. The best developers build a system around it. Five layers. Five files. One stack. → CLAUDE.md : the memory. Sets the rules, naming conventions, repo structure. The agent reads this before every task. → SKILL.md : the knowledge. Auto-invoked when the task matches. Scripts, templates, reference material the agent pulls in on its own. → Hooks : the guardrails. Block rm -rf before it runs. Auto-lint on every write. Deterministic rules that fire every time. Not AI. Just rules. → Subagents : the delegation. Separate agents for code review, testing, exploration. Own context. Own permissions. Keeps the main agent clean and focused. → Plugins : the distribution. Bundle everything into one install. Every teammate gets the same setup. Same rules. Same skills. Same guardrails. The old developer stack was frontend, backend, database. The new one is memory, skills, hooks, subagents, plugins. If you're still treating your coding agent like a chatbot, you're leaving 80% of it on the table.
- 11Replies
- 13Reposts
- 105Likes
- 7.5KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 25
@carlhua ·
i used to write flight software - you know, the one that flies jets and spacecrafts.. and if I had claude/codex back in the day, i wouldnt even need to look at code. hear me out, people say AI slop this, AI slop that, and the code it generated is trash etc etc. the thing is, with a highly tightened coding standard, and a requirement traceability down to say ~30-50 lines of code per requirement, you almost no longer need to look at the code it produced before doing testing. 2022 - oh wow, AI can write some code in the chat app 2023-2024 - cursor is amazing - it can write some code and understands the context 2025- the code is getting better and better, but often with mistakes 2026 - given the right guideline and specs, it is an EXPECTATION that the code should work the first or second round. I foresee in the near future, we would have IDE that no longer prioritizes displaying code. instead the IDE would be a tool to orchestrate agents, with responses gathering and display, so like an agent command center. I already see people building some of this but i think people are thinking about it wrong - don't take IDE or terminal as a baseline, we need to completely revamp it. This excites me because for once, we are going to revolutionize how coding is done. wait.. its not coding anymore, its more general than that, but you get the point! the subagent framework today is largely inadequate - we need a layer of LLMs on top of analyzing agents and then allow humans to control. but not all subagents should report back to the same upper LLM. whos building this? I will invest.
- 81Replies
- 9Reposts
- 272Likes
- 46.7KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 26
@GergelyOrosz ·
Amusing observation: Many of us devs are becoming as opinionated and knowledgeable about SOTA models (and their coding performance) like we used to be about programming languages and the tips-and-tricks to be more productive with them Meanwhile we don't really talk about programming languages all that much...
- 85Replies
- 24Reposts
- 738Likes
- 103.5KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 27
@bibryam ·
If you missed, check out my latest post 👇 →12 patterns behind production coding agents← 1. Persistent instructions: durable rules repo. Helps consistency. Trade-off: goes stale. 2. Scoped context: load rules by directory. Helps local accuracy. Trade-off: harder to debug. 3. Tiered memory: hot index, cold files, full logs. Helps token efficiency. Trade-off: more memory plumbing. 4. Dream consolidation: background memory cleanup. Helps reduce drift. Trade-off: can prune the wrong thing. 5. Progressive compaction: compress old context in stages. Helps long sessions. Trade-off: loses detail. 6. Explore-plan-act: read first, edit later. Helps avoid blind changes. Trade-off: slower to start. 7. Context-isolated subagents: separate research, planning, editing. Helps reduce context pollution. Trade-off: handoff loss. 8. Fork-join parallelism: parallel subagents on isolated branches. Helps throughput. Trade-off: merge conflicts. 9. Progressive tool expansion: start with few tools, unlock more later. Helps tool selection. Trade-off: expansion logic. 10. Command risk classification: classify commands before execution. Helps safety with less approval fatigue. Trade-off: rigid rules. 11. Single-purpose tools: typed tools for read/edit/search. Helps reliability and permissions. Trade-off: less flexible. 12. Deterministic lifecycle hooks: enforce invariants outside the prompt. Helps consistency. Trade-off: harder debugging. https://t.co/ISHCPHFEv5
- 4Replies
- 13Reposts
- 90Likes
- 5.1KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 28
@zarazhangrui ·
How my own usage of coding agents has changed in the past month: 1. Moved from the terminal to the Codex/Claude Code desktop apps. The Codex Mac app is especially great. Now I rarely open the terminal 2. Transitioned from mostly Claude Code to 50-50 Claude Code and Codex. Codex feels like a very reliable engineer; Claude Code is a better PM and designer with good communication skills So I go to Codex if I already have a defined task and just need it to work; I go to Claude Code if I don't yet know what I want and just wanna brainstorm/prototype
- 48Replies
- 17Reposts
- 279Likes
- 37.7KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 29
@SergioRocks ·
Software development tools changed more in 18 months than in the previous 10 years. From 2014 to 2024, the toolbox was stable. - Jira for planning - GitHub for code - VS Code for editing - CI/CD for shipping The improvements were incremental. Better linters. Faster pipelines. Sleeker frameworks. Nicer UI. Now look at that chart. - Claude Code exploding. - Copilot everywhere. - Cursor rising fast. - A long tail of tools climbing behind them. And new ones popping up every week. This is not "just another tool". It's a whole new layer. The modern stack now includes: - AI pair programmers - Agentic coding workflows - Spec-driven markdown files - Context orchestration between repo and model - Token budgets and inference costs We used to budget for seats. Now we budget for tokens. We used to optimize for sprint velocity. Now we optimize for context quality. Teams that treat AI as “just another tool” will see marginal gains. Teams that redesign their process around it will see structural change. If your team's workflow still looks like 2022, the problem is not your engineers. It is your engineering process.
- 18Replies
- 20Reposts
- 158Likes
- 24.7KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 30
@techNmak ·
The fastest coding agent in the world is still slow if ten tasks are standing behind it in a queue. Parallel Code removes the queue. I think the more interesting shift in AI coding is from chatting with one model to scheduling work against a repository. A bug fix, a test suite, a dependency upgrade, a refactor and an experimental implementation often have very few dependencies between them. There is no fundamental reason to serialize all five through one terminal. Parallel Code maps the problem onto primitives Git already understands: > branch = task > worktree = isolated filesystem > agent session = worker > diff = result > merge = selection Create a task and it creates a new branch, spins up a separate Git worktree, links ignored directories such as node_modules, and launches the coding agent inside that workspace. Several tasks can now progress without editing the same working files. When they finish, you inspect the diffs, leave comments, merge the useful branches and discard the rest. There is also an Arena mode for running competing implementations and comparing the results. Importantly, Parallel Code did not invent parallel coding agents. Claude Code already supports isolated worktree sessions. Codex also has built-in parallel agents, diff review and worktree isolation. That actually makes this repo more interesting, not less. It takes a pattern that is quickly becoming native across coding tools and exposes it as a free, open-source control surface for several existing CLIs. The point is not that you need Claude, Codex and Gemini simultaneously. The point is that task isolation should be independent of whichever agent you prefer. This feels less like pair programming and more like an operating system: > Fan out the work. > Isolate the processes. > Inspect the outputs. > Commit the good state. Models made individual coding tasks faster. Now the workflow around them is learning to become parallel. Here's the GitHub repo: https://t.co/sss4ImCEr7
Watch video- 6Replies
- 14Reposts
- 67Likes
- 5.9KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 31
@milan_milanovic ·
𝗪𝗵𝗮𝘁 𝗶𝘀 𝘁𝗵𝗲 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝗰𝗲 𝗯𝗲𝘁𝘄𝗲𝗲𝗻 𝗺𝗮𝗻𝘂𝗮𝗹, 𝘃𝗶𝗯𝗲, 𝗮𝗻𝗱 𝗮𝗴𝗲𝗻𝘁𝗶𝗰 𝗰𝗼𝗱𝗶𝗻𝗴? A long time ago, we coded only manually, but then we started to vibe code. Yet, vibe code is something everyone defines differently. The question is, can we take the best from both worlds and make something more useful? The answer is yes, and this is 𝗔𝗴𝗲𝗻𝘁𝗶𝗰 𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴. Here is how they differ: 𝟭. 𝗠𝗮𝗻𝘂𝗮𝗹 𝗰𝗼𝗱𝗶𝗻𝗴 It means you write every line and understand every decision. Nothing is a black box. The bottleneck is your keyboard, which means it scales to exactly one engineer. For safety-critical systems where every line carries liability, it remains the right call. Everywhere else, it is too slow. 𝟮. 𝗩𝗶𝗯𝗲 𝗰𝗼𝗱𝗶𝗻𝗴 This represents the overcorrection. You describe what you want, the AI decides the implementation, and you ship it. It feels fast at first. Then something breaks, and you are debugging code nobody on your team wrote or reviewed. Many vibe-coded apps shipped with hype but also had security flaws and even more technical debt, which their authors didn't understand. This is a very good example of a Dunning-Kruger effect. Unfortunately, many non-coders are in this group. 𝟯. 𝗔𝗴𝗲𝗻𝘁𝗶𝗰 𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴 Here, you write a PRD before any code is written. Here, you may have a few iterations of back-and-forth with the agent. Then, the agent implements, opens PRs, and runs tests. You review the output and enforce architecture rules in code. The bottleneck shifts from writing speed to the quality of your own decisions. I expect that we push more and more in this direction, recognizing good patterns and best practices, as we did with manual coding. These three coding approaches are a progression, and most teams are stuck in the middle one, thinking they have already arrived. Which one describes how your team works today?
- 10Replies
- 22Reposts
- 104Likes
- 5.7KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 32
@DivyanshT91162 ·
10 GITHUB REPOS THAT TEACH YOU HOW TECH ACTUALLY WORKS. 1. Build Your Own X — recreate technology from scratch. Git, databases, Docker, operating systems, neural networks, browsers, search engines, programming languages and much more. This rabbit hole is MASSIVE. https://t.co/B90mE5QXL7 2. Crafting Interpreters — build your own programming language. Go from parsing source code to actually building interpreters. You don't just learn compilers. You build one. https://t.co/FYxStkhkdc 3. xv6 — build your OS knowledge from the inside. MIT's teaching operating system for RISC-V. Read the code, modify the kernel and understand what an operating system is actually doing underneath. https://t.co/tA5nrJmTQ3 4. Project-Based Learning — learn by BUILDING. A huge collection of project-based tutorials covering Python, web development, machine learning, data science, games and more. https://t.co/i4uFJZZYGy 5. Code Crafters — rebuild real developer tools. Build your own Redis, SQLite, Git and other real technologies through hands-on challenges. Way different from watching another 4-hour tutorial. https://t.co/KSczu3ZM4y 6. Coding Interview University — turn CS into a study system. A massive self-study roadmap covering data structures, algorithms, systems, networking, databases, computer science and interview preparation. https://t.co/KJRRiNB47r 7. Free Programming Books — an insane free learning library. Thousands of freely available books, courses, problem sets and programming resources across languages and topics. https://t.co/2rIJ6mHZdO 8. Reverse Engineering Academy — take software apart to understand it. Interactive labs using real compiled binaries across formats like PE, ELF, .NET, JAR, APK and Python bytecode. https://t.co/kuRbgZI7OG 9. Learning Reverse Engineering — learn what happens after compilation. Real C/C++ programs, assembly, Windows internals, PE files and reverse-engineering exercises. https://t.co/ql9oc7WjoY 10. Code Crafters' Build-Your-Own Challenges — learn by recreating the real thing. Instead of memorizing how Redis, SQLite or Git works, actually implement the core pieces yourself. https://t.co/x3OueF1yYV All are open-source. Bookmark this. Your next learning rabbit hole is sorted.
- 1Replies
- 12Reposts
- 33Likes
- 2.3KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 33
@GohilHardy ·
AI coding tools are exploding: Cursor, Claude Code, Gemini, Grok.. At the same time: - junior roles are shrinking - job postings are dropping - expectations are rising Feels like this is either the best era for adaptable developers… or the hardest one for everyone else.
- 45Replies
- 1Reposts
- 54Likes
- 1KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 34
@vishalsingh2972 ·
Coding isn't dead. But coding alone is. It's 2026. Claude writes the code. Codex reviews it. ChatGPT explains it. Gemini confidently says the architecture looks good. Cursor fixes the bugs. And somehow, production is still down. AI can write code. But knowing what to build, why it matters, and whether it should exist in the first place? That's still on you. The skills worth focusing on now: → Communication (explaining why the AI broke prod) → Public speaking (defending your AI-generated architecture in meetings) → Critical thinking (not blindly trusting "all tests passed") → Problem framing (10,000 lines of code. Wrong problem.) → Explaining tradeoffs (because "Claude recommended it" isn't a technical argument) → Product thinking (building something people actually want) → Asking the right questions (before your agents build the wrong thing perfectly) → System design (before AI creates 47 microservices) → AI literacy (knowing when to use AI and when not to trust it) → Writing clearly (because vague requirements produce very confident garbage) → Debugging and validation (understanding code you didn't write) → Decision-making (when five models give you five different answers) → Prioritization (not every AI-generated feature deserves to ship) → Saying no (especially to "just vibe code it") → Taste and judgment (knowing the difference between working code and good software) → End-to-end ownership (because Claude isn't joining your 3 AM incident call) AI is making writing code easier. But judgment, communication, and ownership? They matter more than ever before. Stop optimizing for how fast you write code. Start optimizing for how well you think, decide, communicate, and ship. Your AI agents can generate the code. You're still responsible for what happens when someone actually uses it.
- 22Replies
- 2Reposts
- 53Likes
- 2.9KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 35
@smratitiwa86867 ·
Developers are quietly building a second brain inside their AI coding tools right now. And almost nobody realizes how important this shift is. Claude Code’s "Skills.md" looks like “just another markdown file.” It’s not. It’s the beginning of programmable AI memory for software engineering. Most AI coding workflows today are broken in the same way: • repetitive prompting • inconsistent outputs • forgotten context • unstable architecture decisions • AI behaving differently every session So developers waste hours re-explaining: “use this stack” “follow this pattern” “don’t break this API” “write code this way” Over and over again. "Skills.md" changes that completely. Instead of prompting the AI every time… You teach it how your team builds once. Now Claude starts operating with: - coding standards - architecture rules - debugging workflows - testing systems - project conventions - review patterns - deployment logic persisted directly into its workflow. That’s a massive shift. Because this is where AI stops feeling like autocomplete… and starts feeling like infrastructure. The real breakthrough in AI coding isn’t smarter models anymore. It’s persistent operational context. The teams moving fastest right now are not the ones writing better prompts. They’re the ones building reusable intelligence layers around AI. That compounds. Fast. And the scary part? Most developers still haven’t noticed this transition happening. They’re benchmarking models. Meanwhile advanced teams are quietly building internal AI operating systems around their workflows. That gap is going to become enormous. "Skills.md" is interesting because it represents something much bigger than Claude Code itself: AI that adapts to YOUR engineering system instead of forcing engineers to adapt to the AI. That changes: • onboarding • consistency • code quality • iteration speed • institutional memory • engineering velocity A lot of people will look back at these “simple markdown skill files” the same way we now look at: - Dockerfiles - package.json - .gitignore - tsconfig Small files. Huge workflow shift. The future of AI coding won’t belong to the people with the longest prompts. It’ll belong to the people who build the best AI environments. And that transition has already started.
- 5Replies
- 9Reposts
- 35Likes
- 1.2KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 36
@Trader_XO ·
I’ve been thinking about this a lot lately - Agentic Coding and framework choice. As someone who’s comfortable with TypeScript with Nest, C# with .Net Core, Python Fast API, and Go, when it comes to building a bunch of APIs, I’ve found myself pausing less to ask can I build this in any of these stacks? and more to as to which one am I actually choosing, and why? Because with agentic coding, the equation feels like it’s changing. The value seems to be shifting away from just how fast you can write code by hand, and more toward how well you can think through systems, make good engineering decisions, and work in a way that lets you build and adapt confidently. So for me, stack choice starts to feel less like a question of personal coding preference and more like a question of leverage. Which ecosystem is the most versatile? Which codebase will be easiest to read, understand, and safely change later? Which stack will make the system easier to operate and maintain over time? I don’t think the takeaway is that coding skill no longer matters, it does. It’s more that code comprehension, design judgment, and maintainability may matter more now than raw implementation speed. That’s what makes the question interesting to me nowadays... - Not just how do I build the APIs? but which stack actually gives me the best long term leverage? Rhetorical Questions...
- 27Replies
- 10Reposts
- 193Likes
- 29.5KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 37
@lemire ·
AI as an ‘IDE’ and what to watch for Since the early days of programming, there has been a feeling that programming needed to be ‘supported’. It could not just be typing text in an editor. And so we got integrated development environments like Turbo Pascal, Visual Studio, and so forth. I estimate that most software programmers work within an IDE. I certainly got serious with programming by using an IDE. With a system like Visual Basic, you could, in a few hours, build an entire desktop application even if you did not know programming very well. We got autocompletion so that you did not need to remember function names or read the documentation. It is obvious to me that AI agents like GitHub Copilot or Claude CLI are just a form of IDE. And I think that they need to be used accordingly. One of my favourite games lately has been to ask an AI to give me the assembly code of a function and to document it. If you accept my premise that AI is like an IDE, then many of my observations regarding IDEs apply. Many years ago, a company tried to recruit me to run their software division. When I learned (accidentally) that it was built on Visual Basic, I immediately got cold feet. There is nothing wrong per se with Visual Basic. You can write solid software with it. But the psychological effect of a tool like Visual Basic is that you tend to spend little time on actual engineering and more time adding features. Thus, it scales poorly. “Being easy” is not always the feature you think it is. And I would react similarly today if I were asked to lead a software team… and I learned that their entire stack was vibe coded (coded entirely by AI). You might say that it is unfair. You have stopped coding by hand months ago and your code has never been better. Maybe it is. And, to be fair, remarkable pieces of software were written using powerful tools that made programming easier. « The medium is the message » said McLuhan. And it is true. I look at Java, a great programming language. The community quickly became very IDE-centric (as opposed to the Unix tradition of command-line tools). Some of the most important systems today are built with Java. But you can feel the struggle to remain relevant, because the pain points are hidden behind a graphical interface; people just get it. « Do not look behind the curtain! » Here is what you want, ideally: Bad engineering should be physically painful. When you are doing things wrong, you should get headaches. Tooling powerful enough to make bad engineering ‘work’ might cause more harm than good.
- 4Replies
- 8Reposts
- 68Likes
- 8KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 38
@nurijanian ·
PMs have been "vibe-coding" since the dawn of times, we just didn't call it that when AI writes your code, your job is managing code you can't fully read. isn't this what PMs used to do before? have any of you actually looked at the code your eng team wrote? there's this great talk from an Anthropic member of technical staff, here are 10 things from his talk that PMs should pay close attention to: 1. most people saying "i vibe code" aren't vibe coding. Andrej Karpathy's actual definition (he coined the term): fully give into the vibes, embrace exponentials, forget the code even exists. if you're reviewing every diff Claude produces, you're doing AI-assisted coding, which is a different skill than what will matter in 12 months. 2. AI task length is doubling every ~7 months. right now it handles about an hour of work. in two years, a full week. you can review an hour of output, but you can't review a week of output line by line, and lock-step human review doesn't survive that curve. 3. we've seen this before with compilers. early compiler users insisted on reading the assembly output. it made sense when programs were small and stopped making sense fast. AI-written code is at the "reading the assembly" stage right now. 4. Erik's framing: forget the code exists, but not the product. same move as forgetting assembly but still knowing software. your verification layer moves up one level of abstraction, and the code becomes an implementation detail you manage through outcomes. 5. managing work you can't fully audit is as old as civilization. every CTO manages engineers whose code they can't all read, and every PM ships features they didn't write. engineers are catching up to a problem the rest of the company solved a long time ago. 6. i think engineers are uniquely unprepared for this because their professional identity is built around full-stack IC mastery and understanding the entire depth of the stack. that identity has to change, and it's the same transition PMs already went through: learning to ship things you didn't build by verifying outcomes instead of inspecting implementations. 7. acceptance tests beat implementation review. Erik writes three end-to-end tests: one happy path, two error cases. he reads only the tests, and if he agrees with what they check and they pass, he trusts the code. this is how PMs have written acceptance criteria for decades. 8. dogfood the product, not the code. use it, check it behaves as expected, don't read the source. this has been the PM move since the role existed, because your judgment about product quality comes from experiencing the product, not auditing the implementation. 9. spot-check key facts, not the whole artifact. the CEO/CFO move on financial models: pick three slices you understand deeply, verify those, trust the rest conditional on those holding. Erik applies this to AI-generated code, and PMs apply it to engineering output every sprint. 10. before touching an unfamiliar codebase, map it first. ask Claude where auth happens, what classes matter, what's similar to what you want to build. build the mental picture before writing a line, which is PM discovery applied to code. by the way, here's a skill to help PMs find vibe-code friendly parts of the code: https://t.co/NHUQrCSmz8
- 1Replies
- 4Reposts
- 26Likes
- 3KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 39
@staysaasy ·
I had this a ha moment recently talking with a bunch of traditionally non-coding people who were all using codex and cursor and Claude code. People I’ve talked to just last year who treated HTML like ancient Sanskrit. Who I had to apologize to if I spoke too much about engineering stuff. And now it’s like we’re all just using the same tools and talking the same language. Can they debug a product incident due to thundering herd issues from a bad cache key expiration? No. But that’s so little of the job these days. In anything I’d reasonably small talk about from an engineering perspective, they were 100% on the same page and understood. And these folks have a very nuanced understanding of the AI toolchain. The world is moving very fast.
- 6Replies
- 1Reposts
- 81Likes
- 5.9KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 40
@Hartdrawss ·
Hot Take : Vibe coding will NOT replace developers. The argument is wrong. Here's exactly why. Vibe coding replaces the tedious parts — boilerplate, CRUD scaffolding, first drafts of UI, repetitive patterns. It does not replace: > Knowing what to build in the first place > Designing a system that doesn't collapse at scale > Reviewing AI output for security vulnerabilities (and there are many) > Debugging the production incident at 2 AM that AI has no context for > Making the 50 architectural decisions that determine if the product survives year one > Understanding the customer problem well enough to know what the software actually needs to do What's being replaced is the developer whose entire value was "I write code." What isn't being replaced is the developer whose value is "I solve problems, design systems, and take responsibility for what gets built." The developers winning are the ones who always knew "solving problems" was the job. It's just has honestly made the processes rapid; but getting aligned still needs more and more great engineer !
- 19Replies
- 2Reposts
- 46Likes
- 6.1KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 41
@nurijanian ·
Saw the Claude Code vs Cowork debate on r/PM. Here's the framework I'd actually use: 1. Cowork wins for one-off work. Writing a doc, quick research, visualizing a decision you won't revisit. It's faster if you're not building something that needs to persist. 2. Cowork also wins on inline canvas rendering. Seeing Claude generate visuals for a decision, right in the chat, cuts iteration time. Code requires switching to files. 3. I think Claude Code wins for anything meant to compound. Hooks, skills, and custom instruction files survive sessions. 4. Code wins for codebase access. Reading PRs, tracing bugs, explaining features to engineering without pinging anyone. Code is the only tool that can do this. 5. Code wins when you want to connect to your own data. Database queries, S3, custom scripts you've already built. Cowork doesn't support this. 6. If you use Obsidian or any second brain, I've found Code is the only option that works. The most impressive setup in that thread was a non-coding PM who built 50 custom hooks, auto-logged meeting transcripts, and made all of it AI-searchable across sessions. 7. Enterprise and regulated environments usually default to Code anyway. AWS Bedrock deployments, no-Cowork policies, screen-sharing security concerns. The debate is moot for a lot of orgs. 8. Best team stack: Code builds, Cowork consumes. Data pipeline in Code, results surfaced in Cowork for non-technical teammates. 9. You don't need to be a developer to use Code. The setup is trivial. 10. Most PMs are using Cowork like a better ChatGPT. That's fine. But if you want your AI work to compound, I'd use Claude Code.
- 2Replies
- 4Reposts
- 13Likes
- 1.8KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 42
@EzekielCrrypt ·
A–Z of Coding , that you dont need to skip A — Algorithm A step by step way to solve a problem. Example: A recipe for cooking is basically an algorithm. B — Bug An error in your code that makes it not work properly. C — Code Instructions you write for a computer to follow. D — Debugging Finding and fixing bugs in your code. E — Editor A tool where you write code (like Visual Studio Code). F — Function A reusable block of code that does something specific. G — Git A tool that helps you track changes in your code. H — HTML The structure of a webpage (like the skeleton). I — IDE A full coding environment (editor + tools). J — JavaScript A programming language that makes websites interactive. K — Keyword Special words in a programming language (like if, for, while). L — Loop Repeats a block of code multiple times. M — Method A function tied to an object. N — Node.js Lets you run JavaScript outside the browser. O — Object A collection of related data and functions. P — Python A beginner-friendly programming language. Q — Query A request for data (often used with databases). R — Runtime When your code is actually running. S — Syntax The rules of how code must be written. T — Terminal A command line tool to interact with your computer. U — UI (User Interface) What users see and interact with. V — Variable A container for storing data. W — Web The internet space where apps and sites live. X — XML A format for storing and transporting data. Y — YAML A human-readable data format often used in configs. Z — Zero & One (Binary) The language computers understand at the lowest level.
- 1Replies
- 1Reposts
- 8Likes
- 228Views
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 43
@smratitiwa86867 ·
🚨 Every AI coder is making this mistake… and most don’t even realize it. Everyone is obsessed with the latest AI coding tools. New prompts. New agents. New workflows. But here's the uncomfortable truth: The biggest reason AI-generated code fails isn't the model. It's the process. Andrej Karpathy just condensed years of hard-earned engineering wisdom into one document: "CLAUDE.md: Field Notes on Getting a Language Model to Write Code You Will Not Rewrite." And it's packed with principles every developer should follow. Here are the biggest takeaways: ✅ Read the existing codebase before writing a single line. ✅ Think through the solution first. Don't let the AI "figure it out" by guessing. ✅ Keep changes small. Huge AI-generated diffs create huge debugging headaches. ✅ Test before you celebrate. Working ≠ Correct. ✅ Define success before coding. Clear goals produce better code. ✅ Debug with evidence, not assumptions. ✅ Avoid unnecessary dependencies—they become long-term liabilities. ✅ Explain why changes were made, not just what changed. ✅ Watch for common traps: • Kitchen Sink refactors • Wrong abstractions • Happy-path-only code • Runaway refactoring The best engineers don't use AI to write more code. They use AI to write less code that lasts longer. That's the difference between shipping features... …and shipping technical debt. If you're using Claude, ChatGPT, Cursor, Windsurf, or any AI coding assistant, this is worth reading twice. 💬 Which one of these rules do you think most developers ignore?
- 6Replies
- 8Reposts
- 9Likes
- 914Views
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 44
@hugobowne ·
"For decades I was all in on Python. Now I don't care. TypeScript, Go, Rust, whatever. Verification isn't about looking at the code, it's whether it actually does what it needs to do." -- @intellectronica (ex-Google, ex-Microsoft, now at Jimini Health) Yesterday I spent 3.5 hours, honestly more than I should have, learning from expert builders on Show Us Your (Agent) Skills. The biggest takeaway: people aren't just writing less code, they're reading less. And this is in agentic engineering, not vibe coding. @honnibal (creator of @spacy_io ) puts Claude in "pre-mortem mode" with a skill that reads production code and writes incident reports for bugs that haven't happened yet but plausibly could, the moment a future dev makes a reasonable-looking change. @nicolaygerold (building @AmpCode at @Sourcegraph) flips that with a post-mortem skill: when an agent screws up, it gets the agent to introspect on which instruction in its context caused the failure. Defaults to removing instructions, not adding more. Full ep: https://t.co/yKKOPsG6gj
Watch video- 0Replies
- 1Reposts
- 15Likes
- 2.2KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 45
@Shruti_0810 ·
Everyone is arguing about which AI coding agent is best. GitHub just showed that they've all been asking the wrong question. 95K+ stars. 8K+ forks. In just a few days. Not for a new AI model. Not for another coding agent. For a workflow. Here's the mistake almost everyone makes: Open Claude Code. Open Cursor. Type: > "Build me a SaaS." The AI immediately starts writing code. It makes assumptions. Adds features you never wanted. Misses edge cases. Then you spend hours fixing AI-generated code. The problem wasn't the AI. The problem was starting with code instead of clarity. That's exactly what GitHub's Spec Kit fixes. Instead of coding first, it makes the AI think first. → Define the project rules → Write a proper specification → Clarify missing requirements → Create an implementation plan → Break everything into dependency-based tasks → Then generate the code Simple idea. Massive difference. Every AI agent performs better when it has a clear specification instead of a vague prompt. That's why Spec Kit already works with Claude Code, Cursor, GitHub Copilot, Codex, Gemini CLI, and many more. I think this is where AI development is heading. Less prompt engineering. More specification engineering. The developers who learn this early are going to ship much better software than everyone else. Repo below ↓
Watch video- 6Replies
- 3Reposts
- 15Likes
- 2.6KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 46
@shekhar_tw ·
GitHub went down today. And for a few seconds, my first reaction was: “Well… I guess I can’t work.” Then I realized how stupid that sounded. Because GitHub being down doesn’t mean Git is down. Your code is still on your machine. Your branches are still there. Your commits still work. You can still build features. You can still run tests. You can still refactor code. You just can’t push it somewhere for a while. And I think this is something a lot of developers—especially when starting out—accidentally mix up: Git and GitHub are not the same thing. Git is the version control system running locally on your machine. GitHub is a platform built around Git that gives us things like: remote repositories pull requests code reviews issues CI/CD integrations collaboration When you run: git add . git commit -m "fix: something" None of that requires GitHub. Your commit exists locally. You could make 20 commits, create 5 branches, merge them, rebase them, inspect your history, revert something you broke… all without an internet connection. So instead of treating the outage as a reason to stop working, I started looking at everything I could do locally. I cleaned up some code I had been ignoring. Removed a few unnecessary pieces. Fixed TODOs that had been sitting there for weeks. Looked at some ugly functions and asked: “Why did I write it like this?” Refactored a few things. Ran the application locally. Tested flows I normally don’t spend enough time testing. And made proper commits for everything. Then there was another useful realization: We’ve become so dependent on cloud tools that sometimes we forget how much of software development is still completely local. GitHub can go down. Vercel can go down. Railway can go down. AWS can go down. Your AI coding assistant can stop responding. Your internet can disappear. But if losing one external tool means you literally cannot make progress anymore, your workflow might be more dependent than you think. There’s also another lesson here: Learn the tools underneath the tools. Don’t only learn how to click “Create Pull Request” on GitHub. Learn git diff. Learn git log. Learn branches. Learn commits. Learn rebasing. Learn merging. Learn how remotes actually work. Learn what origin means. Learn what happens when you run: git push origin main Because once you understand the underlying system, the platform becomes just an interface around something you already understand. The same thing applies everywhere in development. Don’t just learn an ORM. Understand SQL. Don’t just learn Next.js. Understand HTTP, browsers, caching and rendering. Don’t just learn Docker commands. Understand processes, ports, filesystems and networking. Don’t just learn how to prompt an AI coding tool. Understand the code it generates. Abstractions are incredibly useful. But fundamentals are what save you when the abstraction stops working. So GitHub went down. I didn’t get to push my code for a while. But I probably learned and cleaned up more than I would have if everything had been working normally. Sometimes an outage is a surprisingly good reminder: the platform is not the skill. The fundamentals are.
- 4Replies
- 0Reposts
- 8Likes
- 441Views
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 47
@milan_milanovic ·
𝗧𝗵𝗼𝘂𝗴𝗵𝘁𝗪𝗼𝗿𝗸𝘀 𝗧𝗲𝗰𝗵𝗻𝗼𝗹𝗼𝗴𝘆 𝗥𝗮𝗱𝗮𝗿 - 𝗩𝗼𝗹𝘂𝗺𝗲 𝟯𝟰 (𝗔𝗽𝗿𝗶𝗹 𝟮𝟬𝟮𝟲) Two big shifts in this edition: Claude Code moved to Adopt, and MCP by default moved to Caution. Both in the same Radar. The rest of Volume 34 is about agents, with warnings sharper than V33. Four themes stand out: 𝟭. 𝗘𝘃𝗮𝗹𝘂𝗮𝘁𝗶𝗻𝗴 𝘁𝗲𝗰𝗵 𝗶𝘀 𝗴𝗲𝘁𝘁𝗶𝗻𝗴 𝗵𝗮𝗿𝗱𝗲𝗿 Semantic diffusion is part of it. Terms like spec-driven development and harness engineering get used inconsistently, often before their meanings settle. The pace makes it worse. Some tools ThoughtWorks reviewed were less than a month old and were often maintained by a single contributor using a coding agent. The bigger risk is 𝗰𝗼𝗱𝗲𝗯𝗮𝘀𝗲 𝗰𝗼𝗴𝗻𝗶𝘁𝗶𝘃𝗲 𝗱𝗲𝗯𝘁: as more code is generated by AI, teams adopt solutions without building the mental models to debug them later. 𝟮. 𝗥𝗲𝘁𝗮𝗶𝗻𝗶𝗻𝗴 𝗽𝗿𝗶𝗻𝗰𝗶𝗽𝗹𝗲𝘀, 𝗿𝗲𝗹𝗶𝗻𝗾𝘂𝗶𝘀𝗵𝗶𝗻𝗴 𝗽𝗮𝘁𝘁𝗲𝗿𝗻𝘀 AI is pushing teams back to the foundations: 𝗽𝗮𝗶𝗿 𝗽𝗿𝗼𝗴𝗿𝗮𝗺𝗺𝗶𝗻𝗴, 𝗺𝘂𝘁𝗮𝘁𝗶𝗼𝗻 𝘁𝗲𝘀𝘁𝗶𝗻𝗴, 𝗗𝗢𝗥𝗔 𝗺𝗲𝘁𝗿𝗶𝗰𝘀, 𝘇𝗲𝗿𝗼 𝘁𝗿𝘂𝘀𝘁 𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲. After years of being abstracted away in the name of usability, the terminal is back as a primary interface. But not everything carries over. Team topologies will need to evolve into agent topologies, and feedback cycles need rethinking. 𝟯. 𝗦𝗲𝗰𝘂𝗿𝗶𝗻𝗴 𝗽𝗲𝗿𝗺𝗶𝘀𝘀𝗶𝗼𝗻-𝗵𝘂𝗻𝗴𝗿𝘆 𝗮𝗴𝗲𝗻𝘁𝘀 The agents worth building are the ones that need access to everything. OpenClaw and Claude Cowork supervise real work tasks. Gas Town coordinates agent swarms across entire codebases. Simon Willison's "𝗹𝗲𝘁𝗵𝗮𝗹 𝘁𝗿𝗶𝗳𝗲𝗰𝘁𝗮" describes an unsafe agent: private data, untrusted content, external action. That now describes most useful agents by default, not by misconfiguration. Zero trust, least privilege, defense in depth. All table stakes. Safe agent systems will be pipelines of constrained agents, not monolithic ones. 𝟰. 𝗣𝘂𝘁𝘁𝗶𝗻𝗴 𝗰𝗼𝗱𝗶𝗻𝗴 𝗮𝗴𝗲𝗻𝘁𝘀 𝗼𝗻 𝗮 𝗹𝗲𝗮𝘀𝗵 As coding agents get better, humans are tempted to step out of the loop. Teams are pushing back with 𝗰𝗼𝗱𝗶𝗻𝗴 𝗮𝗴𝗲𝗻𝘁 𝗵𝗮𝗿𝗻𝗲𝘀𝘀𝗲𝘀. Feedforward controls, such as Agent Skills, modularize instructions and load them just in time. Spec-driven frameworks like GitHub Spec-Kit and OpenSpec structure planning, design, and implementation. Feedback controls wire deterministic quality gates into agent workflows: compilers, linters, type checkers, mutation tests. Failures trigger auto-correction before human review. In more detail: 𝗧𝗲𝗰𝗵𝗻𝗶𝗾𝘂𝗲𝘀: ✅ Adopt: Context engineering, Curated shared instructions, DORA metrics, Passkeys, Zero trust architecture 🧪 Trial: Agent Skills, Feedback sensors for coding agents, Mutation testing, Progressive context disclosure, Sandboxed execution for coding agents 🛑 Caution: Agent instruction bloat, Codebase cognitive debt, Coding agent swarms, MCP by default, Pixel-streamed development environments 𝗣𝗹𝗮𝘁𝗳𝗼𝗿𝗺𝘀: 🧪 Trial: AG-UI Protocol, AWS Bedrock AgentCore, Graphiti, Langfuse, Replit, SigNoz 🔍 Assess: ClickStack, Coder, MCP Apps, Sprites 𝗧𝗼𝗼𝗹𝘀: ✅ Adopt: Axe-core, Claude Code, Cursor, Kafbat UI, mise 🧪 Trial: cargo-mutants, Claude Code plugin marketplace, Dev Containers, Figma Make, OpenAI Codex 🛑 Caution: OpenClaw 𝗟𝗮𝗻𝗴𝘂𝗮𝗴𝗲𝘀 𝗮𝗻𝗱 𝗙𝗿𝗮𝗺𝗲𝘄𝗼𝗿𝗸𝘀: ✅ Adopt: Apache Iceberg, Declarative Automation Bundles, React JS, React Native, Svelte, Typer 🧪 Trial: Agent Development Kit, DeepEval, Docling, LangExtract, LangGraph, LiteLLM
- 6Replies
- 2Reposts
- 18Likes
- 2.1KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 48
@staysaasy ·
Coding tools are now like gun collecting. > I got Cursor with VcCode completions and thirteen agentic agents in the background on separate work trees. I use codex when it’s a precise problem and Haiku on a loop for my rasberry pi. I alternate Opus 4.6 and ChaGPT 5.4 through OpenCode to arb token limits and I have five Ralph’s running at all times generating test harnesses and doing infosec compliance. > Cool man, do you think you’ll ever use all that stuff for a real life situation? > You’ll see. Oh you’ll see. Soon. Gotta be ready for when opportunity arises.
- 3Replies
- 0Reposts
- 12Likes
- 691Views
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 49
@leeschmidt123 ·
Founders: This is why you shouldn't aim for 15k LOC per day and "let the tokens rip", despite how cool it sounds. Here's a real bug I encountered today: a page in our app was being pushed up by 50px or so, leaving a white strip at the bottom and cutting off the top of the page content. The vibe coded fix: 18 lines of unmaintainable, messy, duct taped javascript The real fix: changing ONE CSS property It's tempting to spend 15 seconds telling cursor to fix it (using both GPT 5.5 and Opus 4.7). Both models concluded that a reasonable fix was 18 lines of code, accessing the Radix viewport, calling getBoundingClientRect(), manually calculating scroll offsets, and replacing scrollIntoView with a manual scrollTo, and adding an additional dependency to a useEffect(). If you've spent any time as a dev prior to AI, you read this code and immediately know it's wrong. Worse, if you've never been a dev - you might think this looks normal! Next you have two choices: (a) you spend a few more minutes thinking in depth on your own or pushing back on the LLM, or (b) you commit, push, and deploy. The vibe coded fix is at the wrong layer, inside the individual page instead of the shared layout components. It leaves the same bug possible in every other page of the app - so would need to be duplicated on every page. It addresses the symptom, not the root cause. If your app becomes filled with this code, I can virtually guarantee you it will eventually become hard or impossible to continue building on (or the tokens required will become out of hand because changing something simple becomes hundreds or thousands of lines - this burns tokens and uses up context, requires more rounds of inference, etc). A messy and unmaintainable 18 lines of code doesn't sound bad. But the same slop magnified by 10-12 hours of prompting and vibe coding every day? Now you have an unmaintainable mess of code that eventually LLMs will be unable to work on, and neither will a human. If your startup's value is delivered in the form of a software product, this is a recipe for failure. Technical founders, technical CEOs, and experienced devs already know you need to read the code to avoid piles of slop that turn into immovable walls. For new founders, or anyone new to development or product building - if you want to build anything beyond a fun prototype or barely working MVP, you *need* at least one technical founder/cofounder, or you need to be learning real engineering.
- 2Replies
- 0Reposts
- 1Likes
- 123Views
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 50
@pascal_bornet ·
Vibe coding was supposed to kill software developers. What strikes me is how quickly that story flipped. We were told AI would replace developers. Instead, it seems to be creating a new role: 𝗩𝗶𝗯𝗲 𝗖𝗼𝗱𝗶𝗻𝗴 𝗖𝗹𝗲𝗮𝗻𝘂𝗽 𝗦𝗽𝗲𝗰𝗶𝗮𝗹𝗶𝘀𝘁™. And honestly, that feels very plausible. Because when an AI-generated `final_final_v12.py` takes production down at 3 AM, the person getting the call is not the AI. It is the developer. That is the part I find most revealing. Every time the industry announces the end of developers, reality creates a fresh mess only developers can clean up. So no, software engineers are not disappearing. They are becoming the cleanup layer for AI-generated overconfidence. What do you think AI is creating faster right now: code, or more work for the people still fixing everything? #AI #VibeCoding #SoftwareEngineering #GenAI #FutureOfWork #Technology #Coding #Innovation
- 0Replies
- 3Reposts
- 4Likes
- 873Views
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post.
Best Coding tweets
Write posts like these, in your own voice
Xholic studies what works in your niche, drafts posts in your voice and schedules them for the hours your audience is online.
Start 7-day free trialTry the live demoTake a 2-minute tour of a sample account in the real app. No sign-up or login needed.
No card needed · Nothing to cancel
Browse all tweet collectionsLive demo: no sign-up or login needed · takes about 2 minutes
Keep exploring
From the blog
- 10 X Analytics API Alternative Options for 2026Compare 10 X analytics API alternatives for 2026, from low-cost data providers and custom scrapers to enterprise listening platforms.
- Twitter API Examples: A Practical Guide for BuildersExplore real Twitter API examples with code, auth flows, rate limits, and patterns for posting, streaming, analytics, and growth workflows on X.
- 10 Best Twitter Bot Maker Tools for 2026Compare the best Twitter bot maker tools for 2026, from the official X API to no-code workflow builders, SDKs, and browser automation platforms.
More topics like this
- Best tweets about ReactExplore the best tweets about React, including components, hooks, Server Components, performance, state, architecture, releases, and production lessons.
- Best tweets about RustFind the best tweets about Rust programming, including ownership, async, performance, tooling, libraries, systems design, releases, and developer experience.
- Best tweets about UI/UX DesignBrowse the best tweets about UI and UX design, featuring research, interaction patterns, usability, accessibility, visual systems, and product outcomes.
- Best tweets about Next.jsDiscover the best tweets about Next.js, covering App Router, Server Components, caching, rendering, performance, deployments, releases, and architecture.