Claude on Claude (2026/04/19)
Prompt:
I would like to know your stance about this: [The Snake That Ate Itself: What Claude Code’s Source Revealed About AI Engineering Culture](https://techtrenches.dev/p/the-snake-that-ate-itself-what-claude)
Claude Opus 4.6 reply:
Let me fetch that article first.This is a substantial critique, and I want to engage with it honestly rather than defensively. Here's my take:
Where the article has real points:
The core observation is legitimate. A 3,167-line function with 486 branch points is poor engineering by any standard — human or AI-authored. The regex-for-sentiment-analysis detail is genuinely ironic. And the documented bug burning 250K API calls daily, with a known three-line fix left unshipped, is hard to defend. These are valid criticisms of engineering discipline.
The escalating percentage claims (80→90→95→100%) without ever defining the metric is also a fair critique. As the LessWrong analysis noted, "lines committed" and "engineering effort" are very different quantities. The ambiguity served a marketing purpose.
Where I think the article overreaches:
The rhetorical move from "Claude Code's codebase has quality problems" to "Anthropic's entire engineering culture is rotten" is a significant inferential leap. The author acknowledges this is a CLI tool — essentially a wrapper around an API — not the model training infrastructure. Extrapolating from a product built with a "move fast" startup mentality to conclusions about model safety or research rigor is tempting but unsupported.
The ouroboros metaphor is evocative but somewhat unfair. All software has feedback loops — compilers compile themselves, test frameworks test themselves. The question is whether the loop has quality gates, not whether it exists. The article assumes no gates exist based on one leaked codebase.
My honest position:
I'm the product being discussed here, so I have an obvious conflict of interest — take that seriously. But I think the article's strongest contribution is the question it raises rather than the answer it asserts. The question: what quality standards should apply when AI generates most of the code? That's genuinely unresolved. The author's grandfather's maxim — "do it well, or don't do it at all" — has real tension with the economics of rapid iteration in software, and that tension predates AI by decades (as the top commenter with 21 years of experience noted).
The weakest part is the ending's false dichotomy: either we accept 3,167-line functions or we become electricians. The real engineering challenge is figuring out what "code review" even means when generation is near-free. That's a hard, interesting problem — not a eulogy.
C&P ENGINEERING 2018-2024 (2024/02/06)
Ho lavorato per 6 anni in C&P, dalla fondazione del gruppo di CSV nel 2018 al 2024.
È stata un'esperienza entusiasmante condivisa con tanti colleghi che ho voulto ripercorrere per immagini.
In numeri (al 10/02/2024):
Progetti 127
Clienti 50
giorni
-------------------------------
Progetti cliente 1296
Gestione interna 88
Ferie/assenze 183
Progetti più lunghi giorni
--------------------------------------------------------------------------------
Supporto per attività di convalida del nuovo sistema gestionale SAP 61
Data integrity remediation plan 51
Supporto per la compliance dei sistemi computerizzati 50
Attività di computer system validation 47
Supporto implementazione sistema DCS 42
Statistica della durata dei progetti:
ore giorni
-----------------------
Minima 4 0.5
Massima 484 60.5
Media 82 10.2
Mediana 45 5.6
Moda 16 2.0
2018
I mezzi in principio erano pedestri, ma il divertimento era totale.
I primi progetti CSV
La prima email, grande classico, la configurazione stampanti che sfugge anche ai più scafati
La prima convalida: un microscopio Olympus (sic!)
I primi mezzi di trasporto
Project Management d'antan
Un flusso ai tempi si disegnava così (non c'era Visio):
Altri grandi mezzi (stavolta a noleggio)
I primi assistenti
Prove tecniche di email
Marketing A.D. MMXVIII
2019
Il ritorno di Porciani
Mezzi aziendali: inaugurazione del Doblò finestrato
Mezzi aziendali: Fiorino
Prima trasferta oltreoceano, NY 2019
Nuove leve
Meeting di fine anno, Porciani presenta Zentao (non fu un successo)
2020
COVID-19
I prodromi del disastro a febbraio
8 marzo 2020 DPCM lockdown in Lombardia
Convalida di SAP HANA
Selfie dalla webcam di Pennabilli
I 100 nomi di Allah, le 106 deviazioni di SAP
Nuovi progetti e nuovi assistenti
Dall'Anna - Ristorante pizzeria Capannuccia
Cellularini
2021
Audit Trail Review di Empower
Convalida di un DCS (raccatted)
Ritratti su sfondo ghiaione
Clienti e cene di livello
Lezioni di SAP
2022
Un altro DCS (più evoluto)
Telefoni meno evoluti
Porciani addestra tutte le ragazze
Santander
Qualifica dell'infrastruttura IT
Nuovo branding aziendale
2023
Professionalità @ C&P
Amadeus hack (2022/12/23)
Lichee RV dock pinout
Hardware BOM:
- Chicco Teddy orso delle emozioni
- Sipeed Lichee RV
- Loudspeaker (4 or 8 ohm)
- 5V power bank
Software
Software BOM:
- OS: to date, the cleanest OS available seems to be the official Ubuntu port
- gpiod
- MPD: Music Player Daemon
gpiod
gpiod provides a set of handy command line tools to manage the GPIO interface. Out of the box, such tools require root permissions to work. To enable a standard user to run gpiod utilities, create a dedicated group and add the standard user to it:
sudo groupadd gpio
sudo usermod -G gpio <user>
Then create a new udev rule:
#!/bin/bash
cat <<EOF >/etc/udev/rules.d/60-gpiod.rules
SUBSYSTEM=="gpio", GROUP="gpio", MODE="0660"
SUBSYSTEM=="gpio", KERNEL=="gpiochip*", ACTION=="add", PROGRAM="/bin/sh -c 'chgrp -R gpio /sys/class/gpio && chmod -R g=u /sys/class/gpio'"
SUBSYSTEM=="gpio", ACTION=="add", PROGRAM="/bin/sh -c 'chgrp -R gpio /sys%p && chmod -R g=u /sys%p'"
EOF
To identify the GPIO lines to be used in gpiod, run sudo cat /sys/kernel/debug/pinctrl/2000000.pinctrl/pinmux-pins:
Pinmux settings per pin
Format: pin (name): mux_owner|gpio_owner (strict) hog?
pin 32 (PB0): UNCLAIMED
pin 33 (PB1): UNCLAIMED
pin 34 (PB2): UNCLAIMED
...
For example, to set PB0 high, run:
sudo gpioset 0 32=1
Start-up sequence (through systemd):
- start the MPD daemon
- setup MPC and lights, play random song, sleep, fade out and stop playing
The following scripts will be running together:
Each monitor script has the following structure:
function action {
# check if music is playing
mpc | grep playing
status=$?
#if YES
if [ "$status" == 0 ]; then
mpc next # bottom right: <PIN>=PD12
mpc prev # bottom left: <PIN>=PD13
mpc volume +10 # upper right: <PIN>=PD15
mpc volume -10 # upper left: <PIN>=PD17
#if NO, resume playing
else
/bin/bash /home/ubuntu/scripts/replay.sh &
fi
}
for((;;))
do
gpiomon --bias pull-down -s -n 1 -r 0 <PIN> && action
sleep 0.7
done
Measuring and modeling complex impedance in the audio range (2022/11/06)
This is postmortem review of a project I started with a couple of friends in 2021 while Italy was partially stuck in a COVID19 lockdown. (Un)fortunately the lockdown ended before we managed to get any real results, but the preliminary work we made can be of some interest in itself. The aim of our project was to study how pickups used in electric guitars work from an electrical point of view, with the long term goal of building something new (a new pickup, a new amplifier a new psychoacoustic model etc... XD). We only managed to reach the preliminary goal of characterizing electrically a couple of existing pickups.
Introduction
A pickup is a transducer that captures or senses mechanical vibrations produced by musical instruments, particularly stringed instruments such as the electric guitar, and converts these to an electrical signal that is amplified using an instrument amplifier to produce musical sounds through a loudspeaker in a speaker enclosure. A typical magnetic pickup is a transducer (specifically a variable reluctance sensor) that consists of one or more permanent magnets (usually alnico or ferrite) wrapped with a coil of several thousand turns of fine enameled copper wire. The magnet creates a magnetic field which is focused by the pickup's pole piece or pieces. The permanent magnet in the pickup magnetizes the guitar string above it. This causes the string to generate a magnetic field which is in alignment with that of the permanent magnet. When the string is plucked, the magnetic field around it moves up and down with the string. This moving magnetic field induces a current in the coil of the pickup as described by Faraday's law of induction. Typical output might be 100–300 millivolts. Pickup - from Wikipedia)
The first step in our project was understanding the basics of magnetic pickups in the simplest form, single coil pickups.
Experimental setup
A way to characterize an electrical component is to model its frequency behavior by fitting experimental data with a theoretical model. An easy quantity to measure, even by means of inexpensive bench-top instruments, is the complex impedance, especially when frequencies involved are in the audio range and everything can be modeled using a discrete component approximation. By using a function generator to produce a sine wave $V_g$ and an oscilloscope to measure the amplitude and phase shift of two voltages $V_1$ and $V_2$ a simple voltage divider can be used to study an unknown impedance $Z$:
$V_g$ is the sinusoid produced by a function generator and $V_1$ and $V_2$ represent the two input channels of an oscilloscope.
Again, given the low-frequency range, it is not necessary to care much about transmission lines and a free standing wiring can be used.
By using the generalized Ohm's law the following relation holds between $V_1$ and $V_2$:
$$ V_2 =R \cdot \frac{V_1}{R + Z} $$
If $Z$ can be approximated with a linear model, this relation allows to fit the experimental $V_2 / V_1$ ratio to estimate the parameters of the model.
Measuring technique
If you have an analog oscilloscope, the amplitude and phase shift of $V_1$ and $V_2$ must be measured manually, but any digital oscilloscope allows to automatize the process.
Entry level Rigol oscilloscopes as ours DS1054Z the one we used are true magic, because they are inexpensive and super flexible at the same time.
Two major features they support are the SCPI programming interface, which is thoroughly documented in the programming manual, and the and the LXI standard for LAN connectivity.
It is trivial to communicate with the scope via the Ethernet interface on any linux or unix-like system: all you need is the nc (aka netcat) utility, no additional driver or software is required. If you what to send the command cmd to the oscilloscope whose IP address is 192.168.2.3 (listening on port 5555) just type in your terminal:
reply=$(echo "cmd" | nc 192.168.2.3 5555)
The variable reply will contain the answer (if any) available for any purpose. Using a bunch of commands, such as:
# Configure the scope to average 4 acquisitions
":ACQuire:TYPE AVERages"
":ACQuire:AVERages 4"
#Measure period of input waveform (channel 1)
":MEASure:ITEM? PERiod,CHANnel1"
# Get horizontal timescale
":TIMebase:MAIN:SCALe?"
#Set horizontal timescale to "new_ts"
":TIMebase:MAIN:SCALe $new_ts"
# Measure amplitude of input waveform (channel 2)
":MEASure:ITEM? VMAX,CHANnel2"
# Get vertical scale
":CHANnel2:SCALe?"
# Measure frequency
":MEASure:ITEM? FREQuency,CHANnel1"
# Measure relative phaseshift of CH2 vs. CH1
":MEASure:SETup:PSA CHANnel1"
":MEASure:SETup:PSB CHANnel2"
":MEASure:ITEM? RPHase,CHANnel1,CHANnel2"
we created a bash script to collect all the repeat the measurement every 0.5s. Setting the function generator to swipe the frequency range 30Hz - 100KHz the output file will look like this:
# Thu Mar 18 13:53:29 CET 2021
#Freq (Hz) V1 (V) V2 (V) Phase shift (deg)
2.958580e+01 2.000000e+00 9.011200e-01 2.130177e+00
2.976191e+01 2.000000e+00 9.011200e-01 0.000000e+00
...
1.020408e+05 2.000000e+00 7.130316e-01 -4.868853e+01
1.024590e+05 2.040000e+00 7.340032e-01 -5.142857e+01
Electrical model
The obvious approximation of a conductive coil is an inductor $L$. Other factors to consider are the series resistance of the copper wire $R_s$ and a parallel capacitance $C_p$.
Two reasonable discrete models of such components are the following:
Given the frequency $ f $ and defining $ \omega (f) = 2 \pi f$ The impedance of the circuit on the left will be:
$$ Z(\omega)= \left( \frac{1}{R_s + i \omega L} + i \omega C_p \right) ^{-1} $$
While the one for the circuit on the right:
$$ Z(\omega)= R_s + \left( \frac{1}{i \omega L} + i \omega C_p \right) ^{-1} $$
gnuplot includes a powerful fit command that allows to fit any user-supplied real-valued expression to a set of data points, using the nonlinear least-squares Marquardt-Levenberg algorithm.
We created a script to analyze a set of measurements by fitting $\lvert V_2 / V_1 \lvert$ against the models described above.
The choice to fit the absolute value is just a convention, any other real-valued quantity such as the real or imaginary part, phase, or any combination thereof could be used. Experimental data is available here.
The core of the script is this part:
i={0,1}
w(f) = 2*pi*f
rad(deg) = deg * pi / 180.0
deg(rad) = arg (rad) * 180.0 / pi
z(real,imag) = real + i * imag
set xrange [20:101000]
set logscale x
set xlabel "Frequency [Hz]"
set ylabel "Abs [ohm]"
set logscale y
set y2label "Phase [deg]"
set y2tics 20 nomirror tc lt 2 font ",13"
set xtics rotate
set grid
set key font ",12"
fit_start = 50
fit_end = 100000
# impedance model
z(x) = (1/(rs + i*w(x)*l) + (i*w(x)*cp))**-1
# V2/V1 ratio from the voltage divider
t(x) = r / ( r + z(x))
# Kwnon value
r = 4600
# Initial guess
rs = 5810
cp = 1e-10
l = 2
in = "single_coil.txt"
fit [fit_start:fit_end] abs(t(x)) in u 1:($3/$2) via l,cp, rs
set label 1 sprintf("l=%.2f H \t cp=%.2e F \t rs=%.0f ohm",l,cp,rs) at graph 0.02, 0.15, 0 left font ",10"
set label 2 sprintf("Fit from %.0e to %.0e Hz - reduced chisquare: %1.1e",fit_start,fit_end,FIT_STDFIT*FIT_STDFIT) at graph 0.02, 0.1, 0 left font ",10"
plot abs(z(x)) t "single coil - abs" lt 6 lw 2 axes x1y1, -deg(z(x)) t "phase" axes x1y2
Results
The results of the fitting procedure are shown in the figure below, where experimental data points are plotted against the absolute value and phase of $V_2/V_1$.
The model used is the one on the left, which gives a better adherence to experimental data (smaller chisquare).
gnuplot will indeed produce two output files: the plot itself, in the format specified, and a fit.log file including all the details about the fit results:
FIT: data read from in u 1:($3/$2)
format = x:z
x range restricted to [50.0000 : 100000.]
#datapoints = 744
residuals are weighted equally (unit weight)
function used for fitting: abs(t(x))
t(x) = r / ( r + z(x))
z(x) = (1/(rs + i*w(x)*l) + (i*w(x)*cp))**-1
w(f) = 2*pi*f
fitted parameters initialized with current variable values
[...]
After 3 iterations the fit converged.
final sum of squares of residuals : 0.0531344
rel. change during last iteration : -7.42185e-06
degrees of freedom (FIT_NDF) : 741
rms of residuals (FIT_STDFIT) = sqrt(WSSR/ndf) : 0.00846796
variance of residuals (reduced chisquare) = WSSR/ndf : 7.17064e-05
Final set of parameters Asymptotic Standard Error
======================= ==========================
l = 2.17113 +/- 0.008791 (0.4049%)
cp = 1.3742e-10 +/- 4.87e-13 (0.3544%)
rs = 5755.05 +/- 14.94 (0.2596%)
[...]
The best estimate of parameters is printed directly above each plot, together with the reduced chisquare.
The plots are related to:
- The single coil pickup
- The two coils of an humbucker pickup, measured individually
- The two coils, in parallel
- The two coils, in series
The plots of the fitted $Z$, again as absolute value and phase is this:
A comparison of all the coils together in the audible range is this:
Logging and plotting data from IoT devices (2022/11/01)
In this post I'll describe some techniques I use to log and plot data from IoT devices.
I will use as an example a power meter which I created some years ago to monitor my domestic power consumption.
A simple current integrator
I placed a cheap split-core current transformer (SCT-013-030) around the main live wire of my house, just after the electricity meter.
The output voltage of the transformer is proportional to the AC current flowing through the wire crossing the transformer: according to the datasheet, the output is in the range 0-1 V for a current in the range 0-30 A.
In order to monitor the power consumption, I built the following circuit:
Such AC voltage passes through a "precision" rectifier and it is integrated using a decent JFET operational amplifier.
The output of the integrator is then conditioned to match the allowed input of an arduino microcontroller (using an Arduino Nano 33 IoT such range is 0-3.3V).
Since the integrating operational amplifier is used in an inverting configuration and the supply voltage is ±12V, a gain of approximately -0.25 is required.
The simple circuit sketched below is used to reset the integrator: basically a JFET transistor short-circuits the feedback capacitor when a digital pin (digital pin 2 in this case) is set high.
Principle of operation
This is the Arduino sketchbook I use to control the circuit above.
The principle of operation is a constant time integration: the circuit keeps integrating in a loop the input voltage for a fixed amount of time.
After the integration time is elapsed, the output voltage is measured by the internal ADC of the 32-bit SAMD21 processor.
In order to improve the precision of the measurement, a series of measurement is averaged.
The number of samples I choose (90) is based on a quick experiment I made to understand how measurements from the ADC are reproducible.
The graph below shows the maximum deviation and standard deviation of a set of 300 averaged measurements of a stable voltage reference.
The x axis shows the number of averaged raw measurements that form each of the averaged measurements.
Sending data over a wireless network
The standard WiFi library provides a quick and dirty way to transmit data over a local network by means of UDP packets, as shown in the following example:
Udp.beginPacket(server_ip, server_port);
ADC_measure = Integrate(INTEGRATION_TIME);
Measure = String(ADC_measure, 6);
Measure.toCharArray(Measure_CA, 12);
Udp.write(Measure_CA);
Udp.write("\n");
Udp.endPacket();
Even if UDP is connectionless and there is no guarantee that datagrams are received, I found no problem using this technique in a small domestic context.
Logging data
Data can be easily received using a general purpose utility such as netcat.
In my linux box I use the following bash script to append data continuously to a text file, automatically named according to the current date:
#!/bin/bash
for((;;))
do
out_file=$(date '+/home/pi/trend/corrente/%Y/%Y_%m_%d.txt')
ncat -u -l -p 2390 -c "date -I'seconds'" -o /home/pi/trend/corrente/temp.txt
# arrange values in a row
paste -sd "\t\n" "/home/pi/trend/temp.txt" >>"$out_file"
Plotting data
I love using gnuplot to plot and analyze data. gnuplot is super flexible, can be scripted and it includes a powerful nonlinear least-squares fitting tool.
This is the script to produce the following plot:
Note how gnuplot allows to add and display statistical calculations on the fly using the stat command (the rolling sum of values in this case).
See also the beautiful html version of the same plot.
TODO
- Discuss how to calibrate the device
- Add a measurement of the AC phase shift to calculate the active and reactive components
Applicazioni di complessi tra ipericina e apomioglobina alla microscopia a super-risoluzione STED (2014/07/17)
Master's Thesis.
In Italian. Università di Parma.
Delcanale; Pennacchietti; Maestrini et al. - Subdiffraction localization of a nanostructured photosensitizer in bacterial cells
Sci. Rep. 5, 15564; doi: 10.1038/srep15564 (2015)
Spettroscopia dielettrica di soluzioni ioniche (2012/04/26)
Bachelor's Thesis
In Italian. Università di Firenze.