DEV Community: Luiz Fernando Puri

Code Agents: Como aumentar a produtividade sem se tornar dependente

Luiz Fernando Puri — Thu, 12 Feb 2026 17:00:04 +0000

Há alguns meses, comecei a usar Code Agents para acelerar meu fluxo de desenvolvimento.

Codex, Claude Code, Gemini CLI, Copilot

De primeiro momento, assim como muitos Devs, eu tinha um pouco de medo. Uma tecnologia nova que me fazia ter medo de ser substituído.

Depois fiquei impressionado com o aumento de produtividade que comecei a ter. Tarefas que talvez levariam semanas, resolvidas em poucos dias.

Também senti um alívio ao perceber que no fim das contas, ainda era eu quem tornava o desenvolvimento possível.

Mesmo com prompts bem estruturados, eu precisava pensar na engenharia, revisar decisões e corrigir erros ou alucinações.

Porém em determinado momento percebi que me acostumei com o uso dessas ferramentas, surgiu um novo medo, o medo de esquecer as bases e ficar dependente.

De perder a capacidade de conseguir fazer sozinho, já que a IA fazia boa parte do trabalho bruto.

Caso eu precisasse fazer algum desafio técnico, e criar um sistema do zero sem uso de code agent nenhum, eu teria mais dificuldades?

Provavelmente sim. Assim como quando voltamos de férias e nos sentimos um pouco enferrujados no desenvolvimento, a prática constante faz diferença.

Foi então que comecei a pensar em formas mais saudáveis de usar essas ferramentas: manter a produtividade sem perder a base técnica — e, melhor ainda, usá-las como aliadas no aprendizado.

O que Code Agents fazem muito bem

Criar testes automatizados
Refatorar código repetitivo
Sugerir melhorias
Prototipar ideias rapidamente

É absurdo a velocidade que conseguimos criar testes, refatorar e desenvolver.

O problema começa quando ela deixa de ser a ferramenta e tratamos ele como nosso substituto cognitivo, esperando que ele resolva rápido e sozinho, o trabalho que é nosso.

O risco invisível: atrofia técnica e comodismo

A dependência não acontece de forma brusca.

Ela é silenciosa.

Você começa a:

Pedir soluções prontas antes de ter pensado em como solucionar
Deixar a IA decidir arquitetura
Não consultar mais a documentação
Confiar em abordagens sem entender 100% do que foi feito, só porque funciona

Nosso cérebro economiza energia sempre que pode.

Se a gente parar de exercitar raciocínio técnico, ele enfraquece.

Um ponto importante

É importante lembrar que somos profissionais utilizando uma ferramenta, e não alguém que transfere para a ferramenta a responsabilidade do próprio trabalho

Estratégias práticas para usar sem ficar dependente e ser mais assertivo

1. Analisar sua solução

Antes de pedir solução para a IA, defina:

Qual é o problema que quer solucionar
Quais são as abordagens você utilizaria
Quais as suas dúvidas a respeito dessa implementação, e quais as possíveis respostas pra essas dúvidas

Depois use a IA para comparar, melhorar ou revisar.

Isso mantém o raciocínio ativo.

2. Peça explicações técnicas

Não peça apenas código.

Peça:

Por que essa abordagem?
Qual a complexidade?
Existe alternativa mais performática e porque?
Quais são os riscos dessa implementação?

Utilize o agente em mentor, não executor. Questione e aproveite para aprender

3. Trabalhe em blocos pequenos

Prompts grandes demais aumentam:

Alucinação
Código inconsistente
Erros arquiteturais

Dividir em partes mantém controle e entendimento.

4. Testes

Além de gerar testes automatizados, podemos pedir sugestões de quais testes adicionar e como testar cada etapa que estamos desenvolvendo

5. Não abandone a documentação

Code Agents são ótimos para resumir docs.

Mas é valido questionar de onde vem aquela informação e consultar a documentação original. Code agents podem ser excelentes professores, mas é sempre importante continuar validando as informações na documentação

Dominar a documentação nos trás mais certeza e confiança

A mentalidade correta

Code Agents não substituem desenvolvedores.

São uma arma poderosa, mas não vão vencer as batalhas por nós.

Eles podem ajudar a aumentar nosso nível técnico.

O segredo está na maturidade de como usamos. Produtividade sem consciência vira dependência.

SQL e Ruby: Explorando Banco de Dados Além do Rails ActiveRecord

Luiz Fernando Puri — Wed, 06 Nov 2024 17:29:06 +0000

