AI-assisted code generation, agentic implementation, terminal workflows, unattended coding, and routine bug fixing

Threads run in the cloud, even when your computer is not online. Support for local workflows is coming very soon.

More in the docs:

I’ve been using assisted AI for coding since early 2023, but 2026 is when everything changed and I started using it full-time on Readplace. At the time of writing this, readplace.com has more than 3000 commits.

So yes I fully jumped on the AI bandwagon.

AI didn’t replace my development workflow. It changed the way I approach it.

AI coding tools have changed dramatically in the last few years.

Today, developers can generate components, debug errors, explore UI ideas, write documentation, and even make changes directly in a Git repository with the help of AI.

But there is one question I kept asking myself:

How can I actually use AI in my daily projects without becoming dependent on it?

After experimenting with different tools, I eventually developed a workflow that works well for me.

Instead of asking one AI tool to do everything, I use different tools for different stages of the project.

My current workflow looks like this:

Idea → ChatGPT → Stitch → MCP → Antigravity → Jules → Human Review

This article explains how I use each part of that workflow and what I have learned from it.

I'm not a software engineer.

Today I taught a room full of them.

The topic was AI-driven development. Not a demo. The actual practice: how you plan the work when an agent writes the first pass, what you still review line by line, where a human has to stay in the loop, and what changes when writing the code stops being the slow part.

I walked in thinking I was the least qualified person in the room. On raw coding, I was. These folks have shipped more production code than I will ever read.

That ended up being the useful part.

Two things I took from it:

1. AI-driven development is a practice, not a title. It rewards people who think in process, systems, and guardrails. That is my day job. The syntax was never the hard part.

2. Expertise didn't go away, it moved. Nobody in that room got replaced by the tooling. They became the reviewers and the architects, the ones who catch what the model gets confidently wrong.

I left more impressed by them, not less. And proud to have had the seat.
If you're waiting on the right title before you say something about AI at your company, I think you're waiting on the wrong thing.

Curious what you all think. Is AI closing the gap between technical and non-technical roles, or just moving it somewhere else?

#AI #Automation #AIatWork #FutureOfWork #GenerativeAI

AI can write code faster than ever.
But speed is not the same as good engineering.
AI can generate an API, build a component, or suggest a database schema in seconds. What it cannot fully understand is the responsibility behind those decisions.
Will the system still perform under heavy traffic?
Is the code secure?
What happens when a dependency fails?
Can another engineer maintain it six months from now?
Does the solution actually solve the customer’s problem?
These are not only coding questions. They require experience, context, and engineering judgment.
I use AI to explore ideas, remove repetitive work, and deliver faster. But I still review the architecture, challenge assumptions, test edge cases, and take ownership of what reaches production.
The role of a software engineer is not disappearing. It is evolving.
Our value is shifting from how quickly we can write code to how well we can make decisions, manage risks, and build systems people can trust.
AI writes code.
Engineers own the outcome.
How has AI changed the way you approach software development?

Go beyond chat in the GitHub Copilot app with these slash commands. They’ll help you plan, collaborate, automate, and customize your dev workflow.

AI didn’t replace me — it changed the way I think, build, and solve problems.

A few years ago, my day as a developer looked very different.

I would spend hours searching Google for solutions, reading Stack Overflow threads, watching YouTube tutorials, and trying different approaches until something finally worked.

It was close to midnight on a Thursday, and I had a feature due by 9 a.m. the next morning.

The feature itself wasn't complicated — a discount calculation system for an e-commerce client, applying tiered pricing rules based on order quantity and customer membership level. I'd built things like this before. But the specific combination of rules this client needed was intricate enough that I was still working through the logic well after dinner.

That's when I turned to my AI coding assistant. I described the problem clearly, included the business rules as the client had specified them, and got back a clean, well-commented function that seemed to handle every case. It was exactly what I would have written if I'd had another hour and hadn't been tired. Maybe better.

New Jira and Teamwork Graph capabilities help engineering teams plan, assign, govern, and measure work across humans and AI agents.

I believe AI should be forbidden for developers who just push buttons and hope it's fine.

At our company, every engineer uses AI for coding, and we fully support it.

What we don’t allow is blindly shipping code you haven't understood. The moment you stop reviewing what the machine writes, you're not an engineer anymore. You're a button.

Part of the problem is the gap between how the world talks about AI and what it actually does.

For non-technical people, AI genuinely is a breakthrough.

Ask Claude or Gemini for help, and you instantly become a “6” (out of 10) at almost anything. Going from zero to six feels incredible. You type something, software appears, and you think: "I'm a coder now. I can build an app." For non-technical CEOs and entrepreneurs, it's a real dopamine hit.

But for an engineer already operating at a 9, AI writes code they could have written themselves. Sometimes faster, often more convoluted. Useful, not revolutionary. That's why professionals use it as an assistant. Engineers don't mind writing code. Writing code is how they think.

Anyone can prompt "build me a CRM." Maintaining and scaling it is another matter. You stop saying "make the button blue" and start saying "this exact hex code, this spacing, this edge case." Once your English becomes that precise, you've reinvented programming, just in a worse language.

At Satellite, we treat AI like any productivity tool.

If a paid plan makes someone more efficient, we pay for it. We don't track prompts or force anyone to use AI. We measure engineers on output and thinking, nothing else.

Some engineers lean on AI heavily. Some less so. Both are fine. What's not fine is outsourcing your judgment. There's growing evidence that leaning too hard on AI erodes learning, because you're no longer the one solving the problem.

Throw AI at every problem without intention, and you don't get faster engineers. You get lazier ones.

That's the part worth forbidding.