Na carreira como Desenvolvedor de Software, o conhecimento de SQL (Structured Query Language) é uma habilidade importante. Estando presente no nosso dia a dia de trabalho ou sendo necessária apenas em momentos esporádicos, é um conhecimento que vez ou outra vamos utilizar. Para nós, profissionais da área, é melhor saber do que não saber. Entender SQL pode nos trazer novas possibilidades, nos permitir ter um controle maior sobre as operações de dados e nos trazer mais oportunidades profissionais.

Embora o Rails facilite o nosso trabalho, simplificando a interação com o banco de dados por meio do ActiveRecord, é comum ficarmos dependentes dessa conveniência oferecida. Acredito que isso ocorra com o uso de outros ORMs, e não é nossa culpa. Muitas vezes trabalhamos em ambientes dinâmicos, de muitas entregas, e em nosso tempo de estudo focamos em aprender novas tecnologias. Dessa forma, podemos esquecer de praticar conhecimentos que já estudamos na faculdade ou no início dos nossos estudos de programação. E por ser um conhecimento que não está sendo utilizado com frequência podemos acabar esquecendo. Assim como um músculo que atrofia se deixar de fazer exercícios, essas habilidades também podem atrofiar.

Neste artigo vamos explorar como fazer queries SQL puro no Rails, a utilização de Banco de Dados no Ruby sem ActiveRecord, e dicas para praticar o conhecimento de SQL

Como e quando fazer queries SQL puro no Rails?

Apesar do ActiveRecord cuidar da maior parte das nossas interações com o banco de dados, há certos momentos que escrever consultas diretas em SQL se torna mais interessante. Por exemplo, em casos onde exista a necessidade de realizar consultas complexas que envolvam joins entre várias tabelas, agregações e subconsultas, é possível que o ActiveRecord seja mais difícil de usar, apresente limitações e tenha menor desempenho. Isso é algo que acontece no uso de ORMs, em situações específicas pode ser mais trabalhoso entender como a ORM realiza determinada consulta, do que escrever diretamente em SQL. Desempenho, Complexidade e Limitações são pontos importantes, que podem tornar necessário o uso das queries feitas diretamente no banco de dados.

Para executar instruções SQL no rails podemos utilizar o método ActiveRecord::Base.connection.execute().

sql = "SELECT * FROM users WHERE age > 18"
result = ActiveRecord::Base.connection.execute(sql)

# Caso nossa query tenha um retorno, ele será um objeto, de tipo result do banco de dados em uso, que poderá ser iterado

result.each do |row| 
  puts "User ID: #{row['id']}, Name: #{row['name']}, Age: #{row['age']}"
end

Um detalhe importante: Da versão do Rails 7.2 em diante, o ActiveRecord::Base.connection foi descontinuado. Nessas versões recentes ele foi substituído por ActiveRecord::Base.lease_connection.

Utilizando Banco de Dados no Ruby sem ActiveRecord

Em aplicações Ruby com Sinatra é possível também utilizar a Gem do ActiveRecord para fazer esse papel de interação com o banco de dados. Mas e se quisermos fazer essa conexão sem o uso do ActiveRecord e ORMs?

Para mostrar um exemplo de conexão e interação com o banco de dados fiz um script Ruby puro utilizando a Gem pg. Essa gem faz a comunicação entre Ruby e o SGBD PostgreSQL. O script de exemplo pode ser acessado no repositório do GitHub

Esse Script é composto de alguns métodos, e o bloco que o executa é este:

begin
  start_database

  conn = connect_to_database

  create_pets_table(conn)
  populate_pets_table(conn)
  show_pets(conn)

rescue PG::Error => e
  puts "Erro: #{e.message}"
ensure
  conn.close if conn
end

O primeiro método chamado é o start_database. Esse método faz uma validação para saber se o container postgres já existe. Caso não exista, ele executa um comando para criar um container docker da imagem postgres com o nome do banco de dados training_db, usuário trainer e senha secret, e mapeia a porta do container para a porta 5433 . Se existir ele apenas sobe o container:

def start_database
  puts 'Iniciando container de banco de dados'
  if container_exists?
    system('docker start postgres_training')
  else
    system("docker run --name postgres_training -e POSTGRES_USER=trainer -e POSTGRES_PASSWORD=secret -e POSTGRES_DB=training_db -p 5433:5432 -d postgres")
  end 
  sleep (7)
end

Após isso é chamado o método connect_to_database para criar a conexão com o banco de dados. O método contém o seguinte código:

def connect_to_database
  # Alias para  PG::Connection.new e PG::Connection.open
  PG.connect(
    dbname: 'training_db',
    user: 'trainer',
    password: 'secret',
    host: 'localhost',
    port: 5433
  )
end

Podemos nos conectar a um banco de dados usando o método PG.connect, que seria o mesmo que usar PG::Connection.new ou PG::Connection.open. Nele passamos os argumentos do banco de dados. Nesse nosso exemplo passamos as informações definidas no nosso container postgres do docker e a porta que foi mapeada. Por padrão a porta do postgres é 5432.

Em seguida armazenamos essa conexão feita em connect_to_database na variável conn para utilizar essa conexão em outros métodos. Depois é chamado o método create_pets_table(conn). Nele utilizamos o método .exec, para executar nossas instruções SQL:

def create_pets_table(conn)
  conn.exec("CREATE TABLE IF NOT EXISTS pets (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100),
    species VARCHAR(100),
    age INT
  );")
  puts 'Tabela de pets criada!'
end

Esse método .exec é responsaǘel por fazer queries SQL. Em caso de sucesso retorna um objeto PG::Result com os resultados da query, e em caso de falha retorna um PG::Error.

Na gem PG também temos o método .exec_params, muito útil se precisamos fazer uma consulta usando parâmetros. Podemos ver seu uso seguindo o script de exemplo, quando chamamos populate_pets_table(conn), que contém o seguinte código:

def populate_pets_table(conn)
  pets = [['ScoobyDoo', 'Dog', 5], ['Pikachu', 'Pokemon', 3], ['Noturno', 'Cat', 6], ['Tanguá', 'Monkey', 7]]

  pets.each do |pet|
    conn.exec_params("INSERT INTO pets (name, species, age) VALUES ($1, $2, $3);", pet)
  end
  puts 'Dados inseridos na tabela de pets!'
end

Nesse método tentei fazer uma ideia de seeds para popular a tabela pets. No trecho conn.exec_params("INSERT INTO pets (name, species, age) VALUES ($1, $2, $3);", pet), o exec_params faz uma query para inserir dados na tabela pets: nos campos name, species e age serão inseridos os valores $1, $2 e $3.

Esses valores que vão ser inseridos devem ser informados em um array, que nos caso é a variável pet. Nesse bloco que está sendo iterado será executado primeiro conn.exec_params("INSERT INTO pets (name, species, age) VALUES ($1, $2, $3);", ['ScoobyDoo', 'Dog', 5]), depois conn.exec_params("INSERT INTO pets (name, species, age) VALUES ($1, $2, $3);", ['Pikachu', 'Pokemon', 3]) e assim por diante.

Seguindo o código do script, é chamado o método show_pets(conn) que usa o método exec para fazer uma querie buscando tudo na tabela pets e armazenando em uma variável que será iterada depois para printar os registros: result = conn.exec("SELECT * FROM pets").

No fim do script temos um rescue que utiliza o PG::Error para fazer a tratativa de erros que possam ocorrer na nossa conexão e interação com o banco de dados. E o ensure para garantir que a conexão será encerrada mesmo que ocorra algum erro.


rescue PG::Error => e
  puts "Erro: #{e.message}"
ensure
  conn.close if conn
end

Encerrar a conexão é uma boa prática, pois garante a liberação de recursos do sistema, evita problemas de desempenho e vazamento de informação.

Dicas para praticar SQL

Existem sites que podemos praticar, como SQL Teaching, SQLZoo e W3Schools. Também jogos como o SQL Murder Mystery. Além disso podemos baixar o MySQL Workbench ou pgAdmin, que são ferramentas gráficas onde podemos explorar os comandos SQL, de forma mais intuitiva e visual.

No mesmo repositório desse script utilizado como exemplo, tem outro arquivo, learning_sql.rb, onde fiz um script interativo com uma interface que permite o usuário executar consultas SQL e aprender a fazer queries de forma prática.

Sei que podemos acabar esquecendo os conhecimentos se não colocarmos em prática, e no caso do desenvolvimento no Rails pode ser comum esquecermos o conhecimento SQL, já que ele faz as queries por nós. Fiz esse artigo com o intuito de trazer um compilado de informações que podem ajudar outros Devs que eventualmente enfrentarão esse problema.

Agradeço seu tempo e sua leitura! E vamos por a mão ~~na massa~~ no código!

Entendendo Active Record, a Gem do Rails e o Design Pattern

Luiz Fernando Puri — Wed, 23 Oct 2024 20:09:33 +0000

Rails é um dos frameworks mais populares em aplicações web, não apenas pela sua capacidade de acelerar o desenvolvimento, mas também por seus componentes robustos, como o Active Record, que transforma a maneira como interagimos com bancos de dados. Um dos motivos de sua popularização foi a produtividade que o Rails trouxe, permitindo o desenvolvimento mais rápido de aplicações utilizando menos código.

A Gem Active Record

O Rails nos fornece uma classe base, ActiveRecord::Base, que nos permite associar classes (models) às tabelas do banco de dados. É através dessa associação e atuação da gem que conseguimos manipular os dados a partir do objeto. Isso torna possível o uso que estamos acostumados, de atualizar informações no banco de dados através dos objetos, em vez de escrever queries SQL.

Por exemplo, usamos:

User.where(age: 26, favorite_color: 'blue', country_id: 55)

Em vez de:

SELECT * FROM users WHERE age = 26 AND favorite_color = ‘blue’ AND country_id = 55;

Porém o Active Record não é apenas uma gem do Rails. Active Record é um Design Pattern. Um padrão que lida com a camada de persistência dos dados.

O Active Record Pattern

Esse padrão foi proposto por Martin Fowler no livro "Patterns of Enterprise Application". Em seu site podemos encontrar essa explicação sobre o padrão:

“Um objeto que encapsula uma linha em uma tabela ou exibição de banco de dados, encapsula o acesso ao banco de dados e adiciona lógica de domínio a esses dados.”

Active Record é um padrão de Mapeamento Objeto-Relacional (ORM). Com a popularização das linguagens do paradigma Orientado a Objetos percebeu-se que era gasto muito tempo desenvolvendo queries SQL. A partir disso, nos anos 90 surge o conceito de ORM, essa técnica/abordagem para resolver esse problema.

No padrão Active Record cada model é associado a uma tabela e cada instância (objeto) dessa classe é equivalente a uma linha dessa tabela. Esse objeto é responsável por suas próprias operações de persistência, além de manipular seus próprios dados (diferente do padrão Data Mapper, onde a lógica de persistência é feita por outro objeto próprio pra isso)

Principais atuações da Gem Active Record no Rails

Convenção sobre configuração: Por convenção, o models herdam de ApplicationRecord que herda da classe ActiveRecord::Base. Dessa forma o mapeamento é automatizado entre classes e tabelas, atributos e colunas. Caso tenhamos um model chamado ‘BookClub’ o ActiveRecord irá associar esse modelo à uma tabela com o nome ‘book_clubs’. Enquanto o model segue o padrão de nomenclatura CapitalCase, a tabela segue o padrão snake_case no plural.

Associações entre objetos: Podemos definir associações entres os objetos de forma simples através de métodos de classe como:

has_many, has_one, belongs_to, has_and_belongs_to_many

Regras de validação: Disponibiliza métodos que nos permite adicionar validações de forma simples:

acceptance, confirmation, comparison, format, inclusion, numericality, presence, uniqueness # E outros

E também definir condições para essas validações ou adicionar validações customizadas através dos métodos:

if, unless e validate

Callbacks: Disponibiliza métodos de retorno de chamada para todo o ciclo de vida (instanciação, salvamento, destruição, validação, etc.):

before_validation, before_save, before_create,  after_create, after_save, before_update, after_update, before_destroy etc

Isso nos permite adicionar código para um comportamento desejado, em um momento específico do ciclo de vida do objeto (Porém use com moderação, usar callbacks em excesso pode te trazer dor de cabeça depois)

Transactions:
Que são blocos de proteção, onde as instruções SQL só são aplicadas se todas elas puderem ser concluídas com sucesso. O exemplo mais conhecido talvez seja o de uma transação financeira

Account.transaction do
  david.withdrawal(100)
  mary.deposit(100)
end

Abstração de banco de dados por meio de adaptadores simples:

A Gem Active Record já tem um suporte integrado para MySQL, PostgreSQL e SQLite3 através de adaptadores. É possível usar outros bancos como Oracle, SQLServer etc mas talvez seja necessário o uso de gems

Caso tenha interesse em saber mais sobre o ActiveRecord, pode encontrar informações interessantes na documentação da gem no github

Este está sendo o primeiro artigo que estou escrevendo. Agredeço pelo tempo que tirou para ler!